Product Teams vs Feature Teams
This is, to me, the single most clarifying distinction in modern product thinking, and it is Marty Cagan's. Two teams can look identical from the outside, with the same headcount, the same standups, the same Jira board, and still be doing fundamentally different work. One is handed a roadmap of features and asked to build them on schedule. The other is handed a problem and a measurable outcome and trusted to figure out the solution. Cagan calls the first a feature team and the second a product team (or empowered team), and once you see the difference you cannot unsee it.
#The core distinction
Feature teams are measured on output: did they ship the roadmap. Empowered product teams are measured on outcomes: did they solve the problem and move the metric. The first is a "feature factory" (John Cutler's term). The second is what good looks like.
| Feature Team | Product Team (Empowered) | |
|---|---|---|
| Given | A roadmap of features | A problem and an outcome to move |
| Measured on | Did we ship it (output) | Did we solve it (outcome) |
| Discovery | Done elsewhere, handed down | Owned by the team |
| PM's role | Project-manage delivery | Own value and viability |
| Failure looks like | Late shipment | A metric that didn't move |
| Cagan's word | Mercenaries | Missionaries |
#Missionaries, not mercenaries
Cagan borrows John Doerr's line: you want missionaries, not mercenaries. Mercenaries build what they are told and go home. They have no stake in whether it works, because they were never trusted with the why. Missionaries understand the problem deeply enough to care whether they solved it, and they will fight for the user and push back on a bad spec. You do not get missionaries by writing "be passionate" in a job description. You get them by giving the team real problems and real autonomy, which is to say by making it a product team. Culture follows structure here, not the other way around.
#Why this is the PM's fight
Here is the part that is personal to the PM job. On a feature team, the PM role collapses into the Product Owner 10%. If the roadmap is handed down and discovery happened upstairs, there is nothing left for you but backlog grooming and delivery coordination. You become a project manager with a product title. Every reason this Atlas exists, including discovery, strategy, the four risks, and judgment, presupposes a product team. On a feature team, most of your competencies have no surface to act on.
So when I tell PMs to push for outcomes rather than features, I am not being philosophical. I am telling them to defend the conditions under which their job is worth doing.
#Most teams are feature teams in disguise
Here is the uncomfortable part. Most teams that call themselves product teams are feature teams wearing the vocabulary. They say "outcomes" and then measure velocity. They run discovery theater, a few interviews to justify a decision already made. The tells are easy to spot once you know them.
- Your roadmap is a list of features with dates, not problems with target metrics.
- Success is defined as "shipped," and nobody checks the outcome 60 days later.
- Discovery, if it happens, happens after the decision, to build the case.
- Leadership hands down solutions ("build a referral program"), not problems ("activation is too low").
- The fastest way to get praised is to ship a lot, regardless of whether anything moved.
If you recognize your team here, that is not cause for despair. It is the diagnosis. The move is to quietly start attaching an outcome metric to everything you ship and reporting on it, whether or not anyone asked. That is how you convert a feature team one decision at a time. The structural version of this choice, owner versus facilitator and outcome versus feature, is laid out in The Product Organization Matrix.
#Continue Reading
- The Product Organization Matrix for the 2x2 that locates your specific situation.
- Outcomes Over Outputs for the principle that separates the two team types.
- Product Manager vs Adjacent Roles for why feature teams shrink the PM into a PO.
- The Four Big Product Risks for the work that only exists on an empowered team.
- Continuous Discovery for the practice that makes a team a product team in fact, not name.