LLenny's Podcast
← All frameworks
LeadershipMarty Cagan (Silicon Valley Product Group)

The Feature Team vs Empowered Product Team Diagnostic

Diagnose whether your team ships output or owns outcomes — and what that means for the PM role.

Difficulty
Easy
Time to result
~weeks to results
Steps
5
Confidence
95%

Marty Cagan argues most complaints about product managers are actually complaints about feature teams. A feature team is handed a roadmap of features and dates and is measured on shipping; an empowered product team is handed one or two hard problems per quarter and is measured on whether the problem is solved. The distinction determines whether a real product manager is even needed: on a feature team the role collapses into project management, which engineers or existing project managers can do better and cheaper.

Origin

Marty Cagan (Silicon Valley Product Group), building on two decades of SVPG's comparative work across strong product companies; the terminology of 'feature team' vs 'empowered product team' comes from his books INSPIRED and EMPOWERED, and he sharpened it into 'product management theater' in the writing preceding TRANSFORMED (2024).

Core principles

  • 01Output (shipping features) is far easier than outcomes (solving the problem).
  • 02You don't get points for shipping; you get points for delivering value.
  • 03The complaint 'we don't need PMs' is the strongest single clue you are on a feature team.
  • 04Executives care about time-to-money, not time-to-market — time-to-market is a solved problem.
  • 05On a feature team the PM has time to micromanage designers and engineers; on a product team they don't, because they have their own work.

How to run it

  1. 1

    Look at what the team is handed

    Ask what arrives at the start of a quarter. If it is a list of features or projects with dates — sourced from an executive, a big-pocket customer, or a sales commitment — you are on a feature team. If it is one or two customer or business problems to solve (plus keep-the-lights-on work), you are on a product team.

    Pro tip The source of the roadmap matters less than its shape: features and dates = feature team, regardless of who wrote it.

  2. 2

    Look at how success is measured

    Ask what counts as done. If done means 'shipped the thing on the date', that is output. If done means 'the problem measurably moved', that is an outcome. Reframe the measure to the executive language of time-to-money rather than time-to-market.

    Pro tip CEOs and CFOs resonate with time-to-money framing; use it when arguing for the change.

  3. 3

    Ask the PM to define their own job

    Have the product manager describe their job unprompted. Squishy answers — 'I facilitate', 'I do communication', 'I herd the cats', 'my job is to say why' — indicate theater. A real answer names ownership of value and viability.

    Pro tip Cagan uses exactly this as his opening interview question: can the candidate even define the job of a product manager.

    Watch out Do not coach the answer before asking; the unprompted answer tells you where the person learned the craft.

  4. 4

    Count the adjacent roles

    Inventory the surrounding titles: product owners, agile coaches, scrum masters, business analysts, product ops, assistant/associate product managers, layers of project managers. A thick layer of these roles alongside 'product managers' is a signature of the feature-team model plus process-heavy scaffolding.

    Watch out Cagan's view: a dedicated product-owner role has no business existing as a separate person — a senior engineer usually does backlog administration better.

  5. 5

    Choose the escape route: raise your game or move the team

    If the diagnosis is 'feature team', do not treat it as a fate to be escaped only by quitting. Either upgrade your own skills toward value and viability so you become the rare person who understands the model, or propose running a small set of teams the new way and comparing results.

    Pro tip Cagan: even if the company never transforms, the skill upgrade alone typically earns appreciation and promotion.

In the wild

The 'we don't need PMs' startup

Founders and engineers repeatedly tell Cagan they don't want product managers — the PM slows them down, tries to be the boss, and contributes nothing. On inspection, nearly every one of these teams is a feature team or a delivery team, where the PM's job has collapsed into project management that the engineers and designers can do themselves.

Cagan doesn't blame them: in that model the PM genuinely isn't bringing value and is, in his words, dramatically overpaid for the value they provide. The fix is changing the team model, not the person.

Meta's apparently top-down bets

Lenny notes that Meta's CTO describes the company as top-down: Zuck and the execs set strategy and the big bets. Cagan says this is exactly what strong product companies do — leaders place the bets, teams get real latitude to solve them. That is not a feature team, because what is handed down is a problem/bet, not a roadmap of features.

The clarification separates 'top-down strategy' (healthy) from 'top-down feature roadmap' (feature team).

Common mistakes

Blaming the PM instead of the model

Teams conclude 'PMs are useless' from experience with feature-team PMs. The role was structurally hollow; hiring a better person into the same structure doesn't fix it.

Assuming a sales-driven feature factory is 'fine for B2B'

Cagan's counter: this is precisely why most B2B software is bad. An empowered product team can do everything a feature team can do and more, so accepting the feature model caps the ceiling.

Treating a roadmap of features as evidence of alignment

Handing a team a feature roadmap is the most top-down thing a company can do, and it removes the very risk work (value, viability) that justifies a product manager.

Is it for you?

Best for

Product managers, heads of product, and founders who suspect their 'product' org is really a delivery org and need a concrete test before restructuring

Not ideal for

Pure services/agency delivery work where the customer genuinely specifies the build and no discovery is wanted or paid for

From the transcript

it is a lot easier to deliver output than it is to deliver outcomes

00:00

on a feature team you're basically given a road map of output

21:00

instead of being given that road map of features they're given problems to solve

21:30

it's all about outcomes you just don't get points for shipping you get points for delivering the value

22:00

it's about time to money more than time to Market

22:30

I consider that complaint you're raising as the biggest clue that they are probably a feature team

20:00

From the episode

Product management theater

Marty Cagan (Silicon Valley Product Group)