Establishing a Product Organization Structure
24 May 2020 ‧ 12 min read
One of the essential areas of responsibility for product leaders is setting up the organizational structure of the product development department. For an overview, read my high-level article on product leadership responsibilities, or continue reading for a deep dive on org design.
Creating digital products is a complex undertaking. Any non-trivial digital product requires multiple people with different skill sets to cooperate in the discovery, design, development, operation, and distribution of the product. This cooperation needs some degree of formalization in the form of an organizational structure and processes. Org structure determines the “who” (who works together with whom), and processes determine the “how” (what are the steps to take in the work). In addition to these formal aspects, informal aspects like culture of course also play an important role, but in this article I will focus on the formal aspect org structure specifically. I am planning future articles on processes and culture.
In general, the larger an organization, the more formal structure is required. A startup of five people can still get away with very little formal structure. Everyone can still talk to everyone, coordination is relatively cheap. Chances are that even at this size, there will be some formalization, though—likely one of the five has the job title “CEO” and the others, well, don't.
It's easy to see why larger organizations need formalized substructures. The number of one-to-one relationships grows with the square of the number of people. In a five-person team, there are 10 one-to-one relationships. In a ten-person team, the number is already 45. For a 20-person team, we're looking at 190 relationships, and for a 100-person team, a whopping 4950. Another way to think about this: in a 100-person company, hiring someone new means they have potential relationships with each of the existing 100 people. Clearly, we need substructures for larger teams, or people will be so busy just managing their various relationships and interfaces with other people that they won't get any work done.
Worst practice: command and control
In this article, I'll talk a bit more about some best practices of organizational setup for product development teams. Before diving into best practices, though, let me first outline what a modern product organization should not look like.
A product organization should not be set up as a command-and-control type hierarchical organization, in which managers make decisions and then delegate tasks to implement these decisions to their subordinates.
There are several reasons why the command-and-control model doesn't work well for product organizations. The first reason is motivation. Product design and development is a highly creative endeavor. The team can't just follow procedures and check boxes and create an amazing product—they need to be motivated to do a great job and produce outstanding results. According to the highly recommendable book “Drive”, the best way to motivate people is by giving them autonomy, mastery, and purpose (leading to intrinsic motivation).
In other words, people do their best work when their leaders give them a “why” they subscribe to (purpose), they have freedom to decide the “what” (autonomy), and they receive support to grow in the “how” (mastery). This, of course, is fundamentally at odds with a command-and-control management style—especially the “autonomy” part.
Team autonomy has another big advantage speaking against command-and-control style management: shorter feedback loops. When an autonomous team discovers new information about the customer, the market, or the technology, they can immediately act on that information. In a command-and-control environment, that information has to travel up the management chain for a decision and then back down for implementation. Of course, even with autonomous teams, new information uncovered at the front lines should not remain confined to where it was uncovered, but rather dispersed through the organization. However, being able to act immediately significantly speeds up the organization's reactiveness. This is especially important in the discovery and design phase, where an amorphous problem or opportunity becomes increasingly well-defined and finally a solution is developed. If every decision made during this process requires management intervention, the process will become painfully slow (or simply produce sub-optimal results since it isn't run as iteratively as it should).
What goes hand in hand with the shorter feedback loop is a greater attention to detail. An autonomous team only works well if the team members fully understand and are bought into the product direction, and if they do, they can sweat the details much more effectively than if decision-making and implementation are separated by layers of management.
What about Apple under Steve Jobs, though? Steve Jobs was well known for being controlling, but Apple produced some of the greatest and most successful products of all time while he was CEO. Doesn't that provide a counter-example to the notion of command-and-control style management being detrimental to good product development? If you read “Creative Selection” about the development of the original iPhone, you will see that there was definitely autonomy as well as a deep understanding of the product vision and direction within the teams working on the iPhone. Also, it's a cliché but it needs to be said: few leaders have the same degree of vision and attention to detail as Steve Jobs had. Therefore I don't think Apple presents a counter-example.
Empowered cross-functional product teams
Now that we've seen the reasons for avoiding command-and-control management and opting for autonomy instead, how should we organize the product development organization? The answer is empowered cross-functional product teams. A product team is an atomic product development team, consisting of the various disciplines required to build or improve a product.
A product team should be as small as possible. Typically, each product team has a product manager, a designer (or one for UX and one for UI), and no more than a handful of engineers. Depending on the team and its subject area, there might be others like data analysts, user researchers, or domain experts as well. Amazon's famous “two-pizza rule” very much applies here: The team should be no larger than can be fed by two pizzas (i.e., no more than 5-8 people). Once a team grows beyond that, it's better to break it up into multiple product teams. Team members should in general be dedicated to the team, i.e., they should spend most of their working hours on the joint mission of the team.
These teams are the key organizational unit in which product work gets done. There typically is no formal reporting line inside these teams, though: team members do not report to the team's product manager, for instance. Therefore, there is no command-and-control style management even within these teams. That is not to say that there is no degree of leadership in the teams. Typically these teams are led by a “triad” of product manager, designer, and lead engineer who work together and with the rest of the team to make decisions.
Beyond the “core” functions of a product team, there is often the question of how bordering functions should be integrated. For example, how should QA, user research, or infrastructure be integrated? What about product marketing or CRM? The answer of course depends on the context and the size of the team. Dedicated team membership works if the function is big enough and there is enough work for the person on the product team. For example, having a dedicated QA person on each team can work quite well. Another option is part-time membership. For example, one user researcher might support two product teams. This option is sometimes unavoidable but it is risky: meetings and processes from two teams can be a huge time suck, the person will have a lot of context switching, and will not be as deeply immersed in the problem and working relationships of the team. The last option is defining interfaces with the other function. One specific example of this would be an internal-facing product team (often used for backend-heavy topics or internal tools).
How exactly the autonomy of the team manifests itself can vary between organizations and from team to team. It depends on the product, the culture, as well as the people on the team and their preferences. One guiding principle, though, is to assign the team problems or opportunities, not projects, and make the team responsible for delivering customer and business outcomes, not output in the form of delivering projects. If you assign problems to a team and give them the freedom to discover the best solution, the team will be more motivated (because they understand the “why”) and more creative in finding the best possible solution.
The autonomy should also be reflected in how teams do their work. While common standards are sometimes necessary (for example, all source code needs to live in the same version control system), teams should be free to decide what works best for their internal workflows.
How product teams come to be
How do these product teams get started? There is no “correct” answer, but there are a few dimensions along which decisions can be made about their setup.
Permanence of the teams
The first dimension is how permanent these teams and membership within them is. On one end of the spectrum, teams stay stable basically forever (but their objectives might change over time). New people are hired onto a specific team and expected to remain there. On the other end of the spectrum, teams are spun up to address emerging opportunities and disbanded once their objective has been achieved. There are obviously also models in between these two extremes.
Both ends of the spectrum have their advantages and disadvantages. Stable teams allow people to build deep relationships and teams to iterate on their way of working, making them more effective over time. On the other hand, it can lead to siloing of knowledge and deviating cultures. It can also have an “everything is a nail” effect: a team gets great at a certain way of working and solving problems, and will start applying that way of working to all problems, regardless of whether it is the most appropriate way. Short-lived teams allow for higher flexibility and matching emerging opportunities with the best talent available in the organization. On the other hand, having to build new relationships with team mates frequently can be stressful for team members and lead to friction, reducing effectiveness.
On the whole, over time I have come to favor more stable teams. However, to avoid siloing, I believe that some degree of change to team composition every now and then should be enforced. These team composition shake-ups usually cause some discomfort for team members. However, it is worth noting that some level of discomfort is necessary for all learning. Leaving a team composition intact leaves the team in its comfort zone; changing it causes discomfort but also causes the team to learn and adapt and ideally come out a better team.
Assigning areas of responsibility
For stable teams, there is also the question of how fixed the areas of responsibility of the teams should be. In other words, does each team keep working on similar topics or parts of the product over time, or do these responsibilities shift? If teams have specialized domain expertise (for example, a dedicated domain expert is part of one team), then the areas of responsibility may have to stay quite fixed. Otherwise, there is again a tradeoff to be considered: stable areas of ownership means expertise (for example, for parts of the code base) can be developed in the team, but it can lead to knowledge silos. As with stable vs flexible teams, there isn't a cut and dry answer for this question. Forcing some team flexibility can also help address the risk of knowledge silos, though.
Another question is whether you attempt to assign responsibilities that cover the entire product. Should every existing feature and every part of the codebase have an “owner”? Again, there is a tradeoff involved. Assigning ownership (to teams or individuals) means there is a steward of knowledge for all aspects of the product. However, it is paramount that each team only has one focus at any given point in time. Therefore, it is important to avoid any additional areas of ownership sucking up too much time of the team. This is best achieved by clearly defining what this ownership entails (and what it doesn't), and monitoring the amount of time spent on it.
Staffing the teams
Staffing—the determination which person goes on which team—can be extremely tricky. If you have teams that stay stable for a longer time, you don't have to make these decisions very often, but they will impact the team performance for a long time. Conversely, with flexible teams, you will make a lot of staffing decisions, but each one won't matter as much. It follows that with stable teams, your staffing process requires more diligence, and with flexible teams, more speed.
It's impossible to be prescriptive about the details of the staffing process. However, here are some criteria to take into consideration when making staffing decisions:
- Capabilities / skills: it almost goes without saying that need the people with the right skills on the team, for example, if the team is working on features requiring backend work then you need an engineer capable of doing that work.
- Previous experience: it can be beneficial to have people on the team who've done similar work or worked on the affected area of the product before, so they have less context building to do and can share knowledge with the team.
- Performance management aspects: in development plans, you might have promised a team member the opportunity to work in a specific area or learn from a more senior person. Staffing decisions help deliver on these promises.
- Team dynamic: to build a high-performing team, it's important to take into account “soft” factors like existing relationships, personality profiles, working styles, etc., and put together people that you believe will be able to work together effectively.
- Physical location: if a team isn't all-remote, they should ideally be collocated. This means seated in a way that everyone can see each other, not just “in the same building”. What's worst is if some people sit together, but the rest of the team doesn't—that means the people not sitting with the rest of the team might feel less included.
- Seniority mix: it's important to balance seniorities on the team correctly, so that you allow mutual learning, set the team up for success, balance different teams against each other, etc.
- Diversity (gender, race, age, background,...): diverse teams perform better, so you should aim to make your product teams as diverse as possible. That's of course partly a hiring question, but needs to be taken into account in staffing too (e.g., don't put all your female engineers on the same team).
Team superstructures
In larger product development organizations, you probably need a superstructure spanning over the product teams—some kind of grouping that helps organize and align the various teams. I am far from an expert on that topic, so instead of diving too deeply into it, let me just mention a few possible organizing criteria by which you might group product teams:
- By product or product area
- By customer/user group
- By overarching goal, e.g. growth vs engagement
- Temporary structures for strategic initiatives comprising multiple teams, e.g. a multi-quarter effort to improve various aspects of onboarding
The role of formal reporting lines
While most of the work gets done in cross-functional product teams, there is also the functional element. In many product organizations, the formal reporting line is functional. In other words, engineers report to engineering managers, designers to design manager, and product managers to product directors or similar roles.
It's important to understand that this formal reporting line does not mean that the functional managers engage in a command-and-control style management with their reports—remember, the cross-functional teams are empowered and autonomous, and these teams are at the heart of the product development lifecycle. However, that doesn't mean there is no role for functional leadership and management. To the contrary: as Marty Cagan emphasizes, autonomous and empowered teams don't need less managing:
Empowering means creating an environment where your people can own outcomes and not just tasks. This doesn’t mean less management, it means better management. You must step back to create this space, while stepping in to remove impediments, clarify context, and provide guidance.
Functional coaching and development
Instead of telling their reports what to do, the key responsibility of the functional managers is developing their reports, for example through development plans, feedback, and coaching.
This functional aspect complements the natural learning and development that happens in the cross-functional team. Of course, product teams should practice continuous improvement, for example, by conducting regular retrospectives. However, there is a limit to the functional learning that can come from this kind of continuous improvement. For example, a designer is unlikely to “level up” in terms of information architecture or trends in UI design from retrospectives with their engineers and product manager. Coaching from a line manager who's a more experienced designer is much more effective here.
Context and direction
The role of providing direction is itself not a task that differs by job function. The product direction needs to be as cross-functionally aligned as the implementation of it in product teams. In other words, at the leadership level, alignment has to happen between the various functions (e.g., product management, engineering, design) before the direction is cascaded down to the product teams.
Functional line management still plays a role in the direction-setting though, in highlighting the specific aspects to the function to their reports and providing guidance and coaching on how to make the direction actionable.
Organization size and reporting structure
Especially in small teams, it is not necessary to have dedicated managers for each function. For example, often the first few product managers report directly to the CEO, or both individual product managers and individual designers might report up to the same VP of Product instead of to separate functional managers. Similarly, on the engineering side, companies often start out with a generic engineering management structure and only later have specific managers for e.g. backend and frontend.
In smaller teams, there is also the model of the “player coach”, in which the team is led by one team member who splits their time between individual contributor work and team leadership. These player coaches are sometimes called “lead” (e.g., Design Lead or Engineering Lead) or specifically for product managers, Group Product Manager (GPM).
While the player coach model means not having to hire a dedicated manager (who is not “delivering” anything), it can also place a high workload on the player coach, since they are expected to deliver 100% in their product team and then also develop and lead the rest of the team. It might be better to have a dedicated manager who can pick up some small tasks to help out the product teams, but who isn't part of a product team themselves.
Alternatives to line management
As a side not to the topic of formal reporting lines, there are also alternative approaches to organizational design that forego line management altogether and embrace a more dynamic structure. Holacracy, perhaps most famously implemented by US E-commerce pioneer Zappos, might be the most well-known one. I personally have no experience with these alternative approaches, and hence have no strong opinion.
In most companies, having a traditional reporting line structure is still the status quo. Abandoning the functional reporting line means that to fully reach the potential of the team, the coaching and guidance aspects have to be anchored differently in the organization. I used to work in management consulting, where this separation is the case: technically, my reporting line was to the office manager, but practically, guidance and day-to-day coaching happened in the project team, and there was whole separate career development and training structure. The reason this (mostly) works in consulting companies is that there is basically one career path and thousands of consultants with very similar profiles. If you wanted to implement such a model in product development, you would have to account for the specifics for all the different functions. Especially for smaller organizations, this might mean too much overhead in comparison to a traditional line management organization.
In conclusion, I think that a functional formal reporting structure is still the state-of-the-art approach, especially for mid-sized organizations that are big enough for dedicated functional managers but not so big that they can afford the overhead of centralized career development teams.
I hope this article was helpful. If it was, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.