HubSpot Community Developer Show | When a Marketer meets a Developer | S01E05

Who can hear me?

I can hear you.

Me.

Okay, Tim, is this two way?

Wait. Okay, now I can hear you.

Okay, you can hear me.

Can you hear you?

I can hear you.

Yeah, you can't hear me now?

I can hear you. Oh my God. This is all going in. This is it right here. Hey everybody. Welcome to the HubSpot Community Developer Show. I am Dennis, your host and I am joined here with Steven some very special folks. We've got Phil Valander, who is the humbly put on his website the sales and marketing director at Blend, but he is also the co founder. How you doing sir?

Very good, thanks. Very good.

I also have Tim Joyce who is co founder of Echo Punch and has quite a history of other projects. How are you doing, Tim?

I am great, thank you Dennis.

No worries. Also from the HubSpot side we have Alexander Gerard, or Alex as we like to call him. How are you doing?

I'm doing well man.

How are you?

I am doing well. I forgot to tell that you are actually a product marketer at HubSpot. So I'd be a little more precise with your job. Aj. You know him? He's been around for a while. If you don't know him then well you need to get on the developer slack and start talking to him. He is a senior CMS developer advocate. How are you doing sir?

I'm doing good, doing good.

How are you?

How are you? Dennis? How are you?

You know what, I was hoping someone had asked and thank you. I'm doing very well, thank you. Today we are going to be talking all about the marketer which is Phil and Alex over there, versus the developer which is Tim and aj. I don't think anyone's going to be hurt in this. So if we all make it out of this zoom call, I think we'll be fine. But before that I have an unrelated question I was hoping you guys would help me out with. This just happened to me before we started. I was looking at my browser. I try to close everything out before I start these things. You know, just for consumption of energy, memory, etc. I had like 3500 tabs that are all important. And how do you guys, what do you guys do? Seriously, like for tab management, like things you want to go back to. I. I've fallen into this terrible habit of just making a folder and a date saying review me. What do you guys do?

So Google's tab manager in Chrome is the best thing they've released since search itself. It's instrumental in how I organize my tabs I need it there to have a group of tabs by project. I can minimize them and then it's just a. A small little dot on my browser instead of taking up the whole thing.

Here's the problem, Alex. I do not use Chrome. I use Firefox, which is the superior Browser.

How is 2012 treating you?

Moving right along.

I have a solution for you, Dennis. Yeah, as you probably expected, I wrote a desktop app for the Windows and Mac that manages my bookmarks for me.

No joke.

Yeah, it's called Bookstack. I'll send you a copy.

Please do.

Yeah, Tim, all over, just writing an app to solve a problem.

I have a different approach.

I have a slightly different approach to the problem. Tim, your 10's over. Get.

Okay, cool.

We'll come back to you. Tim, I have a slightly different approach. I've got one button. It works well. There's a problem. I hit X. Start fresh, start over. That's the only way I can cope.

You are so brave. I want to do that, but I'm like, no, I need every tab. I need every tab. And then started doing the Google group tabs, and now I have just as many groups as I had. That's just the first time.

That's a new problem to solve an old problem.

Phil, your technique's the equivalent of me just walking out my window of the second floor of my house and just saying, I'm done.

No. If you really need it, you'll find it again. I do the same thing with my emails. My inbox gets too full, I delete them all, and if they come back, it was important.

So that's why I never hear from you anymore.

Do the same thing with my bills. All right.

When the lights go out. Yeah, exactly.

A few announcements on the HubSpot side. I thought we should highlight CRM objects. Dynamic Pages is going to be a thing soon. It's in beta presently, and by the time this episode comes out, it should be. Should have dropped. And you can officially use that. It's pretty cool. It's kind of like Hub, DB Dynamic Pages, but for CRM objects. So is it. Is it all objects? Do you guys kind of. You speak to that? Yeah, yeah.

Any object in the CRM, whether it's a custom object or a standard HubSpot object like contact or Company.

That's really cool. Something that I think exclusively AJ is excited about is the site. Tree View is back. Maybe. Phil, you're also excited about this. I think it's a really useful view.

But it's something I'VE seen a lot of people ask for, especially on community, so I'm pleased for them.

And lastly. Oh, go ahead, A.J. please.

Oh, no, no, I was going to say, I know a while back it used to be in the HubSpot system and then it was taken away. And anybody who's been on the developer Slack knows that I lit up the developer Slack like crazy prior to coming to HubSpot as that was one of the features that I just absolutely loved and adored. So to see it finally back in action just makes me extremely happy.

Good stuff.

The last one I have here is Media Bridge is now live and to be quite honest, I knew nothing about this prior to yesterday when Alex told me about it. I did a little research and it's actually pretty freaking cool. So from the developer side, I guess you get a module you got to put in and this will connect seamlessly with any type of video provider, right?

Video, podcast, any kind of media app that you're using. Yeah, you can connect it directly into HubSpot.

And then from more on the marketing side, I mean, you get analytics on it so you can see how long someone's been watching or listening to. You can build workflows from it.

Yeah, I think the workflows is still in the works, but you'll be able to do list segmentation and you'll be able to create customer reports off of how people are viewing your media. So you can start to really harness the power of embedded media within HubSpot, which is really exciting.

Cool. Is there any external documentation on this? Because I couldn't. That's the one thing I could not find is the docs and I blame AJ for this. I think this is where you need to start doing a better job.

So if you, if you look inside of the developer documentation, specifically the embed field, I want to say inside of the module field types, you will see some references to Media Bridge inside of there. We are adding more as. As it goes along and as you know, it gets closer to launch, we will definitely be promoting it a lot more on the docs, but we have been dripping in content into the docs as functionality comes along to make sure developers are prepared.

It's really cool. I'm excited about it. And now let's talk about when a marketer met a developer. I actually didn't get a lot of responses on the community about this. I think that I might have posed the question incorrectly and it's actually kind of an incomplete question or it's an incomplete story because as I was Thinking about this, we're missing a component which is the designer. So at the end of this, I think we can all agree that we can just curse designers. So instead of the developer cursing the marketer and the market cursing the developer designers, it's the problem. Phil, I think you've been in this the longest. I'm not sure. Is that how long you've been working just as a marketer?

Well, so that's probably. That's a quite a question I don't get asked too often. So 10 years at Blender, plus five years of my career before that in product marketing roles. So I guess that's 15 years all told, a little bit before that, but not, not, not really focused on it. So, yeah, let's call it 15 years.

