How To Scale A Product Team From 0 To 15

2/14/24, 6:55 PM How to Scale a Product Team from 0 to 15 - by Aakash Gupta
How to Scale a Product Team from 0 to 15

+ The Tech Wreck Is Turning Around
JUL 11, 2023 ∙ PAID
41 2 Share
In Today’s Newsletter:
The Tech Wreck Is Turning Around
🔒 How to Scale a Product Team from 0 to 15
The Tech Wreck Is Turning Around

The tech market is turning around across the board - private and public markets.
Private Markets
On the private market side, we have none other than Carta to look to, which has made
itself a must-watch with its constant stream of data. The latest drop, on Startup
Valuations is a doozy:
https://www.news.aakashg.com/p/how-to-scale-a-product-team-from 1/39
The unicorns are still suffering. Series D valuations are 55% below where they were in
Q1 2021. But Series A & Seed are already above early 2021 levels. Series C and D are
headed the same way.
There was clearly a distortion in the growth equity funding market, with players like
Softbank, Tiger, and Fidelity rushing in with all too much capital. But other than that
slight hangover, tech funding - and thus hiring - Series C and below has burst back.
Most of the laid off people I’ve been working with land jobs at these venture-backed companies.
Public Markets
The big Tech stocks have been ripping and roaring, with the primary beneficiaries of the
Era of Integrated Generative AI benefitting the most: Nvidia and Microsoft.
As a result, many companies that were laying people off just 6 months ago have now
begun hiring. Nvidia, Microsoft, Google, Amazon, and Netflix all have been hiring PMs.
While the era of tech austerity hasn’t yet come to an end, it appears it may have taken
a turn from the bottom.
ICYMI - Some of my other writing:
Tech: The Las Vegas Sphere (22M+ views 🤯)
Careers: Code Interpreter Use Cases
PM: Trudging Around in the Muck
Welcome to over 2,000 new subscribers since last week. My free Code Interpreter guide & Canva
deep-dive are up next.
How to Scale a Product Team from 0 to

15
With the turn in the markets, many of you are hiring PMs again. So this week, we’re
diving into how to scale a product team.
In 2023, scaling up your product team still feels like a boogeyman. The market is slightly
turning, and the budget is opening back up, but hiring and growing your org just doesn’t
feel the same.
Post the Tech Wreck of 2022, the days of organization building PMs are gone. These
days, product and company leaders are assessed on how much they can do with how
little - not the number of people that report to them.
The game of growing a product team from 0 to 15 has completely changed.
You need to have a much better reason to your grow your team these days. This applies
as much at Series A as it does post-IPO (unless you’re a generative AI startup).
Executives aren’t investing in a problem area. They’re looking for a high degree of
confidence in the solution levers as well.
So, this week, I’m really excited to bring a collaboration with Denny Klisch, one of my
friends and favorite PM creators on Twitter. We’re cracking open the topic of how to
scale a product team.
Why should you listen to us? Denny has just gone through building a PM Team from 1
to 15. As the Director of Platform Product Management at ioki, he’s been living in the
trenches on this stuff.
I’ve also had to scale several PM teams in my career - from thredUP and Epic Games to
Affirm. Now as a VP at Apollo, I also get to see the executive leadership side of the
equation.
In today’s piece, we break down the nooks and crannies of the process:
1. Starting with Your First Product Manager
2. Building the Foundations for a Product Management Team
3. Scaling from a Team of One to a Small Team
4. Building a Diverse and Inclusive Team
5. Leading a Growing PM Team
6. Reflections and Learnings
It’s 9,000+ words of our collected learnings - all tactics, no fluff.
We had a lot of fun with this one.
1. Starting with Your First Product

Manager
Let’s start from square one. And let’s give away the TL;DR before we get there: you
probably don’t need a product manager as early as you think.
When and why you need your first product

manager
It’s very hard for product managers to help you find product-market fit. Just like you
shouldn’t hire a sales person before you have product-market fit, you shouldn’t hire a
product manager until you have product-market fit.
After product-market fit, when’s the right time? A rule of thumb that works well in this
situation is:
When you have co-founders + 1 engineering squads.
So let’s say you have three co-founders and one engineering squad. Then you’re not
ready for a product manager. The co-founders should just do the work.
When the co-founders are really busy, they should first hire and empower an
engineering manager and designer. An engineering manager, designer, and part-time
founder are really the “minimum viable” squad for a properly functioning product team.
As you slowly scale up to more engineering managers than co-founders, THEN it finally
becomes time to hire your first product manager.
“But one of my co-founders is totally focused on sales/marketing!” you say. Two things.
1. That’s fine. That should give another more time to spend with the engineering
squads.
2. The precise reason it’s so important to keep founders close to the product
development process is not to get lost in sales and marketing too easy.
When you’re an early-stage company, the worst thing you can do is start sponsoring
conferences and jumping on podcasts to get growth. You should be looking for high-
leverage activities like building strong product-market fit and growing via the product.
Every example of strong product growth that we’ve profiled - from Stripe and Reddit to
Coinbase and Netflix - followed this approach.
Hiring: looking for the right qualifications and

