On "Product Teams" and "Feature Teams"

(by Bas Vodde and Craig Larman)

On “Product Teams” and “Feature Teams”

This post has its origins in a post by Marty Cagan at https://svpg.com/product-vs-feature-teams/ in which he compares what he calls “product teams” with what he calls “feature teams.” We’re not quite sure where Marty’s definition of “feature team” originates from, as what he calls “product team” seems to be more like a feature team to us than his definition.

That said, the article is strong even when some of the reasoning is weak.

Weak Reasoning

logic weakness - Marty sets up his own definition of feature team (a straw man) and argues against his own definition; i.e. an argument from false premises.

logic weakness - Notice how the article’s argument is framed: either (1) you have “product teams” that are empowered and focus on outcomes, or (2) you have “feature teams” that aren’t. This is an example of the “false dichotomy” logic/argument fallacy, so widespread that we highlighted seeing this as a major thinking tool in the first LeSS book. And of course our suggestion is to consider more options beyond the false binary. For example, here’s a radical idea: How about a team in a large product group that can either be empowered to focus on an outcome with their own innovative discoveries, or that can take on a presented feature request and implement it? Mind… blown!

term weakness - Perhaps the name “product team” is more attractive to you. But notice that the name strongly suggests – although we acknowledge it doesn’t enforce – to the naive ear the idea that the team is creating their (narrow) product. For a fresh 7-people start-up with one team working on the Product, this is fine. For a growing start-up or a larger organization, these many narrow small “products” leads to a profound sub-optimization at the global level in terms of working on highest value, the switching cost of adapting to work on another existing “product”, lack of global vision and alignment, and difficulty of multiple teams to work together on a larger broader product.

You might think, it is just a term. But if you work for a long time in organizational development, you will notice that the choice of terms and the widespread misunderstandings that will arise from those choices is more influential than you might have imagined. We predict that “product team” will easily over time and space get misinterpreted as “each team has a product.”

Note: “feature team” suffers from similar weaknesses, as Marty’s article proves. The main reason for sticking to the term “feature team” is historical. The original use of the term in in Microsoft’s Visual C++ v1 and Ericsson’s AXE basestation – two wildly successful products. Also, we keep using the term because of our failure to find a better one.

Strong Points with which We Heartily Agree

That said, beyond these weaknesses, the article is reasonably good and there are some points that are really important and with which we strongly agree:

• The article reminds everyone of the importance of focus on the customer. Teams involved in building great products need to focus on the customer, understand the customer, live the customer.
• It reminds everyone the most productive feature teams focus on outcome and not on output, and with the freedom to innovate to achieve the outcome (thus the LeSS Guide: More outcome, less output). Teams become much stronger when you give them problems to solve than when you give them tasks to implement.
• It raises some important Product Management dysfunctions that we also frequently encounter.

The article also raises some other questions, which we will discuss in a follow up post. Specifically the question on whether a Product Manager should be a part of the Team. Unfortunately, the answer isn’t trivial and hence another post… “On Product Manager in the Team.”