Factors in Structuring a Product Organization

For nearly every organization that has grown beyond a very early stage startup, one of the most common, yet difficult, questions is the optimal way to split up the product work.  As soon as you have more than one product manager, or more than one interaction designer, teams face this question.  And for larger organizations, this becomes a very significant and ongoing struggle.

I try to never give a quick, general answer to this question because it is so important and also because there are so many factors that need to be considered.

In this article I wanted to enumerate the factors that I look at in coming up with my recommendation.  I have also taken this a step further and tried to prioritize these factors starting with the most critical, although I will admit that sometimes I adjust this ranking depending on the culture of the company.

1. Clear Ownership.  So much depends on empowered yet accountable product teams.  So to me the top priority always is to make sure you carve out something significant that a product team can truly own and feel empowered to make the changes necessary.  This must always be tempered with the awareness that all of the teams are interrelated at some level, so rarely do we have complete control of our resources and our product area, but we do try to maximize for this sense of ownership.

2. Alignment with User/Customer.   Please note that I’m not referring here to internal customers or stakeholders; that’s below under alignment with business units.  I’m referring here to alignment with the actual customers and users of the site or service.  You would be surprised at how far down the list this gets pushed for many companies (mostly due to the strength of the influences below) but aligning with the user and customer has very real benefits for the product and the team.

3. Alignment with Development Team.   Product managers and designers generally work with developers every day to get their product ideas built, and when the product organization is not aligned with the technology organization, the result is almost never pretty.  You see it when a Scrum team is frustrated because they have multiple product owners to deal with, or when product managers have to constantly fight for resources that keep disappearing.  The key is not to drive the product structure around the engineering teams, but rather to work together with engineering to move together into alignment.  This usually requires a little give and take.

4. Alignment with Architecture.   Related to the alignment with the development team but actually much harder is the alignment with the software architecture.  Basically, every architecture is designed around some set of objectives and the result is that some things are much easier to do than others.  There are many teams, especially those with very old code-bases, where minor things can take a disproportionately long time, and/or require changes across many different areas, and it’s usually because the team is fighting the architecture.  Modern architectures improve this characteristic, but even in the best of cases, there will be implications on the product team structure that stem from the architecture.   Again, this is a balance.  You don’t want the architecture to drive the product.  On the other hand, realize that evolving the architecture to better enable the way the team wants to work can be a very significant undertaking.

5. Alignment with Business Units.   The fact that this is last on the list will doubtless cause some grief with some business unit leaders as this is typically the highest weighted factor by most organizations, but in my view that’s often a big mistake.  There’s an old saying that if you want to know the politics of a company, just look at the web site.  The reason this is true is that so often the product organization structures around the business units (rather than the user or customer).  If the business units are organized around the user or customer then this is much less of a problem, but more often they are organized instead around other factors like function or revenue streams.  It is nice when the user, technology and business units all align, but there are often good reasons why this is not the case, and if that’s the situation you are in, I advocate aligning the product first around the user, then technology, and finally the business unit.

Notes:

– This entire discussion relates strongly to the dedicated team model (see https://svpg.com/dedicated-product-teams/) and also to the development process the team is using (especially true with Scrum).  Moving to dedicated teams and using a modern process such as Scrum will force some of these issues and in most cases help considerably in the above alignment objectives.

– 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 revisiting your structure every year or so makes sense.

– For larger teams especially, it is very common to have one or more teams that provide common services to the other product teams.  Often we call these teams “common services” or “core services” or “platform” teams.  This is extremely high-leverage, but also among the most difficult types of product teams because of the technology, the dependencies, and the wide range of users.  Be sure to staff these common services teams with strong and technical product leaders.

Finally, realize that there is never a perfect way to structure a team – every attempt at structure of the product organization will be optimized for some things at the expense of others.  So as with most things in product, it involves trade-offs and prioritization.  Hopefully these factors will help you as you guide your organization forward.