Empowered: Ordinary People, Extraordinary Products

by Marty Cagan

Discovery in general, and innovation in particular, depends on the concept of psychological safety.1 This essentially means that the members of your product team feel respected and their contributions are welcome and valued.

Some helpful checkpoints along the way: At the end of her first day. Has she made at least one hopefully future friend on the team? Does she know what is expected of her? At the end of her first week. How was her first week? Has she had a chance to get to know personally every member of her product team? After she receives her first paycheck. It's normal for the new employee to do a subconscious assessment of the choice she made in joining your company. After her first month. At this point, the new employee has a fairly good idea of the company and her potential in it. After her first 60 days. Has she scored a public “win” that helps establish her value to the company?

Like these checkpoints.

I'll repeat the old saying, “People join a company, but leave their manager.” I (Marty) truly believe that this is true. I have done it myself (left because of a terrible manager) and have seen it happen to others countless times. Some amount of attrition is normal and even healthy. Someone's spouse gets a major career opportunity elsewhere, or after several years with your company someone leaves to found their own startup, or someone decides to retire. However, if the people you really don't want to lose are consistently leaving, this is a real sign of a potential problem in management.

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.

The product vision stands little chance of being perceived as compelling or meaningful if the team thinks it's just a matter of a few features. The product vision describes the future you are trying to create. In what ways will you improve the lives of your customers?

Strong product people want to work on something meaningful. They want to work on something larger than themselves. They want to be missionaries and not mercenaries. So, while you can talk about nice employee benefits and show the candidate the foosball table, the best product people care more about your product vision than anything else.

Remember: stubborn on vision, but flexible on details. Sharing the vision is fine, but sharing a roadmap is very dangerous.

The most rewarding experiences of my career have been identifying talent and aptitude in people who weren't aware of it themselves, and then convincing them that they're great at whatever the thing is. And working with a team—all operating in ways that they are passionate about or excel at—means being part of something so much greater than the strengths of any one individual person. Those teams are transformational, both in terms of how it feels to belong to one, and what they can accomplish.

Optimizing for empowerment requires balancing three interrelated goals: ownership, autonomy, and alignment.

It does not mean that a team should never have dependencies on other product teams. Nor does it mean that a team is allowed to go off and pursue whatever it likes. Autonomy does mean that when we give teams problems to solve, they have enough control so that they can solve the problem in the best possible way that they see fit.

Platform teams reduce the load required to use the underlying technology, creating cognitive capacity for experience teams to own more aspects of the customer problems.

The topic of empowerment for platform teams is always a little tricky. That's because, while the purpose of an experience team is to solve problems for users and customers, the purpose of a platform team is really to enable the experience teams to better solve problems for their customers. So, the contribution of a platform team is indirect.

Yep. I feel it.

Design is far too important to be run as an internal service. It needs to be a first‐class member of the product team, just as the product manager and tech lead are.

You may wonder how it is that so many companies don't have a good product strategy—I know I do. Richard Rumelt gives us a hint: Not miscalculation, bad strategy is the active avoidance of the hard work of crafting a good strategy. One common reason for choosing avoidance is the pain or difficulty of choice. When leaders are unwilling or unable to make choices among competing values and parties, bad strategy is the consequence.2

In terms of empowered product teams, product strategy helps us decide what problems to solve, product discovery helps us figure out the tactics that can actually solve the problems, and product delivery builds that solution so we can bring it to market.

So why is product strategy so hard? Because it requires four things that are not easy for most companies: The first is to be willing to make tough choices on what's really important. The second involves generating, identifying, and leveraging insights. The third involves converting insights into action. And the fourth involves active management without resorting to micromanagement.

The main thing is to keep the main thing, the main thing. —Jim Barksdale

It is easy to generate work with this approach, but not results. As Stephen Bungay explains: Generating activity is not a problem; in fact it is easy. The fact that it is easy makes the real problem harder to solve. The problem is getting the right things done—the things that matter, the things that will have an impact, the things a company is trying to achieve to ensure success.3

The difference really boils down to whether you give your product teams features to build, or problems to solve.

