The Case for Empowered Product Teams

Why you should let your teams figure out what to build

One of the central best practices of modern product development is the empowered product team. An empowered team is a cross-functional team, composed of product, design, and engineering, that is tasked with solving specific customer problems in ways that serve the business. In other words, these teams have goals for customer and business outcomes, not goals in terms of the output (products or features shipped).

However, most organizations do not follow this model, but instead have delivery or feature teams that build product features that someone else (leadership or business stakeholders) has scoped, prioritized, and put on a roadmap. In this model, the teams are responsible for the output the create — the features they ship — not for the outcomes for customers and the business they realize.

In this article, I will review some of benefits of the empowered team model as well as reasons why organizations stick with the “traditional” model, and show that in most cases, the empowered model will lead to better results in the long term.

The benefits of empowered product teams

Empowered teams have benefits over delivery or feature teams in terms of motivation, customer centricity, velocity, and innovation. Let’s look at these benefits in detail.

Motivation

There are two types of motivation: extrinsic and intrinsic. Extrinsic motivation is for example monetary compensation. Intrinsic motivation is driven more by the needs and desires of each person. In general, tapping into intrinsic motivation will lead to higher, more sustainable performance and team morale — after all, if you are intrinsically motivated by the work you do, it is because it is aligned with what you want and need.

According to the fantastic book “Drive”, intrinsic motivation has three pillars: autonomy (wanting to make our own decisions), mastery (becoming better at what we do), and purpose (following higher level goals with what we do). Of the three, mastery is something that can be achieved in both empowered and non-empowered teams. You can become a master developer or master visual designer in each of those settings. Purpose could be achieved in both settings as well, but most of the time, feature and delivery teams are somewhat disconnected from the purpose that their work fulfills — they get handed a task or feature and get told to build it without necessarily understanding the benefits to customers and the business in detail. Last but not least, autonomy is obviously highest in empowered teams, where teams have decision power not only over the “how”, but also the “what”. In feature or delivery teams, leadership and stakeholders decide “what” features will be built, the team only decides “how” they will be implemented.

Due to these reasons, empowered product teams tend to have higher intrinsic motivation, leading to higher, more sustainable performance and lower turnover.

Customer-centricity

Empowered product teams are tasked with achieving outcomes, solving customer problems in ways that serve the business. Their objectives revolve directly around the customer. Feature and delivery teams are tasked with building features that stakeholders have prioritized. Their primary concern, then, is making those stakeholders happy, not the customers.

Empowered teams need to solve customer problems. The only way forward for them is to empathize with and understand the customers, talk to them, and involve them in discovery activities. This leads to a greater understanding of the true customer needs in the empowered team and therefore to a better ability to produce the desired outcomes.

This built up understanding of the problem as well as the empathy with the customer also leads to greater attention to detail in the empowered product team, for example when user testing proposed solutions and identifying flaws in the user experience.

All in all, the empowered team has a more customer focused mindset and therefore is more likely to realize the desired outcomes for the customers.

Velocity

Product discovery and development work should always be iterative. Each iteration leads to decision points — do we pursue a given path further, which of several options do we pick, have we uncovered information that means we should change course, etc.

In an empowered product team, these decisions can be taken within the team. Feature and delivery teams typically need to take these decisions back to the stakeholders sponsoring the work. Since the stakeholders aren’t as steeped in the day to day details of the team’s work, context has to be built up first before a decision can be made.

Often, sprints of fixed length are utilized to ensure that stakeholders are regularly kept in the loop and can make the required decisions in a timely fashion. However, the need for decisions could arise at any point in time. New information could be uncovered on the first day of a sprint, many days before the next meeting with the sponsor. In those cases, the decision will either have to wait, or it will have to be escalated separately.

The empowered product team doesn’t have these timing issues. They have the maximum ability to react to new information as it surfaces, thus increasing reactivity and velocity.

Innovation

Technology-enabled companies create value by solving customer problems in ways that serve the business, leveraging technology. Innovation happens when new insights and approaches are discovered in one or multiple of these areas (technology, understanding of the customer problem, business model).

