Empowered Product Teams, Mapped

What Empowered Product Teams Are

Marty Cagan writes a lot about empowered product teams. In our analysis, we use his description to set the stage:

They [the teams] are cross-functional (product, design and engineering); they are focused on and measured by outcomes (rather than output); and they are empowered to figure out the best way to solve the problems they’ve been asked to solve.

In other words, empowered product teams are not simply executing requested features. They are not the “delivery teams” that work on whatever is spoon-fed to them. Instead, they do real product development work with the goal of maximizing the outcome while minimizing the output.

Product Teams and Delivery Teams

The book 10X ORG names Marty Cagan’s Product Operating Model, next to Team Topologies, among the approaches that encourage and support the creation of Delivery Topology structures in IT and Product R&D. It also quotes Cagan, author of Inspired, Empowered and Transformed, on the limits of delivery:

The most common in terms of sheer numbers are not really product teams at all, they are delivery teams. Also referred to as ‘dev teams’ or ‘scrum teams’ or ‘engineering teams,’ and if your company is running something like SAFe, then unfortunately, this is you. In this situation, there are a number of developers and a product owner. The product owner in this model is what I refer to as a ‘backlog administrator.’ Someone does need to do this administrative work, but this is all about delivering output, and it’s really very little to do with what I am concerned about in terms of the need for true, consistent innovation on behalf of our customers.

One significant difference: an empowered product team can decide which features to build to satisfy a given objective, whereas delivery teams, as in SAFe, are simply given features to build.

Clearing the Terminology Fog

Cagan uses the term “feature team” for a team that is merely coding away a solution. But there is a well-established definition of a feature team in LeSS: cross-functional, cross-component, long-living, customer-facing, self-managing teams. That is enough adjectives to avoid any confusion with delivery teams that just code things away.

Likewise, Scrum, from its first source in 1986 to the modern Scrum Guides, has never described a Scrum Team that solely implements a solution without any accountability for the results. In Scrum, the team has always been envisioned doing the real work for customers and the business, end to end, from business objectives to customer happiness.

What It Takes Structurally

Ideally empowered product teams love the customer’s problems and own their solutions. We believe that culture follows structure: to create an environment for empowered product teams, management needs to put concrete structural elements in place.

• Scope of work. Because ideally empowered product teams deal with high-level concerns, such as customer problems and business objectives, they belong high on the map, on the Scope of Work Mandate.
• Team skills. Engineering excellence is the fair minimum. Beyond delivery, such teams ought to master product management, product marketing, interaction design, quick prototyping, UX and IT operations, to name a few.
• Multi-learning. Small teams cannot hold dozens of skills one per person, so product teams must consist of multi-skilled people who keep learning: ideally empowered product teams are multi-learning teams that work on the product end to end, mastering and acquiring new technical, product and business skills.
• Backlogs. Separate team-level, feature-centric backlogs give each team a permanent focus on a predefined set of features, a “product catalog team” or a “mobile team.” You can’t keep working forever on something and expect constantly high impact; diminishing returns kick in. Those are not product teams.

The book makes the same point with LeSS’s Product Definition: the broader the definition, the more elements are seen not as separate small “products,” but as dependent parts of a larger product that must be managed holistically. Will you have many output-level “owners,” or one outcome-level Owner?

Where Cagan’s Model Sits on the Map

Per Marty’s vision, an empowered product team has a product manager as a team member and works off an independent team-level backlog. That makes it work in isolation from other teams. Marty sees this as a sign of empowerment at the team level; we see it as a local optimization at the level of the whole company. At scale, individual teams will have local interests in the problems they own, and such individualism won’t create a truly scalable product organization where teams share and solve big problems together.

Divided this way, product teams are one more way of slicing an organization into parts, a pattern the book calls divide and conquer. What happens when a “product” team delivers at impressive speed within its area, yet those outputs no longer connect to outcomes that matter, because the market has moved on?

Towards Better Organizations with Empowered Product Teams

The goal is not to downgrade other models. It is to help you, a leader, discover the vector of your organization’s long-term development, toward higher adaptivity, innovation and resilience. Our recommendations:

1. Have the most senior product manager be the Product Owner, the product’s CEO, senior enough to drive the product strategy daily through a clear list of business priorities.
2. Formulate that Product Backlog as business objectives and customer needs, so the teams solve real business and customer problems.
3. Avoid a helpers group around the Product Owner. Put product managers, designers and discovery specialists into the teams. It is better to have 5 of 10 teams properly staffed than all 10 understaffed.
4. Employ multi-team work, such as prioritization over clarification and multi-team backlog refinement, so a single Product Owner can lead many teams.

The book’s Elevating Katas point the same way: Expanding the Product Definition, so teams orient around real customer outcomes rather than narrow components, and Re-Centering Product Ownership on Strategy and Outcomes, which means avoiding team-level local product ownership and introducing shared or unified product ownership.

Read the full analysis, see the three topologies, or learn to map your organization in the C-OTC class. The whole argument is in the book 10X ORG at 10xorg.com.