insights

InsightHub

The Death of the Feature Factory: Building What Matters

September 12, 2025
schedule 4 min read

What Is a Feature Factory?

John Cutler coined the term "feature factory" to describe product teams trapped in a cycle:

  • Stakeholders request features
  • Teams build features
  • Features ship
  • Nobody measures if they worked
  • More features get requested

The feature factory feels productive. You're shipping constantly. Roadmaps fill with checkmarks. But none of it connects to outcomes that matter.

Signs You're in a Feature Factory

1. Success is measured by output, not outcome

  • "We shipped 12 features this quarter" (output)
  • vs. "We improved activation by 15%" (outcome)

2. Roadmaps are lists, not strategies

  • Features grouped by timeline, not by goal
  • No clear thesis connecting items

3. Research happens after decisions

  • Features get committed before validation
  • Research is for "confirming" not discovering

4. Everyone is a PM

  • Sales drives features for specific deals
  • Executives have "ideas" that become requirements
  • The highest-paid person's opinion wins

5. Nothing gets killed

  • Bad features stay because removing them is harder than keeping them
  • The product bloats over time
  • Complexity grows faster than value

Why Feature Factories Form

Feature factories aren't caused by bad people. They're caused by:

Misaligned incentives

  • PMs evaluated on shipping, not impact
  • Engineers measured by velocity, not value
  • Sales compensated on deals, not retention

Short-term pressure

  • Quarterly targets demand visible progress
  • Board meetings need "new" announcements
  • Competitive threats feel urgent

Research avoidance

  • Research takes time; building is faster
  • Negative findings threaten existing plans
  • "We already know what customers want"

Measurement failure

  • No baseline to compare against
  • No tracking of feature usage post-launch
  • Success defined by launch, not adoption

Escaping the Feature Factory

The exit path isn't about doing research (though that helps). It's about changing what counts as success.

Shift 1: From features to outcomes

Replace: "Ship invoicing feature" With: "Increase enterprise retention by reducing billing friction"

The feature becomes a hypothesis, not a requirement. If it doesn't achieve the outcome, you try something else.

Shift 2: From roadmaps to bets

A roadmap implies certainty. A bet acknowledges uncertainty.

Each item should state:

  • What we're building
  • Why we believe it will work
  • How we'll know if it worked
  • When we'll evaluate

Framing as bets invites learning instead of defending decisions.

Shift 3: From stakeholder requests to validated problems

Stakeholder requests are solutions (often bad ones). Your job is to find the underlying problem.

When someone says "build X":

  • What problem are they trying to solve?
  • Who else has this problem?
  • What evidence supports this priority?
  • Are there other solutions?

Shift 4: From launch-and-forget to learn-and-iterate

Every feature should have:

  • Success metrics defined before launch
  • Tracking implemented before launch
  • Review scheduled after launch
  • Decision criteria for iteration or removal

If you never evaluate, you never learn.

Practical Tactics

Tactic 1: Outcome-based planning

Start planning with outcomes:

  • "What business results do we need this quarter?"
  • "What customer behaviors would drive those results?"
  • "What changes to our product might enable those behaviors?"

Features emerge from outcomes, not the other way around.

Tactic 2: Feature audits

Quarterly, review:

  • Which features shipped 6+ months ago?
  • What % of users actively use them?
  • Which should be improved, maintained, or removed?

Tactic 3: Bet reviews

Monthly, review active bets:

  • Are metrics moving as expected?
  • What have we learned?
  • Should we double down, pivot, or stop?

Tactic 4: Saying no with data

When stakeholders request features, respond with:

  • "Here's what our data shows about this problem."
  • "Here's how we'd measure success."
  • "Here's what we'd need to deprioritize."

Data shifts conversation from opinion to evidence.

The Cultural Shift

Escaping the feature factory requires changing what gets celebrated:

Old culture:

  • "We shipped on time!" (even if nobody uses it)
  • "The customer asked for this!" (one customer)
  • "We need to stay competitive!" (copying others)

New culture:

  • "We moved the metric!" (outcome achieved)
  • "Research showed this pattern." (evidence-based)
  • "We killed a feature that wasn't working." (learning)

The feature factory dies when shipping is no longer the goal. Impact is.