Empowered: Ordinary People, Extraordinary Products

by Marty Cagan

Feature teams are cross‐functional (a product manager doing mainly project management, a product designer, plus some engineers), and assigned features and projects to build rather than problems to solve, and as such they are all about output and not business results. Empowered product teams are also cross‐functional (a product manager, a product designer, and engineers), but in contrast to feature teams, they are assigned problems to solve, and are then empowered to come up with solutions that work—measured by outcome—and held accountable to results.

The heart of this book is the importance of strong product leadership. To be clear, by “product leadership” I mean the leaders and managers of product management, the leaders and managers of product design,1 and the leaders and managers of engineering.

The third responsibility of the people managers is to ensure that each product team has one or two clear objectives they have been assigned (typically quarterly) which spell out the problems they are being asked to solve. These objectives derive directly from the product strategy—it's where insights are turned into actions. This is also where empowerment becomes real and not just a buzzword. The team is given a small number of significant problems to solve (the team objectives). The team considers the problems and proposes clear measures of success (the key results), which they then discuss with their managers. The managers may need to iterate with their teams and others to try and get as much coverage as possible of the broader organization's objectives. The litmus test for empowerment is that the team is able to decide the best way to solve the problems they have been assigned (the objectives).

most companies have not been convinced to empower their teams in any meaningful sense. Why is that? When I ask this question of CEOs and other key leaders of these organizations, the answer typically boils down to one word: trust. The leaders don't trust the teams. Specifically, they don't believe they have the level of people on their teams they need to truly empower them. So, along with the other key business leaders from across the company, they believe they need to very explicitly direct the teams themselves. This is also known as the “command‐and‐control” model of management.

It's amazing and distressing how few managers actually subscribe to this principle—that developing people is job #1. Most say the right things about the importance of the team, but their actions tell a very different story. They see their accountability for aggregate product outcomes as their most important job and treat their teams as a means to an end. If you are a manager, you should be spending most of your time and energy on coaching your team. This means expending real effort on things such as assessing your team, creating coaching plans, and actively helping them improve and develop. You should measure your own job performance on the successes of your team members, even more than the success of your products.

A tech lead is essentially a senior‐level engineer who has taken on the additional responsibility of participating in the ongoing product discovery work. The tech lead is the key partner to the product manager and product designer. They are asked to care not just about building and delivering reliable products, but also to care about what gets built. Tech leads bring deep knowledge of the enabling technologies, and when that knowledge is combined with a direct understanding of the customer's pain and problems, magic can result.

Since they now had salespeople, they hired someone who could “generate demand” because the salespeople needed more names to call. This was a mistake. Without repeatable messages, the sales team couldn't effectively communicate the product's value. Despite a growing go‐to‐market team, very little changed.

Once we understand the company scorecard, we can discuss the specific objectives the company is focused on for this year. These objectives are selected by the senior leadership team, usually with the participation of the board, as the most important areas of focus. They might be related to growth, expansion, profitability, or customer satisfaction. And for each of these areas of improvement, there are typically specific business targets the company hopes to achieve (the key results). Hopefully everyone understands that these company objectives must be outcomes (business results), and not output (such as delivering on specific projects). The key results are nearly always KPIs that are on the company scorecard. If they're not yet on the scorecard, then they would typically be added.

Note that while doing product discovery, certain tools and techniques serve both to facilitate collaboration as well as to provide an artifact as an output of that collaboration. Two very popular examples of that are prototypes and story maps.

