One of the most difficult issues facing every product organization at scale is just how to split up your product across your many product teams.
The need to split up your product starts to show up with just a few product teams, but at scale—25, 50, more than 100 product teams—this becomes a very substantial factor in the company's ability to move quickly. It's also a significant factor in keeping teams feeling empowered and accountable for something meaningful, yet contributing to a bigger vision where the sum is greater than the parts.
If you are already at scale, then I'm certain 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 and then make a decision.
One of the most difficult issues facing every product organization at scale is just how to split up your product across your many product teams.
I have personally worked with many product and technology organizations as they considered the options, and for many of those, I've been able to watch how things worked out over time.
I know that many people crave a recipe for structuring product teams, but I always explain to them that there is no recipe. Instead, there are some critical core principles, and the key is to understand those principles and then weigh the options for your particular circumstances.
Alignment with investment strategy
It's remarkable to me how many companies I find in which the teams are simply reflections of their ongoing investments. They have certain teams because they have always had those teams. But, of course, we need to be investing in our future as well. We can phase out products that no longer carry their own weight, and we can often reduce the investments in our cash‐cow products so that we can invest more in future sources of revenue and growth. There are any number of ways to think about spreading out your investments over time and risk. Some people like the three horizons model, while others take more of a portfolio management approach. The point here is that you need to have an investment strategy, and your team structure should be a reflection of that.
Minimize Dependencies
A big goal is to minimize dependencies. This helps teams move faster and feel much more autonomous. While we can never entirely eliminate dependencies, we can work to reduce and minimize them. Also note that dependencies change over time, so track them continuously and always ask yourself how they can be reduced.
Ownership and Autonomy
Remember that one of the most important traits of product teams is that we want teams of missionaries and not teams of mercenaries. This leads directly to the concepts of ownership and autonomy. A team should feel empowered, yet accountable for some significant part of the product offering. This is harder than it sounds because large systems don't always slice up so cleanly. Some level of interdependencies will always chip away at the sense of ownership. But we work hard to try to maximize this.
Maximize Leverage
As organizations grow, we often find common needs and the increased importance of shared services. We do this for speed and reliability. We don't want every team reinventing the wheel. Realize, however, that creating shared services also creates dependencies and can impinge on autonomy.
Product Vision and Strategy
The product vision describes where we as an organization are trying to go, and the product strategy describes the major milestones to get there. Many larger and older organizations no longer have a relevant vision and strategy, but this is key. Once you have your vision and strategy, ensure you have structured the teams to be well positioned to deliver on them.
Team Size
This is a very practical principle. 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, then a product designer is needed, too. Fewer than that is considered below critical mass for a product team. On the other end, it's really difficult for one product manager and product designer to keep more than about 10–12 engineers busy with good stuff to build. Also, in case it's not clear, it's important that each product team have one, and only one, product manager.
Alignment with Architecture
In practice, for many organizations the primary principle for structuring the product teams is the architecture. Many will start with the product vision, come up with an architectural approach to deliver on that vision, and then design the teams around that architecture.
That may sound backward to you, but in truth there are some really good reasons for this. Architectures drive technologies, which drive skill sets. While we'd love for every team to be a full stack team that can work on any layer of the architecture, in practice that's often not an option. Different engineers are trained in different technologies. Some want to specialize (and, in fact, have in many cases spent many years specializing), and some are years away from having the necessary skills. Architecture does not change quickly.
It's usually easy to see when a company has not paid attention to the architecture when they assemble their teams—it shows up a few different ways. First, the teams feel like they are constantly fighting the architecture. Second, interdependencies between teams seem disproportionate. Third, and really because of the first two, things move slowly, and teams don't feel very empowered.
For larger companies, especially, it's typical to have one or more teams that provide common services to the other product teams. We often label these teams common services, core services, or platform teams, but they primarily reflect the architecture. This is very high‐high leverage, which is why so many companies have these types of teams at scale. However, it is also a difficult type of team to staff because these teams are dependencies (by design) of all the other teams, as they are there to enable the other teams. Be sure to staff these common services teams with strong and highly technical product managers (often called platform product managers).
Alignment with User or Customer
Aligning with the user and customer has very real benefits for the product and for the team. If, for example, your company provides a two‐sided marketplace with buyers on one side and sellers on the other, there are real advantages to having some teams focus on buyers and others focus on sellers. Each product team can go very deep with their type of customers rather than have them try to learn about all types of customers. Even in marketplace companies, however, they will invariably have some number of teams that provide the common foundation and shared services to all the teams. This is really a reflection of the architecture, so the point here is that it is perfectly fine—and usual—to have both types of teams.
Alignment with Business
In larger companies, we often have multiple lines of business but a common foundation for our products. If the technology is truly independent across businesses, then we'd just treat them as essentially different companies as we structure product teams. However, mostly that's not the case. We have multiple lines of business, but all are built on a common and often integrated foundation. This is roughly similar to aligning by customer type, but there are important differences. Our business unit structure is an artificial construct. The different business units are often selling to the same actual customers. So, while there are advantages to aligning with business units, this usually comes after the other factors in priority.
Structure Is a Moving Target
Realize that the optimal structure of the product organization is a moving target. The organization's needs should and will change over time. It's not like you'll need to reorganize every few months, but reviewing your team structure every year or so makes sense.
I often have to explain to companies that there is never a perfect way to structure a team—every attempt at structuring the product organization will be optimized for some things at the expense of others. So, as with most things in product and technology, it involves tradeoffs and choices. My hope is that these principles will help you as you guide your organization forward.
Most leading tech companies have jumped on the empowered, dedicated/durable, cross‐functional, collaborative product team model I have described here, and I think they are much better for it.
The results speak for themselves, but I attribute most of the benefits to the increased level of motivation and true sense of ownership when teams feel more in control of their own destiny.
I attribute most of the benefits to the increased level of motivation and true sense of ownership when teams feel more in control of their own destiny.
However, while most leaders tell me they have empowered, autonomous teams, some of the people on those teams complain to me that they don't always feel so empowered or autonomous. Whenever this happens, I try to get to the specifics of just what it is that the team is not able to decide or where they feel constrained.
Most of what I hear falls into one of two cases:
In general, most teams would probably agree that there are some things that are wide open for the team to do as they think best and other areas that are part of the common foundation that all teams share.
As an example of the latter, it would be unusual for each team to select its own software configuration management tool. If the engineering team has standardized on GitHub, then that is usually considered part of the foundation. Even if one team had a strong preference for a different tool, the total cost to the organization of allowing its use would likely far outweigh any benefits.
While this might be a straightforward example, there are many others that are not so clear.
For example, should each team be able to approach test automation in its own way? Should teams be able to select the programming languages they wish to use? What about user interface frameworks? What about browser compatibility? How about expensive features like offline support? How about the flavor of Agile they wish to use? And does every team really need to support several company‐wide product initiatives?
As is so often the case with product, things boil down to a tradeoff—in this case between the team's autonomy and leverage of the foundation.
I will also confess here that, while I love the core notion of autonomous, empowered teams, I am also a big fan of investing in a high‐leverage foundation. This means building a strong foundation that all teams can leverage to create amazing products and experiences much faster than they would otherwise.
For the record, I do not believe that there is one answer to this question. The best answer is different for each company, and even for each team, and the best answer is also a function of the company's culture.
Here are the key factors to consider:
There are roughly three team skill levels: (1) A team—an experienced team that can be entrusted to make good choices; (2) B team—these people have the right intentions but may not have the level of experience necessary to make good decisions in many cases and may need some assistance; and (3) C team—this is a junior team that may not even know what they don't know yet. These teams can unintentionally cause substantial issues without significant coaching.
One of the main arguments for leverage is speed. The logic goes that teams should be able to build on the work of their colleagues and not spend time reinventing the wheel. However, sometimes it's simply an accepted and acknowledged cost of empowerment to allow teams to potentially duplicate areas or proceed slower in the name of autonomy. Other times, the viability of the business depends on this leverage.
In some companies, the portfolio is a set of related, but largely independent, products in which integration and leverage is less important. In other companies, the portfolio is about a set of highly integrated products in which integration leverage is critical. This boils down to whether the team should optimize for its particular solution or optimize for the company as a whole.
If the main sources of future innovation are necessary at the foundation level, then there will need to be more freedom for teams to revisit core components. If the main sources of innovation are expected to be at the solution level, then the company needs to encourage less revisiting of the foundation and, instead, focus the creativity on application‐level innovations.
Many of the problematic issues with autonomy arise because of issues of scale. As companies grow, and especially as companies have teams in disperse locations, leverage becomes both more important and more difficult. Some companies try to deal with this with the center of excellence concept in which leverage is focused on teams in a physical location. Others try stronger holistic roles. Yet others add process.
It is also important to acknowledge the role that an emphasis on autonomy versus leverage plays in team culture. The further on the spectrum that the company pushes toward leverage, the more this can be perceived by the teams as chipping away at their level of autonomy. This may be acceptable for B‐ and C‐level teams but more problematic for A‐level teams.
One frequent problem is to try to standardize on a common foundation prematurely. The foundation isn't yet ready for prime time, in the sense of the leverage it is designed to provide. If you push too hard on leverage before the foundation is ready, you can truly hurt the teams that are counting on this foundation. You're building a house of cards that may collapse at any time.
Assuming the foundation is solid, there's likely more risk in a team not leveraging that foundation. This might be fine for some areas, but with products or initiatives that are business critical, it becomes a question of which battles to pick.
Another factor is the level of accountability that goes along with the empowerment and autonomy. If there's no accountability—and especially if you don't have strong A teams—there's little reason for the teams to stress about these tradeoffs. But you want the teams to stress over these tradeoffs. If I believe the team is strong and they fully understand the consequences and risks, and yet they still feel they need to replace a key component of the foundation, then I tend to side with that team.
As you can see, there are no lack of considerations in the tradeoff between autonomy and leveraging the foundation. But, I find if you discuss these topics openly, most teams are reasonable. Sometimes, just a few key questions about some of the implications can help teams make better decisions regarding this tradeoff.
If you find that teams are consistently making poor decisions in this regard, you may need to consider the experience level of the people on the team, but most likely, the teams are missing the full business context.
The critical context is comprised of two things:
We will discuss both of these key topics in the coming chapters. Problems arise if the leadership does not provide clarity on these two critical pieces of context. If they don't, there's a vacuum, and that leads to real ambiguity over what a team can decide and what they can't.
Note that while the product vision and the team‐specific business objectives are provided to the team by leadership as part of the context, nothing is said about how to actually solve the problems they are assigned. That's where the team has the autonomy and flexibility.