How to Build a Scalable Growth Engine Through Speed - Jaleh Rezaei

I need some traction. You need some traction.

My name is Vasyl. I'm super excited for the upcoming session, How to Build a Scalable Growth Engine Through Speed. Very important topic. And I'm joined today by Jaleh Rezaei, joining me from San Francisco. She's a co-founder and CEO at Mutiny, a UC-backed company focused on helping SaaS other SaaS companies personalize their websites for each visitor. Prior to Mutiny, Jaleh was employee number 12 and CMO at Gusto. Many of you heard of Gusto, many of you are using Gusto right now, and she actually grew company from 500 customers all the way to 50,000 customers. Without further ado, Jaleh, please take it away.

Awesome, thank you, Vasyl. And thank you everyone for joining the session. As Vasyl mentioned, I led marketing for a number of years at Gusto prior to starting Mutiny. And now at Mutiny, we work with some of the fastest growing B2B growth teams. And so I get a lot of exposure to different types of marketing teams, a lot of really successful ones. And I always get this question from, you know, CMOs, CEOs, folks in marketing, you know, what are the winning tactics these days? What channels should we be looking at? And I think it's fine to, you know, keep an eye out on the latest and greatest within growth. But, you know, in my experience, the reality is that tactics are a byproduct of the real driver, which is the culture of the marketing team. So winning marketing teams tend to have, you know, a culture and unique characteristics that consistently leads to really great tactics that work. And as much as there is content out there on tactics and channels and things like that, there's not a lot of trustworthy content out there on how do you build a great marketing culture. And so I wanted to talk about that today and share some of, you know, some of my insights. And you know, the question that I ask, I don't know if you can see this in the chat or not, but you know, how do you define excellence in marketing? I think there is a lot of different characteristics, cultural characteristics of marketing teams that lead to excellence. And as you think about it, I'm sure a lot of these are gonna come to mind. Some of the really common ones are structured thinking, results-oriented, quality, working well with the sales team. Consistency, a great brand. And in my experience, speed is the single most important characteristic of a winning marketing team. And since there's not a lot of content out there, what I wanted to do today is talk a little bit about why speed is the most important thing, because speed is a bit controversial, right? It's, I think it's kind of a misunderstood concept. A lot of people associate it with low quality and being hasty and not thoughtful. And I think that it means something entirely different. And so I want to talk about why it's important and how to incorporate speed into, into your marketing programs. Okay, so why is speed important? First of all, The, you know, in marketing, there's a lot of things that we have to try before we find programs that work. And so the reality is that a lot of our brilliant ideas, even though they sound great on paper, when you get into the execution of it, you realize that there was a lot of assumptions that ended up not working. And we need to pivot away from that. Sometimes divest completely from the program, sometimes a hard pivot in terms of, the way we're approaching a channel, and sometimes just dozens of small iterations in order to get to something successful. And so if we can remain fast, we iterate quickly and either decide to divest from a program that was never gonna work, that was a huge waste of our team's time, or quickly iterate to a program that is working and we get to quality and results, which is ultimately what we are after as a marketing team. And then finally, I think people really underestimate about speed is that when you are fast and you are in a market with a lot of competitors, which I think pretty much everyone is nowadays, you get to lead the market and your competitors are in this perpetual reactionary mode where they're trying to slowly copy your tactics and you get to just always be 5 steps ahead of everybody else, which is incredibly valuable. So what slows us down? I think there's 3 really big ones. The first one is inability to cut our losses. This one's really important because inertia is a really powerful thing. And I think we sometimes tell ourselves stories about things working or not wanting to walk away from something. Second is accepting limitations that can actually be removed. Often this is really apparent in cross-functional dependencies Well, it just takes engineering a month to give us a landing page, right? Like we start to kind of accept some of these things that exist in the company. And then finally, this one's very much self-inflicted by marketers onto themselves, which is a high quality bar for things that don't matter yet. A lot of times you'll hear the term being on brand. And of course, like having a great brand and all those things really matters, but we need to contextualize that around where does it really matter? And I think that's one of the biggest speed killers because mistakes and speed come together. And if we have no tolerance towards mistakes, we can never really be fast. And so to kind of illustrate that, I have this little anecdote here. All of us as marketers, we build these great products, these great companies and this great brand, and this is the Mutiny mark, but just kind of take it as a symbol of what your brand might mean to you. And then your team is moving and they're executing and all of a sudden, there's a mistake. We tend to have this really zoomed-in view, right? Of, oh, we wrote this one really bad blog article or whatever that is. And that's all that we can see. But the reality is that the market has a significantly more zoomed-out view of your brand. And so those mistakes just aren't as apparent to them. And the reason is, you know, brand is the sum of all the interactions that somebody has with your company, your product, your customer support, all of the different, you know, content and things that you put out there. And so I think it's important to kind of remind ourselves of whether, you know, whether not making any mistakes and being kind of this perfect team is worth the cost of not being able to move quickly and iterate. And that's certainly something that I have to remind myself because I also have a really high bar for brand. And it's just a good reminder to remind myself of this is how I see it, but this is how my customers, which really matter, are gonna, are gonna be able, are gonna see it. So what I want to do now is kind of share 5 strategies for how to become fast or how to integrate speed into your marketing programs. And I'm gonna focus this on introducing a new program. And, you know, it could be within marketing or it could be even outside of that, but this is something that that, you know, it's a practice that happens over and over again in marketing as we try to discover new opportunities, new channels. So step 1, breaking down large problems. And so as soon as you come up with an idea for a new channel or a new program that you wanna launch, I think at that very, very early stage, day 1, you can switch over into this, into this, step, which is a 1.5-hour meeting with the core team that's working on that program to really define what this program really means and what are all the unknowns. And so the first step that I recommend, and this is all based on things that I've tried that, you know, we are implementing at Mutiny or things that I've implemented in the past that have, that have worked for me. So it's a culmination of like a lot of those learnings and iterations. So the first step is define one big inspiring problem statement. So for example, in one year we want to have 1 million blog subscribers, or in one year we want to have 5,000 partners that are selling our product to their customers. So you want this to be really inspiring for the team. But then what happens at this stage, or at least what I've observed within my own teams, is that everyone kind of takes this very monolithic view towards this statement and wants to immediately go to, okay, well, how do we make that happen? What does the program look like? And, you know, how can we build a timeline and start executing all pieces that would go into doing this? When the reality is that this statement is actually a composite of hypotheses, which are things that you may or may not be right about. And so what I recommend to break down this big statement is something that we call the black hat technique. So the black hat technique is essentially this. You fast forward to the end of the timeline that you set for yourself, right? So let's say you wanted to get 5,000 partners at the end of the year. And so you would say, okay, today's January 1st. Now let's assume it's December 31st. We failed at our goal. What went wrong? And that switches people from this very optimistic mindset to kind of triggering their problem solving in the direction of, well, what are all the things that we don't know? What are all the things that can go wrong? And so, you know, they— people start brainstorming, they start ideating. And what you want to get to is kind of a list of 5 to 10 of these. Anything more than 10 is too much. And usually big programs will have at least 5 major unknowns that together they form this mutually exclusive, collectively exhaustive list of assumptions. And then what I do is just to kind of make it more easily understandable and usable is I just flip them from negative statements to positive statements. So instead of there wasn't enough partners in the market, you would say there are, the market is large enough and there's enough partners within our ideal profile that we can go after. And I recommend attaching a metric to it. So there's no ambiguity around what that statement means. So there is at least 50,000 partners in the market if you think you can get a 10% penetration rate to hit your 5K goal. And this is once you get to this step. Now everyone has this X-ray vision into the program that I think is really important for staying fast, because once you know what all of those levers are, you can navigate as program owners, you can navigate a lot more quickly, right? If you keep running into the same roadblock and you clearly understand what the levers are, you know, you can start to identify, you know what, we're just never gonna be able to get past this thing. Like I think we were fundamentally wrong about this one thing. And so we should divest from the program or, you know, you can basically just kind of navigate a lot more quickly within the program, you can contextualize your learning. It makes planning a lot easier when you're kind of trying to think about, okay, it's next quarter, what do we focus on? You can kind of use this as a framework as well. And so, you know, now you have this really great strategic understanding that a lot of folks, you know, that are designing really big programs don't. So you're many steps ahead of the rest of the market. And at this point, this is probably the biggest shift in the way, in the way folks tend to want to operate versus what I'm advocating for, which is instead of going into building the perfect thing and coming up with this plan, I think that the best thing to do is to ship it. And you want to ship this within 1 to 2 weeks, 2 weeks being the absolute maximum amount of time that you would want to give yourself to ship it. The reason this is really important is that, you know, I don't know if you've ever tried pushing a really big box. When you first start pushing it, it's really difficult, but then as soon as it starts to move, it gets significantly easier to push. And this is not an illusion, like static friction is just a lot higher than kinetic friction. And I think this analogy works very similarly for people and teams that are executing on programs. Once they are set in motion, Everything is just happening a lot more easily. And what I've observed is that whenever my teams have encountered this brand new program, there's all these new muscles that they needed to build, all these new things they needed to figure out. And that can be really hard and uncomfortable. And it kind of pushes us into this sort of isolated experience where we go into the basement and we plan and create in order to make sure that we really get it right. We want to have done our research. We want to make sure We got it right. And you don't really learn anything in the basement. You have to kind of be out there in the real world to be able to much more quickly test out these, these things. And so the way that I've found to be the most effective way to do this with my teams is to give them motion goals. So these are goals that get you out of the basement and into the real world to actually start, you know, doing the things that get you the impact that you want. In your program. So a bad goal, which may on the surface not feel like a bad goal, but in this framework of speed it is, is, well, let's build a list of all the partners and create a TAM analysis. And just like that, 3 to 4 weeks of finances time or whoever's working on this is gone. Another goal that might seem innocent on the surface, well, if we wanna introduce a new partner program, let's go learn about all the partner programs that are out there, and then put together what ours would be based on all those best practices. It seems really harmless. It seems really valuable. But again, you're in the basement doing a bunch of research and you don't actually have, you haven't learned anything about what the market is really like. And of course the partner program is an example. In the longer version of this stack, which the GMC will share with you guys, there's a lot of examples that kind of accompany each step. So here I'm just kind of anecdotally touching on a few of them. Just to kind of make it more concrete. A good example of a motion goal is sell the program to one partner this week. It's a lot scarier, right? Because you're like, we just thought about the program. We haven't done any analysis. We haven't built anything around it, but that's exactly the point. If, and it doesn't really matter if you succeed at the goal or not. What matters is that it forces you through a lot of the motions of the program and it gets you from that static friction into the kinetic, right? Because you have to go figure out, well, which partner. So you have to like find a list of partners. You have to reach out to them. So you're going to create that content. You have to have these conversations. So you have to think about at a high level, you know, what am I going to say? But nothing that you've created is so precious that you're going to latch onto it and insist on it being part of the program. When it may or may not work for you, right? So it just kind of moves you into getting out there and really starting to test the mechanics of the program. A great goal for week 2 could be book 1 customer meeting. And in doing so, you kind of start to get directional sense on all of those hypotheses of where do I need to be focusing more? Where am I experiencing the most friction? What seems to be the hardest thing that we need to figure out in here? So once you've done that, then what you wanna do is up-level to, you kinda wanna kind of take a step back and think about, okay, you know, we came up with a program, we just spent 2 weeks really executing and getting out there and experiencing this for ourselves. And now what you wanna do is just create a little bit of structure around the way that you execute every week. And what I recommend here, and this presentation is kind of written a bit more for leaders that are thinking about how to guide their organizations, is you wanna come up with weekly targets and some sort of a dashboard that communicates how you're doing. And so, you know, I've tried so many different versions of goal setting, different ways of giving the team guidance. And what I've found is if you take your quarterly goal and can make it one consistent goal every week, that creates the best execution rhythm for the team because they don't have to constantly be thinking about what are we trying to achieve? What's the goal this week? It sort of removes that layer. And so for example, if you wanna get 12 partners, if we continue with that example in one quarter, you divide that and that's one partner per week. And so usually I pick the goal that's the furthest down the funnel that can still be impacted every week. And every week you add one partner and in your dashboard, you always wanna have actual versus target. And so if you can achieve those two things, which is pretty, pretty simple to, to do once you think about it in this way, then that ends up being all that the team needs to be able to kind of self-manage and problem solve on a day-to-day basis in order to get there. And it just like kind of shifts the conversation from, wait, what's happening in this program and what's going on to you have a clear view and you can start to like really talk about, okay, what are the things that are working? What are new things you want to try next week based on, you know, how hard it was to meet the goal the previous week, et cetera. And so this is, you know, this is my recommendation. And the difference between actual and target is a really important part of your dashboarding. My team internally calls it the shame, because that's what ends up driving them. And then a fourth step that I found to be really effective in kind of continuing this momentum of a fast team that's learning really quickly is, is a biweekly learning meeting. I learned this from, from a really awesome growth leader, growth engineering leader, and I thought that it worked really well for marketing as well. So the way that these— the goal of these meetings is to encourage and codify learnings across your team. And so usually you would have your entire marketing team there, and it's actually a really great session for other teams that work with marketing to also attend. And what, you know, what you do is it's a really simple, consistent format. That's hopefully a theme that you're seeing is we're trying to get to a consistency in execution so that the team kind of knows what to look for. And so when a team has something to share about their program, they would join the meeting. You know, we had a Google Doc that just kind of contained all of our learnings, and it was a really great way to onboard new people onto the team as well. And so they would just put in what was my hypothesis. So, you know, we believed X, we constructed test XYZ to be able to validate that. And here's what we learned as a result of that. So for example, you know, to continue with that partner example, it could be, you know, we believed that through a rev-share model, we could create a really meaningful economic incentive. For partners to join our program. And so what we did was created a 50% discount, which is the most rev share we could ever offer. And we ran that by 5 partners and they all told us that that amount of money is just really small relative to the revenue they make every month. So we learned that we probably, that, that, that, that rev share is actually not gonna be a major driver. But we also learned that they're really interested in building their own services model on top of our product that they can monetize a lot higher. And they're also really interested in passing a discount directly to their customers. So that's how we're going to pivot this piece. So as you can see, they don't always have to be the statistically significant A/B test. It's qualitative learnings are just as important. But even if you're doing qualitative, you still want to be analytical about it, which is why you you have this hypothesis-test-learning format. And this is where a lot of times, like, people usually these hypotheses line up really cleanly with what the core hypothesis of the program were. And it's, it's just like a really good way to kind of go back and, you know, focus on the, the, the different levers. And it's a great way to elicit ideation from the whole team. You know, usually if you have a large team, they're not all in the weeds of every single program. And I found that this format surfaces the crux of the issue in a way that any smart person can be helpful to their peers without having a ton of, a ton of context, because you get to the most important part of what they are trying to solve. And it's just a great way for everyone to have this deep understanding of what's going on in your organization and the different programs that you're testing. And then step number 5 is technology. I think technology is a really big part of being fast. I'm gonna skip over that a bit just in the interest of time, but usually in the first couple of months I keep it low tech. And then from then on, you really wanna think about how can I use technology to have instant analytics and to be able to, and to be able to remove repetitive workflows for my team. So technology for me as a, as a marketing leader is always the, the one of the most important areas of investment because that's what allows us to be fast, especially when we reach any kind of scale. Without technology, it's almost impossible to be fast. And a lot of times I would say at larger organizations, I'll see that they have technology, but it's a really old stack that's powerful, but it doesn't enable speed. And so you always wanna kind of be thinking about, you know, the ease of use and how well it lends itself to the workflows that your team needs to execute on so they can be much more quick. And so I have a little scorecard here, which is a summary of the 5 points that I went through. And the final reminder there is like, you wanna make sure that you are a little bit uncomfortable because that means you're moving fast enough. There should be moments where you cringe and you're like, oh, like, I can't believe we put this out there. That's okay. Those mistakes are a critical part of fast. If nothing ever goes wrong, that means that, you know, you are not learning fast enough.

