How to escape the Feature Factory (85% of features are useless)

85%. Only 10-15% of features produce measurable improvements. The rest? No effect, or worse, negative effect.

This isn't an opinion — it's a study by Microsoft and Google on thousands of shipped features. Most of what you build serves no purpose.

And you're paying to do it.

The data comes from a study by Ronny Kohavi (ex Microsoft, ex Amazon) on thousands of features tested with controlled experiments. On Bing, only 10-15% of features produced statistically significant improvements in the target metric. A third had no measurable effect. And a third made things worse. Google has confirmed similar numbers internally.

Now think about your company. If even just 50% of what you produce generates no value — how many hours, how much money, how many people are you dedicating to things that don't matter? For a €2M SME with 3 developers, 50% waste is equivalent to roughly €150K/year in salaries burned on features nobody will ever use.

The term "Feature Factory" was coined by John Cutler in 2016, in a post that went viral in the product community. Cutler, then a product evangelist at Pendo, identified 12 signs that indicate whether your company is a Feature Factory:

1. No measurement of success after launch
2. No connection between features and business outcomes
3. Heavy project management but zero product management
4. "Success theater" — shipping is the success, nobody asks if it worked
5. Roadmaps are lists of features, not lists of problems to solve
6. Teams have no direct contact with users
7. Decisions are made by stakeholders far from the product
8. The backlog grows faster than the team can deliver
9. No team has the power to say "no" to a requested feature
10. Retrospectives are about process, never about impact
11. Designers are "pixel pushers" — they receive specs, not problems
12. Release velocity is the only metric that matters

How many of these do you recognize in your company? If the answer is more than 4, you're in a Feature Factory.

Marty Cagan, founder of the Silicon Valley Product Group and author of "Inspired" and "Empowered," drew a fundamental distinction that clarifies the problem: Feature Team vs Empowered Team.

Feature Teams receive a list of things to build. They execute. They don't ask why. They don't measure impact. Success is delivery — did you ship? Good. Did it work? Not your job.

Empowered Teams receive a problem to solve and a success metric. How they solve it is their responsibility. Success isn't delivery — it's the outcome. You built something that didn't move the metric? That's not a success. It's a failed experiment to learn from.

The difference isn't in the people. It's in the system. The same people, on a Feature Team, produce useless features. On an Empowered Team, they solve real problems. Like in Toyota's NUMMI case: it wasn't the people who were broken — it was the system.

Henry Ford, 1913. The assembly line reduces Model T production time from 12 hours to 93 minutes. Industrial revolution.

The principle: more output = more value. Every unit produced creates value.

We applied it to software, services, digital products. More features = more product = more value. Wrong.

In a factory, every piece has value. In software and services, features confuse users, slow down the product, never get used. You're paying to sabotage yourself. It's the same mistake as copying Toyota's tools without the thinking system.

Melissa Perri in her book "Escaping the Build Trap" (2018) gave a name to this pathology: the Build Trap. Companies fall into the trap when they measure success by output (how many things we produced) instead of outcome (what impact they had). The Build Trap is insidious because it looks like productivity — the team is busy, releases are frequent, the roadmap is progressing. But value for the customer isn't growing.

The paradox: the more features you add to a digital product, the worse it gets. Every feature is a tradeoff — screen space, user attention, code complexity. As Antoine de Saint-Exupery said: "Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away."

Every feature you add has a visible cost — development hours, design, testing. But the real cost is the invisible one.

Martin Fowler, chief scientist at ThoughtWorks, formalized the concept of Technical Debt. Every feature added creates "interest" you pay forever:

• Cognitive load for users: every additional option makes the product harder to use. Hick's Law: decision time increases logarithmically with the number of choices. 10 options instead of 3 aren't "better" — they're paralysis.
• Maintenance for developers: every feature must be maintained, updated, tested with every new release. An app with 100 features requires 10x the maintenance work of one with 10.
• Test surface: every new feature interacts with all others. Combinations grow exponentially. With 50 features, possible interactions number in the thousands.
• Documentation and support: every feature generates tickets, questions, tutorials, FAQs. Support costs grow linearly (or worse) with features.

The most famous cases of feature removal as a growth strategy:

Instagram in 2020 removed the IGTV tab from the home screen, simplifying navigation. Engagement on the platform increased. Fewer options, more focus, more time spent.

Apple in 2016 removed the headphone jack from the iPhone 7. The world went crazy. Sales were unaffected. Apple simplified the internal design, improved water resistance, and created a billion-dollar market (AirPods) — all by removing a feature.

