Stop Building What Users Ask For. Try This Instead.

You know the feeling. You’re sitting in another sprint planning meeting, watching a stakeholder passionately demand a new feature. ‘The users need custom reporting!’ they say. Your heart sinks. You look at your engineering team’s exhausted faces. You know that building this barnacle will drain your velocity for the next month.

Saying ‘yes’ to every user request isn’t customer service; it’s a slow suicide.

We’ve been sold a lie that the customer is always right. In product development, the customer is usually myopic. They ask for solutions to symptoms, not cures for the disease. When you build everything they ask for, you don’t get a better product. You get a bloated, sluggish Frankenstein.

I saw this firsthand in a SaaS company I advised. The sales team demanded a ‘custom dashboard’ because a massive enterprise client threatened to churn. The engineering team spent six weeks building it. The client used it twice. The real problem? The core API was too slow. They didn’t need a new dashboard; they needed the existing product to actually work.

The feature they are screaming for today is the bug they will complain about tomorrow.

It’s time to stop treating your engineering team like a short-order kitchen. ‘Featuritis’ is the silent killer of great software. Every time you tack on a requested feature, you are diluting the core value of your product. You are stealing time from the developers to maintain the very thing that made your product great in the first place.

As an engineering leader, your highest form of customer service is the word ‘No.’ When a stakeholder demands a new feature, you have to be the one to step in front of the train. Ask them ‘why’ five times. Unpack the actual problem. If they just want a hypnogram because everyone else in the sleep-tracking space has one, push back. Destroy the barnacles before they attach.

Your product’s value isn’t found in what it can do. It’s found in what it refuses to do.

The next time you’re in that planning meeting, don’t look at what you can add. Look at what you can cut. The best way to launch is to strip it down to its absolute essence. Defend your engineers. Protect your velocity. Build what they need, not what they asked for.

FAQ

Q: If I say no to features, won't my users leave for a competitor who says yes?

A: Users don't churn because of missing features; they churn because your core product sucks. If you spend all your time building barnacles, your core rots. Focus on what makes you unbeatable, not what makes you identical to everyone else.

Q: How do I actually tell stakeholders 'no' without getting fired?

A: Don't say no to their face. Say 'why.' Force them to justify the request five levels deep. Usually, the request masks a deeper frustration. Solve the root cause, and the feature request evaporates.

Q: Isn't the customer always right?

A: In product strategy, the customer is usually a terrible architect. They know their pain points, but they are terrible at prescribing the cure. Treat them as a diagnostician, not an engineer.

📎 Source: View Source