Leah's Growth and Organizational Scaling Guide
Leah's Growth and Organizational Scaling Guide
Learn to walk before you run.
Let’s get you kickstarted on growth and scaling your organization.
I also have another guide on product-led growth.
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 Why do 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. Why do MQLs suck? 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.
As 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. It’s rare that they 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, in order 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.” → Facilitation of 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 has no effect on 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. When teams commit to OKRs they make a commitment. These commitments should be re-assessed on a regular basis. 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 in order to improve.
Read more about this: Book “Team of Teams” 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.
In order 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, drives 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 quality
Works with other teams
Variations:
Technical Product Manager: A more technical profile that creates APIs / SDK, etc.
Product Marketing Manager: 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 develop software in a sustainable way.
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 in regard to 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 definitely 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 absolutely makes sense to have at least every system to be covered incase 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 stake 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 should be attached to the product though:
4.1 Skills for growth and how to improve them
Due to the broader skillset for anyone in growth compared to classical product work, we need a different view on it.
Adam Fishman’s growth competency model is an excellent way to look at these skills. There’s a detailed description of each skill in the article that doesn’t need repetition here.
The following is how I personally gained knowledge in the different skills and might serve as a practical guide on how to do so yourself.
4.1.1 Growth execution: channel fluency
Distribution channels change fast today - staying on top of those is a challenge in itself. You need to understand your domain well to excel at channel fluency.
You can’t outsource this. So an impactful strategy for channels rests on how well you understand your target customers and how to approach them.
I gained a lot of insights by reaching out to peers in similar industries and simply asking them: how do you engage your channels? A general pattern is that one channel tends to dominate all others by 80 / 20 in terms of efficiency.
4.1.2 Growth execution: experimentation
The first step is to know what key metrics to track and how to utilize them. A great resource to get started is Alistair Croll's book “Lean Analytics: Use Data to Build a Better Startup Faster”.
Then you build your experience. Using the results of experiments to inform future product development decisions is a continuous, conscious effort. That includes solid documentation and the ability to resurface past learnings.
4.1.3 Growth execution: productizing learnings
There are a couple of conditions to turn learnings into productive outcomes:
Future learnings need to be meaningful from the onset. Creating experiments with the future intent of learning from them affects how they are structured. Success is a byproduct. A good documentation mindset allows for creating impact from present learnings in the future.
For instance, store learnings in a retrievable way - you could tag them by:
The nature of the learning
Which part of the customer experience they affected (monetization, retention, acquisition)
If any metrics were affected and how
How the learning is surfaced, with what hypothesis, and through what methodology
How long it took
The methodology above can help you learn how long specific measures took and what we can optimize in the future. It’s not about cutting corners as much as it’s about thinking: “How can we validate whether an Idea or opportunity is good without fully building it?” The answer is not always an MVP; it could also be a painted door or similar forms of testing.
“The Lean Startup” by Eric Ries deals with this core topic.
4.1.4 Customer knowledge: instrumentation & data fluency
My journey to data fluency is structured in 3 subskills:
Surface data: Understanding SQL as a language empowers me to pull data whenever I want. A powerful service with no added frills I recommend is LearnSQL.com - you can start there from zero. In addition, you will get an appreciation on how tables and data structures work.
Understanding data: I have a basic understanding of statistical analysis and how product funnels and loops interact with each other. Some of it comes from experience, and I’ve found certain behaviors tend to be the same.
Specific monetization behavior. For instance, when the feature is free, the free-to-trial rate tends to go down, while the trial-to-customer rate goes up.
The fundamental understanding of value capture and value creation metrics and how to analyze/measure them.
Communication and data visualization: Learnings from data can often be complex at times but they still have to be communicated simply.
My favorite tool (at the very, very beginning) for this is still Google Sheets if the company doesn’t have good BI tool integration. You can use most visualization methods, and the recipient can play with it as well, and adjust the underlying data inputs themselves.
Otherwise, the usual kids on the block like Amplitude come to mind. I prefer tooling that can query directly in your warehouse with SQL. Learning this properly is a good practical skill to have.
4.1.5 Customer Knowledge: User Psychology
My gateway to user psychology was studying human-interaction design 20 years ago. It’s not an exact science, but knowledge about human cognition is always valuable to have.
Jobs-to-be-done: This is an approachable framework of what and how people “want” and “need”.
For beginners: Alan Klement’s introduction to the topic is still one of the best, and it’s free.
Advanced: For a practical follow-up, try Jim Kalbach’s “The Jobs To Be Done Playbook”.
Habit formation: Understanding how humans form habits - which are in essence individual recurring loops - can help understand users.
"Hooked: How to Build Habit-Forming Products" by Nir Eyal is a good study on this topic.
4.1.6 Customer knowledge: creative & narrative development
A solid grasp on ICP that segments your users, as opposed to a feature-driven view, is a table stake before you start tackling the question of how to talk to them.
Qualitative research/interviewing:
Switch Interviews, by thoughtbot
Marketing 101: “Marketing 4.0” & “Principles of Marketing” by Philip Kotler and “Contagious” by Jonah Berger.
4.1.7 Growth strategy: growth loop modeling
Advanced Growth Strategy at Reforge
Nir Eyal’s "Hooked: How to Build Habit-Forming Products" covers this topic quite well thanks to its connection to habits.
Flywheels using Loom as an example - A detailed practical presentation of how Loom employed the flywheel framework to get to 10mio ARR.
Other than that, growth loops are highly individual and can only be measured and discovered meaningfully if your data setup is in order.
4.1.8 Growth strategy: capital allocation & forecasting
Cost forecasting and business valuation are like drive-ins and McDonald's. Especially if you get into more impactful positions.
I learned business valuation by working through the McKinsey brick: “Valuation - Measuring and Managing the Value of Companies” which I found very thorough.
For good forecasting and allocation, have a thorough risk and reward overview and assessment of existing and past opportunities. Select the opportunities that you can further refine as needed.
4.1.9 Growth strategy: prioritization & road mapping
Knowing when and how to prioritize is an invaluable personal and team skill.
If you cannot axe your own backlog out of poor prioritization, you can’t do it for your teams either. Oliver Burkeman’s “4000 Weeks” is my single most impactful read when it comes to personal prioritization.
Prioritization alone is not good enough, you need to get rid of commitments. The best is to limit what you take on. Since that doesn’t always work we should be great at managing expectations
"This is not at the top of my list and I won’t deliver it”. This allows the other stakeholder to find alternatives in time and does not cover up resource shortages.
Roadmapping and team prioritization are in the same vein:
Per definition, roadmaps are fuzzier the more time passes. For teams to focus on problems rather than feature delivery requires an understanding of problem frameworks like JTBD. See 4.1.5
To compare opportunities and risks, you require easy methods to evaluate business cases and when they need more time for substantiation. Only then does a good long-term plan have a chance of surviving.
4.1.10 Communication & influence: strategic communication
Summarization is an undervalued skill when it comes to strategic communication. This holds true when you communicate a strategy downward with the goal to create understanding and alignment. Or upwards, where the goal is to offer an overview to make a decision.
The structure of a great investor deck or business case is at the heart of any internal communication to excite and align people. I usually go by the following structure:
Story: Who is the villain?
Traction: Who is the hero to save the day?
Potential: What happens if you don’t deal with it? What if you do?
Execution: Why are we the right ones for the job?
4.1.11 Communication & influence: team leadership
Communication: Read “Radical Candor” by Kim Scott. Show people that you care through candid feedback instead of resorting to the old “shit sandwiches” concept - that’s a powerful learning of my later career years.
Whether your feedback is positive or negative, it should always carry in itself proof that you listened and engaged with the other person. If whatever you say to a person could be applied to the one standing next to them, it’s worthless. Not to mention disrespectful.
Team Leadership: Assuming you know how to build good teams, leading them is a function of how well you can disconnect from the distracting noise. “15 Commitments of Conscious Leadership” helped me focus on what benefits the team. It comes down to whether you can drive alignment in collaborative environments through 3 levers: transparency, autonomy, and accountability:
Never EVER deprioritize your team’s personal growth with your direct reports. This is the single fastest way to destroy trust and performance, regardless of other factors.
4.1.12 Communication & influence: stakeholder management
Especially as companies grow, there should be more “non-established” teams positioned well in the company. After hitting a particular size, politics and competitiveness get into the mix.
Specifically, growth teams need lots of evangelism when it comes to what they “do”. Common misconceptions are that growth is responsible only for acquisition.
Having a good practical, simple explanation ready of what “growth” means in the company's context can be crucial. Establish a culture first, then scale the teams itself.
5. Summary
How it works
Growth is a function around user acquisition but also retention and monetization. It concerns itself with the entire user experience including before and after experiencing the product.
Who’s it for
Any company that want’s to scale it’s business and revenue exponentially should invest into growth conciously.
What it requires
You need to have product-market fit, otherwise you lose any achieved growth immediately again.
Organizational Conditions
Outcome-driven goal setting
Collaborative environment
Crossfunctional Team structures - PODs
Strategy & Growth
Data-driven environment
Bringing growth into your org
Growth Teams are built from bottoms up
Either from Marketing or Product. Internal hires hve advantages
Attach them to product for easier influence coverage
Build a culture of growth first, then hire a semior leader
6. Further in-depth material
Reforge Growth Leadership course (releasing soon)
6.1. Leah’s product-led growth guide
My other guide features another important scaling topic, the road to product-led growth
6.2 ElenaVerna.com
Elena has about 4001 frameworks and memes combined on Growth. Her ability to have clear, battle-tested opinions made her one of the leading voices when it comes to aligning growth marketers and product people alike on the concept of Growth and PLG in B2B Saas.
6.3 Adam Fishman
I always appreciated Adam’s very actionable perspective on what growth is. His unmistakable candid takes convinced me to rethink some common beliefs I held in regard to Growth.
6.4 BrianBalfour.com
Brian has since incorporated lots of his knowledge into reforge but some of his older articles are still relevant today.
Specifically, his “Growth Machine” series is worth a read for anyone
"Whether your feedback is positive or negative, it should always carry in itself proof that you listened and engaged with the other person."
Preach. There are few greater trust destroyers than making people feel like when they've shared something really important with you after you asked for it that you couldn't be bothered to pay attention / listen / care about the answer.
Wath's the most important aspect you should focalize to create a scale growth of your business model?