Feature Factory
A feature factory measures success by features shipped rather than outcomes achieved, optimizing output over impact. It bloats products and wastes effort. Refocus on outcome-based goals, product discovery, and measuring the impact of every launch.
What It Is
A feature factory is an organization that treats shipping features as the goal in itself. Success is measured by output — how many features were delivered, how full the roadmap is — rather than by outcomes, such as whether users are better served or the business has improved. Teams operate like an assembly line, taking specifications in and pushing features out, rarely pausing to ask whether the last batch actually worked.
The term was popularized by John Cutler to describe product organizations that confuse activity with progress.
Why It Happens
- Output is visible. Shipped features are easy to count and demo; outcomes are slower and harder to measure.
- Roadmap-as-promise. Leadership commits to a list of features, and the team's job becomes delivering the list.
- No discovery. Teams receive solutions to build rather than problems to solve.
- Misaligned incentives. People are rewarded for launches, not for impact.
Why It Hurts
The product bloats with features few people use, increasing complexity, maintenance cost, and user confusion. Enormous effort is spent building things that do not move any meaningful metric. Because nobody measures impact, the organization cannot learn which bets paid off, so it keeps making poor ones. Teams feel busy but disconnected from purpose, and morale suffers when good work has no visible effect.
Warning Signs
- The roadmap is a list of features with no associated outcomes or hypotheses.
- Nobody measures whether shipped features achieved anything.
- Features are launched and never revisited, retired, or evaluated.
- Success is reported as "we shipped X features this quarter."
Better Alternatives
- Outcome-based OKRs. Define success as a change in user or business metrics, not a count of features.
- Product discovery. Validate that a problem is worth solving before building a solution.
- Continuous discovery. Keep a steady cadence of customer contact to test assumptions.
- Minimum viable product. Build the smallest thing that tests the hypothesis, then measure.
How to Refactor Out of It
Shift the unit of work from features to outcomes. For every item, state the hypothesis: what user or business metric do we expect to move, and by how much? Instrument launches so impact is measured, and hold a review after each one. Give teams problems rather than pre-decided solutions, and invest in discovery so effort targets validated needs. Periodically prune features that delivered no value. The objective is an organization that learns from what it ships, not merely one that ships.