Leah's Growth and Organizational Guide
Learn to walk before you run.
Let’s get you kickstarted on growth and scaling your organization. This guide is part of a bigger series covering all company stages.
Hi, my name is Leah Tharin and this is my Substack: hot takes on product-led growth/sales and organizational scaling.
I consult with scaleups on how not to burn down everything in the process.
Table of Contents
What is growth and why should you care?
1.1 Other industry leaders on what “growth” is
1.2 Classic MQLs suck. What’s the deal with Marketing?
1.3 The connection to organizational scaling
1.4 Example: Product-led growth and scaling
1.5.Example: Sales-led growth and scalingWhat does growth look like in action?
Organizational conditions for effective growth teams
3.1 Organizational structure
3.2 Outcome-driven goal setting
3.3 Collaborative environment
3.4 Cross-functional team structures - PODs
3.5 Strategy & growth
3.6 The size of your organization and adverse effects
3.7 Data-driven environmentYour first growth team/hire
4.1 Skills for growth roles and how to improve themSummary
Further in-depth material
1. What is ‘Growth’ and why should you care?
Growth as a functional unit in your organization - much like ‘product’, ‘marketing’, or sales - is an often misunderstood term. The most common misunderstanding is what it should concern itself with.
Without an efficient growth function, you will unlikely scale your organization in an efficient way.
Let’s get one thing out of the way. For the rest of this guide, I will talk about growth assuming one principle:
Growth is a function around user acquisition, but also retention and monetization. It is the logical fusion of product and marketing to chase customer success.
Many organizations’ treatment of “Growth” (or Marketing) is limited to “acquisition”. I will try to outline why this is a recipe for disaster and limited impact later on.
Growth affects much more of a traditional user journey than classical product teams and validates often with hypothesis-driven experimentation.
Growth teams rely on data infrastructure because of that.
Growth as a function appears ideally after a company has acquired product-market fit or the ‘scaling’ stage. In practice, those lines are blurry.
Growth teams are usually comprised of Product & Marketing competencies in one team, which makes them unique.
Ideally, Growth teams report to the Product.
Growth tends to be the most impactful with a bottoms-up approach, contrary to other functions, i.e. starting with a small team, adding more, and only finally a head of growth.
1.1 Other industry leaders on what “growth” is
“Growth is building a predictable, sustainable, and competitively defensible distribution model for the product across acquisition, retention, and monetization levers.“
Elena Verna, Growth Advisor for B2B SaaS, Elenaverna.com
“I define ‘Growth’ as the human(s) or function(s) that understand how a company grows, what levers they have to accelerate that speed and scale, and then create a measured, tactical approach to testing those levers to separate fact from fiction.”
Adam Fishman, Interim Executive, Program Partner, and Exec in Residence at Reforge FishmanAfNewsletter.com
1.1.1. Common problems
Growth being mistaken for "Marketing with engineers"
Growth and Acquisition teams are commonly mixed up. This hurts the support they get from other functions easily.
Tension from other Silos
Marketing, Sales, and Product feel commonly threatened because they think growth teams come to play in their garden. Growth does not necessarily have a focus on any other silo, they just have the possibility to go where an opportunity is.
Growth is incentivized to connect users to value, by any means necessary
We historically built organizations in ways that are simple to set up but hard to manage. It's easy to separate the customer journey into 3 steps. Acquisition -> Retention -> Monetization. It's easy to build teams around it.
But it's not the reality for the customer. Understanding the holistic experience of a user is what growth is concerned about. This naturally clashes with how we build organizations
Setting up Growth in an organization is a cultural thing.
The more customer focussed other silos are, the more likely they understand the mission of "Growth". In either case, typically growth teams are set up for that reason as teams first and then department leads next.
This allows the company to slowly get used to the new player in town. I've seen it commonly attached to a Product or being an independent organizational silo.
Common organizational structures are not ideal for growth teams
It has to be said: Growth Teams have a tough job. Their organizations are not set up ideally for them. It's just the way things are today. We moved from matrix organizations to cross-functional teams years ago. The industry may have to be ready for the next step: Customer journey reflecting organizational constructs, not functions.
We don't challenge other functions with growth, we support the customer.
1.2. Classic MQLs are not enough. What’s the deal with Marketing?
Marketing qualified leads (MQL) deserve a special mention in this guide. The way that classical Marketing has operated within companies is that they generated MQLs which were handed off to sales.
They also illustrate beautifully how customer success is replacing silo thinking (Marketing → Sales → Product)
The quality of these leads was defined by marketing itself so far and the only measurable quality to them was often the quantity.
Lots of leads? Good. Not so many? Not so good.
Like other things in outcome-driven environments, we are starting to put metrics into context. Not only “how many” but “how good” are they?
If we agree with this premise, what is there to be done? Growth teams are a (partial) answer to this. Essentially, if you insource marketers into product teams and expand their garden you get something like a growth team:
A team that is not satisfied with just generating leads but also seeing them all the way through. They understand with data whether the leads were not only many but also of good quality.
Due to the usage of data in this way, they can detect and prove much more marginal changes than classical marketing practices ever could.
Modern Marketing departments are catching up to this trend and use data to inform their activities that are tracked until the end of a customer cycle.
The problem that still persists even if they track the quality of their leads is that marketing teams often lack engineering resources making any interference in product or monetization difficult
Growth teams have both. Data and engineers.
1.3 What’s the connection to organizational scaling?
Whether your method of distribution is product-led, marketing-led, or sales-led growth, the proven method to have a successful product is always:
Have a great product: (Product Market Fit)
The value proposition is serving a pressing need
The product is so well done that it retains people at a good rate
People are willing to pay for it to keep it in their life
Have a great distribution: (Scaling)
Scale what got you product-market fit
Maintain what makes your product retain to prevent churn
Defend your current user base and further optimize your acquisition, retention, and monetization
The 2nd point is key here. Scaling it all affects 4 areas:
Organizational scaling. More people as growth is added as a function. Other functions like marketing, product, and sales are expanded, as well as support functions like dev ops, product ops, etc.
Acquisition scaling. Marketing/growth can use more channels to attract more users.
Leverage scaling. Due to your hopefully growing revenue, your options in the market are starting to increase.
Innovation to optimization shift. While you don’t stop being innovative, a new need is emerging. You need to defend your existing user base. If you don’t have any users, there’s nothing to lose. That changes as you scale - you need to not only add new growth measures but also defend and balance against existing ones.
Out of those 4, organizational scaling is the easiest one to get wrong. It can stop you dead in your tracks if you don’t know how to build your organization up. What worked so far doesn’t work anymore.
That’s why we need to tackle it in the same breath as “growth”. They are inseparable.
1.4. Example: Scaling with “product-led growth”
Proof your free user acquisition. Get a small number of free users with a method you can repeat in the future once you're ready.
Proof that you can retain them at exceptional rates.
Proof that they are willing to pay for it.
You just achieved product-market fit.
If you did everything right, you have a proven loop that you can scale. The lack of this is the most common reason for startups to die. They don't mess up the distribution, they never manage the proof for 1.-3.
Time to scale:
4. Scale and repeat what you did on 1.
5. Maintain what you learned from 2.
6. Defend and optimize what you did on 3.
Now hopefully you are rich because you provided actual long-term value to your users.
Read more about product-led growth: My ultimate guide to figuring out and implementing PLG
1.5 Example: Scaling with sales-led growth
The principle is largely the same as with product-led growth. While you won’t necessarily achieve product-market fit by adding more salespeople, you can deliver proof of it. Without product-market fit, you won’t be able to sell anything in today’s markets.
Once your product matures and the founder hopefully figures out what the market wants and becomes better at selling it, they can teach others how to sell it. Only if that is teachable can you scale in the future.
There is an important caveat though. Sales-led organizations tend to be quite good at optimizing their value proposition and monetization, they tend to underdevelop their retention though.
Good product retention is not necessarily visible in a sales process. A product might be flashy and good enough to sell, but not good enough to retain your accounts.
Good remedies for that are incentivization for sales that work. Reward expansions and other signals from customers that indicate they get value from your product. This motivates sales to deliver feedback back to the product and not oversell at the beginning.
2. What does growth look like in action?
Growth oftentimes gets mistaken for a pure acquisition function, which is usually already occupied by marketing.
If product teams take care of the product and marketing of acquisition, what’s left?
The entire loop.
Growth teams have a holistic view of the entire customer loop and try to find opportunities in there. They rarely do core feature work, but they might change core features.
“You’re not building new products most of the time. You’re connecting more people to the value that you’ve already created.”
- Adam Fishman
In practice, this means that these growth teams need even more cross-functional members. For instance, to affect anything in acquisition they might have a growth marketer. We’ll look in detail at how these teams can be structured later.
Additionally, their goals are commonly set broader than classical product teams to look at the entire user journey. (See 3.2.2 and 3.2.3)
3. Organizational conditions for effective growth teams
Aside from having found product-market fit, there are organizational conditions that will guide successful scaling.
Many of the following principles apply to all product and growth teams. In some cases, they’re a matter of opinion. Personally, I would not work in any company that does not adhere to all of these principles.
First, be aware of Conway’s law. Any product you create will look like the organization that builds it.
The following concept is how I think about product organizations. Growth teams as an extension work the same. Structuring these teams well reduces friction from an ever-increasing number of teams and the associated pains with it like politics, misalignment, and other communication problems.
3.1 Organizational structure
I strongly advocate for an outcome facilitator-based model. The model is structured around 2 core principles:
Outcome-driven over output: "We aim for a specific if possible measurable impact for the customer over just shipping features” → Business outcome
Collaborative over directive: “The team decides as a unit on what makes sense to build to further the company strategy.” → Facilitating the team
The reason why I advocate for this model is that it tends to be the best fit for growing companies. It’s a bit tricky to set up but scales very well for very common business models like SaaS.
A feature owner model, for instance, is common for very early startups:
The Founder has a clear, strong vision and is hiring lots of contractors to execute this vision early to find product-market fit. It’s directive and noncollaborative in nature.
It’s very easy to set up. You can just divide the few teams you have in areas of your product.
But the feature owner model doesn’t scale well due to the operational disconnect from the founder to the operational layer:
As you add more people to the organization your teams tend to become experts in sub-segments and the founder needs to step into a role that guides the general direction without micro-managing teams.
Without goals and a quality-oriented mindset, teams risk delivering unguided features without impact. That’s why shifting to an outcome facilitator model should help.
Read More on this: Organizational Structure types by Reforge.com
3.2. Outcome-driven goal setting
Outcome beats output in any customer-centric organization any day:
“Our team delivers feature x by (date)” is an output-driven goal.
Output goals are fundamentally flawed because they have no quality attached to them. A team can be successful by delivering something that does not affect the business whatsoever, they don’t have to care about the customer.
“Our team improves the number of documents our users share per user by (date)” is an outcome-driven goal.
An outcome-driven goal is ideally measurable and correlates to the revenue but not directly. We use value-creation metrics as team outcome targets (see next section). This makes them harder to manipulate
By measuring team performances on their outcomes we give them the freedom to do whatever they think is best to influence their goals.
They might figure out that a hypothesis does not deliver the results they hoped which allows them to pivot to other methods which influence the same quality metric (for instance customer happiness).
Read more on this: “Escaping the Build Trap” by Melissa Perri
3.2.1 Value creation vs. value capture
Value capture metrics like revenue and churn live in the management layer and should not be directly influenced by teams through goals.
They are important in terms of evaluating business performance and as a tool for finance but are ultimately a result of customer success.
Customer success leads to long-term business value
Say you have a product team that is directly tied to the revenue with a goal like:
“Decrease monthly churn by 10%” (value capture metric)
They could succeed by making it harder to unsubscribe from your service. While this would undoubtedly decrease your monthly churn, it would anger your customers and destroy long-term value.
It’s much harder to manipulate customer success signals. There is a direct correlation between how much people use our product and how much revenue this generates.
High customer engagement (frequency of product usage) leads to high retention, which is an indicator of customer success. Which, in the end, generates revenue.
Early warning signals make great team goals.
A drop in customer engagement is the first warning signal that your retention will drop and that customers will ultimately leave your product. It indicates things could get ugly.
Engagement is a leading indicator of user retention which is a leading indicator for a drop in revenue.
That’s why defining team goals around engagement and retention metrics are a great way to success.
3.2.2 How to practically set team goals
A great way to visualize outcome goals is to get away from thinking “How much revenue does this feature or initiative bring?” to answering “What metrics does this initiative positively impact which ultimately leads to more revenue?”
You can use a tree like this:
While deliveries are important levers for product teams to deliver impact, we essentially don’t care whether something was shipped - only whether it had an impact.
3.2.3 Growth team goals
It’s not uncommon that growth teams have metrics to influence that cover a large part of the customer journey, if not in its entirety. Instead of increased engagement, for instance, the goal for a quarter might simply be to look at the “free to customer %” rate.
3.3 Collaborative environment
Having a collaborative environment means you regard the expertise of different functions before committing to a solution. The following 3 pillars ensure this is the case:
3.3.1 Shared consciousness:
This is the set of shared beliefs within a specific group. It can be established by sharing information even with peers that may not seem the best fit for said information. It's the opposite of the "need to know principle", where information is only distributed to those that need it to do their immediate job.
You share as much as you can about the process, strategy, and direction as is possible. Including business metrics. We're not producing "Feature 'N'". We are solving a specific problem and understanding the context is important for everyone.
Without shared consciousness, the quality of any decision cannot peak.
3.3.2 Empowerment:
Empowerment is the authority given to a person to do something.
Delegating, giving trust.
Letting people decide without gatekeeping or delegating decisions empowers people.
Asking for permission changes to >> informing others why you did what you did and if those things work >> they get recognition for surfacing it.
If you start to be directive as a manager in the operative layer without offering context (which is normal) will lead to a micromanaging culture.
This creates that frustration of knowing what's wrong but being powerless about it. One of the leading reasons to churn from a company.
Does the added value of giving people authority over what they do outweigh the mistakes that will happen? My firm conviction is: yes.
3.3.3 Accountability:
We need to hold ourselves and each other accountable. OKRs are a team commitment. These should be re-assessed regularly. The principle is: to be honest about progress and failure.
While we love success, the goal is to learn, which makes success follow inevitably.
*Never* punish a team or an individual for their honesty even if it is tied to failure. We should reward a culture of honesty to improve.
Read more about this: Book “Team of Teams” by Stanley Mc Crystal
3.4. Crossfunctional team structures - PODs
The purpose of a Pod is to be an autonomous, impact-guided unit in our organization to deliver value. The ideal size is 4-7 people. Any higher, and the increasing communication lines risk misalignment and friction.
We follow the philosophy:
Wherever possible, we eliminate dependencies - not manage them.
To avoid confusion with “teams” we call them “pods”.
3.4.1. Roles of (growth) product managers
Reports to: Product → Growth
Business and customer expert within the team. Responsible for facilitating ideation, prioritization, and delivery.
Accountable for business value, but also that the team believes in that value. Gives purpose to the team.
Develops deep expertise in the product area.
Creates empathy within the team for the customer and the problems being addressed.
Drives high alignment: shared vision, mission, values, identity, shared context & transparency, drive business value (KPIs), real-time info
Accountable for product backlog & product vision
Facilitates backlog prioritization with input from customers & team.
Focuses on the “what”, and collaborates with Tech Lead / Engineering Manager who focuses on “how”.
Defines what “done” means, accountable for the quality
Works with other teams
Variations:
Technical Product Manager: A more technical profile that creates APIs / SDK, etc.
Product Marketing Manager: The more marketing-driven profile, coordinates with Marketing to ensure that features are delivered into the market properly
3.4.2. Roles of engineering managers
Reports to: Engineering
Engineering manager and technical lead for the team. Responsible for ensuring we sustainably develop software.
Manager of engineers within the team.
People accountability: hiring, firing, performance evaluation, onboarding, coaching, retention. Creates a sports team mentality.
Delivery accountability: focuses on “how”, scrum master, manages sprint, guides toward sustained high velocity, continuous improvement, removes roadblocks, timely delivery
Accountable for technology health but delegates ownership to other team members.
Communicates with other engineering stakeholders. Responsible for negotiating dependencies and resolving blockers.
Time to contribute as an IC Software Developer (only possible in small teams)
3.5 Strategy & growth
Communicating to the company that you’re in scaling & growth mode is oftentimes the starting point for that company to start strategy.
Here’s a primer on how to do strategy right:
The relevance for Growth regarding the company strategy is that ICPs (Ideal customer profiles) are present. Without segmenting your users into the groups that are worth targeting, you introduce a lot of unnecessary friction.
It makes the life of growth teams much easier to know on whom they should focus instead of just “all users”. Optimizing a group of users’ experience which retains well is the lifeblood of any growth team.
Reflecting this in a strategy pays off along with differentiators:
It hinges on the quality of the research done that these differentiators are what ultimately drives value for our users. As your company gets bigger, so does the need for a more diversified strategy you may want to have different strategies:
Product Strategy: What do we believe in when it comes to the core product of our company? → Guides product teams
How do we do products differently? → Product-specific differentiators
i.e. use case feature enhancements, new product features
Growth Strategy: What do we believe in when it comes to our distribution model? (PLG, SLG, MLG) → Guides Growth teams
How do we do distribution differently= → Growth-specific differentiators
i.e. Network effects, sharing, inviting other users, etc?
Company Strategy: What is our strategy for growing our company → Guides company structure
How do we plan to finance, attract new talent, enter new markets, invest in very broad terms, etc?
Ideally, the product and growth strategy follow the company strategy as it is the broadest and dictates resource spend and revenue trajectory.
3.5.1 Team coverage
A common misconception with growing companies is that they think their teams need to cover everything. They think “We need to divide our product among teams to cover everything”
While it makes sense to have at least every system to be covered in case something goes wrong you do not have to cover all areas of your product.
Let's say you have a tech business focused on task management and you know that the two most pressing problems you have to address from your company strategy/vision are the onboarding experience and the lack of integration services to other popular products. Provided you have the resources why don't we structure the teams exactly around that for a couple of quarters?
This creates focus and allows the teams to be bold within their gardens. In general, early startups need to focus more on innovation rather than optimizations and a structure like that tends to help that since it's not feature-focused.
3.6. The size of your organization and adverse effects
Teams have more impact than individuals.
Smaller teams that stay together for a long time outperform short-lived huge teams.
Dunbar’s Number
Dunbar’s number visualizes how we communicate and can keep track of relationships with our peers.
~5: Close personal relationships and working memory
~15: Limit of people with deep trust
~50: Limit of people with mutual trust
~150: Limit of people whose roles we can remember
Resulting Consequences:
A single team or POD: 4 to 7 people
In a great working organization: no more than 15 people per team as an exception
Domains / Tribes: Groups of teams of no more than 50 people in total
In a great working organization: no more than 150 people
Divisions: Groups of no more than ~150 to 300 people
Read more about this: Book “Team Topologies” by Matthew Skelton and Manuel Pais
3.7. Data-driven environment
A great business practice and table stakes before you can drive sustainable growth are to track your business and customer metrics.
Assuming you set goals for your teams with value creation metrics as defined above you also need to track, surface, and leverage them.
Whenever users use your product you need to track those events in a fashion that makes sense.
Success Moments, value signals
Setup Moment: The moment when a user uploads a file. → They are ready to go and interact.
Aha Moment: The moment a user modifies and downloads a file. → They’ve realized the value of the product.
Eureka Moment: A user invites other users to edit the file with them. → Not only did they realize core product value, but also additional in-built values like “collaboration”. This is an important signal that they are buyers.
Habit Moment: A user processes more than 3 documents/day over 30 days. → These guys are likelier to stick with you and become buyers!
Retention
1-day / 7-day / 30-day
Trial created
Customer created
Accounts created
Feature usage
NPS, CES → Read more on actionable Satisfaction Metrics
Share feature used
MRR, Revenue ← Value Capture Impact
Surface data: Dashboards and an experimentation setup to easily look at data should be in place before you launch anything.
Leverage data: Hypothesis-driven experimentation is the name of the game. We predict a change in the product to have a specific impact. Good data allows us to learn what works and what doesn’t.
Read more on this: Reforge, Data for Product Managers
4. Your first growth team/hire
Let’s assume we are ready with:
Product-Market Fit achieved
Outcome-driven, collaborative structure
Small, cross-functional team size (Pods)
Excellent data and customer success tracking
One fundamental difference to other functions is that growth teams are ideally built from the ground up. This usually happens out of other product teams. Internal hires are not uncommon:
Growth is sometimes seen as threatening by product or marketing teams because of their sphere of influence
Gaining a basic understanding of the entire user loop tends to take longer (and a broader skillset) than understanding “just” the product, someone with existing pre-knowledge needs less time to get traction
These two factors are also the reason why starting first with a growth-minded team can make sense. The organization gets used to it slowly. Once that team gains traction the opportunity for a head of growth slowly starts to arise (and more growth teams).
Either way, your first growth hire comes usually either from Marketing or Product and needs to grow in the other function respectively to cover the entire spectrum.
The team itself more often than not should be attached to product though since they have almost similar team structures:
Keep reading with a 7-day free trial
Subscribe to Leah’s ProducTea to keep reading this post and get 7 days of free access to the full post archives.