Cross-functional teams bring together the specialists in those areas, and allow them to work hand in hand to discover these new insights. An engineer might be aware of an emerging new technology and a designer of a developing customer need that could be solved by that technology. By working together in interdisciplinary cooperation, a team including these two individuals might be able to unlock a valuable innovation.

Empowered product teams are cross-functional by default and are as close to the customer is possible. In feature or delivery teams, the business and often also the customer knowledge sits with the stakeholder, while the technology knowledge is located within the teams. It is thus much harder to gain an understanding of the synergies and new possibilities unlocked by developments in the various areas.

Empowered product teams therefore have an advantage in discovering and developing technology-enabled innovations.

Why organizations stick with command and control

Given all the benefits of empowered teams outlined above, why do so many organizations stick with non-empowered teams? The first reason is of course inertia. Many organizations are used to a “command and control” style of management in which leaders decide and teams execute. The feature and delivery team model fits well with this model. Organizational inertia, sticking with the status quo, is of course a powerful force, but given the advantages of empowered product teams, should not be used as an excuse — there are good reasons to overcome this inertia.

Another reason why companies stick with the non-empowered model is an organizational setup and operating model in which the “IT” function is a cost center serving the “business”. In this case, all knowledge of the customer and the business is located on the “business” side of the organization and the technology knowledge in the “IT” function. Digital products are developed through the means of “requirements” gathered on the business side.

The big problem with this operating model is that “Software is Eating the World”: increasingly, digital product experiences are becoming core part of companies’ value propositions, the digital products are becoming the business. Separating the people building those products and understanding the technology from the business and customers makes that much harder. Indeed, in Silicon Valley companies, you will not find this “business” vs “IT” divide. In these companies, product organizations which include the engineering capabilities are the business, which is supported by other more business-oriented functions like marketing and sales. In a world where digital experiences are becoming more and more essential, even companies in more traditional industries will have to start adopting this product-centric mindset or face disruption. (An interesting case study here might be that of Tesla vs incumbent auto makers).

While my first two points were about legacy businesses, even startups can end up in a setup of non-empowered product teams. This often happens when founders / leaders hire for operational leverage (more hands to implement the leaders’ plans) instead of hiring for vision leverage (more minds to realize the company vision). In other words, they are hiring mercenaries instead of missionaries. This has all the drawbacks as outlined above, with the added challenge that it doesn’t scale well. If a founder hires their first few mercenaries, the founder might still be able to make all important decisions and simply have the mercenaries execute them, but the more an organization grows, the harder it will be for the founder to make all high-impact decisions. They will become farther and farther removed from the details, resulting in lower quality decisions, and will have far too much on their plate to make all decisions in a timely manner.

One of the reasons startups end up in this position (and this applies to incumbent businesses, too) is that the feature and delivery team models can feel faster from a management perspective. Management makes decisions and the team immediately starts working on them. No discussions, no need to convince, no need to generate buy-in. If the leaders receive information and want to change course, they just tell the team what to do. This, however, is a fallacy. The actual product development work gets done within the team, and from the perspective of the team, management becomes the bottleneck: any time a decision needs to be made, management has to be involved. Also, new information about technology and user experience gets discovered when the team is working on building and validating the product — an empowered team can process the information and make decisions immediately, whereas in the non-empowered team, this information has to travel up the management chain and decisions down again in order for the team to proceed. In the best case, this slows the team down. In the worst case, the information will simply be discarded because the team will deem it too cumbersome to even trigger a decision. In either case, the empowered team will build the better product, faster. It might just feel less fast and more cumbersome to managers who are used to snapping their fingers and getting their will.

Another flaw in the “velocity” argument is that it focuses the team on output. In this case, the product development organization is seen as a “delivery machine”, and maximizing output (features shipped) is seen as the desirable objective. However, more output isn’t really what the end goal is — the end goal is realizing customer and business outcomes. Output is only one necessary ingredient. A singular focus on output is setting the wrong incentives for the team, which is why a team with goals centered on outcomes (but balanced with other factors such as output, input, and learning) will deliver better results in the end.