How do you ensure alignment between product teams and marketing team? Um, how do you ensure that alignment to get that speed with experimentation when testing is dependent on tech tweaking in existing or delivering a product.

Yeah, totally. So this is, um, I would say this has been— this becomes a bigger and bigger problem for marketing teams as every year that goes by, because marketing has shifted to a point where without technology and engineering, it's, it's almost useless, right? And so, and I think a lot of times the way that we, that we structure teams, it's like, okay, here's marketing and then here's engineering, here's product. And they're very siloed from one another. I think that this is one of the first things that you have to solve, whether you create a product and engineering, you know, like an EPD, engineering product design pod within your EPD organization and dedicate them to marketing. Or, you know, for example, at Gusto, I had the head of that team sit on my staff meetings. So they were, they were part of my team and their entire headcount was dedicated to marketing goals. And then we would prioritize within those goals, but there's no, there's no answer that is, you can kind of, they can be in their own world and you can be over here and you have a one-on-one once a quarter. Like, I think those teams need to be incredibly integrated. If you can put engineers directly on the marketing team, that's even better. I think that's a shift that we don't yet feel comfortable about, you know, that engineers have to sit within the engineering organization. If your org is really attached to that mentality, then definitely you wanna have a team that whose entire goals and focus is on the growth project. But like, for example, Samsara is a really good example of this. They have a growth organization, so their demand gen team that's called growth and it's marketers and engineers. And I think that they have done an incredible job of moving quickly and, and testing all sorts of really innovative things because engineering actually directly sits within the marketing team. This is a battle that I would say is worth fighting for. So if you're joining a company for the first time, the first thing I would try to resolve is for me to be fast and effective, I need access. I need uninhibited access to engineering and analytics resources. How are we going to solve that problem? And until you do that, it's really difficult to actually be really good and fast at marketing. What are product-related examples that you test without building the full product? Would love to test one week after building the program. Give you an example of this. We do this constantly at Mutiny. So the way that we— so we're coming out of the marketing realm into the product realm because a lot of these speed tactics can be applied, I think, across the organization. So what we do is we first build nothing, and without building any product, we have to get to a certain level of conviction and validation. That's the piece we can do within 1 to 2 weeks. And then we build the backend, So let's say we want to test the personalization feature. We built the backend but not the UI, the configuration UI for the user. And so we'll manually run the test to get the next layer of validation, which is what is the impact that this feature had on the customer's website experience for their end users? And then we'll build a V1, kind of like a beta, and then, and then continue to iterate from there. So we have several steps before what we would even traditionally consider a beta. So to give you an example of a really light and dirty way to do this, one of the things that, you know, we wanted to do is this idea of community. How do we introduce community into the Mutiny product? Because there's a lot of best practices and things that people can learn from each other. And there's so many different ways in which we can build that into the product. And it's actually, you know, if you go all out with the bells and whistles, it can get incredibly incredibly complicated and resource-intensive for our engineering team. And so the way we validate that is step one, we basically just build a slide deck that has our, you know, idea of what a community-driven inspiration could look like. So we build out, here's the before and after of what companies did when they personalized their website. Here's the lift that they received, and this is the company that did it. And we just share that in a one-on-one meeting and, and tie it to a recommendation like, okay, so they did this. The reason I'm showing this to you is because I think you have a similar audience and you can launch a similar task and you run through a few of those. And that's the crux of, for example, let's say like one of the directions in which we're thinking about building the in-app community. In that meeting that we— that took us like a few hours to prepare for, we now can see what is the energy of this person? Did they look at these and get so excited and they're like, oh my gosh, I'm going to go launch that test? If that's a really good sign, that means that we're onto something. We've directionally found the right kind of angle into community. If their response is okay, cool, I don't know. If that's their response after seeing 5 of these, then that's not the right direction. We can try something else. So usually I would say like 1 to 2 weeks without building anything, you know, with a lot of engineering also applies to product. We use that all the time at Mutiny.

Did you have one final tip here that you want to share on your deck, or was it the wrap-up here?

Oh yeah, so my one final tip around speed was— this is the question that I always ask myself, which is, are we moving as fast as possible toward the most important thing? And usually what that does is it— I realize, oh, I don't remember what the most important thing is right now. I've lost kind of my compass since we did our last planning. And so I have a moment to kind of really think about what is the most important thing and then convey that to my team and then assess whether we are moving as fast or not. And so this is where I start reorgs from, resource reallocation, hiring plans. Like, it always kind of comes back to this question for me.

Excellent. Well, thank you so much, Jaleh. Cindy is saying excellent presentation with actionable items. I 100% agree.

Great. Thank you so much for having me. Thanks, everyone.

Thank you.

I need some traction.