Leah's Product & Growth team Guide
How to build teams that kick ass and move things.
Hi, my name is Leah Tharin, and this is my Substack: hot takes on product-led growth/sales and organizational scaling.
I advise companies on how to not burn everything down in the process. I run cohorts on PLG every two months; join me!
How do you build a product team structure in today’s market climate?
A practical guide for any CEO, CP(G)O, CTO, and future product leader to structure Growth and Product Teams that work.
Let’s map it out:
Table of contents
1. Why good team structures are so tricky
1.1 The last iteration of an overdue model
2. Product-led Teams: New vs Old
3. “Old Product Teams”: The Service center mentality
3.1 The detached Engineering Manager
3.2 External data sourcing without context
3.3 External Business case paralysis
4. “New Product Teams”: Flexibility and Focus
4.1 Future-proof Product Managers
—— Business casing & Altitude maps
—— Data Querying & Research
—— GTM Planning skills
4.2 Internal Engineering Managers
4.3 Flexible Staffing & Team Size
4.4 Focus and Urgency
5. Summary
6. Bonus: The Spotify fight
1. Why good team structures are so tricky
My first post that ever went somewhat viral was when I criticized a notion two years ago that I kept hearing: People raving about Spotify’s squad model and its state art in Product Management. After all, look at Spotify's success!
The irony was that the story was actually never that simple. Spotify wasn’t using it themselves at the time. Not entirely. In either case, it kicked a conversation loose with Spotify’s driving agile coach and other people in the comments about what’s what.
This article is not about this drama but what caused it: it’s really difficult to find structures we can use that work well.
Whether you are a CTO, CEO, CPO, or founder… we try to emulate what successful companies have done. It’s usually born in a problem that surfaces as we stick people together in teams and start to grow:
Shipping meaningful things and moving forward becomes, for some reason, really, really hard with increasing size.
Any leader goes through a couple of stages of grief at that moment:
Reluctance to see the problem: “Just keep doing what we always did. It worked before!”
Reluctance to see the solution: “It’s not that hard! We can’t afford more people, I don’t want complex structures. Just ship! We have no hierarchy here!”
Acceptance: “Damn. We need a concept. But… what?”
So, we turn to popular frameworks and implement them, and they are usually better than having absolutely nothing.
It’s a mixture of expectations that you, as a leader, know how to organize teams and the deceiving complexity of the problem from people inside the teams:
“Our leaders are complete idiots; it would be so simple to solve our problems; just do (insert overly simple solution).”
It’s not simple. In fact, it’s very hard:
The complexity of the task at hand comes from the need to have cross-functional teams that are able to deal with an ever-complicating market environment and increasing demand for everyone's individual skills:
Product has to suddenly connect what they do to the revenue
Marketing has to bring good quality leads that unfold into expansion revenue instead of just some traffic
Sales have to use behavioral data to drive their pipeline forward and understand product metrics
Growth is a relatively new function that covers the gap between marketing and product to connect users to the product value efficiently.
We all are forced to become a bit more cross-functional. That’s not news.
So, how do we address this problem?
1.1 The last iteration of an overdue model
What I’m proposing to you here is, at the face of it, not exactly new to some of you. The writing has been on the wall for quite some time, and the way that I’m looking at it is that this is the final iteration of a structure that is long overdue.
I expect this structure to be replaced by something new in the next few years. Think of it as an electric car vs. a combustion car revolution.
This is as far as we can go with cross-collaborative team structures that rely on structures where people have clear job titles from their silos like Marketing, Product, Engineering, etc.
Let’s dive into it hopefully for the last time:
2. Product-led Teams: New vs Old
Cross-functional teams were the answer to matrix organizations where we separated people by their functions and made it really hard to collaborate. Matrix setups still exist today and are sometimes, in fact, the correct solution for some high-tech hardware companies that are extremely process-heavy.
In SaaS software development, they have no place.
The first iterations of these cross-functional teams are depicted in the graph on the right-hand side:
3. “Old Product Teams”: Service center mentality
Product Managers, engineers, and their designers were moved close together. We created cross-collaborative teams which had their independent backlog. Design, Product, and Engineering are under one roof. Great.
This was a huge improvement over matrix organizations but didn’t go far enough to deal with today’s challenges.
The weakness is in the service center mentality:
Service centers (aka outsourcing a skill that should be in a team) that serve basic data and people management do not work if you give them everything. You might think that you free up something so your PMs and engineers can focus. The opposite is the result.
Here’s why that doesn’t work:
3.1 The detached Engineering Manager
The first culprit is the Engineering Manager. We recognize that engineers need to be managed. The idea was to install Engineering managers outside the teams who take care of your valuable engineers.
This stems from the idea that the Product Manager and Designer are also managed from the outside, and that works. The unfortunate detail that rains on this parade is the number of engineers:
There are usually more than 2 of them in a team, and they work very close to each other, that’s not the case for your PMs and designers.
The other problem is that you should never let a Product Manager fully reign over the product team. We have to put the EM (Engineering Manager) and PM (Product Manager) on the same level of decision so they can balance technical debt and product urgency.
You might think that you are doing this with the old structure, but because the EM usually manages multiple teams, you distribute them unnecessarily and remove them from a critical source of data to stand up to the PM: Business context. They are simply busy managing 8 to 15 engineers all day.
They handle people, not the business.
Outsourced engineering people management is an attempt to conserve money that costs you more money as a result in ways you can’t easily measure:
Your tech debt will skyrocket because your EMs can’t control it on top of what they do. The Techleads (if you have separate ones) don’t have the authority to solve this either alone because they are usually one level below the EMs.
You force your EMs to prioritize people management because they commonly have too many direct reports to do anything else.
3.2 External data sourcing without context
The same principle goes for sourcing data. We all know that we “should” consider qualitative and quantitative data as a source to inform what we do. So we ask people who know about it to do that job for us.
The problem this creates is similar to the EM being outside the team:
The person who has to serve your request has no idea why you need it; they lack the business context and are not involved in your day-to-day activities. A constant back and forth emerges.
Quantitative data misery: Data scientists hate this because they often get degraded into code query monkeys for the simplest requests. It feels like a trained chef has to cut the onions for the line cook because they can’t even do that.
Qualitative researcher misery: UX Researchers have to organize all interviews but lack the business context as well, so they often recruit the wrong type of users to interview. It makes sense to centralize the recruitment of users, but the interviews themselves should be driven in majority by the PM and Designer. More on this later.
3.3 External Business case paralysis
This one is hidden in the graph: Your product managers don’t know how to connect what they do with the revenue of the company because you don’t know how to teach that to them:
You might say, “They need to connect it! We constantly ask them to!”. What’s happening is that these PMs just wait for someone to tell them what to do, or they suggest working on big initiatives because they “feel” important.
(This is something that comes naturally to Growth teams, which at this point are severely needed. They serve as a role model for classical product teams in this regard.)
As a C-Level, you serve as an external service center for their business cases to compensate. You sit together with them and create a strategy on what you think is driving revenue.
The problem is that you don’t understand the product as well as your PMs, so you will miss a lot of important pointers like technical debt and detailed customer insights.
This leads to frustration left and right. It feels like the C-Level is talking in one language and the product team in another.
And to either side, what should be built next is very obvious. Fingerpointing ensues.
4. “New Product Teams”: Flexibility and Focus
We need to go with what we originally implemented with a few tweaks and go further.
You can see in the graph that we expect people to do much more individually. Let’s look at them individually and then deal with the consequences of it:
4.1 Future-proof Product Managers
I expect more from product managers today than I did yesterday and developing them into these roles is the responsibility of their respective managers.
Business casing & Altitude maps
Creating a business case is daunting if you’ve never done it. I wrote an entire guide on it, but that guide deals with one specific case.
An altitude map is an important tool for mastering this art and connecting the product to your company's revenue. It’s a collaborative exercise with your team to figure out what you do and how it connects to the revenue per team.
An altitude map does this on a conceptual level; a business case does it on an operational case-by-case level.
I commonly use a kitchen analogy to illustrate this:
Altitude map:
How your kitchen is organized and what food you produce. It lays out what areas the food ideally improves on your business. It’s the missing translator between the language leadership speaks and the understanding of the Product Team.
You can usually identify Growth and Core Product Teams by what they include in their Altitude maps:
Growth Product Teams: Often focussed on Free to Pro conversions or activation metrics like the “Aha” Moment. They connect marketing traffic to product features. Their metrics to shift are commonly also attached to direct revenue goals. This works well until your company hits about 150 people. After that, we will probably have separate product portfolios.
Product Teams: Often focussed on reactivation and retention metrics, they are further away from the revenue and are rarely incentivized on it. However, when we launch new products, it can make sense to incentivize product teams to commit to certain uplifts on free-to-trial and trial-to-customer metrics (or lead generation for sales). This needs to be carefully evaluated on a case-by-case basis. Common are also quality metrics like uptime and quality-related metrics like # of support requests originating from their products.
An altitude map that works means that teams focus less on what they ship and more on what they affect with it. Deliveries become a tool and not the goal.
Business case:
How much the food you produce moves specific metrics. PMs need to learn how to do that so their initiatives become comparable across all dimensions, internal and external.
Full guide on Business cases:
Research and Data Queriying
In order to find good business opportunities, we need to maximize the chance to see them. Unfortunately, a lot of good opportunities are where you can’t see them. In data, qualitative or quantitative. And oftentimes, you simply don’t know what you don’t know. So you wouldn’t be able to ask someone else what you’re looking for.
It’s the classical problem of doing an investigation: You will know the correct question once you see the problem. I cannot have someone else investigate for me because they don’t understand the business context in which it happens.
No dashboard in this world will save you from this. Things break exactly in places where we don’t look. Sometimes, we just have to dig until we find it.
A lot of Product Managers will hate me for saying this:
The time when you could sleep on doing basic qualitative and quantitative research yourself is over. You HAVE to learn the basics of it.
Sourcing basic requests in your team without having to ask anywhere else here is key.
This means either:
Quantitative
You get a BI tool that allows you to do basic things yourself (this should be a tool for the designer at most)
Your data scientists/engineers teach your PMs how to query the data yourself. No tickets with “Can you make a report with…”. Instead: “Can you teach me how to”
Learning SQL and leveraging language models to adapt existing queries to iron out mistakes has never been easier. There is absolutely zero excuse why your PMs shouldn’t be able to do that in 2024 for basic requests.
To get started takes days, not weeks anymore. The rest is a muscle we train.
Does that mean we have no more data scientists? On the contrary, now they can finally take care of the big investigations and data work that goes across the entire organization and is not contained in one team.
Their responsibility is to support and teach basic data skills and facilitate the really complicated stuff.
Another quick fix is to get help from your in-team engineers. Query languages should be comparatively easy to use and teach for them.
Qualitative
This is less likely a problem because most PMs actually do it themselves already.
In case they aren’t in your organization: don’t allow customer interviews to be outsourced completely. A product manager has to talk to customers and users of their product themselves. Great designers already possess qualitative interviewing skills, so your PMs should learn from them.
Just like with quantitative data, your UX researchers can help, but they should never take the entire process.
We follow the same first principle: UX researchers outside of teams take care of big user studies that stretch across multiple teams; good examples are interface overhauls and navigational work.
Still, these big initiatives should also be connected to meaningful metrics. Temporary tiger teams that follow the same structure can be the right answer here.
GTM planning
You cannot build if you don’t know how it’s being sold. A go-to-market plan should be spearheaded by the product team if they are building something new.
While a product manager doesn’t have to create the marketing campaign themselves, they should collaborate with whoever has to advertise what they build after:
Product Marketing Teams
Marketing
I don’t see this as a shared responsibility but one that has to be owned by the product team. Otherwise, you encourage a finger-pointing exercise and a “ship first, advertise later” mentality that’s extremely frustrating for Marketing to work with.
This also overlaps with the PM’s duties to create a good business case. How can they know what the impact of a feature is if they never asked Marketing what the new keyword potential is in your SEO channel for instance?
An unexpected ally here is your product designers. While they don’t drive GTM plans alone, they usually have a very good view and nose for how the experience changes for your customers as a whole.
They also tend to be buddies with good Marketing teams. And Sales teams love it anyway if they get new, good-looking material that helps them sell.
Someone has to do it, and it should not be the CEO, as already outlined in the business case section.
4.2 Internal Engineering Managers
Limiting EMs to one team gives them the shared responsibilities of a tech lead. This is important so they know firsthand how working with the tech feels while also having time to understand the business context.
This allows them to lead their people better and not regress into a pure people manager role.
That dramatically reduces, though, how many engineers they can handle; anything above three to four should be an absolute exception.
Their role covers:
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”, manages sprint, guides toward sustained high velocity, continuous improvement, removes roadblocks, timely delivery
Accountable for technology health but delegates ownership to other team members.
Communicate with other engineering stakeholders. Responsible for negotiating dependencies and resolving blockers.
Time to contribute as an IC Software Developer (only possible in small teams)
4.3 Flexible Staffing & Team Size
It’s clear at this point that I have shifted a lot of new responsibilities into a product team. We will have to pay the price for that, which usually comes with the size of the team and its seniority.
It might sound counterintuitive, but it’s even more important now to keep the team size smaller.
Because we expect so much more from individual product managers, they have less time for classical product management work. They cannot “feed” that many engineers. The same goes for your designers.
There’s more research and more work around building products, but as a result, the teams become much more efficient per line they code.
As a positive, the current technological improvements driven by AI make product teams more efficient as individuals and allow us to hire specialists for their respective areas:
Growth Product Managers
Technical Product Managers
Product Marketing Managers
Platform Product Managers
etc.
Another side effect is that per product team area, there are fewer engineers working on the same code, which leads to better quality and less error proneness.
But be careful:
Shifting to a new structure like this without reducing team overall size gives the impression that it’s not working.
Sooner or later, you will have to hire more product managers and designers to keep the same number of engineers busy. This usually means a slowdown in the engineering pipeline while you allocate a little more money to your PMs and Designers.
The flexible spot
For extremely complex project stretches, we can insource a data scientist / UX researcher or other specialist to fill a temporary heavy need. This makes sure they are not pulled into three different directions.
The principle here is to bring people into teams wherever possible to create focus.
4.4 Focus and Urgency
The new team structure is extremely efficient if you allow your teams to handle fewer things at the same time so they can focus.
This generates the fear in some leaders that there is not enough urgency anymore to build things and that product teams twiddle their thumbs by staying forever in research.
With good altitude maps and solid planning beforehand about what you want to influence on the business side, you will slowly start to build a layer of trust that allows your teams to work and report proactively instead of constantly firefighting.
Instead of shipping constantly, your PMs should focus a couple of weeks before the next planning cycle on that research while the engineers finish building the current cycle.
A detailed guide for this structure is in this guide, 10.3 Product-led OKRs
5. Summary
We have to ask for more but also enable our teams and give them the room to do so. I wrote this guide because it’s one of the things that I have to fix almost always in a scale-up:
How much can the team lift by themselves without having to ask others?
It, more often than not, is a leadership and organizational structure problem that we have to deal with.
With the right tools, we speak the same language, and work is not a constant battle between silos that have been artificially separated.
It’s how any modern CPO should get their ship in order.
6. Bonus: the Spotify fight
What happened over two years ago on LinkedIn and the related articles on the Spotify discussion:
It started with me posting this:
The Spotify squad model! You know who doesn't use it? Spotify.
“Even at the time we wrote it, we weren’t doing it. It was part ambition, part approximation. People have really struggled to copy something that didn’t really exist.”
—Joakim Sundén , agile coach at Spotify 2011–2017
Jeremiah Lee’s article that got it all going:
https://www.jeremiahlee.com/posts/failed-squad-goals/#1
Joakim’s counterpoint:
”Yes, I said that when the "Spotify model" was more or less synonymous with the white paper and the two videos and that was what people were "copying". Since then I have come to accept that as hundreds, if not thousands, of organizations are imitating some idea of it there is de facto a "Spotify model". On top of that several of them seem to suggest that it has been helpful, which is why I propose that we try to understand what it means and help each other by sharing what's working and what's not. See e.g. https://joakimsunden.com/the-spotify-model-demystified-and-made-applicable-through-essence/
For what it's worth I disagree with much of what is expressed in the article you link to (by Jeremiah Lee)”
Great post. I particularly find the push for durable teams and embedded leadership meaningful. Good synergy with building a Product Mindset: https://bit.ly/48y7LDQ. And I agree about SM’s often not fulfilling on the value promise. But I will add, when you have a truly amazing SM it can work. I recall one while I was at Accenture who really, really got it. He was amazing… delivered on the promise of removing roadblocks, protecting the team. But incredibly rare, so I think “the exception makes the rule.” 😏
Very good article. From what I understand an Internal EM is technical and people focused. An experienced Scrum Master is also people focused. A Dev lead (aka Tech lead) working with an experieced SM could provide similar outcomes for the team. How does the SM fit into the team when there is an dedicated Internal EM?