Empowered: Ordinary People, Extraordinary Products

by Marty Cagan

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

Sometimes there are differences because of the customer's size (e.g., SMBs are reached through a self‐service portal, while larger customers require a sales force and APIs for customization).

the goal is to organize the experience teams in a way that allows them to best serve their specific customer and also align with other parts of the company.

Your topology need not align all experience teams to a single dimension such as vertical market or customer size. Some topologies use different alignment dimensions in different areas when that makes more sense.

In the internal design agency model, the designer is usually not in the room when the key decisions get made, and therefore the designer—and ultimately our users—have to pay the price for that.

for companies using feature teams, this really doesn't matter because the key decisions have already been made by the time the designer is first consulted.

a topology that divides the organization into a web team, iOS team, Android team, and backend team will make it very difficult to give any team the ability to own a multichannel customer experience.

No matter how empowering your initial topology is, it will not stay that way by itself. The realities on the ground are always changing, sometimes in ways that require changes to the topology.

Here are a few warning signs that can indicate your topology could use some attention:

You must frequently step in to resolve dependency conflicts

you should try to keep your existing product teams intact. Your entire organization has made a big investment in establishing relationships to enable good collaboration. This means that, wherever possible, it is better to give an existing team a new set of responsibilities, rather than break up the product team and redistribute the people into other teams.

If you're consistently making major changes to the team topology more than once a year, it is a sign that something is wrong.

Topology determines who people work with on a daily basis, what they are working on, and the nature of your interactions. When it changes, it can be extremely disruptive.

This same sort of care is needed even if you temporarily move someone to another team to deal with an urgent priority. These moves are hard on the person moving as they must adjust to a new team and new work. It's also hard on the team that was le...

If a company's engineering organization is struggling to scale or to deliver, there are likely some serious issues coming from the top. It's important that I understand and address those, otherwise it's very possible any changes will be less impactful or only temporary.

Building and scaling a successful company is really hard, and every company has far more work they want to do, than people to do the work. So focus is essential, and product strategy is what lets us get the most out of the resources and people we have.

Despite best intentions, upon close examination, often organizations that are scaling quickly or currently struggling have no real focus and no real product strategy. Trying to do too many things at once will damage even the best engineering organizations.

I can't usually make the choices for them, but I can insist that the leaders make the hard choices that are necessary.

when an engineering organization is not perceived as able to deliver, there will be trust issues. The executives don't trust the engineering organization, and the engineers don't trust the executives.

I need to work with the engineers to understand that when they make a promise or commitment, it is important they deliver on that promise. There are “why,” “when,” and “how” components here that the overall organization needs to understand and support. This involves coaching the executives to be smart about when they really need a date, and coaching the engineers on how to assess the work and take the obligation to deliver very seriously.

we need to replace any unreliable estimation games they're currently playing to try to predict dates with some rigor—thoroughly assessing what's involved to get something working and delivered. This can be difficult, often requiring new ways of doing things and almost always lots of practice. I'm a big believer in “crawl, walk, run.”

engineering needs to become known for following through on its commitments.

most product organizations I meet don't even have a product strategy. They have no shortage of features and projects being worked on, and everything they are building is being built for a reason, but as you'll see, they have no product strategy.

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.

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.

Choices means focus. Deciding what few things you really need to do, and therefore all the things you won't do. 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.

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

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.

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

I don't just mean deciding what to work on and not work on, but picking the few things that can truly make an impact.

I've been sharing the Pandora example as a clear case study of how not to do product.

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.

By not picking your battles and focusing on the few truly critical problems, most of the work going on does not make an impact. And for the truly critical priorities, there is not enough attention to actually move the needle.

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?

Too many organizations are either not doing this ongoing learning about their customers, or, even if they are, they are not set up to leverage the insights that are generated (usually because their feature teams are already over‐subscribed just trying to serve the business). So, the learnings are all too often ignored.

The insights that are generated need to be shared and communicated. Unfortunately, the most common way that most teams try to share these learnings is by writing them down somewhere—an email, Slack, or a report. Sadly, this is rarely effective.

In many ways, leaders are given the data they request, not the data they need—especially to make insightful strategic decisions.

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.

it is very hard to anticipate exactly where key insights will have the most impact, so it's very important to share the insights broadly, especially across the other product teams.

The vision pivot is most relevant when our insights lead to a larger opportunity. Not when we realize that the problems are harder than we thought (which is pretty much always true).

Note that empowering a team does not mean giving the team a blank check. There are always constraints and context—such as ensuring the solution does not violate an existing contract or compliance constraint.

The OKR technique came from companies that had empowered product teams in their DNA. OKRs are first and foremost an empowerment technique. The main idea is to give product teams real problems to solve, and then to give the teams the space to solve them.

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.

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

the point of team objectives is to execute on our product strategy, and this is where we convert our strategy into action.

It's critical to note that sometimes it's not about the level of ambition, but rather, we need to occasionally make what's called a high‐integrity commitment

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.