As startups scale from 50 to 100 to 500 people, cracks in their operating systems often emerge. For much of the past decade startups could keep growth steady by paving-over the fault lines that emerged with venture capital dollars. They’d buy customers with promos (Postmates, Uber) resulting in poor CAC to LTV ratios. Or they’d throw bodies at the problem, hiring vast sales teams (Carta, Toast). As we’ve seen with significant recent layoffs, that’s no longer an option.
So how do you grow when capital will be more constrained? How do you prevent these fault lines from forming in the first place? I’ve been a full-time head-of-marketing for 4 startups and an in-the-weeds-advisor to 4 growth stage CEOs, which means I’ve had plenty of chances to get this wrong, and this post will help you leapfrog the growing pains I’ve experienced. This post will help you design your company’s goals, organizational structure, and planning processes to prevent fault lines and promote speed. Here are the six rules we’ll cover:
Rule #1: Get your whole organization aligned on the growth model and the levers that drive growth
Rule #2: Organize squads around each lever, and pick thoughtful north star metrics to measure each squad
Rule #3: Actively deprioritize: make it clear what you’re okay missing and what fires should be left to burn in order to hit the north star metrics
Rule #4: Avoid HiPPOs. Create a quantitative, rational framework for evaluating which projects get us the most leverage on each key metric
Rule #5: Sub-divide into cross-functional two-pizza teams; too much collaboration can slow teams down
Rule #6: Let squads stay-the-course for multiple quarters (at least) so they can build domain expertise and pick up speed
On our podcast, we believe there’s as much to learn from failure as from success. So what better way for me to illustrate these 6 rules than by sharing six mistakes I’ve made leading growth teams. Tally ho!
Mistake #1: Team Isn’t Aligned on What the Key Growth Levers Are
It was my second week as head of marketing at a growth stage startup. We were at an annual planning leadership offsite, and my CEO wanted to establish customer targets for the year (totally reasonable). He’d asked our consultant-VP-of-Finance to do a first pass. The approach went something like this: “based on our growth rate the past two years, this year we plan to grow customers by 20% every month.” He laid out the historical data, adjusted for seasonality, and laid out the coming year’s targets. Everyone nodded their heads: this seemed like a data-driven approach. And the rest of the leadership team thought in terms of projects shipped or people hired, not in terms of levers pulled.
The trouble with that approach is that Customers is a lagging indicator. And looking at customer growth in isolation overlooks the leading indicators or drivers of customer growth. In our. case, those leading indicators included incredibly strong category growth which had driven organic leads, giving our business significant tailwinds. I felt that we ought to build a different model. But, hoping to seem agreeable, and hungry to deliver on these ambitious goals, I went along.
That was my failure: I was so new that I hadn’t had a chance to build a proper model, and I was too inexperienced to go with my gut and advocate for a different approach. A few months later I did build a proper model. It showed category growth and organic lead growth were slowing, and we’d likely miss our targets. I had to go back to the board the next quarter and re-state our growth targets downward. Not a good look for the new Head of Marketing. Yeesh.
What I’ve learned is that it’s incredibly important to boil the business down into growth levers, build the model, and educate the exec team (one-by-one if you have to). For a SaaS business like ours, we distilled the business down to these key levers:
Organic Leads
Marketing Spend
Cost per (Paid) Lead
Lead > Subscriber Conversion rate
Churn rate
The way I really drove-home the levers was by creating a better model: one that showed how moving each lever changed our customer growth trajectory. Here’s a simple model you’re welcome to copy that may translate well to your business. I found that a more complex version with cohorting was of course more helpful for the growth team, but actually less-helpful for teaching and demoing with the exec team.
Now, going back to our VP of Finance from earlier who planned to grow customers 20% MoM. With this model in hand, I was able to illustrate how that might happen. In this model, there are 4 levers we can pull to grow Customers by 20%:
Increase budget by 20%
Ship a 20% improvement in Cost per Lead (ex: landing page improvement that converts 20% higher)
Ship a 20% improvement in Lead > Subscriber conversion rate (ex: checkout page that converts 20% higher)
Ship a 20% improvement in Monthly Churn rate (ex: onboarding experience that retains 20% longer)
To sustain 20% MoM customer growth, we’d need to ship one initiative like this every… single… month. Once our department heads grokked that, it gave us so much clarity. And it fueled a sense of urgency. Now we could work backwards, mapping initiatives to months to outcomes. The next two years we grew revenue by roughly 6X.
Mistake #2: Teams Are Not Organized Around the Right North Star Metrics
Picking the right north star metric is incredibly powerful. Facebook’s early growth team decided their key lever would be engagement, and famously chose 7 friends in 10 days as their north star metric. What’s often overlooked in that story is that they chose to 7 friends in 10 days over the more prevalent MAU and DAU metrics that competitors were using to measure engagement. They did this because they believed 7 Friends in 10 Days would be a more actionable north star metric for the team. Aside: To make this post a drinking game, take a sip every time I say “north star metric.”
When I joined a recent startup, our sales manager was measuring his team on meetings booked and dials per day. Sales ops was measured on keeping the sales team happy. Our email marketer measured herself on open rates and click-through-rates. And our Director of Marketing was measuring her agency on cost-per-click and leads.
How I Imagine our Growth Squad
These metrics are convenient, which is why we so often reach for them. But they are are also siloed. They’re too narrow. After all, who cares if open rates are off the chart if the Leads don’t convert to Opportunities? A growth squad, like the Avengers, is a cross-functional team that comes together to fight the biggest baddies, the ones too strong for any one to beat alone. And we need metrics to match.
So the biggest change I made was to set up a cross-functional growth squad that were each organized around moving one key lever. We were spending mid-six-figures every month on paid search and paid social and we had just brought-on a strong agency to manage it, so the first growth squad we had the capacity to spin up was a “Leads Squad.” But the key is how we chose to measure them.
We considered a north star metric of total Leads but this was too loose - we’d have no sense of the lead quality. Our product team was working on a new qualification engine which would enable us to measure Product Qualified Leads (PQLs), but it was still 4 months from shipping. We needed a quality-signal we could measure today, so we chose to go down to the SQL level.
At first the Leads squad, especially Phil our excellent agency lead, pushed-back: the sales team can fudge who they converted to SQL, which puts us completely at their mercy. The counter-argument is that the sales team is measured on Customers regardless of how qualified leads are, which puts them totally at marketing’s mercy. This shared-accountability was a bet, but one that paid off handsomely.
The other variable at play was budget: if we increased budget, they’d inherently deliver more SQLs. I wanted a metric that isolated the squad’s contribution from budget increases, so I chose the north star metric of Cost per SQL.
Over the course of the next four months, our cross-functional Leads squad, aimed at it’s Cost per SQL north star, surfaced unlikely problems and creative solutions:
The agency noticed Cost per SQL was 20% worse on weekends when we had few sales people working, so we staffed up on weekends and closed the gap.
Our target customers are suburbs so we were excluding rural and urban zipcodes at the ad level, but discovered Paid Search leads were being disqualified before the SQL stage because of geography. When we dug-in, the team discovered Google’s zipcode-based targeting wasn’t as accurate as Facebook’s, and switched Google to targeting by city radii instead.
We knew that our connection time from inbound lead to call was averaging days, and wanted to bring that down to hours, so our sales ops manager Aaron and marketing ops manager Johnna delivered project after project to bring that connect time down to hours.
By my sixth month mark at the startup (and our growth squad’s fourth month in existence), we’d managed to double our mid-six-figure spend while simultaneously reducing CAC.
Mistake #3: Leaders Don’t Actively Depriorize
When you’re changing how teams are managed and measured, there can be a tendency to keep stacking new “top priorities” on top of one another. What’s important is that you also make it clear what it’s okay to stop doing.
As a leader, it’s important you also actively depriortize. I loved this recent interview where General Stanley McChrystal said:
The real courage in a leader is not in telling people what to do. It's telling them what it's okay not to do, because there's a whole bunch of other things that they kind of think they should do and the leader has to sign up and say, "If you don't do any of these, I'm okay with that, as long as you do these things that really matter.
I once worked with a consumer SaaS business where 90% of our customers churned with the first year. I was also aware that our top of funnel SEO advantage, which had sustained our acquisition growth for years, was starting to lose ground to competitors. I banged on the table in department heads meetings, explaining that we urgently needed to implement SEO fixes, but with such a small engineering team, there were always too many competing priorities, the team was unfocused trying to solve acquisition, conversion, and retention, all at once, and we weren’t making substantial gains on any front.
The mistake I made is that with such a large leak in the bottom of our funnel, I should have said it’s okay to fail at acquisition as long as we succeed at retention. The model I later built showed quite clearly that if we doubled acquisition, the business would double within 4 months, and then plateau once again. We needed to let the acquisition fire burn and focus putting out the retention fire.
Mistake #4: No Framework for Prioritizing Projects Rationally
I see two things happen pretty often with growth teams. First, when growth teams are staffed by folks who are new to growth, they sometimes gravitate toward shiny objects, like a SaaS company launching a referral program or a contest. Second, the decision on what to pursue ends up being governed by HiPPOs, which I recently and delightfully discovered refers to “Highest Paid Person’s Opinion.” The solution is the same: a prioritization framework rooted in math and experiment data.
Let’s take our simple growth model above. Let’s say our growth squad is focused on improving the MQL > Opportunity lever. They might brainstorm many projects to move that lever. The goal is to use historical experiment results and the team’s experience to estimate the level of effort and impact of each idea. Then we prioritize the ideas that are the highest leverage, meaning they achieve the highest impact at the lowest effort. This framework has been floating around for years, but here’s my personal Growth Playbook Template.
Prasid’s Growth Playbook Template for Project Prioritization
Mistake #5: Org Structure Slows-Down Execution
Jeff Bezos made famous the idea of 1-way and 2-way doors. His thesis: if the decision is reversible, reduce decision-making rigor and prioritize speed. Similarly, Netflix made famous a hiring approach to hire the highest quality talent and empower them with fewer layers of oversight and rules. The thesis: great people self correct, so reduce oversight and prioritize speed.
Similarly, I would argue organizational design is a tool we can use to promote speed, rather than retard it. Let me share an example that will likely sound familiar: when Bloc was small, I’d grab the nearest engineer and ask for help doing whatever needed doing. As the company scaled, our first PM suggested a weekly planning meeting where stakeholders could come together, discuss project priorities, and decide what to tackle.
The team grew further: now we had the Heads of Customer Success, Design, Marketing, the COO, both founders, and a handful of stakeholders from individual teams all lobbying, every week, to get their engineering tasks prioritized. We wanted to be data-driven, so stakeholders were encouraged to bring data. On numerous occasions me or my directs would spend hours prepping charts and graphs for the meeting, when completing the engineering work itself would’ve taken 30 minutes. The problem looked similar at SoFi and Rafter before that, and similar at Codecademy afterward. The solution, it turns out, is another of Bezos’s greatest hits: the two-pizza team.
Above: the structure we started out with at Rafter, SoFi, and Bloc. Below: hypothetical squad approach, resembles structure at Codecademy
As soon as a startup scales to the point where you have many stakeholders chasing engineering priorities, it’s time to sub-divide into squads. Others have done a fine job of documenting the data backing-up two-pizza teams but Bezos sums it up well:
“Communication is a sign of dysfunction. It means people aren’t working together in a close, organic way. We should be trying to figure out a way for teams to communicate less with each other, not more.”
The more nodes we have in the team, the more coordination is required. When the nodes have competing north star Metrics, thrash increases, and throughput declines dramatically.
So how should you organize your two pizza teams?
Lewis Black is my spirit animal
Around your North Star metrics of course!
Depending on the North Star metric, the cross-disciplinary talents you need on each squad will vary. In Kieran Flanagan and Scott Tousley’s Growth TL;DR interview, Calendly’s VP of Product Oji Udezue says Calendly recently added representatives from Product Marketing and Customer Support to every squad within the company. (Sidenote: before starting our own podcast I listened to tons of podcasts. Growth TL;DR has been the most consistently helpful as a startup marketing operator!)
For the example above, I can imagine stakeholders across both marketing and product working together on a top of funnel growth squad whose North Star metric is growing MQLs per month, while a second squad with Product and Customer Support folks might join a Customer Retention squad whose North Star metric is Month 1 NPS.
Mistake #6: Reorganizing Squad Members and North Star Metrics Too Frequently
You’re likely familiar with the life-changing magic of OKRs. Codecademy had an incredibly talented team and worked hard to be the best-run startup possible. As we scaled past 75 people, we started involving the whole organization in OKR planning. The leadership team set company goals, then each department set goals, then each individual. This meant spending a week meeting and planning, then another week aligning across teams. Squad assignments needed to get adjusted, and squads might be merged or split in two. And before we knew it, the process was taking 3 weeks, leaving just 9 weeks per quarter to execute. Once plans were settled, it would take time for teams to build-up context before they could start shipping. And just as the team was starting to pick up momentum, the quarter ended, and the process started over! Blast!
Our mistakes were twofold:
First, our goals were shifting too aggressively each quarter. It’s healthy to grade and tweak OKRs quarterly, but changing key levers entirely or forming new squads should not be happening once every twelve weeks. By doing that we were crushing the team’s momentum just as they hit their stride.
Second, we were sensitive to team members who wanted to rotate rather than being pidgeon-holed into one area of the business. Engineers were attracted to obscure technical challenges rather than the levers that really drove the business. Designers glorified product design rather than conversion optimization. And as a mission-driven freemium education startup, folks across the board were keen to work on the free courses, but uncomfortable thinking about paid conversion.
One solution is to make growth squads permanent. Calendly’s Oji Udezue argues there are speed benefits that come from engineers with specialized domains, and designers can leverage hundreds of hours spent interviewing a single customer persona to solve problems faster and better. The added upshot of making squads permanent at a mission-driven startup is that candidates know the team they’ll be working on before they join, so when you hire a growth designer or growth-engineer, they go in fully-aware they’ll be working on growth.
Conclusion
Now more than ever we need to build growth into our operating systems: our goals, processes, and organizational structures. When we do this right, we unlock enormous speed, achieve a greater business impact, and ultimately build sustainable organizations that will leave a lasting impact on our world. Here are six rules one more time:
Rule #1: Get your whole organization aligned on the model and the levers that drive success
Rule #2: Organize teams around each lever, and choose north star metrics that’s are broad leading indicators rather than narrow siloed metrics
Rule #3: Actively de-prioritize: help your team focus on the north star metric by making it explicit that it’s okay to fail or delay other things
Rule #4: Fight the HiPPOs! Create a quantitative, rational framework for evaluating projects, and weight them by the leverage gained
Rule #5: Too much collaboration can make teams slower. Set your team free by sub-dividing into cross-functional two-pizza teams
Rule #6: Let your squads stay the course for multiple quarters or years so they can build domain expertise and move faster
Thanks for tuning in. I hope these mistakes were as helpful to learn from as they were rough to re-live. If you liked this post, or, better yet, disagree, let me know in the comments! Goodnight, and good luck.
