Empowered Product Team vs. LeSS Feature Team
Recently, while discussing with a potential client, I learned of their interest in adopting a Product Operating Model. This prompted me to study the concept in greater depth. It wasn’t my first encounter with Marty Cagan’s work; I had read his book Inspired long time ago and have been following his blog for years. During my review, I noticed his strong critique of feature teams, which stands in contrast to his advocacy for empowered product teams. While there are meaningful distinctions between the two models, I believe some of the differences are overstated or misunderstood. Since feature teams are a core component of the LeSS framework, I decided to write this article to compare both approaches and help readers distinguish valuable insights from misconceptions.
To clarify, Marty does not explicitly cite the origin of his “feature team” definition, which seems largely informed by his firsthand experience. In this piece, I will refer to the LeSS definition of a feature team when contrasting it with an empowered product team. The graph below provides a high-level comparison.
Do feature teams create outcome or output?
Marty Cagan’s strongest critique of feature teams is that they focus merely on output—delivering features—rather than outcome, which refers to real impact or value. He summarizes this as the key distinction between feature teams and product teams in his Product Team FAQ:
Feature teams usually are cross-functional (at least some form of designer and some form of product manager), but they are still all about output and not empowered.
Product teams are cross-functional, focused and measured by outcome, and empowered to come up with solutions that work.
But does this mean feature teams are inherently designed for output rather than outcome? Let’s look at the LeSS definition of a feature team:
A feature team is a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one.
While this definition doesn’t explicitly mention outcome, that’s because its primary purpose is to contrast feature teams with component teams, but not to define their relationship to outcomes. The emphasis is on the team’s ability to deliver complete, end-to-end customer features. Scrum itself doesn’t use the term “feature team” and it refers to the “development team.” LeSS introduced the feature team concept explicitly to counter the common anti-pattern of component teams, which remain widespread in large-scale product organizations.
Based on my own experience teaching and applying Scrum and LeSS, I can confidently say that feature teams are indeed oriented toward outcomes, not just outputs. Here’s why.
A common misunderstanding actually stems from what goes into product backlog. I prefer the generic term “Product Backlog Item” (PBI). A PBI might start as a large problem or a goal. Through refinement, the Product Owner and the team break it down into smaller problems or sub-goals and eventually into features that represent hypothesized solutions. This is the essence of Product Backlog Refinement. The team then builds these features, and together with the Product Owner, they learn and adapt through iterative development. The backlog is an emergent artifact, and it contains items at various granularities, from problems to solutions. Feature teams deliver features, but with the intent of solving problems and creating value. They actively participate in discovery and refinement, embodying the Agile principle that “the best architectures, requirements, and designs emerge from self-organizing teams”.
LeSS makes it especially clear that feature teams are not passive “feature factories”. With multiple feature teams sharing one Product Owner, it’s practically impossible for the Product Owner alone to focus on outcomes while teams simply take delivery orders. In reality, a significant portion of backlog refinement is driven by the feature teams themselves. The backlog is a shared artifact, owned collectively by the Product Owner and the teams. A hallmark of a well-implemented LeSS adoption is that feature teams collaborate on understanding problems and iterating toward valuable solutions, not just implementing predefined features.
Therefore, in this crucial respect, empowered product teams and LeSS feature teams are similar: both are designed to focus on outcomes, not just outputs. That said, other differences do exist between the two models.
Some differences
- Team autonomy
Both empowered product teams and LeSS feature teams operate with a degree of autonomy, though the nature and scope differ.
In an empowered product team model, product leaders typically set a clear, measurable outcome, such as a quarterly OKR, which serves as a key boundary for the team’s autonomy. The team then has full authority to determine how best to achieve these outcomes. While product teams may use sprints internally, they maintain complete control over their work and can adapt dynamically without ongoing leadership intervention.
In contrast, LeSS feature teams work closely with the Product Owner on sprint basis. While these teams actively participate in backlog refinement and have significant influence, the final prioritization authority formally rests with the Product Owner. In this sense, product teams generally enjoy greater autonomy than feature teams. However, this increased autonomy comes with a trade-off: product teams may experience reduced flexibility due to their commitment to longer-term outcome-based goals, whereas feature teams can adapt more readily within their shorter sprint cycles.
- Organizational structure
In terms of organizational structure, the product team model typically assumes a functional reporting hierarchy, which may not be a conscious design. In this setup, roles such as product managers, designers, and engineers report through separate functional lines, even as they collaborate as long-term, dedicated members of the same product team. By contrast, feature teams operate under a unified reporting structure that effectively dismantles the traditional functional organization. Each approach introduces distinct challenges.
The product team model must contend with issues commonly associated with matrix structures, particularly the difficulty of ensuring members identify with their product team rather than their functional home. The most significant risk is that a product team devolves into a "feature group", where specialists operate in isolation rather than as an integrated unit. In the feature team model, all members are considered developers; while they bring specialized skills, they are not confined by them but actively developing into multi-specialists over time. To counter the natural pull toward functional identity, the product team model requires deliberate organizational reinforcement. On the other hand, the feature team model often encounters stronger resistance, as it disrupts traditional functional structure. It also faces the challenge of maintaining functional excellence, necessitating supplemental mechanisms such as communities of practice or guilds to support cross-team learning and professional growth.
- Multiple teams
Product teams are typically assigned to work on distinct strategic problems, though multiple teams may occasionally collaborate on the same one. This approach, while fostering deep focus, can sometimes lead to local optimization. This contrasts with the LeSS framework, where multiple feature teams share a single, unified Product Backlog, which is inherently designed to promote global optimization across the entire product.
In the product team model, product leaders who hold a role analogous to the Product Owner in LeSS define these strategic problems. While they likely maintain an overall product view, they do not typically manage a single, shared backlog for all teams. Instead, they rely on mechanisms like quarterly OKRs to set and align goals. Consequently, product teams are often more focused on their specific objectives but can be less flexible than LeSS feature teams, which can be dynamically reallocated across a unified backlog to address the most valuable items as they emerge.
Summary
Both the Empowered Product Team and the LeSS Feature Team aim to achieve better outcomes through team empowerment. From the perspective of a single team, they differ primarily in their degree of autonomy and organizational structure. Beyond the team level, the Product Operating Model does not explicitly emphasize multi-team organizational design, while the LeSS framework provides clear guidelines about having multiple feature teams share one product backlog.
