Empowered: Ordinary People, Extraordinary Products

by Marty Cagan

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 key is to make sure the product teams are actively managing progress on the team objectives, otherwise it is all too possible that weeks and then months will fly by with little progress.

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.

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.

The companion to empowerment is accountability. Product teams are given the space and time to come up with the solutions to the problems they are assigned, but with that empowerment comes responsibility and accountability.

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.

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

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.

There is nothing wrong with assigning the same objective to multiple teams—each team tackling the problem from its own perspective and skills. In fact, for difficult product problems, this is often a very effective technique. On hard problems, we expect that not all teams will make the same level of progress, and we can't anticipate in advance what the teams will learn when they each get deep into their product discovery work.

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

I realized I needed to stop designing products in order to start designing a place where good design could happen. I had to design teams that could manage themselves.

Objective 1: Continue to grow core business. Key Result 1: Grow core business revenue by at least 25%. Key Result 2: Reduce annual employer churn from 6% down to 5% or lower. Key Result 3: Increase seeker success rate from 23% to at least 27%.

Objective 2: Establish company as a proven provider for enterprise‐class companies. Key Result 1: Demonstrate product/market fit by developing no fewer than six enterprise‐class reference employers.

At the beginning of the quarter, the company had 16 product teams comprised of 60 engineers, 12 product managers,1 10 product designers, 2 user researchers, and 3 data analysts.

Their analysis of the data shows that positions are filled the fastest, and hiring managers are happiest, when they receive a minimum of 8 but no more than 25 qualified applications.

the product leaders ask for the members of the product teams to meet with them to discuss the product strategy.1 During this session, the head of product starts by updating everyone on the company objectives, then moving into the product strategy work and sharing the relevant data—and especially the insights. The leaders explain that, in the coming days, they will approach each product team with one or two important problems to solve in support of these three objectives. But, in the meantime, they'd like the teams to consider the problems and the ideas and technology they believe can help.

The most common obstacle was when one team identified a dependency on another team and needed to know whether or not they could count on getting what they need during the quarter. This happened both while planning for the quarter, and in multiple cases during the quarter, when the teams were deeper into the work. The dependency was mostly on a platform team, but sometimes, for example, a change to an employer team required a change from a job seeker team. In each case, it required the managers to talk directly to the parties involved to see if and when the dependency could be accommodated. In most cases, a little “horse trading” was able to satisfy both parties.

in certain cases, it worked best to allow the experience team to write the necessary software and then contribute that code to the platform (pending approval by the Shared Services team).

there were some cases where the platform team could not commit to providing what was needed early enough for the experience team to use in time to finish in the quarter. In this case, the experience team was not able to deliver their solutions until the following quarter.

It's important to emphasize that this back and forth is normal. It is a reflection of the fact that some things come from the leaders and other things come from the teams.

Ultimately, the measure of success for this Enterprise Tools team is to develop at least six reference customers for the initial enterprise product offering. However, the leaders and the team expected that it would likely take more than a single quarter (but hopefully less than two quarters), so then the question was what would be a good proxy KPI for real progress towards this business result. The decision was made to use active participation in this customer development program, with the belief that if at least eight customers sign the (non‐binding) letter of intent to buy, then it's reasonable to expect that some number of them will actually buy when the product is ready. This is very much dependent on the team delivering on the promise of the product.

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.

Here are what I consider the 10 most important points I hope you take away from this snapshot of a real company in the midst of dealing with the challenges and stresses of rapid growth:

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.

The necessary give and take between the leaders and the product teams—partly top down, partly bottom up. The leaders did not abdicate their responsibility by inviting the teams to volunteer for areas they felt strongly about, but their willingness to try to accommodate went a long way toward motivating the teams.

Whenever I see organizations that don't have strong values along with a culture of collaboration and empowerment, I know they are going to struggle to deliver great customer experiences and therefore business value.

Great things can happen when you give creative, passionate people the freedom to explore ideas. Creativity is needed to come up with original ideas, which need to be critiqued, evaluated, and elaborated. Many different possibilities need to be explored before focusing on those that have the most potential value. And it is product teams that are able to combine these different behaviors—and switch between them in flexible ways—that are best suited to succeed in the world in which we now find ourselves.

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.

Moving the product teams from the subservient feature team model to the collaborative empowered product team model begins with trust—especially between the product organization and the rest of the leaders of the business. And the keys to that trust are the product leaders, especially the head of product.

Without a strong head of product who inspires confidence and is trusted by the CEO and the other key executives, it will be a long and very difficult road.

it's much easier to get an executive to put their trust in a peer rather than in a much lower‐level subordinate they don't know, and don't believe has the necessary experience or knowledge.

The basis of this relationship is that the executives need to believe the product leaders have a deep understanding of the business and are committed to ensuring that the solutions provided will work for the various aspects of the business. This is table stakes for the product leaders.

there are three aspects the product leaders will be judged on: Business results Product strategy Product teams

it's common that one or more of the most important insights were first discovered by one of the key executives or stakeholders, and in such cases, it's important to be generous in crediting the source of that insight. You want to build a culture that encourages the constant seeking and leveraging of these insights.

I like to tell product leaders that they are only as strong as their weakest product manager,

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.

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.

As we learn important or potentially relevant insights, we want to share these learnings with our colleagues from across the business.

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

it's critical to be able to constantly remind your business partners about (and evangelize, which is discussed below) the product strategy and the importance of focus.

sometimes the business leader will try and get the product team to work on pet features by positioning them as keep‐the‐lights‐on work. But, of course, if this happens too much, we are not able to pursue the critical product work and we are back to feature teams managed by stakeholders.

One of the critical roles of strong product leaders—especially in medium‐ to large‐sized companies—is evangelism. Evangelism in this context means marketing to your own organization (e.g., product marketing, marketing, and sales).

you're not trying to get people to buy. You are instead trying to persuade them that this is going to be very important and something they should care about and contribute to making a reality. There are many techniques to help communicate the value of what you're proposing to your product teams, executives, key stakeholders, and investors. Here are my top‐10 techniques:

Share the vision. People don't just want to know what you're doing today—they want to know where you are heading. The product vision shows where you hope to be in 3–10 years.

A demo is not training, and it's not a test—it's a form of sales. Get good at it.