And how would you say the evolution of just your appreciation, understanding, just. Yeah, the evolution of becoming of a marketer. And how's that changed over the 15 years?

Well, the world for marketers has changed beyond all recognition in those 15 years. The channels, the tactics, the tools, the mediums, they're totally different. The purpose is still the same. Our goals remain broadly the same. Just how you achieve them is not at all the same. For me, it's been an incremental journey. Nothing is guaranteed in marketing. That's another thing I've learned that there is. You cannot take a tactic or a strategy that's used by others and know for certain it's going to have the same effect for you. So every day is a school day. Learning is always incremental and gradual. And over the 15 years that I've been working in marketing, I've never stopped learning at any point along the journey. And I will keep learning as we go because the change is going to carry on cool.

Conversely, from the developer side, Tim, how long have you been working.

Yeah. On the development side in HubSpot, five years grand total. Being a developer, around nine years.

And same question to you, how's the evolution of development been for you?

Oh, God. I was just thinking this the other day. Just some, some things in PHP that I was doing that you no longer have to do because everything's come so far. But I think, I think the whole JavaScript ecosystem has really taken over everything. So if you're today not writing apps in JavaScript instead of just hacking together some jQuery, you're kind of left in the dust. So it's been fun to learn that stuff and have some more powerful tools at our hands. But on the same token, you have to learn powerful tools.

Right? Right, right, exactly. I mean, the cost of entry is a lot higher at this point, I believe, than it was. Alex, you are just a marketer. I mean, this is what you do. You've been doing it. How long you been working in that field?

Five years.

And same question to you. I'm going around here and asking everybody, has it changed? How's your evolution been on this?

I mean, the field of marketing, of course has changed because the market has changed, broadly speaking. Um, I think when I'm thinking about marketing, there's one just so many different roles that a marketer can play. Like I'm a product marketer, so I'm focused on positioning competitive intel, you know, creating narratives that help buyers buy and sell or sell. But you know, within the broad umbrella of marketers, there's, you know, SEOs, there's web strategists, there's, you know, conversational marketers and people that focus on chat, specifically social marketers. There's so many different facets of this and they all kind of go in and out of vogue, I feel like at one point or another. But I think something that always keeps me on my toes is just like understanding, you know, my audience product that I'm trying to sell and then like the competitive, the market in general, I feel like that like kind of triangulation of those three things always changing based off of, you know, market demand, competitors and what your audience wants for you.

So it's always changing.

Yeah, definitely. Lastly, AJ and I saved you for last because I think you kind of sit or when you're in the agency life, you kind of sat in a unique role of kind of that, the marriage between marketing and development. You were kind of, you guys see both sides of it. You were in the marketing department as a developer, Correct?

Correct. Correct. Oh, go ahead.

No, no, no, just you go, you go, friend.

Yeah. So back at the agency I was at, I, as you mentioned, like the hybrid, I was a developer and I was working on HubSpot development. But my position, my location in the company was within the marketing department because at the time. Marketing department, HubSpot. HubSpot was marketing. The CMS was relatively new at that point. So I did a lot of the HubSpot development stuff. But then I was also involved in a lot of the marketing things such as like generating campaigns, a lot of like SEO related stuff. So SEO reporting for clients, things like that. So it, it's been interesting because in my career itself, if you were to say, like, how long have you been a developer? I've been a developer Just as long as I've probably been a marketer, maybe a couple more years as a marketer. So I kind of started at a school supply kit company, getting into the IT department and just doing some like, web stuff minor there and then doing some marketing campaigns and helping out in that and helping build up that marketing. And I've kind of since then taken that hybrid approach as I've gone along. And for me, it's helped because as the topic of this entire podcast, you know, marketers and developers working hand in hand, it's helped me to understand where that breakdown is between the two. And then when working, when working with a marketing department or working with other developers, I'm able to, I don't want to say talk out of both sides of your mouth because that's a bad way to put it, but be able to translate that verbiage and act as a translator between the two. So when one doesn't understand what these developer terms mean, I can break it down from a marketing standpoint to help understand that and vice versa.

Yeah, that's. That's a really good point. So, I mean, a theme I've had through all these podcasts so far is communication. Right. It just seems like that is like the basis of all that's. That's it, right? We could probably just stop the podcast right here and call it a day. Communication wins. I think just a narrower scope a little bit. Let's just talk more about HubSpot development. Phil, the CMS is very relatively new, right? I'm assuming you before CMS is, you know, all marketing CRM type things with a very kind of light hand on the website experience. How is your. How has that changed for you? As you know, there's more power behind the CMS now. You can do many more things. How do you. How are you leveraging that and how are you bringing the developer in to discuss that? I mean, to what extent? I want to say a lot of words. I'm sorry, to what extent. To what extent is the developer influencing how you as a marketer are working? Answer any of those questions in any order. I actually don't remember about seven of them, so run with that.

Okay, well, I'll start by saying that the CMS and its development has been a fantastic boon for Blend. We started working on it when it was an add on, when it first started to surface, because we saw the potential that single customer view and single customer experience offered our customers. So we were quite quick to ditch other CMSs and specialize on this one. And so we've grown and our development resource and the work we've done with Tim, you know, has been very symbiotic with that. We've learned as we've gone, we've pushed the boundaries a little bit each time and we've really made it central to our offering. So CMS Hub is critical to us because we want to be able to build a user experience that leverages inbound to create pipeline and demand. And so we're really focused on building really high performance websites, fast, good core web vitals, good user experience and great looking sites that just produce that demand and tap into all the power that HubSpot offers as a marketing platform. And then we're building in, increasingly building in functionality that leverages hubdb, custom objects, the CRM and so on to take that further and further. And so watching HubSpot come into this market, develop the CMS, which is really, really awesome package of technology, is just something that's helping us deliver a better and better service to our clients and get them better and better results. But it would seem that we're only at the beginning of what HubSpot is going to do with the CMS Hub and what the power is going to be. So we're just watching closely, learning quickly and applying it as soon as we get a chance.

How deeply looking approach? Yeah, seriously, how deeply do you bring a TIM into the process? Like are there? Because backing up when I was in the agency and as a developer I really just kind of looked at building a website and I didn't really go beyond that. That's probably a flaw of my own, I should have corrected that. But there's so much more potential going deeper into, you know, crossing over into the CRM and whatnot. How, how deeply are you investing your developers?

