Skip to main content
A need is a persistent problem your users face that stands between you and a goal. It is the anchor your bets hang from.

​
What makes a good need?

A need is a persistent condition, not a task or a solution. It doesn’t go away when you ship something. You just address it better over time. Good needs:
  • “Users can try the product without commitment”
  • “Compare prices across stores”
  • “Upload audio reliably”
Bad needs:
  • “Add a free trial”. That’s a bet (a specific way to address “try without commitment”)
  • “Fix the upload bug”, that’s a task
  • “Users are happy”, too vague, not actionable

​
The fastest test: can it be finished?

Needs persist and improve. If it can be finished, it is a bet or a job. Bets and jobs get run and completed. A need changes slowly, and independently of what you ship.

​
Do internal users count?

Yes, if you can name the person and the job. A support lead who builds a customer’s compliance report by hand, or a partnerships lead who can’t size an opportunity without an engineer, faces a real condition that doesn’t go away when you ship. What doesn’t count is a statement about your own systems with nobody on the other end. Nobody experiences “we have no read-optimised copy of our data”. They experience its consequences. Internal needs carry a higher bar of evidence. A customer’s need is proven when they pay, complain with money attached, or leave. An internal one is proven only by the team agreeing with itself.

​
Reframe organisational conditions

Products older than a few years carry plenty of items phrased as internal complaints. Entered as needs, they sit in the tree as permanent grievances. Ask who feels it and what they can’t do: Building the read layer then becomes a bet under that need.

​
Needs don’t carry temporal data

Unlike bets and jobs, needs have no iteration, no Kano classification, no maturity. They persist. The temporal aspects live on the bets beneath them, at different satisfaction tiers, shipping at different times.

​
Evidence that a need is real

You can record who feels a need on the need itself: the account or segment, the revenue or size behind them, the date you observed it, and a few words of what they asked for. The need card shows how many entries it has, and the side panel shows the detail. The date belongs to the evidence, not the need. A need doesn’t age, and nothing ranks or sorts needs by their evidence. It tells you why a need matters. The tree, and the order you keep it in, decides what comes next. Record money and commitment, not testimony: who, how much, when. Interview notes and transcripts belong somewhere else.

​
Multiple bets per need

A single need can have several bets, and that’s healthy. Each bet is a different hypothesis about how to address the same underlying problem.
Same need, three bets at different Kano tiers, shipping at different times. The need persists through all of them.