Feature Factory: When Output Replaces Outcomes

TL;DR: A feature factory ships constantly and learns nothing. Output is celebrated at the moment of release, outcomes are never checked, and the roadmap is a conveyor belt that only moves forward - no iteration, no removal, no questions. It feels productive from the inside because everyone is genuinely busy. It is expensive from the outside because every unvalidated feature is inventory: built at full payroll cost, generating maintenance rent forever, and cashing in exactly nothing until someone checks whether it worked. Here is where the term comes from, what it costs, how to spot it in your own delivery data, and the way out.

What is a feature factory?

The term comes from John Cutler's 2016 essay "12 Signs You're Working in a Feature Factory", which needed no statistics to go permanent: just a list of tells that half the industry recognized as their own org chart. Among the signs Cutler names: "no measurement" of impact after shipping, "success theater around 'shipping'", "no connection to core metrics", "rapid shuffling of teams and projects" (his "Team Tetris"), "no PM retrospectives", and "no tweaking", meaning features launch and are never revisited.

Read that list closely and notice what it is not. Nobody is accused of working too little. Feature factories are usually full of hard-working people shipping at a genuinely impressive clip. The diagnosis is structural: the org's definition of success stops at the release announcement, so the feedback loop that would turn shipping into learning simply does not exist. Roast the system, not the people on the conveyor belt - they didn't design it.

The economics: a feature is a cost until an outcome cashes it

Strip the culture critique away and the feature factory is an accounting error. Every feature is built at fully loaded payroll cost and then - win or lose - starts charging rent: code to maintain, surface area to secure, complexity that slows every future change. The maintenance burden is not hypothetical; Stripe's Developer Coefficient survey found developers reporting 17.3 hours of a 41.1-hour week going to maintenance-class work (Stripe, 2018). Every shipped feature buys a slice of that forever.

The return side of the ledger only fills in when someone measures the outcome, and the feature factory's defining move is to never fill in the return column at all. So the org literally cannot distinguish its wins from its waste. It can only add inventory.

In any other department, spending at full cost while refusing to record returns would be a scandal. In engineering economics terms, the feature factory converts payroll into unvalidated surface area at maximum speed, and calls the speed the win.

The research consensus points the same direction from the other side. The Accelerate research found that high-performing delivery organizations were twice as likely to exceed their profitability, market-share, and productivity goals (Forsgren, Humble & Kim, 2018). But that finding is about capability paired with learning, not raw output. The SPACE framework exists precisely because productivity "cannot be measured by a single metric or dimension" (Forsgren et al., 2021), and "features shipped per quarter" is the single-metric fallacy with a party hat on.

Feature factory signs in your delivery data

Cutler's twelve signs are cultural; most leave fingerprints in the ticket and git history you already have. Four checks, one afternoon:

• The iteration ratio. What share of shipped features ever received a follow-up change driven by usage (a tweak, a v2, a measured improvement)? In a learning org the answer is routine; in a factory the history shows release, silence, next feature. This is Cutler's "no tweaking," made queryable.
• The allocation mix. If the completed work is overwhelmingly new capability with token capacity for improvement, validation, or keeping the estate alive, the roadmap is a conveyor belt by construction. A factory's allocation chart is a monoculture.
• The definition of success. Where does your org announce victory: in the release notes, or in a follow-up with numbers? Check the last ten feature announcements for any reference to what the feature was supposed to change and whether anyone came back to report it. Silence there is "success theater" with a paper trail. Your delivery metrics can be elite while this loop is entirely missing. Speed and learning are different axes, which is exactly why DORA-style speed metrics alone can mislead.
• The graveyard that isn't. Count features removed or sunset in the last year. A factory never deletes anything - removal produces no shipping announcement - so complexity only compounds, and the rework and maintenance share creep up while nobody can say why.

One caution while you check: every one of these signals describes the system's feedback loop, not any team's effort. The moment these become per-team scoreboards, you have built a second factory to measure the first.

Escaping the feature factory

The escape is not "ship less." It is "close the loop." Four moves, biggest payoff first:

1. Attach a question to everything that ships. Before a feature starts, one sentence: what should this change, and how will we know? Cutler's "no connection to core metrics" dies here. A feature that cannot state its question is a request wearing a roadmap costume, and now is the cheapest possible moment to find out.
2. Budget the loop explicitly. Reserve real capacity for post-release measurement, iteration, and removal, with the same explicit-allocation discipline as any honest engineering budget. If iteration capacity is zero, "we'll revisit it later" is a lie the roadmap tells itself every quarter.
3. Report outcomes where releases get reported. Whatever channel announces shipping, announce results there too - including the honest misses. The first "this feature did not move the number, we're removing it" announcement is worth ten process documents: it tells the org that learning, not theater, is the product. That psychological shift is also what makes developer-experience investment legible - engineers do their best work when they can see whether it mattered.
4. Prune. Schedule an annual review of features against usage, and sunset the bottom honestly. Removal is the only move that pays negative rent: it is shipping for the maintenance budget.

The door

Run the afternoon audit: iteration ratio, allocation mix, last ten announcements, features removed this year. If three of the four come back factory-shaped, don't convene a working group. Just attach a question to the very next feature that starts, and report its answer where the release was announced. One closed loop, visibly completed, is the whole escape route in miniature; the rest is repetition. Factories are not dismantled by manifestos. They are dismantled by the first team that checks whether the thing they shipped actually worked - out loud, with receipts, either way.