Yeah, I mean pretty deeply. We want the team to be collaborative and cross functional. It varies a little bit depending on the engagement and the brief. Developers know very well how to build the core modules of a website, the core functionality. And so we're keen to involve them in the briefing process and the kickoff process with clients, but they don't need to spend tons of time accompanying writers, designers, strategists through that process because they know they're going to get good Design files in InVision or whatever they're working in and they're going to be able to work off that. But when the functionality goes beyond the user interface, the experience, then yeah, you've got to get your developer involved early doors so that they understand what the market is trying to Achieve what the objectives are. They can iron out any misalignment around the communication that could creep in there and then provide a commercially viable, realistic solution to that problem. Because the marketing side of that team sure won't be able to. Right. We need the developer to help spec that solution. So yeah, they're brought in early, they're brought in a lot, and they're welcome throughout the whole process.

And Tim, historically, I mean, have you, is this consistent with how projects have been in the past? So I think this might be one of the biggest flaws between the marketer and the developer is that developer is brought in at the last minute, it goes through all the creation, the design, et cetera, and then you got 20 minutes to make a site type thing and you don't even know what the purpose of the site is.

You nailed it. Yes. That happens all the time.

Yeah. So how do you, how do you influence that? What's, what's your method of just saying, hey, yo, I need to get in there and we need to talk about this? What am I even doing?

Yeah, it, it definitely takes a while. Usually I'm just a mercenary. Just come in and code some things and then, and then get out. And then, you know, come in and code some more things and get out. But me personally, I'm in a unique position, probably similar to AJ that I run a couple SaaS platforms of my own. So I've had to move into the marketing role. And I'm very, very empathetic now to the amount of work that the, the marketer has. And I mean just small things. I want to get data out of my SaaS platform and into the marketing platform so that I can do some workflows that make sense. And halfway through the, halfway through that functionality, I think to myself, holy cow, there's no way the marketer would be able to do this unless they were a full on developer. So it's made me a lot more empathetic to what kind of needs they have and how much they understand what's possible, I guess. So I try to inject myself a little bit earlier than most developers do because I can put on the entrepreneur hat.

Yeah.

But I think other developers aren't taking that step and it'd be nice to see them start to understand more about the marketing.

Right, right. And AJ, I'll just push that over to you. Like how, let's say I am new to development generally, like I'm becoming a developer. Right. This is, and I'm working on a HubSpot now. What steps Should I start thinking about taking, you know, to just become more of a holistic developer slash marketer, you know, get that good symbiotic relationship going?

Yeah, absolutely. I mean, definitely. If you're new to development on HubSpot, you know, we have that developers course that Jeff Asura did, that's phenomenal. But I would say dabble in some of the marketer courses too. Get to learn the marketing side of the system because you are going to be working with marketers in the system where they want certain things accomplished or there's certain things that they need to provide to the client, whether it's monthly reporting on how things are going, statistics. To Tim's point, there may be certain stats that a marketer needs to pull in order to be able to make the right strategic decisions for the client that they can't get that information unless a developer helps make that connection and provide a way for that information to get into the platform. So for a new developer, it's always good to at least go through Marketing 101, like a very basic idea of marketing because then when you go to do your work, you can kind of put on semi like a marketer hat to say I know what it is they're expecting in the outcome. And that way any questions that come up from your end, you probably won't be able to answer them 100% but you'll at least have an idea of what it is they need. So you can go back to them and say, hey, I know this is exactly what you're going to need. How do you need it? Like let's work on this together. And then that's where the two, when they're talking can go. Well, this will work to a certain degree, but it won't work when you get to X position in a development phase.

And Alex.

And can I add that, Dennis?

Yeah, please.

You don't mind? Yeah, yeah. And to take that one step further, there is value in the developer even offering solutions as well. Not, not just taking tasks from, from the marketer. You know, as a developer I could say oh actually this piece of data might be helpful for you to create a workflow or, or stuff like that, not just say yes or no things are capable.

Right. And Alex, what would you consider be like Marketing 101, like the basics that I should be as a developer, just knowing.

I think the best developers I work with and AJ does an awesome job at this understand what are we trying to do for our customers and what is like the North Star for this project that we're focusing on. So I think if we can align around that, then we can have leeway within the details of the project. I might want something specific from a marketing perspective. I might want the page to have a specific element that me not knowing the technical nuts and bolts behind that might be a bit more difficult than I think it is as a marketer. But if we can all align around what that customer experience you look like, or what our North Star is for the project, what our end goal is for whatever we're working on, then me and the developer, we can kind of say like, okay, well, you know, we can't do xyz, but we can focus on, you know, this other solution. And I think that will either, you know, get us to the same place or it will, you know, exceed what we could have done if we went the other way that you were proposing. So I think having an understanding of like marketing goals and what those metrics are that a marketer cares about, whether it's conversion rate or it's, you know, ranking in search or whatever it might be, I think understanding those specific marketing metrics and what a marketer cares about is going to be the most beneficial thing that a developer could, could learn.

Phil, what are, what are the primary beefs that you've heard or about developers? I mean, what do you complain about or what do you hear people complaining about? I don't think you're a complainer. I'm not saying you would ever complain about ever.

I've got to be a little bit careful here because we've got a brilliant team of marketers and developers back at Blend. But you're right, communication is so often the issue. And knowing where the boundaries of your understanding lie and therefore respecting the knowledge of the other function and working together to create that solution. I think too often people are in a rush. There's time pressure, there's financial pressure, and it leads to kind of half done briefs, not fleshed out specs, rushed handovers. And that can lead to tension and that can lead to frustration. And one of the, one of the common challenges I think I've seen developers fall foul of is when the information is poor or absent or low quality, their approach to a problem can be less than optimal for efficiency, effectiveness and speed. But more conversation about North Star type objectives, what matters, what's important can help a developer and a marketer together define the solution that's really elegant. And elegant is normally quickest, most cost effective and highest value. And that's where I see the problems sometimes creep in When a developer's really left to their own devices to try and solve a problem without enough support, and they've got a ton of options for how they do that, but what they choose may not support the overall objectives that are at play. So, yeah, communication is key and when it's subpar, that's when you get challenge and frustration.