Basecamp (formerly 37signals) is the most radical example: Jason Fried and David Heinemeier Hansson built a company worth hundreds of millions by systematically refusing to add features customers were requesting. Their book "Getting Real" is a manifesto against the Feature Factory: "Build half a product, not a half-assed product."

The question isn't "is this feature useful?" — the question is "is this feature more useful than everything I have to give up to build and maintain it?" Almost always, the answer is no.

Insight

Every feature has a hidden cost: cognitive load, maintenance, testing, documentation. Sometimes removing a feature creates more value than adding one.

2006. Netflix has a retention problem with DVDs. People sign up and then vanish.

They discovered that the number of DVDs added to the queue in the first session predicted retention. Those who added many DVDs came back. Those who added few vanished.

They optimized that single moment. Retention exploded.

They didn't add features. They didn't improve the catalog. They found the moment that mattered and made it inevitable. Exactly like Facebook's 7 friends: one number, one constraint, exponential results.

Slack did the same. Stewart Butterfield discovered that teams that sent 2,000+ messages in the first 30 days had a trial-to-paid conversion rate of 93%. Teams under 500 messages? Virtually zero. The metric that predicted everything wasn't a feature — it was a behavior. Slack redesigned onboarding to maximize initial messages, not to showcase features.

This principle is called the North Star Metric — the single metric that predicts long-term success. For Spotify it's listening time. For Airbnb it's nights booked. For your company, what is it? If you don't know, you're building features blindly.

Insight

Netflix didn't improve the product by adding features. It found the single moment that predicted retention — and made that experience unmissable.

If the Feature Factory is the problem, controlled experimentation is the solution. And nobody does it better than Microsoft.

Microsoft's ExP (Experimentation Platform) runs over 30,000 controlled experiments per year. Every change to Bing, Office, Teams, Azure is tested on a sample before being released to everyone. Ronny Kohavi, former VP at Microsoft and author of "Trustworthy Online Controlled Experiments", estimated that ExP generates hundreds of millions of dollars in annual value — not by building more, but by building better.

A concrete example: in 2012, a Bing engineer proposed a change in how ad titles were displayed. Seemed trivial. The A/B test revealed an impact of +$100 million in annual revenue. Without the test, that change would have been in queue behind 50 "more important" features according to stakeholders.

Booking.com takes this principle to the extreme: every employee can launch an experiment without asking permission. The company runs thousands of tests simultaneously. The CEO declared that 90% of experiments fail — and that's the point. The 10% that work generate billions.

For SMEs, you don't need enterprise platforms. You need three principles:

1. Every feature is a hypothesis. Not "let's build X." But "we believe X will improve metric Y by Z%." If you can't formulate the hypothesis, don't build the feature.
2. The success metric is defined BEFORE launch, not after. 90% of companies define success retroactively — cherry-picking the metric that improved. That's not experimentation. That's confirmation bias.
3. Minimum Viable Test (MVT). What's the smallest thing you can build to test the hypothesis? Not the complete product — the cheapest version that gives you real data. A clickable mockup. A landing page. A manual test with 10 customers. Like in Zara's model: small batches, real data, scale only the winners.

The practical framework for an SME: before the next release, write on a sheet of paper: "If we launch [feature], we expect [metric] to improve by [X%] within [timeframe]." If you can't fill in this sentence, you're not ready to build. You're ready to understand the problem better.

Data

Microsoft runs 30,000+ controlled experiments per year. 90% fail. The 10% that work generate hundreds of millions. — Ronny Kohavi, "Trustworthy Online Controlled Experiments"

The solution isn't "produce less." It's "produce with knowledge."

The factory produces. The scientist experiments.

The difference: every feature, every service, every initiative starts with a hypothesis and a success metric defined before launch. Not after.

Ford invented the factory. But you don't build cars. And in your industry, the factory isn't enough. You need the laboratory. Like Zara launching 12,000 products: small batches, real feedback, scale the winners.

The laboratory template in 4 lines:

1. Hypothesis: "We believe that [change X] will produce [result Y] for [segment Z]."
2. Metric: "We'll measure it through [specific metric] within [timeframe]."
3. Threshold: "We consider success an improvement of at least [X%]."
4. Kill criteria: "If after [timeframe] the metric hasn't improved by [X%], we eliminate the feature."

The kill criteria is the hardest part. Nobody wants to eliminate something they built. But without the discipline to kill features that don't work, the product becomes a graveyard of good intentions. And every dead-but-not-removed feature consumes resources — forever.