qualities
There’s two major ways to think about your first PM:
On one end of the spectrum: people who believe you should hire a senior product
leader that can build out the function
On the other end of the spectrum: people who believe you should hire a junior
tactician who can work with the co-founders
Which is best? Well, of course, it depends. Here’s factors that bring you more to the side
of hiring someone junior:
There’s a co-founder who could clearly be the Head of Product: Then you don’t
need another senior leader until they give up the role.
You have junior Engineering Manager and Design Manager/ Designers to pair
them up with: Senior folks tend to like to work with other senior folks. And junior
folks work better with people their age.
You don’t have the salary for someone senior: Yes, you capture senior hires with
equity. But their base cash expectations are also pretty high. In the US, most PMs
Senior PM and above from reputable companies want $200K base cash minimum.
Many startups don’t want to pay that, let alone $300K for a more senior person.
And here are the factors that bring you to the side of hiring someone more senior:
You have senior engineering and design leaders: A junior person is going to get
run roughshod over senior counterparts in engineering and design, and they won’t
be able to bring out the best in the team.
You have a high pressure to produce soon: If your company needs to get it right
now because of its massive fundraising, or conversely its lack of cash, a senior
person is more likely to get things right with minimal ramp up time.
None of the co-founders have worked in Product Management: The art of product
management has developed a bunch of skills, artifacts, and ways of working that
most co-founders don’t have. You know you’re in this situation if there are a lot of
things your engineering manager and designer are asking for that no one has
experience with - like good PRDs, strong quarterly planning, user research
validating an approach…
What do Denny and Aakash think? Our take would be: most teams generally aim too
senior with their first hire.
Generally, teams try to hire someone and promise them that they can “lead the product
team.” But a couple different factors conspire to make it so that is not so wise a decision:
1. There’s always a well-paid PM that is just out of your reach: Top PMs earn $5M
per year. Most companies cannot afford them. And, in our experience, these PMs
are generally worth it.
2. This means you always want to hire more senior product leaders as you grow: they
help you scale up at each step, series B/C to pre-IPO, pre-IPO to post-IPO, small-
cap to mid-cap, mid-cap to large-cap, etc.
So, instead of trying to go senior to get someone to lead your organization, recognize
you’ll always end up hiring people more senior if you continue on successfully. This
means it’s on you to just “right size” seniority. And you generally want an Individual
Contributor PM who is willing to roll up their sleeves, not a manager of PMs.
Here’s how we generally think about right-sizing: only look at startup PMs. Then ask
yourself the following two questions:
1. Will a co-founder still be really involved in product? Start at Lead PM base; if not,
start at senior PM base.
2. How many product teams do you want them to take on? Add or subtract levels for
the difference between the number of product teams they take on and two.
So, for example, if a co-founder will be involved, then start at senior PM base. And if you
plan to have them PM one team, then subtract one level, now you are at regular product
manager. Then you just need to find someone who has a few years of experience as a
product manager at at startup. In the US, with enough equity, you can get someone like
that for a mere $110K. That’s much more palatable than $300K for a startup.
And if you set up the right roles and responsibilities for them, they can be pretty
effective:
The initial role and responsibilities (R&R) of the

first product manager
The most common failure pattern for early-startup PMs R&R is to make them project
managers who complete the founder’s vision.
It’s a painfully easy trap to fall into, so something like 75% of startups fall into it. But the
problem with this is that you’re way overpaying for a project manager. In an
environment where every dollar counts, you owe it to your bank account to get the most
out of this product manager.
That means not giving them features and projects to build, but giving them problems to
solve. The founders are still the people who have lived and breathed the customer
problems for the X number of years before hiring the PM. They have the right gut
instinct and internal context about the product to prioritize problems.
But after that, you should expect the PM to work with the engineering and design team
to discover the right solutions to solve those problems.
With that context out of the way, here’s what the roles & responsibilities should look
like in an ideal case:
CONSULTED: on the overall business strategy
INPUT: on the overall product strategy
DRIVE: the product strategy for the problems they own
DRIVE: the creation of the roadmap to solve those problems
DRIVE: the execution with design & engineering to solve those problems
DRIVE: the decisioning on whether to graduate features or experiments
CONSULTED: the go-to-market strategy
CONSULTED: the marketing strategy
Notice what’s not on that list: prescriptive advice to write PRDs, holding PMs
accountable for data analysis, or asking PMs to be the project managers. PMs should be
held accountable to goals. But at this early-life stage, the highest ROI activity is not
always big-company PM process.
Often, a great early startup PM will be very flexible with what PM practice they actually
pick up. Instead, they’re super agile to do what the business needs of them at any given
time.
Onboarding your First PM

So you have your R&R ready. Let’s address one final topic: onboarding your new PM.
The first thing to realize is that their onboarding isn’t going to be cost-free. It’s going to
take time from your existing team-members to ramp them up. And the new person
doing their job isn’t going to have done it as well as the founders would have at first.
This is going to decrease the team’s productivity temporarily. So you want to minimize
that period to as close to as zero as possible.
Don’t forget to nail all these basics:
Get your quick win ready: PMs tend to do the best when they can be given a high
conviction to execute at first.
Write up an onboarding doc: Create a to do list for the newbie. Compile links to
the key documents, key meetings, and people so they can ramp up.
Define team-wide onboarding responsibility owners: Who is responsible for what

in the onboarding process? Name a buddy (the one go to person for the newbie) and
spread other responsibilities accross the team (e.g. team onboarding, product
onboarding)
Communicate your expectations: Again, it is all about preparation. Write down

