User Research & Discovery
User Research & Discovery
The most common cause of product failure is not bad engineering. It is building the right thing in the wrong way, or the wrong thing extremely well. The top two causes of startup failure in post-mortem studies are "no market need" and "ran out of cash" — the second often being a direct consequence of spending money on the first.
Discovery is the discipline of answering one question before spending resources: is this problem real, important, and underserved enough that a solution people will pay for (or use at scale) can be built?
Jobs To Be Done
Clayton Christensen's Jobs To Be Done framework reframes product thinking: users don't buy products, they hire them to do jobs. When someone hires a power drill, the job is not "have a drill" — it is "have a hole in the wall." When someone hires Slack, the job is not "have a messaging tool" — it is "coordinate my team without email chaos."
Understanding the job means understanding:
- The functional job: the practical task to be accomplished
- The emotional job: how the user wants to feel while doing it
- The social job: how the user wants to be perceived while doing it
The famous milkshake example: McDonald's discovered that a large proportion of milkshakes were purchased early in the morning, by commuters, for a job that had nothing to do with hunger or enjoyment. The job was "give me something to hold and sip that makes my commute less boring while keeping one hand free." Competing products (donuts, bananas) failed the social job (messy to eat while driving) or the functional job (done too fast). The milkshake hired better for that job than any obvious substitute.
The Mom Test
Rob Fitzpatrick's "The Mom Test" (2013) identifies the fundamental error in most user research: asking questions users want to answer nicely rather than questions that reveal truth.
"Would you use this?" — a bad question. Users want to be supportive; they say yes.
"Do you have this problem?" — a bad question. Users retroactively construct a problem to validate your interest.
"What is the hardest part about your current approach?" — a good question. The answer is about their life, not your idea.
"Tell me about the last time you tried to do this?" — a good question. Anchors to specific past behaviour, not hypothetical future behaviour.
The Mom Test principle: ask about the customer's life and past behaviour. Never pitch or reveal your solution until you've confirmed the problem exists and is genuinely important.
Assumption Mapping and Risk
Every product idea rests on a stack of assumptions. Before building, make them explicit and rank them by risk:
- Desirability: Do users actually want this? Does the problem exist? Is it important enough to address?
- Feasibility: Can this be built with available technology and resources?
- Viability: Will this create a sustainable business? Will users pay for it?
- Ethical: Are there unintended negative consequences?
Most product teams get these backwards — they validate feasibility (can we build it?) first because it is most comfortable, and test desirability last or never. Discovery flips this: test desirability — the riskiest assumption — first, and only invest in feasibility once desirability is established.
The MVP Is Not a Beta Product
"Minimum Viable Product" is widely misunderstood as "a crappy early version." Eric Ries's original definition: the smallest thing you can build (or do) to test your most important assumption.
The MVP is a learning tool:
- A landing page describing a product that doesn't exist tests whether people click "Sign Up"
- A concierge MVP (doing the process manually for early users) tests whether users value the outcome before automating it
- A Wizard of Oz MVP (where a human behind the curtain simulates the AI or automation) tests whether users would pay for a fully-automated version
- A smoke test / pretotype shows a product and counts intent-to-purchase before building
Dropbox's MVP was a demo video. Zappos's MVP was manually purchasing shoes from physical stores when online orders came in. Airbnb's MVP was a website for one event in San Francisco with photos taken on a digital camera.
Continuous Discovery
Teresa Torres popularised "continuous discovery" — the practice of doing small amounts of customer research every week rather than periodic large research projects. Weekly habits:
- 1-2 customer interviews per week
- Ongoing review of support tickets and user feedback
- Regular observation of session recordings
- Monthly review of analytics against discovery hypotheses
Continuous discovery prevents the organisation from going months or years between customer conversations and making large bets based on stale understanding.