Principles of Structuring Product Teams

Principles of Structuring Product Teams 

One of the most challenging issues facing every product organization at scale is determining how to split up your product across your many product teams. This challenge begins to emerge with just a few product teams, but at scale—25, 50, or more than 100 teams—it becomes a crucial factor in the company's ability to move quickly. It's also vital for keeping teams empowered and accountable for something meaningful, while contributing to a bigger vision where the sum is greater than the parts.

If you are already at scale, you know what I’m talking about.

What makes this such a difficult topic is that there is no one right answer. There are many considerations and factors, and good product companies debate the alternatives before making a decision.

I have personally worked with many product and technology organizations as they considered their options, and for many of those, I've been able to observe the outcomes over time. Many people crave a formula for structuring product teams, but there isn’t one. Instead, there are some critical core principles. Understanding these principles and weighing the options for your particular circumstances is key.

1. Alignment with Investment Strategy

It's remarkable how many companies have teams that are merely reflections of their ongoing investments. They have certain teams because they have always had those teams. However, we need to invest in our future as well. We can phase out products that no longer carry their own weight and reduce investments in cash-cow products to invest more in future revenue and growth sources. There are many ways to spread out your investments over time and risk. Some prefer the three horizons model, while others take a portfolio management approach. The essential point is to have an investment strategy, and your team structure should reflect that strategy.

2. Minimize Dependencies

A major goal is to minimize dependencies to help teams move faster and feel more autonomous. While we can never completely eliminate dependencies, we can work to reduce and minimize them. Also, dependencies change over time, so it’s important to track them continuously and always look for ways to reduce them.

3. Ownership and Autonomy

We want teams of missionaries, not teams of mercenaries. This philosophy leads directly to the concepts of ownership and autonomy. A team should feel empowered yet accountable for a significant part of the product offering. This is more challenging than it sounds because large systems don’t always slice up cleanly. Some level of interdependencies will always exist, chipping away at the sense of ownership, but we work hard to maximize it.

4. Maximize Leverage

As organizations grow, common needs and the increased importance of shared services become evident. Shared services are created for speed and reliability, ensuring that teams don’t reinvent the wheel. However, creating shared services also creates dependencies and can impinge on autonomy.

5. Product Vision and Strategy

The product vision describes where the organization is trying to go, and the product strategy outlines the major milestones to get there. Many larger and older organizations lack a relevant vision and strategy, but these are key. Once you have your vision and strategy, ensure your team structure is well-positioned to deliver on them.

6. Team Size

The minimum size for a product team is usually two engineers and a product manager, and if the team is responsible for user-facing technology, a product designer is also needed. Fewer than that is below critical mass for a product team. On the other end, it’s difficult for one product manager and one product designer to keep more than about 10-12 engineers busy with meaningful work. Each product team should have one, and only one, product manager.

7. Alignment with Architecture

For many organizations, the primary principle for structuring product teams is the architecture. Starting with the product vision, an architectural approach is developed to deliver on that vision, and then the teams are designed around that architecture. This approach is practical because architectures drive technologies, which drive skill sets. While full-stack teams are ideal, in practice, different engineers specialize in different technologies. 

It’s easy to see when a company has not aligned its team structure with its architecture: teams constantly fight the architecture, interdependencies are disproportionate, and progress is slow.

8. Alignment with User or Customer

Aligning teams with the user or customer has significant benefits. For example, if your company provides a two-sided marketplace with buyers and sellers, there are advantages to having some teams focus on buyers and others on sellers. Each team can go deep with their specific customer type rather than having to learn about all types of customers. However, there will still be teams providing the common foundation and shared services to all teams, reflecting the architecture.

9. Alignment with Business

In larger companies with multiple lines of business, but a common product f10oundation, the technology is usually integrated across business units. While there are advantages to aligning with business units, this usually comes after other factors in priority.

10. Structure is a Moving Target

The optimal structure for a product organization is a moving target. The organization’s needs change over time. While you won’t need to reorganize every few months, reviewing your team structure annually makes sense.

Conclusion

There is never a perfect way to structure a team—every structure will be optimized for some things at the expense of others. As with most aspects of product and technology, it involves trade-offs and choices. These principles should help guide your organization forward.