Use Cases
Four frameworks with worked examples, when to apply them, and the failure modes that trap most PMs. No framework without failure modes.
What it is
Converts a problem statement into an open invitation to ideate. Reframes problems as opportunities. "Users can't find order history" becomes "How might we make order history feel effortless?"
When to use
At the Define → Ideate transition. When the team is anchored on one obvious solution. When you need to widen the solution space before narrowing.
When NOT to use
For technical or infrastructure problems. When you already have strong evidence for a specific direction, HMW will waste time generating alternatives you do not need.
Worked example
"New users abandon signup at step 3." → HMW: "How might we make signing up feel like the first moment of a great experience rather than a form to fill?"
What it is
Surfaces every assumption embedded in a solution and ranks by importance and certainty. The riskiest, least-certain assumptions become your first prototype tests before any development begins.
When to use
Before committing any engineering time to a new initiative. When a stakeholder says "I'm sure users want this" without data. Before sprint planning for high-uncertainty work.
When NOT to use
For incremental improvements to validated features. When time pressure makes discovery impossible, acknowledge the risk explicitly instead of skipping the map.
Worked example
Assumption: "Users will save payment details for faster checkout." Importance: High. Certainty: Low. → Run a fake-door test before building the feature.
What it is
Matching prototype fidelity to the specific assumption being tested. The cheapest artefact that answers the question is always the right choice; higher fidelity than needed biases users and wastes time.
When to use
Before any prototype work begins. The PM decides the fidelity level; the designer executes it. Ask: "What is the minimum fidelity that answers the specific question we are testing?"
When NOT to use
You always select fidelity intentionally. The failure mode is not using it. It is defaulting to high fidelity because it looks more professional rather than because the assumption demands it.
Decision rule
Concept validity → Paper sketch. Workflow intuition → Clickable wireframe. Willingness to pay → Fake door test. Technical feasibility → Spike or coded prototype only.
What it is
A set of rules for structuring user interviews so that the PM gets honest data rather than polite validation. Based on Rob Fitzpatrick's principle: if you ask about your idea, people will be kind instead ask about their life.
When to use
Every user interview a PM conducts. The rules apply whether the interview is for Empathize research, problem validation, or post-launch learning. They are not optional for high-stakes initiatives.
When NOT to use
You always apply the principles. The failure mode is reverting to "Would you use this?" under time pressure, which produces data that feels useful but contains no signal.
The three rules
1. Talk about their life, not your idea. 2. Ask about specific past events, not hypothetical futures. 3. Listen more than you speak. If you are talking, you are not learning.
The Prototype Fidelity Spectrum - Cheapest to Most Expensive
Every step increases learning accuracy and cost. Move right only when the assumption demands it.
|
#
|
Prototype Type
|
What You're Testing
|
Cost
|
| 01 |
Paper Sketch
|
Testing a concept or layout. Does the user understand what this does?
|
Hours
|
| 02 |
Whiteboard Flow
|
Testing a user journey. Does the sequence make sense end to end?
|
Hours
|
| 03 |
Clickable Wireframe
|
Testing a workflow. Can the user complete the primary task?
|
1–2 Days
|
| 04 |
Fake Door Test
|
Testing demand. Will users click to access this feature before it is built?
|
1 Day
|
| 05 |
Visual Mockup
|
Testing desirability. Does the look and feel match user expectations?
|
2–3 Days
|
| 06 |
Wizard of Oz
|
Testing value. Manually deliver the experience the technology would provide.
|
1 Week
|
| 07 |
Coded Prototype
|
Testing technical feasibility or performance-dependent experience.
|
Weeks
|
