The 3-Month Mistake
We built a feature based on user requests. 3 months of development.
Usage after launch: 2%.
Nobody wanted it. They just thought it sounded nice.
Here's how to avoid that.
The Problem with Requests
Users ask for solutions, not problems.
"Add a calendar view" is a solution. The problem might be "I can't see my schedule clearly."
Ask "why" five times. Get to the root problem.
The Research Methods
1. Contextual Inquiry
Watch users do their actual work.
Not interviews. Not surveys. Observation.
You see what they actually do, not what they say they do.
2. Five Whys
Ask "why" repeatedly to find root causes.
Why do they need this feature? "To track tasks." Why do they need to track tasks? "To remember what to do." Why don't they remember? "I have too many things to track."
The real problem: cognitive overload, not missing features.
3. Jobs to Be Done
What job is the user hiring your product to do?
Not demographic. Not psychographic. Job-to-be-done.
The Framework
Before Every Feature
- Who has this problem?
- How do they solve it today?
- What would a perfect solution do?
- How often does this problem occur?
- What's the cost of not solving it?
The Honest Take
Building features without research is gambling.
Research isn't expensive. Building wrong features is.