Yeah, speaking, maybe. Tim, you talk about this mercenary approach. Like, I feel I've been there before, and it's one of those things where you don't really. I think if you do too much of that, you start kind of not really feeling any kind of investment or, you know, passion for the job. It's more of like a transactional type thing. And even what you're solving for, you don't even know what. What the question is to ask to.

Yeah.

You know, get beyond that. So, yeah, I'm 100% behind this whole communication business. It's hard though, right? It's sometimes speaking from a developer side. Again, it's when you're brought into something as like a freelancer, for example, I mean, how do you broach these conversations? I think. I'm sorry, I'm probably asking the same question over and over again, but I feel like that's the heart of this, is basically being able to successfully communicate what you want. And Tim or Phil, I'd love for you just to talk about, like, what is the best way to convey your needs to the developer and conversely to Tim, developer to the marketer.

Well, this is really interesting to me and I think whenever I'm asked a question along these lines, I go back to something I learned at university when I was studying AI and we learned that there's an inverse relationship between computers and humans in terms of what's simple and what's complex. So if you state a problem and it sounds relatively simple to a human's ears, it's probably very hard for a computer to solve. And let's face it, developers are our interface to those computers. So by definition, they're the same. And if the problem sounds simple to my marketer is the chances are it sounds very, very hard or it's very vague or unclear to a developer. Conversely, if you state something incredibly complex that a human couldn't possibly do, it could be quite easy for a computer to do. So if I say to Tim, Tim, pull this piece of data out of this record number, multiply it by a million and six and send me back the binary version or whatever, that's actually very easy for a computer to do, but impossible for A human. But if I say make me a portal, make me a portal where customers get stats and they receive info and jobs and documents, that sounds really simple to the marketer, but it's a massive problem and a massive challenge to the developer. So I think the key to communication with developers is to complicate it. Add specificity, add data and information, because that will always make it really, really easy for the developer to give you that elegant solution which wastes no time and wastes no money, but gets you the results you're looking for.

Phil, that was a great answer. I'm going to let Tim respond to that. I'm not sure if he's up to that.

Yeah, you just took one of my legs out, Phil, because you're literally the first person to ever say that. And I enjoy being the quote, unquote, white knight when it comes to hard problems that seem hard to solve. And I just go in and do a line of code and it's fixed and are done and then you look like a hero. And now I have to be careful with Phil.

Yeah, well, no, I mean like full disclosure, Tim is a wizard, right. And he can solve any problem and has helped us at Blend immensely. We work together a lot and with great results. But you know, I think it's still true that the more airy and vague I am about stating the problem, the more choices the developer's got to make before it can even start to build that solution out. And let's face it, we've all got limited resources, limited time, limited people, limited energy. So if we can cut down that decision making time, Tim can get on, do a great job that much quicker and the time to success is going to be so much shorter.

Yeah, totally agree. So like Tim, you don't always get a fill, right? I mean, you're going to have.

There's only one fill, honestly.

Right, Exactly. How do you get that out of a marketer who just honestly might not even have thought the idea out too much themselves? You know, they're still kind of struggling with what they want and you're kind of in a tough situation, you know, to deliver this product, but you don't even know what it is.

Yeah. And to be quite frank, there's times where as a developer you just have to give up and just say, okay, fine, I'll, I'll do what you're asking me to do. I think it's right. I'll wait to find out and you come back to me and tell me it's, it's, it's right or wrong. And other times I tend to be a little flashy with. With my background, you know, being an entrepreneur and a developer. And then they'll start to trust me a little bit more and inject me into the situation and help me actually solve the overall problem and not obfuscate that problem and just say, here, I need the solution right now. Instead, they'll say, here's the problem. Can you help me come to a solution? So I'd say in the last few years, I haven't really run across that because I know how to handle it better now. But early days, it would either be do what they're asking or just let it fail and see what happens, or try and struggle and fight and tell them, no, this is the way it needs to be done, or I need to know more about the problem in order to come up with a solution.

I'm curious, Tim, like, how common is that for developers in your space where they want a seat at the table to see, okay, we have this problem. What are ways we can solve it? Is that something that developers. They really want that opportunity, or is it more so like, they want a marketer to give them a set of instructions? It's a really interesting thought.

Yeah.

When it comes to specifically agency work and more specifically Phil's team, he's got some hungry developers. They're extremely hungry. And there's two things that I look for whenever I'm looking for a developer, and that's competency and hunger. And his team definitely has that. And then he's also injected account managers in between the developer and the marketer and those you walk into any meeting, and those account managers are actually the smartest people in the room, and the developer is kind of in awe, and they want to. They want to learn more and be more like that, you know. So I think in general, in this industry, the developer is pretty hungry and wants to get a little bit more out of it. I think if you go to more of. More of just like a corporate tech job, you're looking at just. Just developers that just want to put their head down and develop.

Right. Yeah.

Interesting thoughts are, yeah, say I. I think Tidney nailed it 100% with agencies and things like that, it's a little bit easier than it is in the corporate world, for sure. You know, in an agency setting, like, being able to even have the. Like if the PM or the strategist has all of the information available for the client, it's good to tell the developer, hey, here's all of the docs, like, here's the discussions we've had with the client, client. Here's like the plans that we've created with the client along the way, because developers oftentimes can take a look at that and then be even more informed as to what the strategic decision or the strategy pathway is. And then they can insert themselves at certain points throughout it to help aid that along. You know, like if you, if you have a certain strategy and a vision that the client wants an E commerce site and it's got to be the best one out there. And all this, if a developer is inserted early on enough, they can provide the right MVP product to set a smooth pathway to make that escalation happen, as opposed to coming up with all the bells and whistles. Everything this client needs, then going to a developer and go, this is everything they need. Build it. To be able to iterate on and to be able to, you know, we're all about analytics, especially on the marketing side. Like, you want to make sure things are working, you want to make sure things are going correctly. If you bring your developer in at the end, it's going to be harder for you to really see the yield of those analytics and to see that smooth uptick of a project to go. At least in my opinion.

Yeah. How do you measure your success? You've done your product. I have two questions here. I'll start with the success one. Phil or Tim, please take it. What are your measurements for just how successful a project has been? I know this, this is beyond just a developer marketer relationship. This is, you know, higher level everything. All right, what talk. I'm sorry, I'm going to stop talking.

