Delivery team, feature team, or product team? Only one ships value.

If you're only told what to build and how to build it, you're not running product - you're administering a backlog. That's blunt, but it's the fault line Marty Cagan draws between three types of “product” teams: delivery teams, feature teams, and product teams. The first two look the part and wear the title. Only the third actually does the job.

The delivery team

The most stripped-down version. A delivery team:

• Is told what to build and how to build it.
• Focuses on delivering outputs - features shipped.
• Has no real cross-functional collaboration - usually just some developers and a product owner.
• Receives a list of features to code and ship.
• Scopes the PM down to Backlog Administrator, whose sole job is prioritising a queue of features.

The feature team

A step up, and the one most companies mistake for a product team. A feature team:

• Is told which features to deliver - by stakeholders.
• Still focuses on outputs.
• Has some collaboration, but designers and engineers are mostly told what to do by the PM, while value and viability are treated as “the stakeholders' problem.”
• Works off a roadmap of prioritised features and ship dates handed down from above.
• Scopes the PM closer to a Project Manager than a Product Manager.

The empowered product team

The real thing. An empowered product team:

• Exists to discover valuable and viable solutions from explored and validated product opportunities.
• Is focused on and measured by outcomes, not outputs.
• Runs on genuine cross-functional collaboration across product, design, and engineering - a Product Trio.
• Is empowered to figure out the best way to solve the problems it has discovered.
• Has a PM who owns value and viability, backed by deep knowledge of the customer, the data, the industry, and the business.

The fastest way to diagnose your team

You don't need a maturity audit. Ask two questions. Who decides what to build? And are you measured by what you shipped, or by what changed for customers and the business? If the answer is “someone else decides, and we're measured by output,” you're a delivery or feature team wearing a product team's badge.

How to move right

The good news: you rarely need a re-org to start moving toward the empowered end. Tie your work to outcomes, not outputs. Talk to customers to find the real problems. Make product decisions with design and engineering instead of handing them a spec. Validate the riskiest assumption before you build. Do that consistently and you drag your team rightward one decision at a time.

And if the organisation structurally won't allow it - if every decision has to travel up to a stakeholder and back down - that's not a team problem, it's an operating-model problem. That's exactly the kind of thing a Product Model Transformation is built to fix. (And if your “product” role is really a backlog administrator in disguise, we wrote a whole piece on that.)