Irene Au recently pointed a link to this article by Marty Cagan that I absolutely adore. It picks apart the difference between a delivery team vs a product team vs a feature team with a strong lens of criticality.
When products are essentially agile development problems running at scale, they look like a delivery team:
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 some 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.
Marty Cagan
The “empowered” product team is charged with solving and owning a problem that will impact the business.
Product 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. The purpose of a product team in this sense is to solve problems in ways our customers love, yet work for our business.
Marty Cagan
He then describes how feature teams tend to be resourced with talent that skews towards delivery vs problem-finding. They aren’t necessarily needing to be responsible for an outcome and empowered to own the work themselves.
In a feature team, you still (hopefully) have a designer to ensure usability, and you have engineers to ensure feasibility, but, and this is critical to understand: the value and business viability are the responsibility of the stakeholder or executive that requested the feature on the roadmap.
Marty Cagan
If they say they need you to build feature x, then they believe feature x will deliver some amount of value, and they believe that feature x is something that is viable for the business.
And this piece is particularly a zinger with respect to the invisible difference between UI and UX:
In the vast majority of cases where you have feature teams, the designer (if there is one) is a graphic designer. It’s not that graphic or visual design is not important, but what’s relevant here is that now there’s a big gap – someone needs to figure out at least the interaction design and hopefully do some user research. Hence it’s very common to see pressure on the product manager in this model to try to fill these gaps.
Marty Cagan
Cagan goes on further to say that the tools of the designer are now easy to use, but it’s not a trivial task to create a working experience based upon research and principles.
In short, his point is that to make good products that are impactful, it is important to have a well staffed, fully accountable team.