I mean, that depends very much on the project, of course, and increasingly, you know, certainly the product that's produced by developers tends to be a piece of a larger tapestry that's creating an overall result. So, you know, it can be quite hard to pin results on individual pieces of work. Right. That's, that's harder and harder to do. But ultimately, everything that warrants investing a developer's time should have an objective. And that objective is going to be your measure of success. And so that might be a page that performs a certain function or provides a certain feature or does something specific, or it might be an asset that produces a certain measurable result in terms of clicks or conversions or new contacts generated or so on. So, I mean, the answer is easy really, as in the measure of success is whatever you set the objective as in the first place, but have an objective, you should and Maybe that's the key thing, which is let's not just do these things for, you know, for no stated purpose. Let's be clear what our purpose is, because then we can all know whether we've achieved it. How well.

And do you continue your relationship with the developer after, you know, the product has been launched? By product, I'm saying website at this point. Yeah, I was just thinking about how to. Oh, go ahead, go ahead. I'm so sorry.

No website's ever done anymore, is it? So you've got to keep your developer in, in reach. And I think there's something interesting going on, which is, you know, there is clearly a advantage to having developers create really highly editable and flexible resources that marketers can use without going back to the developer for every single thing. But I don't think it should be a business's aspiration to not need developers at all. Right. The aspiration should be to use these things to grow to the point where you need the developer again to take you to the next level. So when I think about editable templates, drag and drop sites, modules, and all those great functions that the developer can enable us, it's a stepping stone to the future when I'm going to need them again.

I think we just have a pull quote added right there. I think I can just take that and run with it. Sorry, Alex.

I think that's a great point, Phil.

Though, that.

You shouldn't build your website to a point where developers just never needed, but the developer should build a website in a way that enables marketers to get their work done without having to pull in a developer to, like, tweak every little thing, you know, so, like these, you know, technologies that we have, like drag and drop page editing and things like that, it enables me to build a website that looks amazing. And it looks like I had, you know, a staff of 10 developers behind me, and maybe I did, but they kind of created the framework within which I can work. And I think, you know, that's really been beneficial for me and it's enabled me to get my work done. But also, I don't feel, you know, bad whenever I tap my developer on the shoulder and say, like, hey, can you, you know, change the color of this thing? Or can you move this 10 pixels to the left so it doesn't something else? And it works kind of both ways. Yeah, Just really interesting point.

Yeah. A question I actually have for Tim or AJ on this is how prescriptive do you want to be when you are building out your templates? Or your modules. I mean, do you. You can either do like, no holds bar, full Monty, like Risk, text editor, let them go and do whatever they want in there, or you can do a text field and limit what they can do. What approach do you guys find to be the most successful?

Tim, do you want to go first or do you want me to go first?

I'll take it. So I can steal all your answers. Because I really feel like any developer that is going to listen to this podcast is going to say, that's the million dollar question. What are they going to say? I want to hear this. Yeah. When do you stop adding features to your build? And this circles back to the original question you had, Dennis. It's how do you measure success?

Who do you want me to go first?

I'll take it so I can steal all your answers because I really feel like any developer that is going to listen to this podcast is going to say, that's the million dollar question. What are they going to say? I want to hear this. Yeah. When do you stop adding features to your build? And this circles back to the original question you had, Dennis. It's how do you measure success? And I think the average developer, it's quality of work, whether or not you built what the designer is asking you to build and whether it's functional. And then. And then continuing on that to. To add to that hungriness of the developer. They should start to be conscious of the budget, too, and make sure that they're on budget and they're. They're filling up that budget and they're not going over it. And if they are going under it. Is there a reason why it was misquoted or, or, you know, any other reason like that? But when do you stop? I usually it's a gut reaction. Like, you gotta be a little clairvoyant and say, I could see them asking for this maybe in a couple weeks, because this, this just doesn't make sense the way it's built right now. So, yeah, most of it's a gut reaction. And then most of it's. There's way too many settings in here for the marketer or the client to even come in here and understand what I did. Yeah, I need to. I need to stop. I need to cut this off right now.

Yeah, I've been there myself. I've put so much stuff in there, like, I don't even know what I'm doing anymore. It's like I can toggle all kinds of things now. Right?

Yeah.

AJ, do you have any Follow up on that.

Yeah, I mean, I have to agree with Tim 100%, especially when you talk about the budget. There's a lot of factors that people may not think about in terms of how much do I build. Like we'll take a module, for instance, right? A module that has like an image and text. How much do we want to provide for them? Right. How much do we want them to have the freedom to do things you need to think about, okay, how long is this going to take me to build number one? And what is the allocated time that the client has, the budget and what can I do within the constraints of that? But also, and I know this is going to sound harsh and I don't mean this at all or any disrespect to marketers, but like, I love marketers and everything, but there has to be a understanding of just what kind of functionality you can do. So what I did back at the agency was we did lunch and learns all the time. One of my lunch and learns was basically breaking down. These are the things that we can do inside of a module. I can give you as much control as you want. But on the caveat of do you know what that means to use those controls? One of the big things in this is an article and we could surface this in the show notes. I have to find the URL, but it was my old coworker Sarah Corley. She wrote an article that was basically HTML that marketers should know. And this comes into play basically in any rich text area type thing where you can click View source and I can edit my source code. Don't worry, developers have blown that up too by forgetting an end tag and things like that. So it's not just marketers that sometimes mess those things up, or content editors. Developers have been notorious for doing it as well. I just want to get that myth out of the way. It's not always the marketer. I myself have completely blown things up from my own, just not paying attention or for getting a period in a JavaScript or something like that, right? But I think that's where, like you need to understand the knowledge that your marketer has and take that knowledge and say, where's their knowledge gap? And like, I'm not going to give them a bunch of bells and whistles if they don't understand the consequences that can come from toggling these things on or off. And then that's where internally you take it to the side and you do kind of like a mini training session almost or cross informational sharing Session, if you want to call it that. Like they can explain to you the reasonings they need to build these modules and why they need these certain features and you can explain to them, okay, if we do this, you have to make sure you close tags. You do this, you do that, only go in here and here's like a class list that I've written out of what you append and here's how you add a class to a div element if you don't know. Like I think that's the kind of discussion that needs to happen for any project because just internally at an agency you need to have an understanding of each other's level of knowledge when it comes to the certain things. And then that's when you know like, like I know fully, you know, back at the agency I could build a module, put every bell and whistle on there and they were knowledgeable enough to know what to tick on and what to, you know, check off and what to do. And we had, it was very easy for me because I had a lot of brilliant people that I worked with. But there still are those one off circumstances, like especially in freelance where I don't know this person's ability. So I'm just going to be blunt and ask them and it's nothing against them. I just want to be informed as to what they know so that way I can make an appropriate, informed decision in my development process to suit them.

