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 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.
- 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.
- Maximize Leverage (refers to the strategic use of shared services, resources, or common needs to maximize efficiency, speed, and reliability within an organization.): As organizations grow, we often find common needs and the increased importance of shared services. We do this for speed and reliability. 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.
- 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.
- 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.
- 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. 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.