Deciding what to build, what to prioritize, and what to avoid.

The closer we get to identifying DEMAND (what people want from our product), the better we feel. The trap is that in many cases, when we think we’ve identified DEMAND, what we have really identified is just SUPPLY (features to be built).
Misinterpreting an idea as demand can lead to building an expensive feature that nobody wants.

Key points:

• Differentiate DEMAND from SUPPLY.
• Think and search about WHEN:
  Get the context of the problem. Don’t focus on the WHY or the WHAT (feature request), focus on how it happened.

Story:
A clients wants permission management.
Bad: start user research and needs collection for permission management.
Good: understand when the problem surfaced.
The story: a contractor archived a project without knowing it would impact everybody. Solution: more warning at archiving.

Actionable:
For interaction workflows: instead of focusing on the user (needs), focus on the path of actions that lead to the user problem. Try to change this path of actions, at any point in the path, not necessarily at the end.