Need someone to lead product management at your software company? I create software for people that create software and I'm looking for my next opportunity. Check out my resume and get in touch.

How to scale your product team from one product manager to an entire organization

Freshness Warning
This blog post is over 3 years old. It's possible that the information you read below isn't current and the links no longer work.

Note: This post deals with the scaling issues of a high growth company that starts with a single product person and needs to grow beyond that. That’s the structure and path I have the most experience with, and if you’re doing something different, this might not apply to your situation.

Most companies start with a single product manager. As the product grows in size and complexity, the demands on the product manager’s time increase, and you hire several product managers to share the load. This is usually a haphazard process leading to problems.

As your product management team scales, you’ll have issues around redundancy, communication, and consistency.

Game pieces on a map

When the team is small the product person does a little of everything. In a startup, the product role is a utility player. Does engineering need some UX research? Product. Does marketing need mockups for the upcoming release? Product. Maybe an important customer needs hands-on training to get started? Product.

As the team grows, this leads to redundant efforts. Two different product managers find out they’ve been working on wireframes for the same thing. Multiple ad hoc training courses are created. Several people end up building the same set of reports to understand customer behavior data.

The mistake was in hiring that second product manager when what you needed was to start building a product team around the product manager.

Instead of a second product manager, your product team needs to start containing specialized roles. A UX designer. Product operations to figure out what metrics the product team needs and how to track them.

You’ll reach a point where, even with all the specialized roles on the team, the product manager is overwhelmed. Now it’s time to hire your second product manager. She’ll appreciate having a support infrastructure around her.

That second product manager now creates a consistency problem. The UI for the billing portal uses different words and styles than the account dashboard because the product managers responsible for those areas had different ideas. The API for accessing customer information uses ISO-8601 date formats, but the API for usage reports uses Unix timestamps.

With a single product manager, it was simple to coordinate. Dirk was responsible for everything, so everything could be in his head. As you add PMs and they become responsible for different things, more communication is needed to keep things consistent.

To solve this communications overhead, it’s tempting to split your team horizontally. Someone is responsible for all UI everywhere. Someone else leads the API efforts to ensure consistent data access.

Organizing like this creates a different problem. How does the product organization coordinate activities when they’re being led by multiple product managers? They’ll battle for development time. You’ll end up with dependencies where the UI team needs the API done before they can move ahead.

Outside of the product team, you’re creating communications problems. Sales needs to know what’s shipping next quarter, marketing needs to know what’s coming on the horizon to start building datasheets, and support wants to know if this week’s hot customer issue is nearly fixed.

Who do they talk to?

Instead of splitting up your product into parts as you scale, align your product teams vertically around functional areas. One team owns everything to do with billing and payments. Another is in charge of the dashboard and analytics. This makes it much easier for the rest of your company to follow along.

Even with a vertical focus, you still need to scale communications.

As the product gets larger and more complex, you may end up with product managers for each component, which causes an even greater communication problem. I once talked to someone at a large e-commerce company that was the product manager for the Add to Cart experience. Imagine having someone responsible for the Buy button on a site.

A large amount of communications overhead is required to keep the entire product team in sync when everyone knows a little about everything and no one about the whole

Not only does such a structure make it hard to communicate within the product team, but it’s also hard on other parts of the company.

Sales needs to know what’s shipping, support needs to know that a hot customer problem is solved, marketing needs to know what’s on the horizon to put spec sheets together. Making the support managers get their information directly from the Buy Button product manager and the Payment Processing PM and the Shopping Cart PM creates an inefficient communications path.

If you’ve grown to the point that you do need to have multiple product managers on the same part of the product (for example, a PM for the Buy button) then it’s time to organize related capabilities under a senior product manager or a Director of Product Management. You might make Susan the Director of Product Management for Purchase and Checkout Experience and then put the PMs for Buy Button, Payment Processing, and Shopping Cart under her.

Susan’s job at this point is to communicate with the company and customers about anything having to do with Purchase and Checkout experience. Todd, the Shopping Cart PM, supports the developers who are working on the shopping cart. Susan supports the rest of the company’s needs for the shopping cart. Susan creates a single stream of communications about her product focus.

The Director of PM can also help with consistency. As your product team grows, it’s easy to end up with an incoherent mess of styles, tones, and ideas. Your Buy Button PM calls it "Add to Bag" and the Shopping Cart PM calls it a "shopping cart." This sort of thing never happened with a single product manager. When Dirk was doing everything, the visual style, word choice, and writing tone all came from Dirk.

It’s tempting at this point to create a top-down process to enforce consistency. A single person like the VP of Product creates all the terminology, decides on all the colors, and writes all the copy. Or at minimum approves it all. But this doesn’t work in practice. People rebel when you take away their ability to be creative. Even if you can keep the team motivated, you’ll find that you can’t anticipate everyone’s needs. Your top-down process gets subverted in the name of efficiency. Or you become a bottleneck when the approval pipeline inevitably clogs up.

Scaling consistency requires that you create a lightweight structure and process. More of a decision making framework than a set of rules. Your goal is to let teams keep their autonomy by giving them a set of guide rails to stay within. Inside those rails, they have total freedom. Outside those rails, they go up the ladder for help.

Those guide rails of your framework will likely change over time, both as you scale and as your team gels. The newer a team is to each other, the product, and the framework, the more support they are likely to need. The framework doesn’t need to be complex. For a mature team, I’ve seen it as simple as, "you can make any decisions that align to our North Star as long as you don’t affect other product lines and don’t cost the company more than $X." For a younger team, your framework might tell them to confirm all plans with any product director outside their reporting chain so that you can catch cross-product consistency issues.

There are a lot of other parts to scaling a team, from recruiting to onboarding to continuing education to designing promotion paths that make sense. These are beyond the scope of this essay, but I’ll end by saying the single best way I’ve found to solve those issues is to put people that are comfortable with change and ambiguity in your leadership positions. As you scale, everything will change rapidly. How you hire, how you train, how you promote, and how you organize your teams will need to change just as quickly. It’s not uncommon to find that what worked six or eight months ago is no longer effective and it’s time to rethink things. Having leaders that can recognize this and thrive on turning chaos into order is the single best hack I know for scaling an organization.

Recently Written

Great prodct managers own the outcomes (May 14)
Being a product manager means never having to say, "that's not my job."
Too Big To Fail (Apr 9)
When a company piles resources on a new product idea, it doesn't have room to fail. That keeps it from succeeding.
Go small (Apr 4)
The strengths of a large organization are the opposite of what makes innovation work. Starting something new requires that you start with a small team.
Start with a Belief (Apr 1)
You can't use data to build products unless you start with a hypothesis.
Mastery doesn’t come from perfect planning (Dec 21)
In a ceramics class, one group focused on a single perfect dish, while another made many with no quality focus. The result? A lesson in the value of practice over perfection.
The Dark Side of Input Metrics (Nov 27)
Using input metrics in the wrong way can cause unexpected behaviors, stifled creativity, and micromanagement.
Reframe How You Think About Users of your Internal Platform (Nov 13)
Changing from "Customers" to "Partners" will give you a better perspective on internal product development.
Measuring Feature success (Oct 17)
You're building features to solve problems. If you don't know what success looks like, how did you decide on that feature at all?


What I'm Reading


Adam Kalsey

+1 916 600 2497


Public Key

© 1999-2024 Adam Kalsey.