In my experience, there are two situations where this most often goes wrong. The first is that the product manager has not done her homework and she doesn't know the various aspects and constraints of the business—sales, marketing, finance, legal, privacy, and so on—so the product team really doesn't have the information it needs to solve the problems it has been assigned (which usually means they're back to implementing features on a roadmap).

The second situation is arrogance. If the product manager believes the solution she already has in mind is clearly the best, even if she is right, collaboration is stifled, and she probably now has a team of mercenaries rather than missionaries.

A good product vision provides us with meaningful work. A list of features on a roadmap is not meaningful. How you can positively impact the lives of users and customers is meaningful.

A good product vision leverages relevant industry trends and technologies that we believe can help us solve problems for our customers in ways that are just now possible.

A good product vision provides the engineering organization with enough clarity about what's coming in the next several years so they can ensure they have in pl...

The product vision is a primary driver of the...

When we tell the story of the product vision, we do so from the perspective of our users and customers. The idea is to demonstrate how their lives will improve in some meaningful way.

First, in order to come up with a compelling product vision, the head of product will need to work very closely with the head of design and the head of technology. The product vision is a critical collaboration between the customer experience, the enabling technologies, and the needs of the business. It will likely require the talents and best efforts of all three.

Another effective way to communicate a product vision is with storyboarding, much like what is done to create and share an outline of a movie. As with a video showing off a visiontype, a storyboard focuses on the emotion and the customer experience and not on the details. Because this is about communicating a product vision, and because the product vision is meant to be told from the users' perspective, your product designers will need to play a key role—both in crafting the experience and in determining the best way to communicate that experience.

Similarly, the team topology (described in Part V) is heavily impacted by the product vision and the architecture, especially for platform teams that encapsulate the underlying services. A product architecture informed by vision becomes especially critical in organizations suffering from serious technical debt.

So many decisions revolve around trade‐offs, and the product principles help to illuminate the values we prioritize when we make these trade‐offs. The product team needs to understand these principles and the reasoning behind each one.

First and foremost, your topology choices should be guided by principles that support team empowerment. These include giving teams real ownership of the space of problems they will be responsible for, providing autonomy in their ability to deliver the solutions to the problems they're asked to solve, and alignment with various aspects of the company's customers, business, and technology.

Ownership is bigger than just the team's objectives. It sets the scope of each team's full responsibilities around functionality, experience, quality, performance, and technical debt. Teams are expected to make the necessary trade‐offs to best address the work that fits into their scope of ownership. Empowerment improves when each product team has something meaningful that they are responsible for.

Ideally, the architecture is based on the product vision, as the job of the architecture is to enable the product vision. If that's the case, a topology that aligns with technical architecture will also be naturally aligned with the product vision. Teams can own a meaningful scope and can be given autonomy to make significant product decisions.

if a product team is working on the experience for anyone who is part of the company's customers—including consumers—this is called a customer‐facing experience team

Users may also be internal to your company itself but are critically important for delivering the necessary customer experience. Examples of these types of users are customer service agents or in‐store associates. If a product team is working on a product experience for these types of internal employees, this is called a customer‐enabling experience team

So, separating out the keep‐the‐lights‐on work, there are two main ways that platform teams are empowered to move the platform forward: shared team objectives and platform‐as‐a‐product objectives. Shared Team Objectives The most common way for a strong platform team to pursue major work is through shared team objectives. With shared team objectives, the platform team has the same objective as one or more experience teams.

On a related note, an emerging trend is that a growing number of companies are working to manage their internal platforms more like external platform products. With these platform products, it's normal to find objectives looking much as for experience products—growing the number of customers, getting customers to adopt the capabilities, or better monetize the customers (in the case of external platforms).

A key point was that experience teams are most empowered when they are given as much end‐to‐end responsibility as possible. This is more likely to happen when the scope of ownership for each team follows other natural patterns of the business such as the sales channel, market segment, or user type. More often than not, this means creating a topology that is aligned by customer. Here are some examples of alignment by customer: By user type or persona (e.g., Riders Team, Drivers Team) By a market segment (e.g., Electronics Team, Fashion Team) By customer journey (e.g., Onboarding Team, Retention Team) By sales channel (e.g., Self‐Service Team, Direct Sales Team) By business KPI (e.g., New‐User Growth Team, Conversion Team) By geography (e.g., North America Team, Asia Pacific Team)

In most cases, the needs of the individuals on each side of the marketplace are quite distinct. This is also true of the rest of the business that is trying to support each side. For both of these reasons, it is often empowering for the topology to organize experience teams by the sides of the marketplace.

The design manager can ensure a holistic view of design by establishing design standards, guidelines, and design systems; reviewing the work of the designers; and also by conducting design strategy and review sessions with the broader group of product designers.

Another way to say this is to beware of shipping your org chart. One of the biggest benefits of cross‐functional teams is that membership can be determined by what is best for the product. The bottom line is that there is no reason that reporting relationships should dictate team topology.

Hopefully it's clear that there are trade‐offs for each of these dimensions of proximity. As a general principle, we try to optimize for the product team as opposed to optimizing for the managers, or for access to customers, or for anything else.

So many of the companies I meet have a goal (such as doubling revenue), and they have a product roadmap (the tactics), yet no product strategy to be found.

In most companies it's not quite so obvious, but so many companies have some similar sort of stakeholder‐driven roadmap process, where they basically are trying to find a way to “fairly” divide up the engineering capacity across the different business stakeholders. This is very much what I mean by feature teams striving to serve the business, versus product teams striving to serve the customers in ways that work for the business.

empowered product teams don't need less management, they need better management. These leaders need to take the learnings and pass them along to other teams that may benefit from these insights, and more generally, help to build their understanding of the holistic business.

One practice I have long advocated is that the head of product should aggregate the key learnings and insights from all the different teams in her areas, and at the weekly or bi‐weekly all‐hands. She should summarize the most important of these learnings and insights, and share them with the broader organization.

In the empowered team model, our intention is to provide the teams with the set of specific problems they each need to solve, and then give them the space to determine the best way to solve those problems. There are various techniques for managing these problems to solve, but the most popular is the OKR system, which stands for objectives and key results. The objectives are the customer or business problem we need solved, and the key results are how we measure the progress.

The leader said that if I was doing my job properly, the engineers should be complaining about the pressure I was putting on them. For a little while, I tried changing my approach. But I soon realized that this was the path to damaging collaboration, breaking trust, and likely losing the innovation we depended on.

We also value getting ideas in front of our customers as fast as possible because we know that's when the real learning happens.

The essential point of team objectives is to empower a team by: (a) giving them a problem to solve rather than a feature to build, and (b) ensuring they have the necessary strategic context to understand the why and make good decisions. The most important point to understand about team objectives is that, first and foremost, they are intended to give the product team the space to come up with solutions to hard and important problems.

The best people to determine the most appropriate solution are those closest to the problem, with the necessary skills—the product team. We want the team to take responsibility for achieving the desired outcome. If we tell the team the feature we want them to build, then if that feature doesn't provide the necessary results, we can't hold the team accountable.

If the first solution the team comes up with does not produce the desired outcome, they know they must continue to iterate and/or try alternative approaches until they find a solution that does.

So, potential key results could be measured by: Reduce percentage of incorrect deliveries While ensuring that total deliveries continue to grow While ensuring the cost of delivery does not grow Notice that, while these key results do imply specific KPIs, we don't yet have the expected values or timeframes because those will need to come from the team.

it is the responsibility of the leaders to decide which problems should be worked on by which product teams. Many companies think that the idea is to let the product teams come up with their own objectives, yet are somehow surprised when the organization complains of lack of direction and little is accomplished. And it's important to point out that this is not the fault of the teams—it's the clear fault of leadership.

More explicitly, the whole point of assigning objectives to product teams is to execute on a product strategy. The product strategy is all about deciding which problems to work on. Assigning objectives to product teams is both a top‐down and bottom‐up process, and it often requires iteration. These assignments are a function of the product strategy and the team topology (aka team scoping). In other words, the strategy tells us which problems we need to solve, and the topology will imply which teams are best positioned to tackle each problem.

Teams that pursue low‐risk/low‐reward solutions will test product ideas that are much different from teams pursuing high‐risk/high‐reward solutions. The nature of the product discovery work will be different, and the techniques they use will likely be different as well.

If you're used to conventional‐style Agile processes, you probably know that coming up with a high‐confidence date is very difficult if not impossible. However, if you're used to the model of doing product discovery in parallel with product delivery, then you know that coming up with a high‐confidence date is not hard, so long as the company is willing to wait until the necessary product discovery work has been done before the date is provided (usually a few days).

One final note of warning: high‐integrity commitments and deliverables should be the exception and not the rule. Otherwise, it is a slippery slope and pretty soon your objectives become nothing more than a list of deliverables and dates, which is little more than a reformatted roadmap.

If a team fails substantially on their team objectives, then I encourage the team to treat this in much the same way we treat an outage.

Selecting the objectives to be worked on, and ultimately deciding which team or teams works on each objective, is the explicit responsibility of product leadership. However—and this is critically important for empowerment—the key results need to come from the team.