Phil, from, from your agency perspective, you know, you're not just building for yourself, you're building for clients, right? How do you have conversations about, you know, what kind of ability do you guys have directly related to AJ's question there or answer, do you do, do you do like little tutorials for them or do you, what's your process, I.

Guess in relation to understanding where to draw the line in terms of developing these, you know, this editability into the.

Modules or just understanding what, how much they know how to operate the site, I guess. Like these modules, like how to what extent do you train them up on, you know, how to actually use what has been developed?

Yeah, well, it's become essential now because yes, we typically build an awareness of what the client's resource and ability is like, but most often they're coming to us for a solution that is easy for marketers to use and will come back to you when we want to take it to the next level. So we know that we're trying to create that polished but manageable interface for that marketing team or person. The thing that I look out for Most of all, or try to educate our clients on most of all, is that everything's on a sliding scale. And the more permutations we ask the developer to consider the potential effect that has nudging down the design freedom that we have. Because ultimately, if you want absolutely anything to be possible with no coding involved, then you've got to have white backgrounds, square images, you know, everything just neutral so that it can exist anywhere on any page at any time. But we typically don't want to create sites that have that look about them. We want to put the scale slightly up from there. So it is important to understand what aesthetic are you going for, what level of aesthetic and what level of editability is reasonable within that aesthetic and try to strike that point. Now the developers have got a real job on their hands because they've got to build out those templates and modules and also make those decisions around editability. And it's something that I think increasingly agencies need to get better and better at defining and doing and educating on because it's the new experience, it is the new way of building websites and we're not going to go back to the old way. So this is a really interesting topic where I think we've still got some learning to do and some work to do on a process. But I want to have the scale right, so that you've got a great looking site but you can easily edit it.

Right, right. I mean, to what extent do you have scope creep in these types of things? I'm curious, like when is it? How often are you. Right.

Well, I think there is no such thing as a project without scope creep of some sort. And the agency dilemma is how do you manage it? Right. And that's every agency's primary challenge. I would say. Most customers come to their agency and say, we'd like a new website, how much will it cost? And you don't have any idea of the size, structure, customer journey, etc. So you have to work out some sort of estimate and try to build a good relationship there and then so that when the scope changes, you can have a good conversation about it and determine how to tackle it. But yeah, that's every day in agency life, right?

Yeah. Enjoy it. We had one related question. Oh, no. Go, go, Tim.

Okay.

It's all you, by the way, Dennis. It goes back up the chain as well. From the developer standpoint. You can ask any marketer, can go out and ask any HubSpot developer. Do you feel like you're. You have this constant weight on your shoulder? Like you're trying to build the perfect module. Because that. I feel that every day, every time I sit in the, in the design manager, man, I know, I know it's there. It's right at the tip of my tongue. I could build the perfect module and the marketer and the developer can never have to have this question ever again or this conversation. And it's just, it's, it's almost unobtainable, but it's, it's right there. And I feel like it's, it's so close. But, but that is something that us developers are constantly thinking about. And I've, I've asked the rest of the team at Blend, you know, the same question, like, oh my God, yes. Like, thank you for asking that because yes, it's there, but I just never really like said that out loud.

I'm glad. I want to. We had one question on the, on the forums. I think I just want to read it off and get your thoughts on it. It's not really a question, it's actually just a statement or an opinion. I'm a marketer and a developer. I try to leave my code clean enough for the marketer to go in and change and what they need to without breaking the whole site. Also comment, comment, comment. If they know where things are in the code, they don't have to rely on their MySpace era CSS skills to reverse engineer my work. I want to pause right there, Tim. Aha. How do you feel about the marketer going into the code?

Your turn, aj.

I, I think like I said, as long as, as long as the marketer understands the concepts or at least it's been documented out for them to be able to reference something to do it. I have no problem with marketers going into code. I think their, their comments about comment, comment, comment should be one that every developer should be doing anyways. Always document your code. Especially like on the HubSpot platform. I, I've seen HTML comments be used, used Hubble comments, you know, those things don't show up on the front end when you go to view source. So use the Hubble comments to really communicate the important things. And I mean you can use HTML comments to say like, this starts, this ends here, but if you want to provide direction to somebody inside of your code, use the Hubble comment coding because otherwise anybody can view source and see that you're clearly providing like a plethora of instructions on how to do something. But yeah, I think it just comes down to like again, having that conversation with the marketer. To understand their level of proficiency. Yeah, and that's when, like, I have no problem, like, letting a marketer go in if I know that they understand what a class name is and how you apply it correctly. Go for it. You know, it saves me the time of having to jump between, like, five tickets that I'm working on in JIRA to just simply add a class name.

So I would like to interject my opinion here, and I am strongly against marketers going into the code. I think there needs to be a converse. This is one of those communication situations where you need to know why. I mean, it could be something very simple, you know, like we just want to change this font color, whatever. But this is something that you need to talk to your developer about so you can optimize your site. You know, there might be a better way of going about it. The developer knows that you're. You're just adding some css, you know, rule with an important tag, you know, at the end of it, and that's going to mess with some developer later on trying to override that. And then you, it just, it just spirals, you know, all of a sudden you have more and more, more, more classes added, you know, important tags. Tim, what do you think?

Yeah, yeah, Phil. I'm ashamed that I don't know this, but Sasha, is he a marketer as well as an account manager? Because I want to call him out.

Yeah, most definitely.

I was mortified when he was about to go into my code the first time he was going to go into my code and then, man, he blew me away the way he understood what I did and, and everything in the module. And from there on out, anybody on the Blend team can, can go in and, and mess with the code and I'm completely okay with it.

First books.

There are, there are obviously going to be developers that. No code, sorry, design marketers that know code. Right. They exist. I know some code. Sasha evidently knows good code. But I agree with Dennis. You know, I'm against marketers going into the code. And, and the great thing about HubSpot is they shouldn't have to. You know, we've got now a tool, a platform, which means developers can create tools for marketers to use, but still control the quality. And quality is so important because, you know, we're not manipulating the same medium that the user is receiving at the other end.

Right.

