This article has been updated on November 1st, 2022 to reflect our improved understanding of Marty Cagan's model. As a result, the conclusion and mapping have been changed.
TL;DR
This is a series of articles (among them are analysis of Spotify's Tribes and Squads and Team Topologies) where we compare and contrast different well-known approaches applicable to product development organizations to help leaders make better org design decisions.
For our analysis, we are using a map of seven archetypical org designs, that we call Org Topologies™.
Empowered Product Teams is not a new concept and Marty Cagan hasn't coined this term, but he writes about empowered product teams a lot these days. So, we're going to use his quote from this source 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 on 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.
What we conclude:
Per Marty's vision: an empowered product team has a product manager as a team member.
Such a team works off an independent team-level backlog.
This will make such a team work in isolation from other teams.
Marty sees this as a sign of empowerment (from the team's level), and we see this as a local optimization (from the global company's level).
A team, that works from its independent backlog, has its own local priorities.
Per Marty's vision, a team's backlog should be set at a level of business/customer problems (not features).
We agree that it helps a team to find more creative solutions by owning discovery and delivery as a whole.
Though, Marty is not 100% clear if the whole team is involved in discovery, or it is just the product manager's job.
At scale with many teams, individual teams will have local interests in solving problems that they own.
Such individualism won't create a truly scalable product organization where teams collaborate in a multi-team fashion to share and solve big problems together.
Such an org design doesn't lead to higher adaptivity and innovation; it doesn't create a resilient organization.
Empowered Product Teams in Marty's Words
Below is a short interview with Marty Cagan where he shares his views on this subject, while dropping some terminology that we will debunk in this article:
He says a few things that we would like to highlight for further study:
“empowered product teams” are contrasted to “feature teams”
from the outside they look very similar, they both are “squads” in the Spotify language
they both have someone with a title like “product manager”
How Marty understands what a “feature team” is and how it works:
the “feature teams” are told the solution, often without even explaining the underlying problem, like “go and build this feature that we need”
then Marty describes a process when such a “feature team” designs the feature and puts it on its backlog to implement in a sprint (a very diminished view of Scrum)
“it is all about output”, he says, “they can't be held accountable for the results”
20-30% success rate of such an approach
a product manager on such a team is more like a project manager “herding the cats”
In contrast, “empowered product team”:
is given a problem to solve: a customer problem, a business, or both
and empowered means that they are given the freedom to determine the best solution to that problem
they eventually build features too, but they measure the outcome and may try other approaches to succeed
they might then try to redesign and even eliminate the features to find whatever works
and because they were given a problem, they can be held accountable for the results
such teams have a different purpose, they are to serve the customers the way it works for the business instead of just building what the business wants
and this has implications for the people on that team as their job is not just to code, but to solve – that is discovery to come up with a solution that is valuable, usable, feasible, and viable; and then build a quality implementation and ship it
this is a much broader job for the entire team
and the product manager on such a team is responsible for the valuable and viable aspects (the hardest parts)
the designers are responsible for usable and the engineers – for feasible
the product manager is more like a start-up CEO (the head of product in a startup)
These words have a lot of wisdom, the “empowered product team” do definitely provide organizations with high adaptivity and innovation, so they deserve to be placed higher on the Org Topologies™ map. More detailed analysis of this in the article below.
Clearing the Terminology Fog
But that interview has some disturbing parts too:
Marty Cagan seems to undermine and diminish Scrum to be just the implementation cycle.
Marty uses the term “feature team” when he tries to describe a team that is merely “coding” away the solution.
We both, authors of the Org Topologies™, train and consult organizations with Scrum and Large-Scale Scrum (LeSS) for many years. We are also affiliated with Scrum Alliance and Scrum.org – two key bodies that represent Scrum in the industry.
So, we feel obliged to clarify the shadow of confusion that Marty's words are casting upon Scrum and LeSS.
Our clarification on Scrum Team and “feature team”:
Scrum (per its first early source from 1986 and the modern scrum guides updated in 2020) has never been described in such a way, where the Scrum Team solely implements a solution without any accountability for the results. So, Marty's words distort Scrum which is in fact a meta-framework that helps to find a suitable work process to deliver value through adaptive solutions for complex problems. Maybe, we guess, Marty refers to broken and dysfunctional Scrum implementations that he saw in the industry. But the game of football and the game of basketball are still great games, no matter if someone plays football with hands and basketball with no basket. And Scrum is a game with clear values, principles, and rules.
Marty's refers to “feature team” without really defining what those are and clarifying the source. We assume he means teams that are not involved in the discovery and are given pre-decided features to build. OK. But there is a well-established and not overloaded definition of a feature team in LeSS. And according to that source, those teams are cross-functional cross-component long-living customer-facing self-managing teams. That are enough adjectives put together in this definition to help avoid any confusion with “delivery teams” – that just code things away.
If not for these two important corrections, Marty's vision of empowered product teams is an interesting concept to study. And now that we clarified some points and references that Marty Cagan has been making, we can proceed with analysis to see what it takes to create and sustain such organizational design.
Mapping Ideally Empowered Product Teams
In this and the next chapters, we will be looking at what we will call “ideally empowered product teams”, i.e., without any anchoring to Marty Cagan's idea for now. We will do this to broaden our discussion and analysis. And then in the conclusion, we see if what Marty Cagan's claims match our understanding.
Ideally empowered product teams should display a very different organizational culture than delivery teams. Formerly do love the customer's problems and own their solutions. Being organizational consultants, we believe that culture follows structure (in established organizations). That means that to create an environment for empowered product teams, management needs to put in place concrete structural elements. The structure goes first and affects how people see the work, do the work, and think of the work – affecting the culture of work. So, what are those structural elements required in the org design for empowered product teams?
We will be looking at ideally empowered product teams from the viewpoint of organizational adaptivity, innovation, and resilience using Org Topologies™ mapping. Our main question is always: how to create and sustain an organizational design to make such teams flourish?
The X-axis of the map is “fluency of delivering a given customer value item”. And the Y-axis is “fluency in learning the whole product”. This gives us a matrix where different org archetypes can be mapped and compared with one another. Organizational adaptivity, innovation, and resilience are increasing when moving top right. A detailed description of this mapping is available at orgtopologies.com. Get yourself familiar if you are new to this. And then read on.
Scope of Work
On the map, the scope of work increases going upward the Y-axes: from tasks to user feature focus, from customers to product & services focus. So logically, we can conclude that because ideally empowered product teams are dealing with high-level concerns, such as customer problems and business objectives, their archetypes should be represented high on the map.
Team Skills
Ideally empowered product teams should be working on customer problems towards business objectives. That implies they speak both the customers and the business languages. They should be formulating problem statements, designing hypotheses, building prototypes, running experiments and measuring the impacts, and then iterating to improve.
Let's now try to understand the empowered aspect. And what structural implications it has.
Being empowered has many layers to this meaning. One that stands up for us as a prerequisite is to have technically sufficient teams (end-to-end). Teams need to have a high level of fluency in delivering features (the X-axes of the map) to have a short lead time, and receive and process market feedback fast. So, engineering excellence is the fair minimum for product teams to be empowered.
But not just that. Such teams need to possess more than just delivery skills. They ought to master product management, product marketing, human interaction design, quick prototyping, UX, IT operations – to name a few.
If we sum up all the skills, we are getting to a few dozen of them. Does it mean that such teams have a few dozen of team members in them? So, large teams?
Multilearning
Having large teams is an option, but it contradicts what we observe to work best in software product development. Self-management, the feeling of empowerment, and process ownership are easier to cultivate in smallish teams. Ideally with 5-7 members.
This leads us to an inevitable realization. Product teams must consist of multidiscipline individuals, people with primary, secondary, tertiary, and so forth skills. We need multiskill team members. This doesn't mean that everyone can do absolutely anything. But this definitely helps to understand and collaborate on the shared work that is in front of a team.
That's not new. Full-stack engineers are the kings of the software industry today. Also, the technologies such as Flutter and React Native help to minimize the zoo of programming languages and technologies required.
But there's more! Such teams are not just polishing the same feature subset over and over again. Instead, they got constantly challenged by novel customer problems and business challenges. They are product teams, for god’s sake!
How do they cope with that anyway? To be able to work on new things, they ought to be constantly learning to acquire new skills. That is inevitable. They are learning teams.
We are going to refer here to a somewhat forgotten term of “multi learning teams”. This has been one of the six characteristics defined in the very first article on Scrum in 1986. Surprisingly, empowered product teams stay very close to what Scrum authors were envisioning. And modern definitions of Scrum come even closer to that.
So let us repeat this:
Ideally empowered product teams are multilearning teams that work on the product end-to-end, mastering and acquiring new technical, product and business skills.
Scrum Teams
If you agree with our logic above, then we can conclude Scrum teams and ideally empowered product teams are, in fact, the same. Provided for Scrum applied is the context of product development.
In Scrum, the Scrum Team has always envisioned doing the real work for customers and business (not just feature delivery). A Scrum Team works end-to-end from business objectives to customer happiness, from concepts to cash.
It is the failure of our industry (and us, coaches) that we have allowed Scrum to be redefined and reduced to “executing delivery teams”.
We have failed. Not Scrum. But let's move on.
Product Learning
Let's try to understand the product aspect of the ideally empowered product teams. And what structural implications it has.
There is one key structural element of product organizations that can either constrain or facilitate broad product thinking. It is the product backlog(s). Some naïve coaches and consultants don't pay attention to the number and the level of the backlogs. But let us explain why this is a big deal.
Consider these two extremes:
Separate team-level feature-centric backlogs (one backlog per team).
A common product backlog with shared business objectives for a group of teams (one backlog for all).
Backlogs create mental filters and barriers in teams and team members. Note how different the teams will look at their work depending on whether they have individual feature-centric backlogs versus one common objectives-centric backlog.
So, what kind of backlogs do the empowered product teams should have? Do they have individual, narrow team-level feature-centric backlogs? If yes, the presence of such narrow separate backlogs will make the teams have a permanent focus on some predefined fixed set of product features. In such an organization, we will expect to find specialized teams. A “product catalog team” working on the product catalog, a “mobile team” working on the mobile app, and so forth.
It is not uncommon to see such teams in organizations. But is such an org design (with a narrow separate backlog per team) compatible with the idea of product teams working from concept to cash, from problem to happiness, that are driving high outcomes with low outputs? We don't think so.
The thing is that you can't keep working forever on something and expect to make a constantly high impact. An effect of diminishing returns will kick in eventually. And it will eventually stop making any economic and business sense to keep working on the same stuff over and over again.
Isn't that what those “product catalog” and “mobile” teams are destined to do? Sadly, yes. That's why those are not product teams!
Broader Product Definition
To avoid being fixed on a product aspect and face the effect of diminishing returns, a product team needs to have a moving focus. This is not the same as not having a focus. They will have to switch from one solved top-priority customer problem to the next unsolved one. If those problems affect the same product part – fine, they can leverage their present skills. But that might not always be the case.
This means such teams need to be constantly learning to work with different product parts, customer problems and business aspects. Over a very long period of time, you can expect that such teams will have worked already on the entire product and acquired a significant set of skills.
We claim that;
Learning to work broadly on the product (meaning not having a static fixed focus) is an inevitable characteristic of ideally empowered product teams.
Our understanding is that the ideally empowered product teams need to share a common objective-oriented product backlog, with its items prioritized by a top-level business representative. And this view might be different from the one that Marty Cagan and his fellow consultants hold.
Conclusion: Mapping “Empowered Product Teams” to Org Topologies™
We've looked above at ideally empowered product teams – our understanding of what it takes to create and sustain an organizational design where such teams would flourish.
The X-Axes
We've proven that such teams must be technically advanced and embrace multi learning. That should be the far right on the X-axis. But in some interviews, Marty Cagan claimed that a product lead is doing evidence value and viability proofs, before handing out this work to the team. And at the same time, Marty was saying that the team does discovery and delivery. We were not sure really what to make from this. Listen to the last 5 minutes of Xagility podcast. Marty Cagan literally says there:
“… We can have it [the evidence] with a lot of prototyping and quick testing… And when it's worth building, then it goes on the product backlog, and then the team, Scrum or Kanban, would … be delivering a product. “
Does that imply that someone (a team lead?) does the prototyping and testing? Is that done separately and without the involvement of the team (as implied by the quote from the interview above)? If this is the case, then such a team is not doing the work 100% multidisciplinary, as there is some kind of reliance on a specialist. It is not clear to us what Marty means. But this made us doubt whether a team stretches to the far right on the map.
The Y-Axes
If we want the teams to work on the highest impact on customer and business problems, as we concluded above, the ideally empowered product teams have to share a single prioritized product backlog. This way, when the teams pull work from the top of the backlog, they engage themselves with the discovery and delivery of something of high value. An example can be: to increase customer retention rate to some desired level. But when this goal is achieved, improving retention is no longer the most important goal (as it has already been achieved). Therefore, the teams will have to work on something different that is now at the top of the product backlog.
If we allow the teams to have individual backlogs, a given team might stay for as long as it wishes on a given topic, e.g., on improving retention. But it will also mean that the team isn't contributing to the highest impact because it ignores global priorities.
We didn't hear Marty Cagan saying anything to confirm the fact that teams in his model to share a common product backlog. In fact, he insists that a product lead (a product owner) should be on a team, deciding priorities. That contradicts the idea of having cross-cutting priorities and implies local backlogs at the team level.
It was also not in Marty's materials and explanations whether he sees multiple teams working with a single product lead (a product owner). And again, embedding a product lead (a product owner) into a team suggests the opposite. On the Org Topologies™ map, such an org design represents an A-row – teams working in isolation. This is not a place of high adaptivity, innovation, and resilience.
We conclude our analysis with the following mapping:
Comparing to SAFe
In his articles, Marty Cagan contrasts “empowered product teams” with “delivery teams”. And we think we understand the distinction he tries to draw: product thinking vs. execution mode.
Marty Cagan is used to saying that they have never seen any successful product organization using SAFe. That's a powerful statement! We believe he's got a point. His observations are also aligned with ours – we believe SAFe won't create a proper environment for empowered product teams to flourish. Instead, SAFe creates disempowered delivery teams focusing mainly on the execution with separated team-level feature-oriented backlogs.
Below is the mapping of SAFe to Org Topologies™. Compare it with the mapping of empowered product teams: SAFe organizations and empowered product teams live indeed, slightly, in different worlds as per the mapping.
One significant difference between these models is that an empowered product team can decide which features to build to satisfy the given objective. Whereas teams in SAFe are simply given features to build.
Towards Better Organizations (with Empowered Product Teams)
The goal of Org Topologies™ is not to downgrade other models or provide some sort of basis for another maturity assessment model. Not at all.
The mission of Org Topologies™ is to help you, a leader of a given organization, to discover a vector of your long-term organizational development. We believe that higher states of adaptivity, innovation, and therefore overall organizational resilience are a great place to grow towards.
As we did in our other analytical articles (on the Spotify Model of Tribes and Squads and Team Topologies), we conclude by sharing some improvement recommendations.
Have the most senior product manager be the Product Owner (product's CEO). For a start-up of 50-ish people, this role shall be played just by the CEO. We see this role as similar to what Marty Cagan defines as a Product Leader. This person needs to be: senior enough in the organization to have the necessary mandate in the context of the product work. This way, such a leader can drive the product strategy on a daily basis by making his list of business priorities clear (Product Backlog).
That Product Backlog will likely be formulated as business objectives and customer needs. That is precisely what it takes to let the empowered product teams solve real business and customer problems.
We suggest avoiding creating a helpers group around the Product Owner that typically consists of product managers and designers. Instead, make them team members of the empowered product teams.
Introduce product and discovery specialists right into the existing teams – avoid separate specialist groups. Thus, you will facilitate the expansion and growth of the teams to become real product teams.
What if you don't have enough product specialists for each team? It is better to have 5 out of 10 teams properly staffed than all the 10 teams understaffed and suffering. We believe that the fully end-to-end teams will show the difference by shipping faster, better solutions. And eventually acquiring the missing extra UX skills for some teams becomes a tactical decision.
Employ the idea of multi-team work. To offload some work from the Product Owner (product lead), try applying prioritization over clarification pattern and practices of multi-team meetings. This would minimize the bottleneck and increase the flow, allowing the single Product Owner to lead many teams and increase the business impact of their work.
© 2022-2023, Alexey Krivitsky and Roland Flemm. Org Topologies™.
