Back to Library
Library rep  ·  Saturday, May 30

Marty Cagan: You're probably on a feature factory — here's how to tell, and what to do instead.

Kettlebell Coach
Read first. Then rep it.
Ready to apply this idea?
Five application reps based on what Marty Cagan discussed.
Practice this insight
Based on Lenny’s
Interview · Marty Cagan · Aug 21, 2022

The nature of product | Marty Cagan, Silicon Valley Product Group

Start from the original episode or newsletter, then use the ideas below in the reps.

Key ideas to remember

  1. 01 Your roadmap's structure reveals your team's model: if it lists features, it's a list of other people's hypotheses — not a plan to solve problems.
  2. 02 Shipping is not the win; solving the problem is. Celebrate outcomes, not releases.
  3. 03 As a PM on an empowered team, you own 'valuable' and 'viable' — not the sprint board. Those are two of the four hardest dimensions to get right.
  4. 04 You cannot contribute meaningfully to a product team until you've done the fieldwork: deep customer exposure, data fluency, industry knowledge, and business understanding.
  5. 05 Every escalation of a product decision up the chain is a step toward a feature factory; the Netflix principle says decisions belong with the people closest to the problem.
3-minute summary

The default is broken — and most PMs don't know it

Marty Cagan's central argument is uncomfortable: most product teams are feature factories masquerading as empowered teams. The difference isn't visible on an org chart — both have squads, sprints, and standups. The difference is in what the PM is actually responsible for.

The roadmap is the tell

The fastest diagnostic: look at your roadmap. If it lists features and projects, you're operating in feature-factory mode. Those feature names are solutions — someone else's hypothesis about how to fix a problem you were never told about. A roadmap that names outcomes or problems instead is the first visible sign of an empowered team.

Output vs. outcome — a real distinction, not a slogan

Cagan is direct: shipping is not a win. Continuous deployment means releasing many times a day is trivially achievable. If you're celebrating releases that don't move the metric or solve the user problem, you're celebrating the wrong thing. Empowered teams celebrate when the problem is solved — when the outcome is achieved — not when the Jira ticket is closed.

What the PM actually owns

On a feature team, the PM is a requirements organizer — herding specs into Jira and onto sprint planning. On an empowered team, Cagan says the PM owns two of the four product dimensions: valuable (does it solve a real problem worth solving?) and viable (can the business actually build, sell, and sustain this?). Design owns usability; engineering owns feasibility. None of those four can be ignored, and the PM is responsible for two of the hardest ones.

The four things you need before you can contribute

New PMs on an empowered team can't just start deciding. Cagan describes four domains of knowledge you have to earn first: deep understanding of users and customers, fluency with product data, knowledge of the industry, and understanding of the business model. His own coach refused to let him make any team decisions until he had visited 30 customers (15 in the US, 15 in Europe). The point: opinions formed at a desk are second-hand. The knowledge that makes you valuable on a real product team comes from direct exposure.

Push decisions down — or escalation creates the factory

Cagan invokes the Netflix principle: decisions should be pushed to the people with the best knowledge — the engineers working with enabling technology daily, the product teams talking to customers weekly. Every escalation up the chain is a signal that the team isn't trusted. And when teams aren't trusted to decide, they stop trying to solve problems and start waiting for feature lists.

Kettlebell Coach
This is where the reps count.
Practice the insight now
Turn the operator summary into five product decisions.
Practice this insight