We're programming computers to spit out stuff. And I think that's a slippery slope. And yeah, you can get away with it a lot of the time, but you can just as easily degrade it, break it, wreck it. And so if at all possible, it should be avoided.

Yeah, I agree.

That's what you do the history and see who it was and then blame them.

I feel like this goes back to like sphere of expertise and ownership, almost like, and honestly, at the end of the day, communication. Because if you have a good relationship, a good working relationship with a marketer and a developer where like the developer trusts that marketer to go in and make an edit, then like by all means. But if we flip this around. I remember I was creating some marketing materials recently and it was rather technical. And so I looped in some technical folks to like spot check me for accuracy to make sure that I was speaking to things correctly. And they started to copy edit the doc. They weren't like just you know, checking for the technical accuracy of my copy, but they were like changing some grammar things and nothing that they suggested was inaccurate and so I just let them have it. But a piece of me was like, hey, like, you know, this is my.

Domain, this is my realm.

I think it comes down to communication. If you have that working relationship between a marketer and developer where you feel comfortable to let them, you know, go into the code, make edits and you feel confident that the edits aren't going to break anything. I like to say that I know just enough HTML and CSS to break things. But you know, if you feel comfortable with your market or your developer that you can make those edits and you know, that, you know, things will still be, you know, moving forward and working well after the fact, I say go for it. But it all is about the relationship and the communication level that you have between the two parties, I think.

Yeah. Knowing who you're working with and I mean, just like Tim, I'm sure, I'm glad you're okay with Sasha going in there and you know, and working with your code, but I mean, does that break your workflow? I mean, what if you have like you're a locally developed something, you know, your site's locally developed, you got, you're pushing it up to GitHub, you know, you got your repositories, you got a staging branch, push into production branch and then you have this person, this Sasha, who is going into the design manager and you know, editing your modules.

Yeah, yeah, that's. I won't say that's true for everybody. I do take it a little personally when people go into the code and mess with things, you know, other people. So that was just an example of something I was okay with in general, not okay with it. And I'm also curious to know how much you asked how, how much of the line a developer is willing to cross to go into the marketing. I would like to know the opposite. Are the marketers like generally really wanting to understand the code? Are they wanting to take coding classes to better understand what our role is? You know, not, not just the other way around where the developer wants to go into the marketing and, and understand that.

Personally, I view it as like a fun challenge to try to solve. I manage HubSpot's Inspire site. So inspire.HubSpot.com, quick plug, but it's a repository of just amazing, incredible websites that are hosted on the cms. And I wanted to make a change to it and I did not build the site, but I was like, okay, I think I have the technical ability to add this row to Hub DB to get the row to show up in the editor. And so I reviewed some of the documentation and took an honest stab at it. And then I quickly realized I was in over my skis. And so I stepped back, documented the changes that I made and then went to my developer and they were helpful in fixing what I broke. But I do think that me personally at least, I do want to increase my technical acumen because I want to, I want to streamline the process as much as possible because I think something that could, you know, move us forward as a group and, you know, developer can focus on more high level projects, more projects with bigger impact instead of fixing, you know, this slight thing that I want to change on a website that's just going to move us all forward at the end of the day. My two cents.

Yeah, I agree there. I think marketers learning development, I mean, just, you know, the product better, right? I mean, you know, more things you can do, you have, you can think of cool things that are possible that you never thought were possible if you know what's going on on the development side. I mean, Phil's all over the place in the community. He's answering API questions, CMS questions.

I don't set the best example of staying in my lane, but like Alex, I find it all an interesting challenge, but I think it's also worthwhile thinking about the consequences if it doesn't go well and who will be breathing down your neck when things go wrong. Or conversely, if it's your, you know, project your product and another person comes in and takes it offline and breaks it, what will be your reaction? And you know, we're talking about. I mean, we've said it many times already. It's communication. It's knowing who you're working with and it's knowing all of your boundaries. And that's organization, isn't it? That's. That is work. You know, who you're working with and what they're capable of.

I think, I think the only reason why I went in and tried to make those changes to the Inspire site on my own, because I knew I had. I had AJ behind me to help me and like, kind of as a safety net and I knew that I wouldn't piss him off too much if I ask to help me get out of the weeds.

Continuing on this question or comments. When it comes to images, I always give clear dimensions on any image that are on the site and instruct them to make sure the images they are using match dimensions exactly. Background images are always massive files that may be constrained by style. Please, marketers don't get the biggest image on unsplash, whatever it might be, you know, soul Plug, but make the site take forever to load. Don't get me started on team photos. I won't, I promise. Nothing really to add there. Lastly, I try to code with marker by keeping the CMS in mind. Yeah, If I can get away with making a single page that has every type of visual element filled with Lorem Ipsum on it, I do. I even go so far as to making that a part of the design process, which I think is pretty smart. I like the idea of like, you know, having everything on one page. You get an idea of what you can do. You know, it's kind of like a palette almost. Right?

Yeah. That can be a useful approach to.

Go off of that. I think that's something that every agency or every freelancer, developer, anybody, when you build a site for a client, you should have some kind of like style guide type area for them to show them, especially in HubSpot, right? Like show them like this is what this module does and document it out for them, you know, just to give them some transparency. But it's not just transparency, it's directional. So that way they understand the full capabilities of what they can do with that module and then they understand the limitations. You know, we always built style guides for every site. You know, back at the agency that we were in and we, we didn't just deal with HubSpot, we dealt with, you know, Episerver and Actron and Bracco. We dealt with a lot of different platforms, but on every site we built, there was always a link to them on their site. That was a style guide for content editors to understand, like what the typography is that there is. And basically kitchen sinking samples of everything that they could do with their site. Because that's really the best way to inform anybody who's even inheriting your code or inheriting your project from somewhere else. They can then get an understanding of exactly everything that you've done for this site.

Yeah, and also it helps you sell, it helps you upsell or downsell. You know, if you've already built a site for a client or a customer, you know, they have a budget of maybe five hours. Creating a module alone might be five hours. They can go to this documentation and say, okay, I could cherry pick that. I could cherry pick that. Which, by the way, that might be something HubSpot might be interested in generating automatically. That would be nice for us developers.

