Skip to main content
Needs describe what must be true for a goal to succeed. They’re the enduring problems your users face.

​
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 an approach (a specific way to address “try without commitment”)
  • “Fix the upload bug”, that’s a task
  • “Users are happy”, too vague, not actionable

​
Needs don’t carry temporal data

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

​
Multiple approaches per need

A single need can have several approaches, and that’s healthy. Each approach is a different bet on how to address the same underlying problem. 
Need: Users can compare prices across stores
  └── Approach: Manual price entry (must-have)
  └── Approach: Barcode scan with live lookup (incremental)
  └── Approach: AI price prediction from photos (delighter)
Same need, three approaches at different Kano tiers, shipping at different times. The need persists through all of them.