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

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.

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.