Effectively scaling a product team requires more than hiring additional product managers. You also need to consider the big picture. For example, how will all the individuals on your team work together? And how can you help them operate as efficiently and friction-free as possible? This is where considering your product team’s structure begins to matter. Giving your team at least some structure as you expand will help ensure your organization divides roles and skills by the most effective means possible.
Even if your company has just one product manager today, you should still have a structure in mind when it’s time to scale the product team.
There are several ways to structure product teams that have worked for other companies. In this blog, we’ll discuss some of the most common product team structures and give some guidance on choosing the best one for your company.
First, though, let’s review one common misstep you’ll want to avoid when structuring your product team.
Why Your Product Team Shouldn’t Report to Engineering
This often happens in companies where the founders and executives are engineers themselves. Because these businesses are often engineer-focused, they instinctively slot product management under engineering. And in most cases, this is a big no-no.
Sure, plenty of engineers-turned-entrepreneurs have built successful companies. However, one reason for their success is they understood the value of tension between engineering and product management. This understanding ensures the product benefits from multiple viewpoints and that different teams are advocating for what they believe is best for the company.
But a company oriented toward engineering—above, say, marketing—runs the risk of becoming too inward-looking. Such a company might focus on technical elegance, for example, instead of whether that product can achieve a market fit.
For these reasons, you usually do not want to place your product team under engineering.
3 Ways to Structure, your Product Team
1. One product manager per product (or feature).
This is one of the most straightforward ways to grow a product team. Each product or feature (if individual features are large and complex enough) gets its own product manager.
Under this structure, a product manager will own responsibility for all strategic aspects of a given product. This might include market research, forecasting, budgeting, prioritizing features, working with the marketing and sales teams on messaging, and of course, overseeing product development.
Within this framework, you will still have other decisions to make. For example:
- How many developers and designers will you assign to each product manager (in other words, to each product or major feature in the portfolio)?
- How much autonomy will these PMs have? For example, will they need to run all work by an executive or team of stakeholders, or will you allow them to release their work directly to the market?
- Where will these PMs report? For example, will you create a senior-level product position, like a Chief Product Officer or VP of Product? Or will the report to a business unit manager, such as a GM for a given product line.
In our experience talking with many companies that have structured their product teams this way, the most successful arrangement is to create a standalone product organization led by a VP of Product or Chief Product Officer.
2. Product managers’ responsibilities are divided not by product—but according to their skills.
Under this product team structure, you will leverage your product managers’ different skill sets across multiple products.
One product manager might take the lead on market research and developing expertise about user personas across your entire product line.
Another PM will own the budgeting role for the entire portfolio and work with the development team on resource allocation and timelines for all products.
What might this look like in practice? One model is to build a balanced product team consisting of a business product manager, a technical product manager, a design product manager, and a growth product manager.
This product team structure can work well for some companies because they can develop high levels of domain expertise on various aspects of their products and market. However, a risk of using this model is that if one product manager leaves, the entire team might be left without whatever domain knowledge that PM had. This could undermine all products until the company can replace that PM’s expertise.
3. Product managers work closely with a (sometimes autonomous) cross-functional team.
The best example we’ve seen of this product team structure is the product squad, popularized by Spotify. We’ve even written about how the Spotify Squad model could help improve your development.
This type of product team is cross-functional, meaning each team consists of a small group of developers and a product owner. This team will work on a specific functional area of the product line—they will develop domain expertise that can serve multiple products across its product portfolio.
These characteristics can be applied to different types of product teams. But what makes the squad model different is that each squad has the autonomy to release its work to the market (and autonomy is one of the traits of high-performing product teams). No executive stakeholder approval is necessary—no red tape. Instead, the squad develops new code, tests it until the team is satisfied, and then pushes it to the live product.
You can find another example of this model in Amazon’s “two-pizza” team structure. Amazon’s goal is to keep its internal teams lean and able to move quickly. The name comes from the idea that no team should be so big that two pizzas couldn’t feed everyone if they gathered for an evening meeting or work session.
With Amazon, this two-pizza model applies to all internal teams, not only product management. And these teams aren’t all as autonomous as Spotify’s Squads. Often they still need to get the okay from a higher-up before they move forward with an idea.
But the general principles remain the same: Keep your teams as small as possible with the skills and resources they need to get work done.
Why You’ll Need to Restructure Your Product Team—and Why That’s Okay
As any agile company knows, the goal isn’t to get the product right on the first try. Instead, the goal is to get something out there, learn what your users like about it, and then make the product better.
The same is true for structuring your product team. Don’t worry about finding the perfect model right out of the gate. As the social media management company Buffer found out, your first product team structure might not work. (Same goes for your second and maybe even your third.) In fact, Buffer changed its structure four times!
So, be prepared for your product team structure to change as your needs evolve with time. But, for now, based on your company’s size, culture, product portfolio, and other factors, make an educated guess about the best way to set up your product management team. If it works, great. But if it doesn’t, that’s okay. Your next approach will be better.
One final tip: If you’re a product executive interested in learning more about growing and managing a team of PMs, check out our recent book on product leadership.
