Empowered: Ordinary People, Extraordinary Products

by Marty Cagan

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.

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.

Note that there is a big assumption here, which may not be true in your organization: We assume that the product leaders are generally at the same peer level with the other key executives and stakeholders in the organization. Normally, in a tech‐powered product company, they are. However, in some older, pre‐internet companies, the product leaders are buried under someone like a CIO, CTO, or inside of individual businesses (all clear signs of the subservient feature team model). In this case, it is politically much more difficult to get the senior vice president of sales or the chief marketing officer or the chief financial officer to have a collaborative relationship with the head of product.

You might have noticed that we have not talked much about the topic of “stakeholder management” in this book. That's because this term represents a mindset that is more often a trait of feature teams and less so for empowered product teams.

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

One of the great ironies of this entire topic of empowered product teams vs. feature teams is that, in general, it costs significantly less to staff and fund empowered product teams than it does to fund feature teams.

However, sometimes the engineers do tell me they don't really care much about discovery. They prefer to code and are fine building “whatever.” In this case, I ask them to tell me the last time any of the engineers were able to personally visit with a customer. The answer is usually between “a very long time ago” and “never.”