The Feature Factory, ten years on: John Cutler revisits his famous essay on feature factories

The content received is a partial version of the article: it cuts off right at the start of the section “AI Amplifies Both Directions.” This summary therefore covers only what appears in the downloaded text and cannot say anything reliable about what the author concludes regarding AI.

John Cutler, author of the newsletter The Beautiful Mess, publishes issue number 445, dated October 15, 2026. It is a retrospective on the piece he wrote ten years ago on Medium about “feature factories.” He recounts that he wrote it in a few minutes to prove to a Medium researcher that more forceful, critical pieces get more traffic than nuanced ones. The piece went viral, reached Hacker News and, according to him, helped him land a job he liked. Since then he has written around a thousand posts. He admits he does not write that way now, but he likes to revisit the topic every few years.

His first thesis is that we all work in a feature factory: someone at the company thinks about the product in terms of what has been shipped. According to Cutler, those people are not stupid. They simply have not seen another way of working, or have not seen it work. He adds that there are other kinds of factories (“a ___ factory”) with equally dominant mindsets. The challenge is knowing what to do about it without losing your sanity.

Second idea: he is tired of “X vs. Y” framings, such as outcomes vs. outputs or projects vs. products. He acknowledges he used them a lot himself. He argues that they present work as binary when almost everything is done at once. He relates an anecdote about a team at a company often cited as a product benchmark. There, they found it very amusing that the rest of the world was stuck in those false tensions. At their company they also used projects, had products and cared about both outputs and outcomes. According to that team, executive pressure to “ship faster” exists everywhere. Cutler criticizes how the idea of moving from projects to products led many companies to call anything a “product,” to over-hire product management roles and to “install” an operating model as if it were plug and play. In his view, this sidelined design and UX and turned platforms and teams lower in the stack into second-class citizens. He also mentions premature convergence, hiring and branding around “new product teams,” and states that many layoffs had to do with that logic. He prefers multi-quarter bets with a real business case, and says the factor many organizations overlooked was the change in funding and governance mechanisms.

On proxies and trust, Cutler argues that features are not the best indicator of progress, but not the worst either. A well-oiled feature factory that delivers reasonably usable things without piling up a mountain of bugs would be a big step forward for some teams. Conversely, he sees teams expert in discovery and frameworks that fail to deliver. He notes they may feel more comfortable in Miro boards, documents and strategy meetings than making hard decisions, and says they reduce uncertainty until they feel one hundred percent comfortable instead of taking the leap. When there is little trust, little familiarity or many dependencies, he says, teams lean on proxies, and features are the most tangible thing they can agree on. He also warns that problem statements, metrics, opportunities and OKRs can be proxies too, an agreed-upon game to cover up the anxiety and fear of working together. He mentions teams that claim to “focus on problems” but never admit they did not solve them, and “promotion-driven development” at supposedly outcome-oriented companies.

In the section on the human side, Cutler acknowledges that the original piece is not well written: it is repetitive and grumpy without depth. Yet many people have told him what they felt when reading it: the sense of being trapped in a machine that does not care about people, or of having your worth reduced to checked-off feature boxes. For him, what is at stake is the desire to have impact, epistemic honesty and respect for the craft. He attributes the problem to ignorance, to disconnected leaders who only want output, and also to the constant challenge of making sense of work and professional identity.

Another central thesis is that it is a spectrum. Every problem is the nested solution to a higher-order problem, and every input is to some degree an output. According to Cutler, you are always a feature factory to some extent, even when running validated experiments. He quotes Greg LeMond, with a twist: “It doesn’t get easier; you just focus on a higher level of abstraction.” Platform teams understand this well. If nobody accepts their causal chain to revenue and costs, he says, they may be better off operating as a feature factory while running parallel experiments and measurements. And he warns that “problem-focus paradise” does not exist: you will always have to justify what you ship and how it contributes to revenue.

From his perspective as a UX researcher and designer, Cutler also criticizes “performative outcome-centricity.” He says so much apparatus of outcomes, goals and jobs to be done can lead to justifying nearly unusable designs propped up by flimsy research. He describes a full circle. On one side there is high-level, vague math, and on the other prompts and specs, with no experimentation, modeling or hands-on work left. If something does appear, it is because someone “built a prototype for fun” and the team responds “OK, ship it,” which in his view is not a prototype. He adds, noting that he may be reacting to the current AI chaos, that PMs incentivized by the “business case” use AI to create “tornadoes of garbage,” because LLMs connect everything in a seemingly realistic way.

Nor does he rule out that features are sometimes the answer. There are situations, especially in domains solved decades ago, where the sensible thing is to make a list of features and deliver them. He cites AppFolio, where he worked, as a good example. They entered a domain with established on-premise software, reverse-engineered property management accounting and at the same time bet on segmentation with fewer features and on new technologies. He wonders where the line is between a long-standing capability and “the feature” of solving it today with AI. He mentions that his former company, Dotwork, was betting that many long-tail features from legacy SPM vendors would become unnecessary or change with AI, and admits he does not know whether that bet will hold up.

On what holds teams back, he lists structural factors: direct access to customers and data, enough autonomy to avoid premature convergence, training (sometimes it really is a skills problem) and the promotion structure. He states that many of these things are not about attitude but about investing money, time and political capital. He calls for moving beyond 0/1 thinking: an “outcome” can be scheduling a short call with a customer, instrumenting a data point or getting a narrative about whether something worked. He criticizes success stories and the “summaries of summaries” from companies that print money, and points out that reality is a continuum of things that go wrong, others that are mediocre and a few successes.

On experimentation and conviction, Cutler argues that any feature adjacent to costs or revenue and with a short experimentation cycle should already be the subject of experiments. But many product challenges do not lend themselves to controlled experiments and require other ways of reducing uncertainty, closer to pseudo-experiments. He defends the role of conviction: data can reinforce it, but over long time scales it is necessary. In his experience, teams that move beyond the factory usually do so out of conviction in their way of working, often after serious past mistakes. He acknowledges that conviction can also drive a product off a cliff.

Finally, he argues that the game starts before the team does. For him, defeating the feature factory begins with the justification for creating the team and with how the game is set up from the outset, including the business case and basic economics. It is very hard to go back and change the game once it is established. Hence the importance of organizational design, beyond boxes and arrows, journey maps and team assignments by JTBD.

The text received ends at the start of the section on how AI amplifies both directions (“apparently factories are all the rage right now. Software facto…”), so it is not possible to summarize that final part or its conclusions.