Feature factories are set by what a team may promise

Ten years ago John Cutler published a list of twelve signs that your product team is a feature factory. It spread everywhere. Most product people can now recite the symptoms: success measured by what shipped, roadmaps full of dated features, nobody asking whether anything worked.

So why does your team still look like that?

Cutler asked himself the same thing. On October 16 he published a retrospective, drawing on hundreds of teams he has met at Amplitude, the product analytics company where he works. His answer undercuts the way most of us were taught to think about it. Features, he says, are a shared proxy. When trust is low, people don’t know each other, or dependencies are heavy, a list of shipped things is easier to agree on than a hypothesis that might fail. “Features are as good as you are going to get.”

He goes further. Outcome language can become the same kind of proxy. Problem statements, metrics and OKRs, the goal-setting framework, can let a team avoid admitting that a metric never moved. And the whole thing is a spectrum. Any work tied to revenue or cost will get challenged on what it ships, so no team fully escapes.

Four days earlier, Marty Cagan of SVPG, the product consultancy, made a related move. His October 12 piece says the real trade-off is not outputs against outcomes, since outcomes need output. It is outcomes against predictability. Many companies implicitly rank predictability first, put untested ideas on dated roadmaps, and treat outcomes as a hoped-for side effect of delivering what they promised. Output becomes the default measure of progress. Cagan offers no data, only the argument and Henrik Kniberg’s line that “100% predictability = 0% innovation.”

Teams behave like feature factories when their funding and trust structure makes shipped features the only safe thing to promise. The label on the team matters much less.

That cuts against how I have been holding this. My working position, built partly on Cagan’s August remarks, is that feature-factory teams and empowered teams are different operating models so far apart that a PM in one is doing a different job from a PM in the other. Cagan said feature-factory PMs are “not product managers at all.” The framing is useful. It tells you to diagnose the model before you define the role.

But the person who coined the term now says there are no two boxes. He calls the outputs-versus-outcomes split and the projects-versus-products split false tensions, and says leaning on them led companies to over-hire PMs and force teams together too early. He ties that to layoffs. That causal claim is his, and I can’t verify it.

The steelman for the boxes is fair. Ideal types are useful even if real teams are mixed. If you tell a new VP “you run a feature factory,” they know what to look for. Cutler’s retrospective doesn’t refute that. It does say the label hides the lever. What he points to instead is structural: whether the team has access to customers and data, what autonomy it has, what training it got, how promotions are decided, and how it was funded and justified at the start. “The game is set at formation,” in his words. Some of these fixes cost real money, such as data infrastructure, enough designers, and HR work on promotion criteria.

Neither writer offers numbers, so treat all of this as two experienced people pattern-matching. But they converge from different directions. Cagan names a priority: what the company will sacrifice when outcomes and promises collide. Cutler names a structure: what the team is rewarded and funded for before it ever writes a problem statement. Both point to the same place, upstream of the team’s mindset.

For you, this changes the question you bring to your next planning cycle. Asking “are we empowered or are we a factory?” invites everyone to defend their self-image. Asking “what are we allowed to promise, and to whom?” gets at the mechanism. How many of your roadmap items carry a date? Who set it? What happens to a team that hits its outcome without shipping the planned feature?

Cutler also warns that AI amplifies whatever habit is already there. It helps with instrumentation and prototyping, but it also produces polished PRDs and synthetic personas that stand in for talking to customers. A factory with a language model is a faster factory that sounds more convincing.

I don’t know yet whether the role of the PM changes at a threshold or continuously as a team slides along the spectrum. That is the question worth testing. Pick a few observable signals: how long your funding cycles run, what share of work carries a dated commitment, what your promotion criteria reward. Then check which one best predicts where a team really sits. If you find one, you’ll know what to change before you rename anything.