Build what users need, not what they want
I was at a hackathon last week. Out of 12 teams, only one truly got something the others missed.
Most teams built what users said they wanted. The winning team built what they needed.
The difference? The first group impressed during the demo. The second solved a real problem.
The “that would be so cool” trap
When you ask a user what they want in your app, they’ll say things like:
- “Dark mode”
- “A gamification system with badges”
- “Social features — follow friends”
- “AI everywhere”
These are desires. Not needs.
The need is what the user can’t articulate. It’s the problem they face every day and have stopped trying to solve because they think “that’s just how it is.”
Steve Jobs said it: “People don’t know what they want until you show it to them.” Henry Ford, in a quote often attributed to him (though probably apocryphal): “If I had asked people what they wanted, they would have said a faster horse.”
The point isn’t to ignore users. It’s to understand that their request is a symptom — not the diagnosis.
Showcase features vs retention features
I learned this distinction building BeeDone, my gamified productivity app.
Showcase features are what make someone download your app. The App Store screenshot. The demo that impresses. The pitch that gets a “wow.”
Retention features are what make someone come back tomorrow. And the day after. And in 3 months.
The problem: they’re almost never the same features.
| Showcase features | Retention features | |
|---|---|---|
| Goal | Acquisition — drive downloads | Retention — drive return visits |
| Example | Badges, leaderboards, visual themes | Smart reminders, reliable sync, fast loading |
| Feeling | ”So cool!" | "It just works.” |
| Lifespan | 3 days | 3 months+ |
| Visibility | High (screenshots, demos) | Low (invisible when working) |
According to a Pendo study, 80% of features in a product are rarely or never used. Most of these unused features are showcase features. They served to convince, not to retain.
The hackathon winner
Back to that hackathon.
The theme was mental health at work. Most teams built dashboards with mood charts, AI wellness chatbots, gamified meditation systems.
Shiny. Impressive. Exactly what people say they want.
The winning team built something simple: a tool that detects when you’re chaining meetings without breaks and automatically blocks 15 minutes in your calendar.
Not sexy. No charts. No conversational AI.
But it solved a real problem everyone in the room experienced without articulating it: the absence of breaks between meetings.
The need was there. Nobody had asked for it.
How to identify the real need
The question isn’t “What do you want?” but “What frustrates you?”
Here are the 3 approaches that work for me:
1. Observe, don’t ask
Watch how people use your app (or your competitors’). Where do they drop off? What do they work around? Which tasks take 5 steps when they should take 2?
Analytics don’t lie. If 80% of your users never open the “Stats” tab, it’s not a discoverability problem — the feature doesn’t solve anything.
2. Listen to complaints, not suggestions
Suggestions are solutions in disguise: “Add offline mode.” The complaint behind it: “I lost my data on the subway.” The need is reliable sync — not necessarily offline mode as the user imagines it.
3. The week 2 test
If a user doesn’t use your feature after 2 weeks, they probably never will. Focus on features people use at D+14, not the ones that impress them at D+1.
The nuance: you need both
I’m not saying ignore showcase features. You need them to sell. The App Store is a visual marketplace — if your app looks boring, nobody downloads it.
The strategy is:
- A few showcase features for acquisition (2-3 max)
- Most of the work on retention features that solve the real problem
- Measure D+7, D+14, D+30 retention — not just downloads
Apps that succeed long-term have figured this out. They sell the desire, but deliver the need.
How I apply this now
On every new project, before coding anything, I ask myself 3 questions:
- Does this feature drive downloads or drive return visits? If it’s “downloads,” I keep it minimal.
- If I remove this feature, does the app still solve the core problem? If yes, it’s nice-to-have.
- Would the user notice if this feature disappeared? If not, it’s not worth the dev time.
It’s brutal. But it’s what makes the difference between an app with 10,000 downloads and 200 active users, and an app with 2,000 downloads and 1,500 active users.
The takeaway
Next time a user tells you “I wish the app could do X,” don’t build X.
Ask yourself: why do they want X? What problem are they trying to solve? And is the solution really X — or something completely different they can’t articulate?
Build the need. The desire is just the packaging.