How to set up your product team

Your guide to product org design

Team is everything

Some say it’s the product roadmap. Others say it’s the product requirements documents.

I say it’s product team structure that has the biggest impact on your product team’s success.

A well designed PM org is the difference between a bunch of infighting and turf wars versus a team that is greater than the sum of its parts.

If there’s one thing product leaders need to focus on getting right, it’s not what to build - it’s who to put where.

But how do you actually achieve a well structured product team?

First of all… Whose Model Do You Follow?

There are so many ways to set up a product team.

Should you follow Amazon, Google, Facebook, Microsoft, Apple, or Oracle?

Comic: Manu Kornet

There’s no right answer. And neither looks particularly appealing, either.

The biggest piece of intellectual self-soothing people do on this is read pieces on “How X does product.” But how a place does product is just that: how they do it.

Ramp, Miro, and Linear live in completely different market conditions from you. They benefit from superhuman founders who have set their companies down an inevitable path of success.

Your company probably does not.

Everything is Specific

So there’s some learnings to be gained from hearing how others do it, but it’s never going to be everything.

Your situation is going to be different.

• The personality of your CEO will be different.

• The dynamics with your stakeholders will be different.

• The skill of your designers & developers will be different.

Which is why you haven’t seen a string of those article here.

Reading those pieces is fun. And they’re insightful. But a bunch of anecdotes, on their own, leave a gaping hole.

They don’t systematize what your options are and help you choose.

Today’s Post

Today’s post attempts to help us all product leaders sort through what options are available, and provide a rubric for making decisions:

1. Lens for understanding your options to structure your team

2. Going through the most common four structures

3. A framework for you to make the right choice

It’s a tactical guide for product leaders living in the world of infinite content on how to structure a product team.

---

1. Lens for understanding your options to structure your team

The first thing I did when starting this piece was ask several product leaders how to structure a product team.

My most striking observation was that almost no one had a shared vocabulary for how to explain the different ways to structure a product team.

Just about everyone understood that the most common structure for product teams is organizing around a product or product line. Each product has a dedicated product manager who reports directly to the VP of product or chief product officer.

But going any further was hard for most people.

What’s happening here?

The Feature Organization Method Isn’t Everything

The problem, of course, is everyone just considers the feature method of organization.

It is an okay method, but it’s not the best fit for every situation.

1. It ignores the importance of feature vs product focus. When you have a PM aligned to a feature, they’re highly unlikely to suggest killing that feature. It makes the PM devoted to the feature instead of the product as a whole.

2. It obscures the role of impact. It assumes that the PM who owns a feature will be able to direct their resources to the strategic priorities of the business. The problem is: this very often breaks down. Feature teams have to do the work, and often fail, in mapping the features to outcomes.

3. It doesn’t touch on whether ownership for these features is solely PM owned or cross-functionally owned. In a PM-owned org, cross-functional leads contribute but aren’t equal owners to the plan. In cross-functionally owned orgs, multiple teams and cross-functional stakeholders contribute.

A Better Model for Thinking About Organization

So what’s a better way of thinking about structuring your product team that helps overcome these problems?

The best I’ve seen is from Ravi Mehta in his Product Leadership Reforge course. I took it a while back. It’s excellent. Today’s piece will build upon it.

But let’s briefly recap. There are two questions to ask:

1. Are teams focused on features or outcomes?

2. Do teams own their metrics or share their metrics?

The answers to these questions maps to the type of product org you have.

Here’s what each roughly looks like:

• Outcome owner: This is when the PM has sole ownership over a metric and is responsible for driving it.

• Outcome contributor: This is when the PM is focused on a metric (vs a feature) but does not solely own it.

• Feature owner: This is when the PM has sole ownership over a feature.

• Feature contributor: This is when the PM is focused on a single feature but does not solely own it.

So where does one PM per product feature fit in? That’s a grouping together of the top row of possibilities here: feature owner and feature contributor.

Company Size Matters

Of course, variance by company size is the biggest determinant.

In the startup phase, when there’s just a single PM things are very different from when there is a head of product and several PMs. And that situation is still quite different from the giant corporates.

Generally, you can only make the decision to focus on outcomes after you have achieved product-market fit. Until then, the only dimension that matters is whether the PM is a feature owner or a feature contributor.

Non-Options for Organization

There’s lots of terrible structuring options out there in the literature.

For instance, some articles refer to the option to structure a team by a product manager’s skills. I have not seen this work. Similarly, there’s suggestions to structure teams by customer segment or customer journey stages.

These sound good in theory - but no one I’ve surveyed or talked to actually does them.

So let’s go much deeper into the different ways people actually do structure their product teams, and which is best for you.