Use this when: You have a hypothesis about a product or feature and need evidence that it's worth building before committing engineering time.
You're done when: You have a go/no-go decision backed by evidence from real conversations and a lightweight experiment, not opinions or enthusiasm.
The Sequence
Template
The Milkshake Test
Clayton Christensen's Jobs-to-be-Done theory offers a validation shortcut: don't ask customers what they want, ask what they hire your product to do. His famous example: a fast-food chain wanted to sell more milkshakes. They surveyed customers about flavor, thickness, and price preferences. Sales didn't budge. Then researchers watched what actually happened. Most milkshakes were bought at 6:30 AM by commuters who needed something to make a boring drive less boring, something that lasted longer than a banana and was less messy than a bagel. The "competitor" wasn't other milkshakes, it was boredom. When you validate an idea, the question isn't "do people want this product?" It's "what job are people currently hiring a bad solution to do, and can I do it better?"
How to use JTBD during validation conversations. When interviewing potential users, focus on the switching moment, the point where they went from tolerating the old way to actively looking for something new. Ask: "When did you first start looking for a solution?" then trace the timeline forward. What triggered the search? What did they try? What made them switch (or not)? This surfaces the functional job (what they're trying to accomplish), the emotional job (how they want to feel), and the existing alternatives you're really competing against, which are often not what you'd expect. Bob Moesta's Forces of Progress model explains why people switch (or don't). Every potential customer has four forces acting on them simultaneously:
During validation, you're not just checking whether the job exists. You're measuring whether the forces are strong enough. A real problem (push) with an attractive solution (pull) still fails if switching feels risky (anxiety) or the current workaround feels tolerable (habit). The best validation conversations surface all four forces, not just the pain. Ask: "What almost stopped you from trying something new?" (anxiety). "What were you already doing that sort of worked?" (habit). If push and pull are weak but habit is strong, your idea might solve a real problem that nobody will bother switching for.
Example
A team wanted to build an AI tool that auto-generates sales proposals. They listed assumptions and identified the riskiest one: sales reps spend significant time writing proposals. They interviewed 8 reps. 6 said proposals take 15 minutes using templates they already have. The problem wasn't painful enough. They ran no experiment, killed the idea in week 1, and redirected to a problem the interviews actually surfaced — reps spending 2 hours per deal researching prospects. That's validation working correctly: a fast no saves months of building the wrong thing.
Written with ❤️ by a human (still)