So, in terms of actually getting the benefits of OKRs, there are three critical prerequisites: Move from the feature team model to the empowered product team model Stop doing manager objectives and individual objectives, and instead focus on team objectives Leaders need to step up and do their part to turn product strategy into action

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.

But one of the major lessons our industry has learned is this: How work is assigned matters. There are many reasons why this is preferred, but the most important are: 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 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 much more ownership of the problem. 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.

Really like these points.

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.

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

The higher‐order point is that it is normal and often wise to have multiple teams pursue the same objectives simultaneously. Companies that avoid shared or common objectives in the name of autonomy or communication often limit their ability to solve the toughest and most important problems.

Here are the 10 most important keys to effective team objectives: The most important thing is to empower teams by assigning them problems to solve and then give the teams the space to solve them. For them to make good decisions, they will also need you to share the strategic context, especially the product strategy. We love it when product teams volunteer to work on specific objectives, and we try to accommodate this when possible to leverage their motivation and enthusiasm for the problem. But we can't always do so because we need to make sure we cover everything we need to. 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. It's normal that there's a back and forth—not that the leaders doubt or question what the teams propose as their key results, but rather judging which investments are worth the effort and associated risk. For example, suppose a team believes that, with their other objectives, they can only make a very minimal improvement to a specific, important KPI. The leaders might consider having that team focus exclusively on the one objective or decide to ask a different team to pursue it or help in some way. There is nothing wrong with assigning the same objective to multiple teams—each team tackling the problem from its own perspective and skills. I...

Similarly, there is nothing wrong with asking multiple teams to collaborate on the same team objective. It's not unusual to ask multiple teams to work together—especially when the problem requires different sets of skills. A common situation is asking a platform team and an experience team to collaborate on a difficult problem. For product teams to come up with key results, it's essential that they understand the level of ambition you want from them. We need to be clear with teams when we want them to be very ambitious (aka moon shot), when we want them to be conservative (aka roof shot), and when we need them to make a high‐integrity commitment. Product teams can only be accountable to the results if they are empowered to figure out a solution that works and if they are the ones to come up with the key results. The product leaders have to realize that while team objectives are critically important, they are not the only things that the product team is working on. Every team has some level of ongoing “keep‐the‐lights‐on” activities. This includes such things as fixing critical bugs, handling customer situations, and so forth. Normally, these team objectives are created or updated every quarter. That gives teams enough time to make real progress, yet not too much time that the business can't adjust to changes. There may be occasional situations where team objectives need to change during the quarter, but these should be the exception rather than the rule.

These are presented here in OKR format, but 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.

SMALL number of objectives.

Recall that a product strategy begins with focus on a small number of truly important objectives. Then we will search for insights that can be leveraged to make a real impact on these company objectives. Next, we will map the insights into action, which means identifying a set of one or more objectives for each product team to work on. Finally, the managers will need to actively track progress on the objectives and be prepared to remove obstacles and make adjustments in support of the product teams.

Really like this way of putting it.

Note that this process is necessarily a combination of top down and bottom up. The teams have all been provided the company objectives and product strategy (top down), and they are all asked to consider what they may be able to do to contribute (bottom up).

Remember that these objectives are problems to solve—they are not solutions. The teams are expected to try out potential solutions in discovery and pursue solutions where they have evidence they will work. This is what is meant by an empowered team.

The company believes the best results come when you get the right people, trust them, give them freedom to find the best path to achieve objectives, and let them share in the rewards their work makes possible.

I like this. How could I make this a reality at my workplace?

In an empowered product team, the team is there to serve customers, with products that customers love, yet work for the business. The stakeholders are partners we need to collaborate with to come up with solutions that work (specifically, that means the solutions are valuable, usable, feasible, and viable). In particular, the stakeholders help us with viability

“Failing” in discovery is not really failing—it is very fast and inexpensive learning. “Failing” in the market truly is failing, as these mistakes are typically very slow and very expensive. We want the broader company to understand this difference. We still can't completely avoid market failures, but we can dramatically reduce their frequency.