your expectations for the newbie in the first weeks/months. This helps to make
things explicit
Involve the new PM: Onboarding is not a one-way street. The new PM should help
define goals and new expectations.
Involve other teams: Get support cross-functionally. Engineers, sales & support
should also take ownership in part of the onboarding. This new person is an
important hire - not like your 100th hire down the line where those other groups
won’t be involved.
After you’ve onboarded them, once the hire starts and get’s going, the team will go
through some shaky patches. It’s just inevitable in product. Here’s what you can do
when that happens:
Talk proactively about the change: Make it explicit adding a new team member
always leads to some shaking of the existing structure. This is normal and the team
should not worry if this happens.
Support the team: Don’t leave the team alone, support them in any given way. But
don’t be too tight, the team should handle most of the part itself.
Do retros: It must be clear that the new setup structure will be discussed in a
soonish retro (e.g. after 3 months.
With all this work, you’ll be well on the way to integrating the first PM into your team
and growing faster through product. But how do you go from 1 PM to 15?
That’s a different ball-game entirely 👇
2. Building the Foundations for a Product

Management Team
So what do you do once you have a strong PM in seat? Then it’s time to build out the
foundations of your product practice carefully. Not to just start hiring more PMs.
Practicing product at this stage is a unique art - miles different from big company OR
founder-led PM.
There are three key activities to consider:
1. Creating product strategies and vision
2. Establishing processes and frameworks for product development
3. Developing a product culture
Foundational Activity 1 - Creating product

strategies and vision
With just a single PM, there’s going to be a ton of excitement in design and engineering
to work with that PM. It’s all-too-easy for them to get sucked into the vortex of product-
design-engineering work exclusively.
But that’s just a small part of a PM doing their job well. If you’re only in execution mode
all the time, you’re setting yourself up to become a feature factory. You can run fast, but
it’s mostly in place.
So beginning the process of creating product strategies and vision is the critical starting
step for creating a strong product culture.
The way we recommend to think about this is:
1. WHY → Vision
2. WHO → Segmentation
3. WHAT → Strategy
4. WHEN → Roadmap
5. HOW → Specifications
You want to use your vision to justify your why, your segmentation to justify your who,
and your strategy to help you understand the what. You should develop all these things
in writing and get feedback from the broader design and engineering teams to refine
them.
This will be the first step in establishing an empowered product culture that isn’t purely
founder-led.
The PM that you’ve hired then can double click on creating the roadmap and
specifications to deliver on the strategies and vision. It creates a clear lane for them to
operate in.
Foundational Activity 2 - Establishing processes

and frameworks for product development
The next thing to do as you get the strategies and vision in order is to establish
frameworks and processes for product development. Your first PM should lead much of
this, but there are at least levels to clarify process:
1. 10K FOOT VIEW - EXECUTIVE & ORGANIZATIONAL: How will you solicit
feedback and review from executives and across the organization for product work?
2. 1K FOOT VIEW - WITHIN PRODUCT TEAM: Will you plan on a half-year or

quarterly basis? What roles & responsibilities (R&R) will PMs vs EMs vs Designers
hold in that process?
3. 0 FOOT VIEW - EXECUTION ON TASKS: Will you have 2 week sprints or 3 week
sprints? Will you have a daily standup? And will the PM be a part of all the rituals
associated with these?
You want to have the team bottoms-up decide on these. There is no “right” way. A lot of
it depends on the prior experiences and preferences of the key players.
If we had to generically give you guidance on “best practice” at this stage… here’s what
to consider:
10K FOOT VIEW
Have executives involved in three processes:
1. A review of all strategies, visions, and roadmaps
2. A product specifications review after PRDs are ready
3. A design review after designs are ready
This gives the team enough empowerment to the team to present their own strategies,
visions, roadmaps, PRDs, and designs. But it also keeps executives, who are going to
have a much more intuitive grasp of what to build, involved in the process.
1K FOOT VIEW
Plan on a quarterly basis. Half-year planning makes you overly waterfall and not reactive
enough to the market. Instead, have a new look at your strategy and roadmap every
quarter. Have the product team present their point of view on the roadmap.
Encourage a single point of contact from product, design, and engineering to co-own
each roadmap. Instead of putting it all on the shoulders of the PM, make the R&R such
that the PM is only responsible for writing it. Make everyone equally responsible for it
being good. This takes advantage of the brain power in design and engineering.
0 FOOT VIEW
Aim for 2 week sprints. 3 weeks is just a bit too long to be adaptable to changing market
requirements. More often than not, you end up with mid-sprint changes that no one
likes. But if you stick to 2 week sprints, it’s much easier to stick to the sprint plan you
just set a few days ago.
Don’t have the PM attend the daily standup every day, but make them optional.
Occasionally, expect them to drop in to get status updates on big projects. But
otherwise, expect engineers to operate and update independently.
Foundational Activity 3 - Developing a product

culture
The final step to consider as you set up your product team to soon scale is developing a
strong product culture. Product culture is one of those things that is very hard to get
right.
What’s right is what works in your circumstances, in your market, for your customers.
But there are things you can do as a founder to improve the culture. A great example of a
founder playing an active role in developing product culture as the team was small is
Brian Armstrong at Coinbase. In 2015, three years into the company’s life, he posted this
article to the Coinbase blog, “How Coinbase Ships Product.” It’s a gem of a post.
Here’s some select parts that you should consider adopting.
Every Week
Run a standup meeting on Monday. Give a brief update on how the metrics are
trending. Have everyone on the team say (1) what’s going well (2) what’s not
going well (3) what they are doing this week and (4) where they could use help.
(Max of 2 items each to keep it short — ideally under 2 minutes per person — we
try to minimize time in meetings).
Go through the new user experience (NUX) yourself to ensure things are
working correctly — if they aren’t, reprioritize the sprint to fix these
immediately. It is key to stay in the mindset of a new user more than an already-
onboarded customer.
Take a moment to celebrate small wins and give public recognition.
Every Two Weeks
Run a ‘sprint’ — a set of features/bugs that will be completed in that two week
period. This helps set a regular cadence to a product team and minimizes
sudden changes/requests.
Run a product review toward the end of each sprint, where you demo to the
founders (or head of product) what the team is working on. This ideally (1)
reinforces speed of execution (2) ensures we’re working on what matters most (3)
sets the bar for quality and (4) provides an opportunity to coach/teach team
members.
Hold 1:1s with every team member to give two way feedback: Err on the side of
being honest rather than being liked (easier said than done).
Obtain a report of top requests from the customer support team. Use this to
inform the next sprint. Create a tight loop between customer
complaints/requests and time to resolution. We mostly use JIRA agile for
sprints, but each team can choose their own tools. Create a tight loop with
support so top customer issues make it into the next sprint..
Every Month
Spend time talking with at least 3 customers one-on-one. Are we solving a

problem they have? What would they change if they were us? PMs must have
their finger on the pulse of the market, and the best way to do this is to talk to
customers.
Send out an email with the key results spreadsheet to the whole team, and a
list of things that shipped in furtherance of those metrics. Reinforce speed of
execution and relentless progress toward the key results.
Write a blog post about one or more features that have shipped. It’s important
to show the external world how the product is continually improving. (If it is a
technical feature, post it to your developer blog to help with recruiting). The
product blog helps customers see continual improvement.
Every Quarter
Perform a more in-depth user study. Record a video of a real customer using
the product and share it with the whole team. They need to feel the customer’s
pain and have this be a constant reminder that normal people don’t use the
product like they do.
Use at least one of your two week sprints exclusively for bug fixing,
refactoring, or removing old stuff. If bugs, pagerduty, or speed/performance
become an issue, have the whole team focus on this for as many sprints as
needed to get things back below the threshold.
Hold an off site event and do something fun to help the team bond.
Every Year
Brainstorm 3–10 key results with your team that will move the needle for your
product. These should be quantitative/measurable. They should also be
ambitious but potentially achievable. Choose one of them as your north star
metric which you prioritize above all else — list this one first. This will break
ties when a decision needs to be made or there is lack of clarity about what to
work on next. Choose an owner on the team for each key result if appropriate.
Take some time to think holistically about product market fit. Does the overall
direction of the product need to change? Does the product need to be split in
two or merged with something else? Repositioned as something else? Usually if
your product does 3–4 things, 80% of all usage is in just one category. Can you
double down on that one thing and simplifying or eliminate the rest? Take some
time to think big picture about this each year.
He’s really laid out on a tactical level what the expectation is for Product Managers. He’s
created the playbook for being a successful PM at Coinbase, and he had conviction in it,
because he’d done it himself.
That’s the level of involvement that really makes sense once you have one PM, before
you scale to a small team.
3. Scaling from a Team of One to a Small

Team
Hiring your first PM is hard, but hiring the next batch might be even harder. How do
you know when to grow the team? How should you split roles and responsibilities?
Here’s your roadmap.
Determining when it's time to grow the team

Recognizing when to scale the team is a subtle art that requires careful observation and
strategic thinking. It isn't as simple as when you have co-founders + 1 engineering
squads.
It involves considering the pulse of the team and how they are coping with the current
work environment. The problem if you don’t scale your team soon enough is that all of
the following happens:
Overtime: If they've been consistently putting in overtime, you might be asking too
much, or you may need to hire more people.
Dip in the quality of deliverables. A persistent decline in work quality, despite the
best efforts of your team, signifies that it's time to bring in fresh hands on deck.
Long response times: If previously, messages to your team would get instant replies
but now they seem to languish unanswered for hours, it may be time to expand.
Our advice would be - don’t get to this point. If you scale at this point, you already have
a problem. So you should aim to get the headcount budgeted almost 6 months before
something like this happens.
On the other hand, though, prematurely scaling can be as detrimental as waiting too
long. If you’re stretching your burn or over-investing in R&D, it can become a recipe for
layoffs down the line. So you also want to make sure you have the following in place:
1. An engineering team for them to take over: You want to have a group of
individuals by which the PM can make impact.
2. A designer who has been working with that team: Unless they’re a backend team,
it’s hard to make impact without a designer.
3. An established product scope that someone is giving up: Either a founder or the
inaugural PM should be ceding some responsibility to this person to truly have
them be empowered and set up for success.
Balance is critical in scaling a product team. Keep this principle in mind as your
company progresses on its journey. Every growing company had to tackle these
challenges on their growth journey. The key lies in recognizing these signs and acting
on them.
Defining new roles and responsibilities

Every situation is different. What we’ll do is go through the generic process and then
come in with our opinionated points of view on this.
When it becomes clear, your team needs to grow, it’s time to define R&R. Here’s the
process we recommend:
1. Write it down as a leader
2. Get feedback from the team
3. Calibrate on the seniority based on budget & impact
Write it down as a leader
You as a leader should start first and write down what you have in mind, what is needed
for a new role, which responsibilities etc.
Write down necessary skill sets to succeed. To achieve goals you need certain skills.
Write down which skills/strengths your current team has and what is missing. The
missing pieces will help to describe the role and responsibilities as good as possible
Think well ahead. Don’t just think about the next 3 to 6 months, but actually, if possible,
where the team should be in 12 to 24 months. This will help a lot to define roles needed
in the short-term.
Get feedback from the team
Talk to the experts in your team. You are not alone. Make a process to get feedback from
each member of the team not only on the first draft, but also future iterations.
Be sure to also talk to the experts outside your team. One of the most effective methods
we have found is to ask other teams whether specific skills in your team are missing.
Calibrate on the seniority based on budget & impact
Discuss seniority level. Is it ok to have a junior? Or must it be a senior? Depending on

the maturity of the team you must be clear how much experience is actually needed.
The other factor to consider is your constraint - your available budget. What,
realistically, can you afford? Generally if you’re hiring your second-fifth product
managers, you’re going to have a constellation of hiring needs.
That’s the generalized process in the nutshell.
What’s our more prescriptive view of how you should consider scaling out a product
team? We think that you should:
Hire a product leader at some point in your first five hires: as we said at the
beginning, often your first hire isn’t quite ready to be your product leader. You’ve
grown in revenue now that you’re ready to expand the team and you can afford even
more tenured individuals with even more domain expertise.
Don’t be afraid to shake up your org structure: It’s still early in your product’s life.
You’re not going to get the product team definitions right, right off the bat. The
best product teams have lots of evolutions of their product structure.
Align product teams with engineering teams exactly. The artifacts that you split
your product should be the artifacts by which you split your code base and on-call
rotation for those features.
Getting budget for the team

When you want to scale a team, you’ll need a budget. Who approves the budget?
Especially in (early) startups, the executives will spread the budget across different
teams. These are likely tight, so it is your responsibility to get a decent share of the
cake.
Our recommendation: make a good case before the planning process. In particular, we
recommend four things:
1. Gather data that supports your argument (e.g. amount of overtime)
2. Outline benefits to show which impact a new hire would have for the business
(impact on outcome)
3. Highlight what happens if no new hire comes onboard (e.g. de-prioritization of

topics) and
4. Engage with stakeholders early on in 1on1s to talk them through your ideas and
get direct feedback (Clarify as much as possible up front before it comes to an
actual decision).
If you can work to address the concerns of folks privately on their own, then you can
book a meeting as a group where the overall approval happens. Then, when you go into
the budget planning process, everyone is already aligned on your need. It’s like magic.
People actually argue for your headcount - for you. Think, “team growth inception”
when it comes to scaling your product team.
Recruitment strategies for expanding the team

Growing a product team in the early days is tough. Your brand isn’t as well-known. Your
TC budget is tight, and most of it is tied up in risky options.
Here’s our recommendations:
1. The best candidates aren’t looking: You want to set up an outbound process using
a tool like Apollo to send email sequences of LinkedIn messages to your target
candidates.
2. Hire slow, fire fast: In the early days, unfortunately, you make the wrong hire. It’s
better to fire a bad hire than to draw out your process into the 12-step, 3-months-
long process you had at Google or Amazon. As a startup, one of your differentiators
is speed. And you should signal this to candidates in the process.
Once you have your outbound going and you have a stack of resumes that you are
pushing through the interviews, you don’t want your team to de-focus your pre-existing
too muce. Therefore, you must be prepared:
The process must be crystal clear to everyone (who is needed at what stage)
It must be decided who owns which part of the process (e.g. I own the complete
process, in step 1 two colleagues support, in step 2 the rest of the team is involved)
Everyone needs to understand how the decision-process works (who makes the
final call, or if the whole team can decide and consent must be in place).
That’s how you execute a smooth product team scaling recruitment process.
Challenges of scaling and how to overcome them

We’ve helped you with a first-principles process to hire well, but how do you avoid
problems along the way? There are four main challenges that we see teams facing:
1. Addressing the Pre-Existing Team
2. Aligning product team with company objectives
3. Scaling product team culture
4. Implementing appropriate tech/tools
Challenge 1 - Addressing the Pre-Existing Team

When scaling the existing people on the team will have the questions: “What does it
mean for my area of responsibility”. You don’t want these trains of thoughts. We like the
why, what, how framework of communication to get them onboard:
1. The Why: Involve team members early on and explain your reason behind the
decision to further scale
2. The What: Let the team give feedback to your ideas and incorporate these.
3. The How: Let them be part of the journey! For example in setting up the job listing,
being part of the interviews etc.
It’s best for the pre-existing product team to be excited about what the new member will
add versus competitive with them when they start. They will scare off good candidates
and lead to suboptimal outcomes.
So part of this is also just in emphasizing teamwork and calling out that expectation for
the team.
Challenge 2 - Aligning product team with company

objectives
Rapid growth brings fresh talent into product teams. Each new member adds a unique
perspective, and sometimes, these diverge from the company's main objectives. Keeping
everyone focused on the end goal while fostering creativity is a monumental challenge.
It's like walking a tightrope.
A solid solution begins with a well-oiled onboarding process. This lays the company's
objectives out clearly. Regularly communicating these goals also helps to align every
team member's work. After all, in product development, every little piece contributes to
the larger puzzle.
Challenge 3 - Scaling product team culture

Culture isn't just a buzzword, especially in product teams. It's a shared understanding
that glues the team together. It's how problems are approached, how solutions are
crafted. As the team grows, preserving this culture is like holding water in your hands -
tricky.
The preservation begins with leadership. By leading by example, managers can set the
tone for the team's work ethic, communication style, and problem-solving approach.
Regular team-building activities can also help foster this culture among newer
members. It's all about making culture tangible.
Challenge 4 - Implementing appropriate tech/tools

Product teams rely heavily on their tools. Think about roadmaps and PRDs, user
research hubs, and analytics software. Introducing new tools or transitioning to
different ones as the team grows can feel like switching boats mid-stream.
The answer here lies in a democratic approach. Let the team have a say in what tools are
used. Then, back this up with solid training. A feedback loop is also necessary to ensure
the tools are serving their purpose and not hindering progress. With the right tools in
place, the product team becomes a well-oiled machine.
4. Building a Diverse and Inclusive Team

Creating groundbreaking products isn't just about assembling a team of experts. It's
about stirring together a vibrant mix of perspectives, experiences, and skills. This is
where diversity and inclusion come in. They're not buzzwords. They are bedrocks of
innovative product management.
The importance of diversity and inclusion in

product management
Numerous studies have validated the importance of diversity and inclusion in the
workplace. According to a 2017 report by Boston Consulting Group, companies with
more diverse leadership teams reported innovation revenue that was 19% higher than
those with below-average diversity scores. This is not just a coincidence.
In product management, diversity breeds innovation. Having people with different

backgrounds, life experiences, and ways of thinking stimulates fresh perspectives. It
fosters an environment of robust brainstorming and leads to the development of
products that appeal to a broader audience.
Inclusion, a crucially different practice, is about ensuring that every voice within the
team is heard and respected. It's about creating a space where everyone feels valued,
and their contributions matter. An inclusive culture promotes employee engagement,
satisfaction, and retention. These are critical components to maintaining a highly
productive and innovative product team.
Strategies for building a diverse team

Building diversity in product teams starts with intentional and strategic hiring. Here's
the details to remember throughout the process:
Use Unbiased Language in Job Descriptions: Ensure your job postings don't favor
any specific gender, age, or race. We recommend tools like Textiot to eliminate
biased language.
Highlight Company's Commitment to Diversity: Include explicit statements about

your company's commitment to diversity and inclusion on the website and in the
job posting. This attracts a more diverse pool of applicants.
Unbiased Recruitment Process: Work with HR to remove unconscious bias from

the recruitment process. Techniques can include anonymized applications or
structured interviews.
Diverse Hiring Panel: Ensure your hiring panel reflects the diversity you seek in
your team. A diverse hiring panel is more likely to select a diverse group of
candidates.
Skills and Culture Add: Instead of looking for culture fit, look for culture add. This
means hiring people who can bring new elements to your company culture, not just
blend into it.
It’s not enough to just say you care about diversity. To build the best teams, you have to
implement it in every step of the process like this.
Nurturing an inclusive culture within the team

Then, you have to nurture an inclusive culture within the team. Creating an inclusive
culture isn't about hosting an annual diversity training. It's about nurturing an
environment where every voice is heard, and every contribution is valued.
Here are some strategies:
Foster Open Communication: Encourage team members to share their unique

insights. Make it safe for them to express differing views.
Celebrate Diversity: Regularly highlight and celebrate the diversity within the
team. This helps to reinforce the value of different perspectives.
Develop Empathy: Promote activities that help team members understand each
other's experiences and viewpoints better. This could be as simple as having
regular team lunches where team members share about their backgrounds
Equitable Opportunities: Ensure everyone in the team gets equal opportunities for
growth and leadership roles. This can mean providing training, mentorship, or
stretch assignments to team members.
Inclusive teams outperform super well-qualified teams every time. And they don’t end
up in mockumentary shows like Uber (Super Pumped) or WeWork (WeCrashed) either.
So don’t miss this step.
5. Managing and Leading a Growing

Product Management Team
Once you’re leading a growing product team, the game changes completely. Here’s how
to not just cope, but excel.
Leadership styles and management techniques for

a growing team
Working at a scale up within an evolving and developing market is challenging. To have

the best chance to succeed you must work as a team, no matter which hierarchy level.
An approach that we both have used that works well is the Servant Leadership style.
Developed by Robert Greenleaf in 1970, this style is now a classic. The basic idea is this:
invert management on its head. Traditional leadership is about gaining power and
exercise control. Servant leadership is about serving.
This contrasts from several other effective leadership styles:
Autocratic Leadership: In this style, leaders make decisions without consulting

their teams. It's considered the opposite of servant leadership because it focuses on
power and control, not on the needs and growth of team members.
Transactional Leadership: Transactional leaders operate on the basis of

'transactions', meaning the leader believes in a give-and-take relationship with
their employees. They reward good performance and punish bad performance. This
contrasts with servant leadership which focuses on meeting the needs of team
members, helping them grow and develop, and creating a community, rather than
focusing on performance-based rewards and punishments.
Charismatic Leadership: Charismatic leaders lead through the force of their

personality and often make decisions alone. While they can inspire their teams,
they don't necessarily put the needs and growth of their team members first, as a
servant leader would.
The Servant Leadership style lives and dies by the lead to live after the principles but
also by the team, to take on ownership and accountability. Without it, the Servant
Leadership style is doomed.
There are a lot of upsides of this style:
It really pushes everyone to work as a team: Servant leadership fosters a

collaborative culture, enhancing synergy and improving team performance.
The lead is explicitly part of the team, working on regular tasks: The leader, as an
active team member, earns trust, respect, and a deeper understanding of team
dynamics.
It encourages everyone to be a leader in their specific professional domain: By

empowering team members to lead in their areas, servant leadership fosters
innovation, productivity, and job satisfaction.
Self-Organization leads to ownership and accountability: Team members' freedom

to manage work promotes responsibility and commitment.
Empowerment leads to great development of individuals and teams: A focus on

growth creates a learning-oriented culture, improving skills and team resilience.
Empowerment leads to engagement: Employees who feel valued and heard are
more engaged, improving job satisfaction and productivity.
Unique working environment increases likelihood of staying at the company: A

supportive and inclusive culture can make the company a more attractive
workplace, increasing employee retention.
Pair the servant leadership management style with these tips to grow your team:
Technique 1 - Stay connected with your team
To stay connected with your team members, have regular 1on1 sessions with all of them.
This will build trust, a robust relationship and a great foundation when times get tough.
The 1-on-1 should not focus solely on business topics, focus is to get an understanding
of how your colleague is doing, what is currently blocking them in their work, what
motivates them, where you can support and more.
Technique 2 - Path the way to outcomes
As a leader you are, among other things, responsible to generate real value (outcomes)
for the business, as well as for users. To get there, you and your team need to derive
measurable objectives (e.g. decrease churn rate by 5% over the next three months) from
company goals. By doing so, everyone on the team knows what their work contributes
to.
Technique 3 - Stop starting, start finishing
To achieve the objectives, the team needs a collective “Stop starting, start finishing”-
mindset. However, teams tend to put more on their table than they are actually capable
of doing.
You want to generate value/outcome, therefore, no time to waste. If things they started
are not supporting joint objectives, don’t do it.
Technique 4 - Establish a feedback culture
Yea-sayers are the killer for any conversation. In a team you want an open feedback
culture to get different perspectives and the best results.
You as a leader must be a role-model. Be explicit about how important feedback from
each team member is. When asking for feedback and no one says anything, stay calm, be
silent, someone will eventually break through. Further, you can also call out everyone in
the room to give feedback.
Technique 5 - Manage expectations of other teams
When a team grows it is very usual other teams like sales, engineers etc. expect
everything will be 10x faster now. But it won’t. Onboarding a newbie naturally will slow
down things at the start. At least a bit.
You as a leader have a very important role here: expectation management. Whenever
discussions come up, don’t hide. Be the one who drives the conversation and
supports/protects the team. Especially in the stormy setup phase a team does not need
“outside”-distraction.
Technique 6 - Don’t beat around the bush
If you want your team to trust you, be transparent in your communication. Therefore,
make things explicit, always. Don’t play politics and beat around the bush. When things
are good, talk about it. When things are bad, talk about it.
Technique 7 - Do not micro-manage
When you work in the mud and become the leader, you do have different
responsibilities. If you still keep on doing everything by yourself, the team will lose
trust, maybe even relax, because they know, eventually you will take over.
You need to have this in your mind and act accordingly. Give away responsibilities you
had, share responsibilities. Whatever makes sense, do so.
And stop asking for reports every day. Maybe even weekly is too tight depending on the
seniority level of your colleague.
Technique 8 - Explain the Why
As a leader you want your team to understand the reason behind decisions (the ones you
made, the ones done on company level). So whenever you present something to the team,
start with the why! This helps them to understand where you are coming from, aligns
everyone and makes it easier to follow when you talk about the How/What part of your
message.
For decisions on company level: address these proactively, repeat the information for
everyone in the team meeting again and make explicit what the impact for the team is (if
any) - e.g., company decision: recruiting must slow down, impact on team: we stop
hiring for now!
Technique 9 - Involve the team early on
You don’t want to surprise your team with decisions and lose trust and let them be
detached from your doings. If possible, involve your team in thought-processes early on,
get early feedback and therefore, let them feel involved. This collaboration mode will
strengthen the trust and relationships within the team
Technique 10 - You don’t need to know everything!
Being a domain expert is great. As a leader you usually oversee different domains and
therefore, you won't be an expert in all the things. And that is absolutely ok! Trust your
colleagues in their capability to do their job best. You are responsible for the Why,
maybe even for the What, for the How the team is responsible.
Technique 11 - Be repetitive. Again and Again.
Teams getting buried in daily work. They need someone to show them it is all worth it.
Talk about the product vision, talk about the product strategy, attach daily work to
specific outcomes so that everyone sees and feels what they are working on has a real
meaning. No matter how minor a task might seem.
Communication and decision-making processes

Very early on, when the team is still very small, it is quite usual to talk stuff through and
that's it. Very few interfaces exist, very few dependencies exist. Everyone knows what
they have to do. The larger a team gets the more sophisticated communication. Some
suggestions to deal with adjusted communication:
Verbal vs. written communication
In Germany they say “Who writes, remains” It essentially means, write down what was
discussed, decided etc. so everyone can at any point link to that document, slack
conversation or whatsoever.
New communication channels
When growing a team it is very likely a new (team) structure will be in place. It’s likely
the leader will not have everyone as a direct report anymore and/or simply needs a 1on1
peer who they can talk to at any time. This means, triaging communication can take
place. You talk to the direct peer, they (or you talk together) to the team at a later stage.
Tailored communication
When teams grow new characters will be onboard. Which means, you might have to
tailor your messaging. Maybe being more explicit about things, maybe making explicit
what a message does not mean etc.
Furthermore, in a scaling environment you want teams to be fast, agile and really get
going. What is the number 1 reason for slowing down? Teams do not have decision-making-
power. A lead must make sure their team is empowered enough, so that they can work
self-organized on their daily work without asking for permission, decision from their
lead and more. Some ideas to keep the decision-flow up to speed:
Clarify decision-making-power (within the team)
In scaled environments, decision-making-processes tend to slow down. To encourage

decisions, the team and individuals must be empowered and enabled to make decisions
on their own.
One great technique to make decision-making-power explicit is “Delegation Poker”. In a

nutshell:
Manager and colleague have each 7 cards
Each card has a number
Number 1 means, the manager does the decision all by themselves
Number 7 means, the colleague does the decision all by themselves
Number 4 means, both need to agree on a decision
In general: the higher the number, the more decision-power the colleague has
By playing Delegation Poker, you make decision-power for the team as well as each
individual explicit. This will speed up decision-making-processes.
Clarify cross-company decision-making-power
The more a company grows (products, customers, new teams etc.), the more
responsibilities will be within the organization. Quickly it can lead to situations, where
it is unclear who is responsible for what and who can have the final decision.
As a leader you want your team to have a clear understanding not just about the “inside-
power” (who decides what within the team), but also the “outside-power” (who decides
what when topics cross other teams).
Best case: the topics get clarified between the teams. If there is no solution, the
leadership team must make decisions here.
Revise setup
As for so many things in companies, it is important to revise once made decisions. For
example, you decided for a certain topic you are the one (not your team!) who makes the
final call. Back when you decided this, it made sense.
Maybe six months later, it makes sense to revise this and empower the team even more.
Never shy away from revising and revoking formerly made decisions.
Building trust and morale within the team
Career development and progression for team

members
Career development is different in startups than in large enterprises. Especially in
startups, the first year's development in skills is way more important than development
in terms of hierarchy.
But this will change. At the latest after two years of (heavy) startup life people will put
their heads up and want to understand where their career is heading towards. You will
need an answer here!
Listen carefully
Not every team member will talk about their aspirations openly. Your task as a leader is
to understand where people see themselves in a given time period (like 12 months).
You can talk about this in your regular 1-on-1 session. But you might want to break free
from this routine and do something different, like a dinner-sessions every six months. It
helps in two ways:
You come out of the office-mood (order pizza or so)
Everyone is in more of a talking mood.
In this session, let the colleague pitch where they see themselves and you give feedback.
Career path from generalist to specialist
In small teams it is quite likely people wear multiple hats (having different
responsibilities) at the same time. This helps to develop very broad skills, however, likely
they are only mediocre to good in certain skills, but not very, very good. Small teams
tend to have generalists.
Therefore, when teams start to scale one can really use the chance and help the team
move away from generalists towards more specialized roles. Which means, individuals
can focus their growth and development in very specific areas and can become real
experts (but watch out to not build “Knowledge silos”).
Puzzling together the right pieces
When talking about individual development you as a leader need to zoom out and have a
broad view on team development. You do not want everyone to become a specialist in
the same area.
You have to make sure to play to the strengths of each individual and help them become
the best individual contributor in a specific area. These specific areas must be combined
to make the team work (productive, outcome driven etc.).
It’s like a puzzle: if you always have the same piece, you will never finish the puzzle. You
need individual pieces with individual characters to make the puzzle (team) work.
Career path from Individual Contributor to Leadership role
When teams scale, new structures will arise. This can eventually lead to colleagues
transition into leadership roles. This is one of the most interesting, yet most challenging
career development paths a leader can be part of. There are two major things to keep in
mind:
1. Transition from IC to a leadership role needs a lot of mind-shifting (e.g. give away
decision-making-power, give away responsibilities) and therefore, one should be
supported in their transition.
2. When someone from the team becomes the lead of former colleagues, it could lead
to tensions within the team.
Be prepared, involve and guide the team. Explain the reason behind and align everyone
on the new team setup.
Development is not infinite (for everyone)
Even though we wish so, development is not infinite (for everyone). Which means,
especially in a fast pace and quickly changing environment, colleagues will be left
behind. Even though you put time and effort into development, colleagues simply don’t
develop further.
The question is: what do you do? You can try to give them an opportunity to work at a
different place in the company. You can try to let them work at a very (hardly changing)
specific scope. If everything falls loose, one has to consider ending the relationship (in a
proper way, please!).
6. Reflection and Learnings

Reflection on the journey from 1 to 15: Denny's
personal experiences
Scaling from 1 to 5 for one product was comparatively easy as to get from 5 to 15.
With 5 people you can still work fairly close together, communication is still on a
manageable level. Growing further adds quite some overhead, slows down processes etc.
Even if you put in counter measures, you will never be as fast as at the very beginning.
So you have to be prepared: scaling a team is a lot of fun, yet also a lot of hard work.
However, it was (so far) all worth it. It was (and still is) a crazy ride where I learned a lot.
I did my fair share of mistakes and I’m very lucky to work in an environment where
feedback is just part of the culture. The good times definitely outshine the bad times
and I absolutely love what I’m doing.
Reflection on the journey from 1 to 15: Aakash’s

personal experiences
I’d call out two main reflections.
Reflection 1 - Culture is everything

There’s absolutely no sacrifice you should be willing to make on culture.
If a PM is toxic in some way:
Bad teammate
Not receptive to feedback
Or even not actively carrying the culture forward
Then you need to set a timeline for how long you will work with them on that skill.
And if they don’t improve in the required time, then you need to consider removing
them from the situation.
PM is a low-valence role. You don’t have a flat impact. It’s either positive or negative. As
a leader, when PMs are negative, it’s time to cut them from them situation. Ideally you
can find them another place on the team or in the company, but sometimes you also
need to make the tough decisions as a leader.
Otherwise, it can come back to bite you.
Reflection 2 - Scale-Ups Move Fast
A lot of this advice might not fit your current situation. That’s the nature of scale-ups. It
might fit your situation four years from now or two years in the past.
If there’s a constant in 0 to 15 product teams , it’s that there’s always change. So you
need to adapt to the situation. Sometimes, it’s best to hire a PM earlier than we
prescribed. Other times, you should do half-year and not quarterly planning. It’s okay.
We’ve suggested some guiding principles in terms of things to focus on as a leader. But
these concepts aren’t going to be universal on a time or team dimension. Use them to
inspire you.
Common pitfalls and how to avoid them

There are three main pitfalls we would call out:
Pitfall 1 - Insufficient role definition
When hiring new people it is maybe easy to set up the job listing (some broad bullet
points and that's it) but once the person starts the role definition must be absolutely
clear. Not just for the new PM, but also to the rest of the team.
Pitfall 2 - Unclear decision-processes
In teams in their very early stage, where you come from 1 to 2 people, decisions are
naturally made quickly, and it is clear who can make which decisions. When scaling this
becomes a lot more complex.
We’ve seen many teams fail due to the unclear decision-making-process. Don’t go this
wa.! Discuss decision-processes within your team but also cross-company. Setup the
team to be fast. Make sure they know what they can decide.
Pitfall 3 - Unclear new team structure
When adding a new person (or even more within a very short amount of time) it must be
clearly communicated and outlined what this means for the existing team.
If you don’t do this, people will have question marks and this will for sure have an
impact on the team's morale. When explaining, always start with the why. Not so and so
founder decided.
Key takeaways for other PMs considering scaling

their team
Before we end the piece, we want to leave you with four final takeaways.
Takeaway 1 - Fast growth needs close company by the leader
When you scale a team very fast you can’t delegate the responsibility away. Even though
a team is greatly empowered, you as a lead must company the growth especially at the
beginning closely. Once you see processes, decision-making etc. is on a good way, let
loose.
Takeaway 2 - Keep the team together
When you not just scale one team, but actually add further teams with very own
responsibilities and capabilities make sure, these teams feel at home in their home turf:
the product management team.
Think small things like a joint weekly, or lunch every week. Feeling part of a group is
psychologically extremely helpful.
Takeaway 3 - Setup cross-team objectives
When having multiple teams after a heavy scaling phase don’t let them live and work in
silos. Look for synergies and let the teams work on cross-team-objectives.
Takeaway 4 - Ask for help
You are not the first one to scale a team. Therefore, ask for help, listen carefully, and use
the given advice to avoid pitfalls. Your fellow leaders in the company are your resources,
not your competitors.
The future of product management team growth

The Tech wreck has scarred tech executives for the next few years into wildly large PM
organization.
The zeitgeist right now is towards higher engineers per PM. Whereas the ratio might
have been 5:1 two years ago, it’s trending more towards 10:1. So PMs are going to have
to focus on more leveraged tasks than ever
At the same time, it’s not all doom and gloom. The private market is snapping back
faster than most people realized. Series A, B, and C have already snapped back. It’s just
D that is a laggard now.
Eventually, the time of org building will begin again. And when that happens, you’ll be
ready!
Final Words
That's all for this week, folks. This was only the 101 of topics. There’s so much more,
like organizational design, that we still have to cover. Expect it in future editions.
Cheers 🍻,
Aakash and Denny
41 Likes · 2 Restacks
Comments
Write a comment...
© 2024 Aakash Gupta ∙ Privacy ∙ Terms ∙ Collection notice

Substack is the home for great writing

How To Scale A Product Team From 0 To 15 - by Aakash Gupta

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

How To Scale A Product Team From 0 To 15 - by Aakash Gupta

Uploaded by

Copyright:

Available Formats

2/14/24, 6:55 PM How to Scale a Product Team from 0 to 15 - by Aakash Gupta

The Tech Wreck Is Turning Around

🔒 How to Scale a Product Team from 0 to 15

The Tech Wreck Is Turning Around

ICYMI - Some of my other writing:

Tech: The Las Vegas Sphere (22M+ views 🤯)

Careers: Code Interpreter Use Cases

PM: Trudging Around in the Muck

How to Scale a Product Team from 0 to

The game of growing a product team from 0 to 15 has completely changed.

1. Starting with Your First Product Manager

2. Building the Foundations for a Product Management Team

3. Scaling from a Team of One to a Small Team

4. Building a Diverse and Inclusive Team

5. Leading a Growing PM Team

6. Reflections and Learnings

It’s 9,000+ words of our collected learnings - all tactics, no fluff.

We had a lot of fun with this one.

1. Starting with Your First Product

When and why you need your first product

When you have co-founders + 1 engineering squads.

Hiring: looking for the right qualifications and

The initial role and responsibilities (R&R) of the

CONSULTED: on the overall business strategy

INPUT: on the overall product strategy

DRIVE: the product strategy for the problems they own

DRIVE: the creation of the roadmap to solve those problems

DRIVE: the decisioning on whether to graduate features or experiments

CONSULTED: the go-to-market strategy

CONSULTED: the marketing strategy

Onboarding your First PM

Don’t forget to nail all these basics:

Define team-wide onboarding responsibility owners: Who is responsible for what

Communicate your expectations: Again, it is all about preparation. Write down

That’s a different ball-game entirely 👇

2. Building the Foundations for a Product

There are three key activities to consider:

1. Creating product strategies and vision

2. Establishing processes and frameworks for product development

3. Developing a product culture

Foundational Activity 1 - Creating product

The way we recommend to think about this is:

Foundational Activity 2 - Establishing processes

2. 1K FOOT VIEW - WITHIN PRODUCT TEAM: Will you plan on a half-year or

10K FOOT VIEW

Have executives involved in three processes:

1. A review of all strategies, visions, and roadmaps

2. A product specifications review after PRDs are ready

3. A design review after designs are ready

Foundational Activity 3 - Developing a product

Here’s some select parts that you should consider adopting.

Take a moment to celebrate small wins and give public recognition.

Every Two Weeks

Spend time talking with at least 3 customers one-on-one. Are we solving a

3. Scaling from a Team of One to a Small

Determining when it's time to grow the team

Defining new roles and responsibilities

1. Write it down as a leader

2. Get feedback from the team

3. Calibrate on the seniority based on budget & impact

Write it down as a leader

Get feedback from the team