Feature teams vs. product teams: Marty Cagan on building products that matter

Executive overview

Most software companies run feature teams — shipping a prioritised list of requests from stakeholders — while the best companies run empowered product teams given problems to solve. The gap between the two is not incremental; it is structural.

Cagan's thesis, reinforced by a 1995 Steve Jobs interview, is that companies lose product culture as they grow: sales, marketing, and finance leaders rise while product people leave. What remains is a fear-driven organisation that optimises rather than discovers.

The core insight: an idea is 5% of the work — the craft of getting from idea to product is everything, and most executives have no appreciation for this.

Feature teams vs. product teams

• Feature teams receive a roadmap of prioritised features; product teams receive problems to solve
• Feature teams measure output (releases); product teams measure outcomes (did the problem get solved?)
• In a feature team, the PM is a project manager herding requirements into sprint planning
• In an empowered product team, the PM owns value and viability — two of the hardest product risks
• Only ~10–15% of commercial product companies operate as true product teams
• Engineers and designers on feature teams execute; on product teams they co-create the solution

Why good companies turn bad

• As companies scale, product becomes less celebrated than sales, marketing, and finance
• Good product people leave for companies that value product; the remainder optimise
• After founders depart, teams lose institutional knowledge of what is essential vs. incidental
• Fear of breaking a working business leads to endless low-risk A/B tests instead of real discovery
• Steve Jobs called this a "disease" — sufficient market share removes the pressure to innovate
• Executives mistake the idea for the work; only ~20% of stakeholder-chosen features generate positive return

The PM's job is the how, not just the what

• The PM does not just define "what" — they own value (is this worth building?) and viability (can the business support it?)
• Designers own usability; engineers own feasibility; PMs own value and viability — all four must pass or the product fails
• Declaring "PMs only do the what" would reduce the role to 15 minutes of work a week
• The PM is not the designer's or engineer's boss; together they arrive at the best solution

Four areas a PM must master before leading a product team

1. Deep customer knowledge — visit customers directly; no proxy or report is a substitute
2. Product and business data — understand how the product is actually used and what the metrics say
3. Business context — know how the product is marketed, sold, monetised, and what compliance constraints exist; earn stakeholder trust
4. Competitive and industry landscape — track trends, competitors, and enabling technology

Discovery: solution beats problem validation

• Most of the team's time should go to solution discovery, not re-validating a known problem
• The clock is ticking; spending weeks on problem validation frustrates founders and delays value
• User research should surface reasons users won't use the product, not collect approval ratings
• Evaluative research (finding blockers) is more valuable than generative research for most product decisions
• PMs and designers must be present during user research sessions — reports left for others to read are ignored
• Steve Jobs' description of "5,000 things in your head" at any moment is a description of active solution discovery

Three things a PM must never delegate

• Direct access to users and customers
• Direct access to engineers
• Direct access to stakeholders

Removing any one of these breaks the feedback loops required for good product decisions. Product ops is healthy when it handles runtime/production triage or builds PM productivity tools — unhealthy when it mediates between PMs and any of these three groups.

How a feature team can experiment with a new way of working

• Ask your manager for one quarter to run as an empowered team — low risk to try at team level
• Reverse-engineer the feature request into its underlying problem by asking stakeholders how they measure success
• Ensure the PM builds knowledge across the four areas before the team begins discovery
• Read: Continuous Discovery Habits (Teresa Torres), Sprint (Jake Knapp), and Inspired (Cagan)
• Find a manager or coach who has done real product; coaching is the single most cited differentiator at top companies

The process trap

• There are two ways to scale: with process or with leaders — only scaling with leaders produces good outcomes
• Frameworks like SAFe are repackaged waterfall; calling something Agile does not make it Agile
• Process is attractive to leaders who do not understand software — it feels like a controllable answer to scaling
• "Process people" are the other disease Jobs warned about; they optimise away the conditions that produce innovation
• Product owners trained only in Scrum are taught a process, not how to do product — the blind leading the blind