Empowered: Ordinary People, Extraordinary Products

by Marty Cagan

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...

If we give the team the problem to solve, and the space to solve it in the best way they see fit, the product team will feel ...

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 approa...

team objectives are comprised of an objective (the problem that needs to be solved) and some measures ...

what is important is (1) their focus on a small number of meaningful objectives, and (2) they are measuring the results based on business results, not output or activities.

The specific objectives will, of course, be a function of the type of product and the responsibilities of the particular product team, but typical examples of good objectives are:

Remember not to get too attached to the specific wording of the objective. Often, once a product team understands the strategic context and has had a chance to investigate the objective, they find that it may make more sense to rephrase, or change the emphasis, or generalize the objective. This back and forth between the leader and the product team is both normal and healthy.

What's most important about all of these examples is that they are problems to solve and not features to build. Some are customer problems, and some are business problems, but in each case, there are any number of potential solutions. The point is that the product team is best suited to determine the most appropriate solution.

many of the most important objectives will require the product team to either collaborate with other product teams or, in many cases, to collaborate with different parts of the organization to achieve the goal.

While the objective is the problem to solve, the key results tell us how we define success.

it's essential that we define success by business results (aka outcome) and not simply activity or output.

The second most common reason that teams go wrong with team objectives is that they end up listing activities or d...

it is very easy to ship a deliverable yet not solve the underlying problem. In which case, we're back to the same old problem we have with product roadmaps.

Generally speaking, we want between two and four key results for each objective. The first key result is normally the primary measure. Then we have one or more key results as a measure of quality—sometimes called guardrail or backstop key results—to ensure that the primary key result is not inadvertently achieved by hurting something else.

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 ab...

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.

we love it when teams volunteer to pursue an objective, and we try hard to accommodate that desire, but we also are clear with the teams that we can't always accommodate them because we have to ensure that, in aggregate, the organization is cove...

even though a team may wish to pursue a specific objective, it is up to the leaders to decide this. Hopefully this is understood, but this is not a power thing or a control thing—this is just about the managers doing their job. Someone has to l...

if it's the first time they have worked on this problem, then they will likely need some time to learn the space, start collecting some data to establish a baseline, and get a sense of what the possibilities are. In this case, encourage the team to jump in and not get stuck in paralysis by analysis, and acknowledge with them that they will learn much more as they progress, and that the confidence level will, of course, be low in this first quarter because they are still learning what they don't know.

In some cases, this ongoing work can reach the point that it consumes the team, in which case the leaders will need to potentially grow the team, or else not expect anything beyond this overhead work, or they can look into ways of reducing this overhead burden.

it's important to distinguish long‐term objectives from long‐term key results.

it would be easy to just list some activities as our key results (an example of an activity would be to say we'll be “code complete by the end of the quarter”). But that's not what we want because that is output, not outcomes. The point is to show results. The normal and preferred way we handle this is to break up the work into intermediate product results.

Let's say the goal is to get six referenceable customers on the path to product/market fit. That's a very powerful business result, and it's one of our best leading indicators of future sales. The problem is that it may take two or three quarters of time to get the product deployed and in use by the customers and get them to the point where they're referenceable. So how do we know in just the first quarter that we're making meaningful progress? One possibility is that we might have the goal of just getting to two references this quarter. If even that is not achievable, we can find a leading indicator for this. For example, a good key result would be getting eight prospective customers to sign a non‐binding letter of intent to buy.1 That's clearly not as good as having actually bought the product, but it's a strong leading indicator and it has real business meaning.

One useful way to think about team objectives is that the leaders are placing a series of bets. Some are low risk, some are high risk, and some are in between.

if something is important enough, the leaders might choose to have several teams each attack a problem in their own way—some going for low‐risk, quick wins, and others maybe going for much more ambitious but higher‐risk approaches.

The point of a moon shot is to encourage the team to think beyond the small and safe optimizations, and revisit how the problem is solved today in the hopes of breaking through.

leaders are essentially managing a portfolio of potential risk and reward. They may have certain teams that are more ambitious than others, even for the same objective.

You especially don't want anyone to assume that something is a very‐high‐confidence result when it's not.

While most objectives are meant to be aspirational, where we aren't sure which will succeed and to what degree, and we can vary the degree of ambition the team strives for, there are always certain cases where we need the team to make what is called a high‐integrity commitment.

In all businesses there are occasional situations where something important must be delivered by a specific deadline date.

The deadline might be a major industry trade show–driven date, or it might be a partner‐driven date due to a contract, or a calendar‐driven date due to tax days or the holiday period, or a marketing‐driven date due to a purchased advertising campaign.

one of the main reasons leaders gravitate toward the command‐and‐control model of management—especially with old‐style roadmaps of features and projects delivered on dates—is precisely because of this need to know when important things are going to happen.

a key condition to moving to empowered teams is that the teams be able to provide dates and deliverables when necessary—not just the low‐integrity dates of the roadmap era (because we really had very little understanding of what was being committed to), but dates the leaders can count on.

if a company has too many of these date‐driven commitments, it is usually a sign of more serious issues, but I always try to explain to product teams that some amount of high‐integrity commitments is necessary when trying to run a business.

Even if you don't have these external commitments, there will be cases where you depend on other product teams. An example is when you depend on a new capability from a platform team.

High‐integrity commitments are intended for situations where you have an important external commitment or a very important and substantial internal commitment.

In the case of an experience team depending on a commitment from a platform team—where that platform team may need to provide an API or a new service that the experience team will build upon—the platform team can inherit from the experience team their objective and key results.

for high‐integrity commitments, the actual deliverable that is the commitment needs to be noted and tracked independently of the key results.

High‐integrity commitments are given special treatment. We do not talk in terms of how ambitious the team needs to be. These are binary. The team either delivers what they promised or not. And a team that makes a high‐integrity commitment is absolutely expected to deliver, or at the first sign of trouble, they need to raise the flag early and ask for help.

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.

The first and most basic form of collaboration is the concept of a shared team objective—when multiple teams share the same team objective.

The most straightforward example of this is when both an experience product team and a platform team have the same objective because the platform team is expected to need to provide one or more new services to enable the experience product team.

Another form of shared team objective is when multiple teams temporarily combine their talents to solve a particularly hard problem. Especially on problems that benefit from a range of different skills brought to bear, bringing the teams together can often provide the knowledge and synergy required to quickly come up with an effective solution.

One of the questions that often comes up with common objectives is how to attribute progress to a specific team when multiple teams are making changes in parallel. This is referred to as the product attribution problem,

it is normal and often wise to have multiple teams pursue the same objectives simultaneously.