Four sources of needs
Where a need comes from determines how it should be validated. Drop the source and the backlog turns into a list no one dares delete.
Where a need comes from determines how it should be validated. Drop the source and the backlog turns into a list no one dares delete. Each of the four sources has its own credibility — and its own trap.
What you'll run into:
- The backlog holds dozens of items and you don't know which matter or dare to delete any
- You build something and realize it was one person's passing remark, not most users' need
- You follow whatever the competitor ships, and can't explain why afterward
How to use the four sources
| Source | What it tells you | First thing to do after getting it |
|---|---|---|
| User feedback | Someone is stuck, and at which step | Ask what they were doing at the time. Don't rush to discuss their proposed solution |
| Business goals | What the company wants this quarter | Translate it into user value. If it can't be translated, it won't keep users |
| Data anomalies | Which step dropped harder than usual | First rule out instrumentation or definition issues, then look at the behavior |
| Competitor moves | Which direction others bet on | Figure out whether their users and yours are the same group; if not, don't follow |
Credibility roughly runs: data > observed user behavior > what users say > competitors. But the credible end usually tells you where the problem is, not why. Data says "step two loses 62%" — it doesn't say where the user got stuck; you need to ask a few of them for the why. What users say is even less reliable: people polish their own behavior and nod along with your questions.nng-first-rule No single source is enough on its own — use them together.
Carrying the source also makes "why" auditable. Every backlog item is anchored to a fact, so debates go back to that fact instead of competing memories.
The trap in each source
The four traps share one shape: grabbing one piece of information and jumping straight to a solution, skipping the "why" in between.
- The user feedback trap. The people who give feedback are the most active 1%, and their requests often run opposite to the majority. Treating power users' preferences as everyone's need is a mistake.
- The data trap. Conversion dropped 8% — could be the redesign, could be a new acquisition channel. Concluding from the number without a comparison is a mistake.
- The business goal trap. This quarter needs higher paid conversion, so you narrow the free features. Short-term numbers hit, long-term users churn.
- The competitor trap. They shipped an AI assistant, so you do too. You copied the feature but not the judgment behind it.
The format for logging
A need entering the pool should carry at least these four fields. Miss any one and months later you cannot judge whether it's still worth doing.
| Need | Source | Original scenario | Date | Status |
|---|---|---|---|---|
| Batch export | User feedback | Reports to the boss every Monday, currently copying by hand | 03-14 | To validate |
| Shorten signup | Data anomaly | Step two loses 62%, 20 points higher than last month | 03-16 | Confirmed |
| Add comments | Competitor | Rival shipped it, but they target teams and we target individuals | 03-18 | Parked |
The "original scenario" column is the easiest to skip and the most valuable. It's the only thing that lets you recall, months later, why you wrote the item down in the first place. The status column deserves a few fixed values too — "to validate," "confirmed," "parked" — instead of a vague "maybe later." Without fixed states, you'll have to re-read every item just to prioritize.