What is a feature factory?

A feature factory is a team that measures success by how much it ships, features launched and story points closed, instead of by what actually changes in the user. John Cutler popularized the term in 2016, and by his own account he picked it up from a developer friend who felt he was just cranking out features and sending them down the line.

The tell is subtle: a feature factory usually looks productive. It ships fast, keeps velocity high, and has a visible record of finished work. It has optimized the activity of building, not the result of building.

Warning signs you’re in one

• Success is measured in output (releases, points, features), not in behavior change or business outcomes.
• Features get added because a competitor has them, a big customer asked, or someone said “it’d be nice to have,” each with its own local logic and no target behavior behind it.
• Nobody can answer “what new behavior did we install this quarter?”
• The roadmap grows. The reason for any single user to stay doesn’t.
• Discovery exists as a slide deck from last quarter, not as decisions that change what gets built this week.
• Demo day shows features working. It never shows a user doing something they couldn’t do before.

Why teams fall into it

Not on purpose. Productizing produces immediate signals of progress, demos, changelogs, meetings where you show something new, while changing behavior is invisible for months. Almost no organization rewards the invisible. It rewards activity. And adding surface is activity.

What it costs

Roughly 80% of the features in average software are used rarely or never, and only about 12% drives most of the daily use (Pendo. The Standish Chaos report puts it near 64%, methodologies debatable, direction consistent). That’s surface that exists without changing anything, plus the growing team needed to maintain it. It’s not free. Every living line carries a cost every day, used or not.

What replaces output metrics

The way out is not to stop measuring. It is to change what counts as the score. A team starts leaving the factory when its default questions change.

Three replacements do most of the work:

• “Did we ship it?” becomes “who does something different since we shipped it?” Every item on the roadmap carries a target behavior, or it doesn’t get on.
• Velocity becomes time to evidence, how long the team takes to learn whether a bet worked. A factory can ship weekly and learn nothing for a year.
• Features launched becomes decisions recorded with the evidence behind them, so the next bet starts from what the last one taught instead of from zero.

Output still gets measured. It just stops being the score, the way lines of code got measured long after everyone stopped treating them as productivity.

Coding agents turned the dial up

Everything above predates AI coding tools. What changed is the price of surface.

When a feature cost three sprints, the factory had a natural brake. Someone had to defend that cost, so at least some bad ideas died in estimation. With agents, the build that took a month takes days, and the brake is gone. Output was always a proxy for progress. Now it is a proxy anyone can inflate at will, which finishes it as a measure of anything.

The same speed cuts the other way too. Cheap building means cheap experiments for the team that runs them against an explicit assumption and reads the result. The factory and the product team now use identical tools and ship at similar rates. The difference is no longer visible in the changelog. It is only visible in what each team counts, and in whether anyone can trace a shipped feature back to the behavior it was supposed to install.

The one test that gets you out

Before anything goes on the roadmap, complete this sentence:

Thanks to this, [type of user] will go from doing [X] to doing [Y], and we’ll know it when we see [metric Z].

If you can’t fill it in, you have a feature idea, not a product idea. Making product is installing a behavior, not accumulating surface. That distinction is the difference between a moat and attention debt, and in the AI era, when copying a feature costs an afternoon, it’s the only one that matters.

FAQ

Where does the term “feature factory” come from? John Cutler popularized it in 2016. By his own telling, a developer friend complained about sitting in the factory cranking out features, and the name stuck.

Is shipping features always bad? No. Sometimes productizing is the right call, reaching parity, keeping a customer, buying time. The problem is doing it on autopilot, without knowing it.

How is this related to AI coding? AI makes generating features nearly free, which accelerates the feature factory unless intent and verification sit upstream. The discipline that counters it is the same idea applied one level down: a green build is not a correct feature.

Which metrics does a product team use instead? Behavior change per bet (the from-X-to-Y sentence, observed in a named metric), time to evidence per decision, and the share of shipped work that traces back to a recorded decision. Output is still tracked. It is no longer the score.