Another reason that organizations stick with the non-empowered model is that business leaders that they “know better”. After all, they have more experience than the team and are the experts of their industry. This is another fallacy, though: of course, experience can be helpful as context and can speed up getting to the issues that matter. Once a team has built up that context, though, it’s worth noting that the uncertainty axiom applies to management just as it does to team members: regardless of your initial confidence in product ideas (and whose ideas they were), most of them won’t deliver the hypothesized value (to the customer, to the business) you hoped for. Moreover, you won’t be able to identify the bad ideas until you have invested substantial effort in exploring them. In other words, ideas of managers and leaders won’t necessarily be better. What’s most important is trying out ideas with as little effort and as fast feedback loops as possible in order to identify the “bad” ideas and improve and iterate on the “good” ones. Feedback loops, however, are much faster in the case of the empowered product team that can immediately act on new information as it is uncovered.

A related but different reason is that management believes their product development staff to not be capable enough to work in an empowered fashion. This can either mean that they generally assume the talent level to be too low (“this could never work here, we don’t have talented folks like Google”) or specifically (“our IT guys don’t understand the business, we need to write requirements to translate business terms into technical terms for them”). The general assumption of low talent level really shouldn’t hold anyone back from the model of empowered teams. You need a certain base level of competence, and more importantly, you need people who are willing to collaborate and not be jerks to each other. In Marty Cagan’s words:

Truly empowered teams that produce extraordinary results don’t require exceptional hires. They do require people that are competent and not assholes, so they can establish the necessary trust with their teammates and with the rest of the company.

In terms of the understanding of the business by folks on the “IT” side: this can indeed pose an issue when starting to set up empowered teams. You do need a certain level of interest in how the business works and what problems customers have. You do need people that are willing to make the realization of the company vision their objective, instead of just striving for functional mastery. In other words, you need people to be willing to convert from mercenaries to missionaries. However, very often, people will have a certain degree of identification with the organization and its mission already. With the base level of interest, the understanding can then be built up. To that end, it’s important to understand that empowered product teams are by nature cross-functional, with product managers representing the business perspective on the team, as well as designers representing the customer perspective. You don’t need the technical people to start as experts in the business and customer. Over time, everyone on the team will build up a deeper understanding of everything that makes up the product — business, technology, and customer/user experience — while of course, the disciplines will still have their areas of expertise. So while getting started in an empowered model might require a bit of bootstrapping, building up of mutual understanding, and potential clashes of perspective, over time, the team will be more motivated (due to the trifecta of autonomy, mastery, and purpose) as well as producing better results due to cross-functional collaboration.

In summary, the reasons why organizations stick with the “traditional” model of delivery or feature teams might indeed be impediments to adopting the empowered product team model, they aren’t reasons to stick with the non-empowered model.

When non-empowered teams are right

Are non-empowered teams always the wrong choice, then? Not necessarily. As always in product development, there are trade-offs. Here are some situations in which I can see non-empowered teams being the “correct” choice, at least for the time.

If you truly only need operational leverage, for example, for short-term spikes, and don’t want to build up any additional capabilities, it might be correct to spin up short-lived teams that handle the excess load and then dismantle them again. In those cases, where scope is fixed from the outset, it doesn’t make sense to build up an empowered team, have them question all the fundamentals, and chart their own course. Empowered teams might deliver better results in the long term, but if you just need work to get done in the short term, perhaps the “overhead” of an empowered team isn’t worth it.

In a similar vein, sometimes the long term doesn’t matter to a company. When the company’s back is against the wall and there are only a few months of financial runway left, sometimes a more command-and-control operating model can be correct, in which leaderships makes one big bet how the company will be turned around, and then uses the entire organization as one big delivery machine to deliver on that bet. If the bet is successful, the company can then return to an empowered team model.

Lastly, if a company is still at the beginning stages of a transformation from the non-empowered model to the empowered one, it can make sense to slowly move to the empowered team model — from dictating roadmap and feature details over only rough scoping of features to full-blown ownership of a problem space. Here, the non-empowered model is again only used for a period of time while the organization transitions to the empowered model.

I hope you found this article useful. If you did, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.