Empowered: Ordinary People, Extraordinary Products

by Marty Cagan

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. This is an especially clear example of the lack of product strategy, a lack of focus, and more generally, a lack of product leadership.

He pointed out that, while pretty much the entire code base could be improved, the vast majority of this effort would not matter in the least. In fact, it would not even be enough to be perceived by the user. However, there were a few spots where almost all the time was going, and if we could improve those few areas, we could make a real impact. So that's where we needed to focus. He pointed out that in most organizations, they tell everyone that “performance is important,” and so every team works a little on performance. But the vast majority of that work makes absolutely no difference. And, in the few places where it could make a difference, it gets too little concentrated attention.

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.

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

empowered product teams don't need less management, they need better management.

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

This is the point where there's a fork in the road, and it's where we can tell if a company is serious about empowered product teams or is still addicted to feature teams.

.c1

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

.c2

If the leaders believe they know the necessary features and projects to execute on the product strategy, then they'll likely put that info on a product roadmap and assign the work to the relevant teams. However, if the leaders want the product teams to feel ownership of the problem and take responsibility for discovering and delivering a solution that provides the necessary results, then they'll want to give the relevant teams as many degrees of freedom in coming up with an effective solution as possible.

With all the normal urgencies and interruptions of life in a company, it is all too easy to find yourself halfway through the quarter with very little progress on the team's objectives. This is why weekly tracking and coaching is so important. You as the manager are ensuring that the product team is making progress, and also as important learnings or insights are discovered, or major issues are identified, they are shared with you so this knowledge can be aggregated and disseminated to the relevant teams. The coaching and the management of the strategy are not so much different responsibilities as they are two sides of the same discussions.

Not explicitly limited to this, but definitely applies to Director of Engineering responsibilities in supporting teams in delivery.

When I was leading product at a prior job, one of the company's leaders gave me the feedback that I was not a good leader because the engineers liked me too much. 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.

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.

Some people like to refer to level of ambition as either a roof shot or a moon shot. A roof shot refers to a team being asked to be conservative and pursue lower‐risk, but also highly likely, tangible results. Optimization work fits well here. On the other hand, a moon shot is when the team is asked to be very ambitious, such as going for a 10X improvement. It is expected that this is high risk, but we also believe that it's not impossible and the team is well‐positioned to make a serious attempt.

.c1

Whatever the level of ambition associated with your key results, be sure to clearly communicate this across the organization. You especially don't want anyone to assume that something is a very‐high‐confidence result when it's not.

.c2 So teams frequently not completing OKRs could meam different things. It could be badly estimated (or well estimated but badly communicated) initial confidence in the OKRS. Or it could be the choice of OKRs all of which the teams have low confidence for.

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 first and most basic form of collaboration is the concept of a shared team objective—when multiple teams share the same team objective. For an important objective, this is not at all unusual.

.c1

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. In this case, the teams will normally collaborate to establish a simple form of contract with each other in the form of an API, and then both proceed to figure out their sides, and then they will again collaborate on testing and delivery. 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.

.c2

Another form of collaboration is a common objective—when multiple teams are asked to pursue the same problem, but each in their own way. The reason for this is really risk management.

.c1

If the problem is especially difficult, then we know that it can be hard to know which approach, if any, will produce the necessary results.

.c2

At a minimum, product teams stay on top of progress by discussing at weekly check‐ins where they are, what is upcoming, and where they might need help. These weekly team objective check‐ins are the key mechanism that teams use to track and manage their own progress.

.c1

Occasionally, the teams will raise an issue that requires the leaders to coordinate to resolve conflicts or issues.

.c2 Perhaps me bringing these up as a director is an antipattern. It helps for this week but doesn't improve the team's ability to self-manage to notice and deal with similar situations in the future. Perhaps the TL should be led (coached) to bring these questions up with the team on a weekly basis on their own instead.

For product teams that are not yet experienced, the managers will need to be more proactive in their questions and coaching to ensure that the teams are making progress on their team objectives.

Sign of an immature team.

So, what happens when a team fails to deliver on one or more of their team objectives? The first thing to keep in mind is that accountability is directly related to ambition. If the team was asked to be very ambitious (e.g., a moon shot) and the attempts failed to generate the desired results, then that is largely expected. However, if the team was asked to be conservative (e.g., a roof shot), or even more important, if they were asked to make a high‐integrity commitment and they failed to deliver in this situation, then this is where accountability comes into play.

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. Get the product team together with a set of their peers—especially peers from any product teams that were impacted by their failure—and have the team discuss what they believe was the root cause of their failure. Ask them to explore what they believe they could—and should—have done differently.

Here are the 10 most important keys to effective team objectives:

A reference

Key result: Increase employer success rate from 37% to 39%.

Is this metric stable enough to assign causality of such a small change to the team's work instead of normal (even if rare) variations in the metric?

KR: Improve employer success rate from 37% to 40%.

Another team had a KR for the same metric, but with a different goal. How to untangle the impact of different team's initiatives on this metric? Answered in an earlier sidebar. Answer is A/B tests or slicing (limiting changes to a particular "slice" of all customers and measuring changes within that slice). Doesn't say which approach was used here though.

Most of the platform teams had the platform product manager role covered by the tech lead. For some of the teams, this was really not a problem (Infrastructure, Tools, and even Shared Services). However, for other teams (Payments and Billing, Data and Reporting), the business complexities and constraints overwhelmed the tech leads, and the company added platform product managers to these teams later in the year.

The TPM role may sometimes get ignored for too long

I like to tell product leaders that they are only as strong as their weakest product manager, and this is why.

The same could probably be said about EMs and TLs for an Engineering Director.

This is also why it's so important during new‐employee onboarding that the manager make sure that the new employee (this mostly pertains to new product managers) has done her homework and truly understands the customers and the business before she interacts with the key executive or stakeholder. Without this deep knowledge of customers, there will be no trust.

An agency—whether a design agency or a development agency—is there to provide you with design services or development services, respectively. You may not have thought about things this way, but a feature team is really very similar to the agency model. The main difference is that a feature team is insourced, and the agency model is outsourced.

One other observation: You can often find exceptionally good people to hire from design and development agencies because the people have been exposed to so many types of products. However, realize that moving to an empowered product team will be a major cultural change. In many cases, the people from agencies bring with them the same problems that cause feature teams to fail. More than a few have told me excitedly, “Now I get to be the client!” I try to point out to them that this would very much miss the point.

the difference between a prototype getting a bad response during discovery, and a product failing in the market. “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.

you'll need to give those strong product leaders the ability to recruit and develop the staff required for empowered product teams. This almost always means raising the bar on the product managers, but it may go well beyond that. Note that you don't need to up‐level all teams at once. You just need to be sure that, before you empower a given product team, you have ensured that the team is staffed with people who are up to the task.

If you're just using your engineers to code, you're only getting about half their value. Hopefully, this is obvious at this point in the book, but a strong tech‐powered product company would no sooner outsource their engineers than they would outsource their CEO.

Every single member of a product team has at least one manager that is committed to helping her reach her potential. You have built a reputation as a company where ordinary people who are competent and have good character can develop into a member of an extraordinary product team.