I will take that feedback back, trust me. I know, I know. I have brought that up myself, so I know that like there we. It's like it's on a document somewhere to be like more documented out. But there are definitely discussions that we. The one thing I could say to people, because I know this comes up a lot too, from developers, specifically in our Developer Slack, your ideas and the things that you post in there, don't think that those go unnoticed. Please don't think that we are always watching and not in a creepy way. Like, I don't want to make that sound creepy, but like the posts that happen on the community, the posts that happen in the Developer Slack, the Facebook posts that are in the partner groups, we are there, we are watching, we are looking at that. And just because we don't publicly respond to something doesn't mean that somebody internally hasn't gone, hey, check out this idea that somebody said, this is awesome, we should explore this. And a lot of conversations happen around the comments and the things that you guys provide to us. So please keep going with that feedback. Even if you think that nobody's going to hear it. Somebody will. I guarantee you, you're here.

Although I do actually delete anything that Tim says, so no feedback ever makes it.

Are we going to give the listeners, you know, the backstory on our rivalry there? Dennis?

Yeah, so it's been a long, long journey that I've had to deal with this. Tim Joyce yeah, we were both community champions back in the day and now I'm a manager of the community, so I can do what I want. I cheated a lot.

Places, the police.

Dennis One time we were Getting some swag from. From the community. And I got Tim's swag and I have been holding that above him. I should have brought it with me today, actually. I'm gonna.

I'm gonna.

In the show notes, I think I'm gonna have an image of Tim, swag his note, personalized note, and show that off.

I'm pretty sure he sent me a text message, said, I have your swag. If you. If you want it, here are my plans.

Sounds like something Dennis would do. Yeah.

Yep. It's so good closing up this post and I think actually we've spent a long time together. I'm going to stop talking to you in a few minutes. That way, if they are using one of the popular WYSIWYG editors, they can copy and paste sections from the page if they have enough code experience to use classes. I built out a number of classes that have predetermined widths and layouts is a pain to do in the beginning, but it saves so much time down the road trying to fix what was broken. I don't know about that. Do you guys do this? Do you? Tell me, aj, go.

I've done it. I've done it in the past. Essentially, it's depending on the module, for instance, that is being built, or a certain part of the page. I would say to the marketer, what are all the things you want to do? You know, are you. Are you going to be reusing this on multiple pages and are those pages going to be different? You know, because you have, like, your standard templates, like, you have your, you know, back in the day before we had drag and drop and all that was like, okay, you have your single column page, you have your left, you know, left column, you know, content area thing. What are the different layouts that you're going to want for this? Because sometimes dragging a module onto a page, the layout is going to change or things are going to be different. And when it's tablet or mobile, you probably want things stacked as opposed to left and right. Like, these are all things that you kind of just have these conversations with. A great example is like a team member module. Right, you want the photo on the left, the information on the right, some want the photo above and the information below. You can easily solve that if you're using, like a media element with some classes to make it happen. So it's one of those things where, like, now, with the way that things have been and how we've progressed so much in HubSpot, you can just simply put, like, A select dropdown in a field to let them apply. Or like radio buttons and toggles. Yeah, but back before that, that was like a conversation that you needed to have of saying, okay, well, we can add different class names. Here's a text field. Punch in this class name. Good to go.

Yeah, that's, that's a good call. I've kind of forgot about that time. I've definitely done the whole drop down and there, there are actual class names in there, but you know, it's to the marketer, it's more of a like right, left, you know, or black white type of name in there. Any, any closing thoughts? Yeah, I know, I just, I just really just hit it right there. So, so sudden. Yeah. Tim, what's, what's up?

I think if there's any kind of hidden agenda to this meeting or this kind of conversation, it's, it's to remove the demarcation between the marketer and the developer and start to start to overlap a little bit. I think it, you know, like Alex said, it'd be beneficial to everybody and move Everybody forward.

I, 100%, as A.J. says, agree with you. I, I, this is going to happen more often, I think, you know, I think the, the overlap is going to continue to increase. And I, the goal here is to remove as much friction as possible. And I, I think, as we said, and we'll say a thousands of times again, communication, ask questions, really don't have an ego about it. You know, if you don't understand something on the marketing side or if you're on the marketing side and you don't understand what the developing side ask, you know, I mean, if you got a good developer, a good marketer, they're going to be talking to you about it and you get an education, you could become a better employee or worker, you know, and everyone wins.

Yep. I have a couple of closing thoughts. That's okay.

Please, please.

I just, It's a great discussion that will rumble on for a long time because we're not done.

Right.

But, you know, today was really good. You know, I just wanted to say a big shout out to Tim. Tim has been working with Blend for quite some time now and he's been a hero and done some really incredible work for us and working with him is absolutely a joy. So props to Tim.

Thank you, Phil.

A shout out to Sasha as well, who's an honorary participant in this recording. He's a brilliant member of the Blend team, an absolute star. And the whole Blend team, they're great. So thanks to them, and to HubSpot too, because HubSpot CMS is something else. Right. It's an absolute game changer. I think what they've bundled into the technology as a platform, what they've made possible for marketers and what we can deliver as a seamless customer experience as a result is making working with HubSpot CMS an absolute joy as well. So, you know, congratulations all round.

Really cool. I want to know. Go ahead.

Did you know Blend exclusively develops on HubSpot? I didn't know if you knew that or not.

I did not know that, no. Wow.

Well, yeah, I alluded to it earlier on because we were quick to hop onto it when it first came out because we weren't in love with WordPress. We weren't dedicated to it enough to not see the potential and the power of. Of what HubSpot were just starting to do.

Right.

So, yeah, we were very quick to sort of despecialize in WordPress and other CMS and just focus on this. So we've been, you know, developing on this since guess 2015 was about when it really started to become a thing and not looked back because. Yeah, okay, there are boundaries there. Right. And that's another discussion for another day. But I think they're healthy boundaries and they focus you on your objectives, which typically in business is generating pipeline and generating opportunity. And we exist as an agency to help you do that. So it's the perfect CMS for us. And add to it the rest of the platform and, well, you just. You've got. The world's your oyster, really.

And I promise we do not pay. We do not pay Phil or Tim to say these things.

As the, as the product marketer for the CMS Hub. I might be following up with you after this. Philippines.

I want to. I want to close by saying that Phil's. Everyone just take a note of Phil's background because it's real. It's. It's not, you know, it's an actual. Not a virtual background. I don't know. It is.

Touch it.

Look at that. Look at that. And with that, I want to say goodbye. Thank you guys for having this conversation. It's been really, really fun. There's a lot more to be said, as you said, Phil, and we'll probably do another one of these sometime soon, so have a great rest of day, weekend, things like that.