Empowered: Ordinary People, Extraordinary Products

by Marty Cagan

It's important to emphasize that any topology must consider both the underlying technology architecture as well as the broader strategic context (including the business objectives, product vision, strategy, etc.) of the product. This means that it's essential that product and engineering leadership must determine the topology together.

experience teams are most empowered when they are given as much end‐to‐end responsibility as possible. Such teams have a meaningful sense of ownership, more autonomy, and it's easier for them to see their impact on solving customer problems and achieving business results.

The famous computer scientist Melvin Conway coined an adage that is often referred to as Conway's Law. It states that any organization that designs a system will produce a design whose structure mirrors the organization's structure.

Regardless of the reason for reviewing your topology, you should optimize for the empowerment of the teams by focusing on the dimensions of ownership, autonomy, and alignment.

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.

While there are many forms of strategy, what I care about here is product strategy. Which in short means: How do we make the product vision a reality, while meeting the needs of the company as we go? 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 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.

But I can't tell you how many companies I've gone into that have on an office wall or spreadsheet a list of literally 50 major objectives or initiatives they're pursuing. And each product team complains to me that they really have no time to pursue their own team's product work because they have obligations that cover more than 100 percent of their available time, not to mention all the “keep‐the‐lights‐on” work and dealing with tech debt. Moreover, many of these 50 major objectives or initiatives are truly hard problems, and just getting a little time slice and no clear ownership from a dozen‐or‐so different product teams has virtually no chance of making any real impact. So, focus comes from realizing that not everything we do is equally important or impactful, and we must choose which objectives are truly critical for the business.

While product strategy starts with focus, it then depends on insights. And insights come from study and thought. These insights come from analyzing the data and from learning from our customers. The insights might pertain to the dynamics of our business, our capabilities, new enabling technologies, the competitive landscape, how the market is evolving, or our customers.

the bottom line is that product strategy requires choice, thinking, and effort.

Good strategy works by focusing energy and resources on one, or a very few, pivotal objectives whose accomplishment will lead to a cascade of favorable outcomes.

Good strategy … does not pop out of some “strategic management” tool, matrix, chart, triangle, or fill‐in‐the‐blanks scheme. Instead, a talented leader identifies the one or two critical issues in the situation—the pivot points that can multiply the effectiveness of effort—and then focuses and concentrates action and resources on them.

there are four consistently effective and valuable sources of insights, and strong product leaders spend much of their waking hours contemplating these:

The user research community generally breaks down insights into two types. The first is evaluative, which essentially means, what did we learn from testing out this new product idea? Did it work or not, and if not, why not? The second type of insights are generative. This means, did we uncover any new opportunities that we aren't pursuing, but maybe we should?

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.

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

The OKR technique came from companies that had empowered product teams in their DNA. OKRs are first and foremost an empowerment technique.

in the vast majority of companies I see that are struggling to get any value out of OKRs, the role of leadership is largely missing in action. They literally think that the idea is to let teams identify a set of objectives, and then let them pursue those objectives, and we'll see where we are at the end of the quarter. They think that empowered product teams, and this technique especially, is about less management. But as I've tried to emphasize throughout this book, it's really about better management.

successful companies aren't successful because they use OKRs. They use OKRs because it is designed to leverage the empowered product team model.

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

As with any difficult technology‐based endeavor, we need to actively manage this work, always being mindful to manage by coaching and servant leadership, and not to regress to command‐and‐control‐style management—undermining the benefits of empowerment.

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.

This is in stark contrast to a typical product roadmap, which provides the team with a prioritized list of features and projects to build. If those features or projects do not solve the underlying problems, then we fail, even though we may have delivered what we were asked to build.

one of the major lessons our industry has learned is this: How work is assigned matters.

I am presenting these 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, not output or activities.

Objectives

Examples of Problems to Solve

the reason this is so much of a problem is that 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.

The higher‐order point here is that the best team objective will come from a back‐and‐forth dialog between the leader and the team. As teams investigate and consider, they often find new and better approaches that may suggest different key results, or even a modified objective. Moreover, it's the leader's job to ensure that this back and forth is happening. As a leader, you don't want a passive team—if the team is not actively engaged and debating, be sure to explicitly ask them what they think and why.

there is always what we call “keep‐the‐lights‐on” work involving fixing critical problems, responding to customer issues, providing assistance to other teams, technical debt work, and more.

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

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

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

the problem is especially difficult, then we know that it can be hard to know which approach, if any, will produce the necessary results. In this case, we may ask multiple teams to pursue the same problem and hope that at least one of those teams will be able to generate the necessary impact. It would be even better, of course, if all of them made a significant impact, but we know that's highly unlikely. A good example of this might be when one of the focus areas is subscriber churn, where too many of our customers are leaving the service. There are, of course, many ways this problem can be addressed, and having multiple teams address this from multiple angles is often a good way to mitigate the risk.1

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.

I often encourage teams to pursue multiple approaches to difficult and critically important problems. "Opportunity Solution Trees," invented by discovery coach Teresa Torres, is a helpful technique for identifying and evaluating multiple approaches to solving an important problem.

The best product teams know that, when it comes to tech companies, we either all succeed, or none of us succeed. And it's not unusual to find yourself in the situation where you believe you must do something that's not in the best interest of your product team, but you see that it is in the best interest of the customer and of the broader organization.

As a reminder of the big picture regarding product strategy: 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.

The team objectives are intended to cover the critical work in support of the company objectives. 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.

Because the leaders had been very open and transparent with the executives and stakeholders in the company, several of those leaders shared with me that they had a much better appreciation for how technology products get made, especially the level of experimentation required to solve the particularly difficult problems.

The importance of a true product strategy based on focus and insights. The product strategy is what tells us which problems we need each product team to solve. These leaders crafted a strategy around a few high‐impact insights and then asked most of the organization to tackle these problems. The results will only be as good as the strategy.

Your results will only be as good as your strategy

I have spent the last 10 years on the boards of a wide variety of organizations, many of them on journeys of “digital transformation.” The outcome of this endeavor has to be the delivery of compelling digital experiences for customers, and this requires empowered product teams.

To create the conditions for this, leaders need to establish and communicate a clear and compelling purpose and vision—what the organization is trying to achieve and why. There needs to be obsession with the customer from the top—who they are, what they want, and how they behave.

And to develop the solution, there need to be highly‐focused and effective cross‐functional teams led by a capable product manager, empowered to deliver on the product vision. And this means clear objectives, acco...

Leaders need to set the expectations, establish the governance that acknowledges necessary boundaries—but removes barriers to progress—and support the teams with the necessary tools and resources. And then they need to get out of the way. Senior leadership support f...

Marty asked me why I thought so many companies still prefer command‐and‐control‐style leadership versus empowerment. I don't know if it's a preference or even conscious; in many cases it seems to be the only model the leaders know. I do know that changing it is very hard, and it only works with strong leadership and a sustained, committed effort to create the right culture and values. The leaders must establish...

As a board member, I try to impress upon the senior leaders these principles and values, and emphasize that the product teams need to be empowered. Without this, there will be little progression, and a great deal of frustration, which inevitably means that the necessary digital talent—which has been brought into the organization with g...

Realize that your company is currently used to feature teams that exist very clearly to serve the business, and now you're trying to replace them with empowered product teams that exist to serve our customers, in ways that work for the business.

What this really means in practice is that you need to move your product organization from a subservient model to a collaborative model.

At a very human level, you're asking very senior executives to think differently about teams comprised of ordinary people—individual contributors—who have been coached into extraordinary teams.