Stop Building Features Nobody Asked For

The graveyard of failed products is full of brilliant engineering. Every week, teams ship features that nobody wanted, built with technologies that impressed no one, solving problems that didn't exist.

The Feature Factory Trap

It starts innocently enough. Someone suggests a new feature. The team discusses it. Engineering estimates the work. Product adds it to the backlog. Sprint after sprint, features pile up like cordwood.

But here's the uncomfortable truth: most features are built for the builder, not the user.

"Users will love this" — they won't. "It'll be easy to add" — it won't. "What could go wrong?" — a lot.

The Question Nobody Asks

Before building anything, ask this: "What user problem does this solve?"

Not "what problem could this feature solve if users happen to use it exactly as we imagined?"

Not "what technical challenge would this address?"

What. Real. Problem. Does. This. Solve.

If you can't answer in one sentence, don't build it.

What Actually Matters

Problems users know they have. Not problems you think they have. Talk to users. Actually listen. The best product ideas come from watching people struggle, not from brainstorming sessions.

Outcomes over outputs. Don't measure yourself by features shipped. Measure by problems solved. Did your users actually achieve what they needed?

Less is more. Every feature is a liability. It needs documentation, testing, maintenance, support. The best code is often the code you don't write.

The Pivot

We had a feature that took three months to build. Sophisticated. Elegant. Technically impressive.

Zero users.

We spent another month figuring out why. Turns out, we solved a problem that only existed in our heads. The users had already found a simpler workaround that we hadn't considered because we were too busy building.

Now, before any feature, we ask: "What's the simplest way to solve this?" Sometimes it's a spreadsheet. Sometimes it's an email. Sometimes it's telling users to do it manually.

We still write code. But we write a lot less of it.