Feature Team vs. Empowered Product Team Diagnostic
Tell in minutes whether your squad is handed features to ship or problems to solve
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 5
- Confidence
- 95%
Cagan argues that 'feature teams' and 'empowered product teams' are superficially identical squads doing radically different jobs, and that most PMs cannot tell which one they are on. The diagnostic keys on four observable signals: what the team is handed, who owns the solution, what gets celebrated, and what the PM actually does all day. A feature team is given a prioritized list of possible solutions and measured on output; an empowered team is given problems and measured on outcomes.
Origin
Marty Cagan's own distinction, developed across SVPG's coaching work and formalised in INSPIRED and EMPOWERED. He credits the underlying decision-rights principle to Netflix ('push the decisions down to the people that actually have the knowledge to best solve the problem').
Core principles
- 01A roadmap of prioritized features is a list of possible solutions, not a list of problems.
- 02Outcomes over output: a release that doesn't solve the problem is nothing to celebrate.
- 03Push decisions down to the people closest to the enabling technology and the customers.
- 04Engineers and designers are peers in the solution, not implementers of the PM's ideas.
- 05The two roles are so different they arguably shouldn't share the title 'product manager'.
How to run it
- 1
Check what the team is handed
Look at the artifact that starts your quarter. If it is a prioritized list of features and projects agreed by stakeholders, you are on a feature team. If it is a set of customer or company problems with success measures, you are on an empowered product team.
Pro tip Read the roadmap literally: every line item that names a solution ('add buy now pay later') is a bet someone else already placed for you.
- 2
Check who owns the solution
Ask whether the team is allowed to come up with a different solution than the one requested. On a feature team the team does 'a little design and a lot of coding'; on a product team the team is given the skills and the latitude to discover the best solution to the problem.
Watch out If proposing an alternative solution reads as insubordination rather than as doing your job, you have your answer.
- 3
Check what gets celebrated
Watch what triggers celebration. Shipping the release = output culture. Moving the metric the problem was framed around = outcome culture. With continuous deployment, shipping is not an achievement.
- 4
Check what the PM actually does
If the PM's week is gathering requirements, documenting them in Jira, and shepherding them through sprint planning, that is project management ('herding cats'). If the PM is personally responsible for whether the solution is valuable and viable, that is product management.
Watch out The designer and engineer roles look similar in both models, so don't use them as your test — the PM role is where the difference shows.
- 5
Decide: transform in place, or leave
Once diagnosed, choose deliberately. Cagan's advice is to attempt one team-level experiment before giving up on the company, because converting a single team is cheap while converting a business unit is expensive and risky.
Pro tip Frame the diagnosis to leadership as a comparison to admired companies, not as a criticism of colleagues.
In the wild
Cagan describes the near-universal pattern: stakeholders meet quarterly, decide 'to run our part of the business we need these features', and hand the list down. The team does a little design, a lot of coding, some QA, then deploys — and exists to serve the business.
→ The team ships continuously and reliably, yet has no way of knowing whether any of it worked; Cagan notes only about 20 percent of such items generate any positive return.
Instead of executives choosing solutions, the decision is pushed down to engineers who work with the enabling technology every day and product people who work with users every week.
→ The people with the most relevant knowledge choose the solution, and the team is judged on whether the problem got solved rather than on whether the feature shipped.
Common mistakes
Assuming the squad structure tells you the model
Both models look like a cross-functional squad from the outside. Cagan: 'superficially they're both squads but they are very very different.' Judge by inputs, decision rights, and celebrations — not the org chart.
Calling a project-management job 'product management'
Herding requirements to sprint planning is non-trivial work, but it is not product management. Conflating the two leaves PMs with no idea which skills they are actually missing.
Is it for you?
Best for
A PM, designer, or engineering lead who suspects their company is a feature factory and needs an objective test before deciding to push for change or leave
Not ideal for
Custom-solution / agency work delivered to a client's spec, where the 'problem' genuinely is contractually fixed
From the transcript
“it's a prioritized list of features and projects so some stakeholders got together usually quarterly”
“so you're being asked to do a little design and a lot of coding and then some qa and then deploy and more generally you're…”
“instead of being given a roadmap of prioritized features they're given problems to solve”
“that's sort of the netflix principle is push the decisions down to the people that actually have the knowledge to best solve the problem”
“another difference is when you're given a problem to solve that's not output that's outcome so you either solve it or you don't”
“who cares if you make another release if it doesn't actually solve the problem it's nothing to brag about”
“so in a real product team you know you celebrate when you actually solve the problem when you accomplish those results that's why we say…”
“on the other hand in a feature team the product manager is basically there to herd the cats to get it now”
“the developers aren't there to just implement your dumb ideas they are there to help you come up with a great solution”
From the episode
The nature of product
Marty Cagan, Silicon Valley Product Group