How to Stop Being a Feature Factory When AI Makes Features Cheap to Build

In 1931, a young Procter & Gamble manager named Neil McElroy wrote a three-page memo proposing a new job he called the "brand man." Each brand would get one person responsible for it as a business. That person would study its history, go into the weak territories to find out what was wrong, build a plan, and then "follow through to the very finish" to see whether the plan produced results. That memo is the closest thing product management has to a birth certificate, and the job it describes is ownership of something that already exists.

How product management easily drifts into a feature factory

Somewhere along the way, software product management drifted toward what's next: roadmaps, launches, the next big bet. John Cutler described the "feature factory" in 2016, and most product leaders I talk to recognize their own org in it. The pull toward shiny new things isn't a character flaw in PMs. It comes from incentives. Launches get announced, celebrated, and cited in promotion packets. Keeping an existing feature healthy is invisible when it works and only noticed when it breaks.

AI made the feature factory cheaper to run

AI throws fuel on that. When building the next feature costs a fraction of what it used to, product teams ship more of them, and every AI-empowered roadmap I see is longer than it was a year ago. But the true cost of software was never the build. Research going back to Lientz and Swanson in 1980 puts most of a system's lifetime cost after release. Every feature that ships becomes something someone has to monitor, scale, support, justify in the next budget cycle, collect feedback on, and eventually decide whether to kill.

Picture a product team that ships an AI summary feature in a week. Six months later, someone has to know whether customers actually use it, why its model costs keep climbing, what to tell the enterprise accounts sales promised it to, and whether it's safe to turn off. None of those questions existed during the week it took to build.

Every free feature is a free puppy

Engineering has its own version of this problem in code comprehension, which I call “ comprehension debt.”  The one I'm worried about here belongs to the product owner. Open source developers have long compared free software to a free puppy. The shelter doesn't charge you anything, and you still sign up for fifteen years of food, walks, and vet bills. AI made new features free in the same way. A product team shipping at today's pace brings home a few new ones every week, and each one needs someone watching its usage, answering for its results, and deciding what it needs next. One person can only look after so many before some of them stop getting walked.

Amazon worked out a version of this years ago with its single-threaded leader model, where one person owns one initiative with no competing responsibilities. Dave Limp's line on it: "The best way to fail at inventing something is by making it somebody's part-time job." The inverse holds for everything already shipped. The surest way to let a feature rot is to make it one of forty things someone nominally owns.

CTA

Two costs falling at very different rates

The fix starts with what product teams weigh when deciding what to build. AI is driving the cost of getting the next feature out the door toward zero. It's helping with maintenance too, but the costs that come after launch fall far more slowly, because so much of that work runs through people: watching how customers use a feature, answering for its results, handling what sales promised, and deciding when to retire it. Those two costs are falling at very different rates, and a team that only looks at the first one will keep saying yes.

Ownership is the way out of the feature factory

Product teams that stay accountable for everything they've already shipped make better decisions about what to ship next. When the person approving a new feature knows they'll be the one monitoring it, defending it at budget time, and eventually deciding whether to shut it down, they ask harder questions before it gets built. They add fewer things, and the things they add are ones they're prepared to run. That discipline pulls product management back toward McElroy's version of the job: owning a line of business, with the results that come with it.

The product teams that do well with AI will ask, before every launch, whether someone has the capacity to take care of the thing for the next several years. The ones optimizing for launch count will end up with more features than anyone can look after, and a product nobody is actually running.

If you want to make sure what you’re building is the right thing, with the right measurements in place from the requirement through release, start using Product Studio today.‍

References

• Neil McElroy, "brand men" memo, Procter & Gamble, May 13, 1931, via Ken Norton, "Product Management Was Born in 1931 (Maybe, Sort Of)"
• John Cutler, "12 Signs You're Working in a Feature Factory," November 2016
• Lientz & Swanson, Software Maintenance Management, 1980
• Jeff Dyer & Hal Gregersen, "How Does Amazon Stay at Day One?", Forbes, August 2017 (Limp quote)

Frequently asked questions

What is a feature factory?

A feature factory is a product and engineering organization that repeatedly ships new features in products without measuring and evaluating if the features are worth building or keeping. John Cutler named the pattern in 2016. The usual cause is incentives. Launches get celebrated and cited in promotion packets, while keeping an existing feature healthy goes unnoticed until it breaks.

Why does AI make the feature factory problem worse?

AI lowers the cost of building a feature much faster than it lowers the cost of owning one. Teams ship more features because each one is cheaper to build, and each feature still needs someone to monitor its usage, answer for its results, handle what sales promised, and decide when to retire it. Most of that work runs through people, so it doesn't get cheaper at the same rate.

How much of a feature's cost comes after launch?

Most of the feature cost comes after the launch, especially now with AI. Ideas are cheap, AI development is cheap and fast, but the ongoing upkeep is not. Research going back to Lientz and Swanson's 1980 study of 487 data processing organizations puts the majority of a system's lifetime cost after release. After launch, a feature has to be monitored, scaled, supported, justified in budget cycles, improved from feedback, and eventually either kept or shut down.

What is a single-threaded leader?

A single-threaded leader is Amazon's term for one person who owns one initiative with no competing responsibilities. Dave Limp's summary of the idea is "The best way to fail at inventing something is by making it somebody's part-time job." The same logic applies to shipped features. A feature that is one of forty things someone nominally owns is a feature nobody is running.

How do product teams avoid becoming a feature factory?

Keep the people who approve new features accountable for the ones already shipped. Before every launch, ask whether someone has the capacity to take care of the feature for the next several years. Teams that work this way add fewer features and are prepared to run the ones they add. For how that changes team shape, see rethinking the PM-to-engineer ratio for the AI era.

Jeremy Freeman is Co-Founder and CTO of Allstacks, where he works on how product and engineering teams build and run software as AI changes the cost of both.

Decide what to build with the context to own it. Allstacks Product Studio is a context-aware workspace for AI spec development, grounded in the engineering data your teams already produce. See Product Studio.