docs(guide): add new appendix sections for product thinking
add four new appendix sections covering idea sources, double diamond model, jobs to be done, and mom test interview method. includes both zh-cn and en versions with comprehensive content and navigation updates. update introduction.md and stage-0 index files to include new sections in tables of contents. add sidebar navigation entries in config.mjs for all languages. each new appendix provides beginner-friendly explanations, practical frameworks, and AI integration tips for product development and validation.
This commit is contained in:
sanbuphy
@@ -82,6 +82,33 @@ Master the Vibe Coding workflow, learn to deconstruct requirements, and independ
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
### Appendix: User Research and Validation
|
||||
|
||||
**Why needed**: When you already have an idea but are not sure whether it is a real need, how to interview users, or what to validate first, this group helps you turn vague instincts into more grounded judgment.
|
||||
|
||||
**When to watch**:
|
||||
- When you cannot clearly explain what users are really trying to get done
|
||||
- When you want to interview users without collecting only polite encouragement
|
||||
- When you want to define the problem better before jumping into a solution
|
||||
|
||||
<NavGrid>
|
||||
<NavCard
|
||||
href="/en/stage-1/appendix-jobs-to-be-done/"
|
||||
title="Jobs to Be Done"
|
||||
description="Turn vague product ideas into clearer user scenarios, real needs, and better MVP directions."
|
||||
/>
|
||||
<NavCard
|
||||
href="/en/stage-1/appendix-mom-test/"
|
||||
title="The Mom Test"
|
||||
description="Learn how to ask better interview questions and collect evidence instead of just encouragement."
|
||||
/>
|
||||
<NavCard
|
||||
href="/en/stage-1/appendix-double-diamond/"
|
||||
title="Double Diamond"
|
||||
description="Learn when to explore the problem first and when to start comparing solutions and prototypes."
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
### Appendix: Technical Solutions
|
||||
|
||||
**Why needed**: When you encounter technical problems during development or want to know better tools, these technical appendices provide ready-to-use solutions.
|
||||
|
||||
@@ -0,0 +1,421 @@
|
||||
---
|
||||
title: 'Double Diamond: First Choose the Right Problem, Then Build the Right Solution'
|
||||
description: 'A beginner-friendly introduction to the Double Diamond. Learn when to explore the problem, when to narrow it down, and when to start comparing solutions and prototypes.'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = 'About <strong>1.5 hours</strong>'
|
||||
</script>
|
||||
|
||||
# Double Diamond: First Choose the Right Problem, Then Build the Right Solution
|
||||
|
||||
<a id="top-dd"></a>
|
||||
|
||||
## Introduction
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['Double Diamond', 'Design Thinking', 'Discovery', 'Problem Framing']"
|
||||
coreOutput="1 clearer problem definition and 1 better validation starting point"
|
||||
expectedOutput="Stop jumping straight into prototypes and learn to define the problem before comparing solutions"
|
||||
>
|
||||
|
||||
One of the most common beginner mistakes is not a lack of effort. It is moving to solutions too fast.
|
||||
|
||||
You get an idea, then immediately start sketching pages, features, AI integrations, buttons, and flows. Later you realize the real issue was never clear in the first place: is this even the right problem, and is it worth solving now?
|
||||
|
||||
That is exactly what the **Double Diamond** helps prevent.
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info Minimal SOP
|
||||
**Goal**: After this, you should be better at knowing when to think about the problem first and when to start designing solutions.
|
||||
|
||||
**Action**: Move through `Discover → Define → Develop → Deliver`, and only do the work that belongs to the current stage.
|
||||
|
||||
**Result**: You will leave with a clearer problem definition, a few comparable solution directions, and a more realistic first validation cut.
|
||||
|
||||
**Quick links**: [What it is](#dd-what) · [The first diamond](#dd-first) · [How AI can help](#dd-ai)
|
||||
:::
|
||||
|
||||
## What You Will Learn
|
||||
|
||||
1. What the Double Diamond is and why it helps beginners
|
||||
2. What Discover, Define, Develop, and Deliver actually mean
|
||||
3. How to tell whether you should still be exploring or should start narrowing
|
||||
4. How to use the Double Diamond in AI products, prototyping, and validation
|
||||
|
||||
<a id="dd-what"></a>
|
||||
## 1. What the Double Diamond Is [↩ Back to top](#top-dd)
|
||||
|
||||
The Double Diamond is a design process framework popularized by the UK **Design Council**.
|
||||
|
||||
It divides the process into four stages:
|
||||
|
||||
1. **Discover**
|
||||
2. **Define**
|
||||
3. **Develop**
|
||||
4. **Deliver**
|
||||
|
||||
It is called a “double diamond” because it includes two cycles of:
|
||||
|
||||
- divergence: opening up possibilities
|
||||
- convergence: narrowing and choosing
|
||||
|
||||
In simple language:
|
||||
|
||||
- the first diamond is about choosing the right problem
|
||||
- the second diamond is about building the right solution
|
||||
|
||||
## 2. Why It Matters for Beginners
|
||||
|
||||
Beginners often do this:
|
||||
|
||||
- get an idea
|
||||
- start prototyping immediately
|
||||
- keep adding more features
|
||||
- lose track of the real problem
|
||||
|
||||
The Double Diamond helps by separating two very different questions:
|
||||
|
||||
- What problem is worth solving?
|
||||
- What solution is best for that problem?
|
||||
|
||||
Many failed products are not weak because people did not work hard. They fail because they polished the wrong thing.
|
||||
|
||||
<a id="dd-first"></a>
|
||||
## 3. The First Diamond: Choose the Right Problem [↩ Back to top](#top-dd)
|
||||
|
||||
The first diamond is about the **problem space**, not the solution space.
|
||||
|
||||
You can translate it as:
|
||||
|
||||
**before building, first make sure this is worth building.**
|
||||
|
||||
### 3.1 Discover
|
||||
|
||||
This is the broad exploration stage.
|
||||
|
||||
You look at:
|
||||
|
||||
- what users actually do
|
||||
- when the pain shows up
|
||||
- what workarounds they use now
|
||||
- what other products or substitutes already exist
|
||||
- what constraints, environments, or process details shape the problem
|
||||
|
||||
The goal is not to rush to a conclusion. The goal is to avoid acting as if you already know the answer.
|
||||
|
||||
### 3.2 Define
|
||||
|
||||
This is the narrowing stage.
|
||||
|
||||
You turn a broad topic into a focused problem definition.
|
||||
|
||||
For example:
|
||||
|
||||
- too broad: “I want to improve resume writing”
|
||||
- more useful: “Students applying for internships often delay submitting because they are unsure whether their resume is good enough”
|
||||
|
||||
Now the direction is more actionable:
|
||||
|
||||
- who the users are
|
||||
- in what situation the problem appears
|
||||
- where they get stuck
|
||||
- what success would look like
|
||||
|
||||
## 4. The Second Diamond: Build the Right Solution
|
||||
|
||||
Once the first diamond is done, you can move into solutions without drifting as much.
|
||||
|
||||
### 4.1 Develop
|
||||
|
||||
Now you explore multiple solution directions:
|
||||
|
||||
- checklist
|
||||
- AI rewrite tool
|
||||
- feedback tool
|
||||
- example library
|
||||
- role comparison view
|
||||
|
||||
The goal here is not to fall in love with the first idea. It is to open the solution space while keeping the problem fixed.
|
||||
|
||||
### 4.2 Deliver
|
||||
|
||||
This is where you narrow again:
|
||||
|
||||
- choose the most testable direction
|
||||
- build the smallest useful version
|
||||
- test it with real people
|
||||
|
||||
Deliver does not have to mean “launch the full product.” It can be:
|
||||
|
||||
- a flow sketch
|
||||
- a low-fidelity prototype
|
||||
- a tiny MVP
|
||||
- a small user test
|
||||
|
||||
What matters is that the solution becomes testable.
|
||||
|
||||
## 5. A Simple Comparison Table
|
||||
|
||||
| Stage | What you are doing | Keywords | Typical outputs |
|
||||
| --- | --- | --- | --- |
|
||||
| Discover | Understanding the problem | research, observation, interviews | notes, patterns, pain points |
|
||||
| Define | Narrowing the problem | synthesis, prioritization, framing | problem definition, target slice |
|
||||
| Develop | Expanding solution directions | brainstorming, comparison, prototyping ideas | multiple concepts, rough flows |
|
||||
| Deliver | Narrowing and testing | prototype, test, iterate | prototype, user feedback, validation cut |
|
||||
|
||||
If you want the shortest version:
|
||||
|
||||
- **Discover / Define** = choose the right problem
|
||||
- **Develop / Deliver** = build the right solution
|
||||
|
||||
## 6. Common Double Diamond Mistakes
|
||||
|
||||
### 6.1 Jumping to Deliver before Discover
|
||||
|
||||
This is the classic one: people build screens and flows before they even know whether the problem deserves attention.
|
||||
|
||||
### 6.2 Staying in Discover forever
|
||||
|
||||
The opposite mistake is endless research with no convergence. The Double Diamond is not “keep exploring forever.” It is “explore, then decide.”
|
||||
|
||||
### 6.3 Quietly changing the problem to fit a favorite solution
|
||||
|
||||
Sometimes teams define a problem, then later shift the problem statement just to justify the solution they already wanted to build.
|
||||
|
||||
That is dangerous because you may stop solving the real problem and start defending a favorite idea.
|
||||
|
||||
### 6.4 Treating Deliver as “build everything”
|
||||
|
||||
Deliver does not mean a complete polished product. A useful prototype or a small validation test can already be a strong deliverable.
|
||||
|
||||
## 7. How This Helps in AI Products
|
||||
|
||||
AI products are especially vulnerable to “capability-first” thinking because the technology looks exciting.
|
||||
|
||||
It is easy to jump to:
|
||||
|
||||
- Should we add multimodal support?
|
||||
- Should we build an agent?
|
||||
- Should we connect a workflow engine?
|
||||
- Should we add voice, image, web search?
|
||||
|
||||
The Double Diamond helps you ask first:
|
||||
|
||||
- where are users genuinely stuck?
|
||||
- is this a place where AI is actually necessary?
|
||||
- what is weak about the current workaround without AI?
|
||||
- what progress would AI make possible here?
|
||||
|
||||
That protects you from a common failure mode:
|
||||
|
||||
**high capability, low value.**
|
||||
|
||||
## 8. A Template You Can Use Right Away
|
||||
|
||||
If you are working on your own product, you can write through the stages like this.
|
||||
|
||||
### Discover
|
||||
|
||||
- Who are the users I am observing?
|
||||
- When did they last experience this problem?
|
||||
- What do they do now?
|
||||
- What feels slow, painful, or risky?
|
||||
|
||||
### Define
|
||||
|
||||
- Which problem is most worth prioritizing?
|
||||
- Which situation is most frequent or most important?
|
||||
- Who does version one serve, and what exactly does it solve?
|
||||
- What changes for the user if we solve it well?
|
||||
|
||||
### Develop
|
||||
|
||||
- What solution directions are possible?
|
||||
- Which are the lightest, fastest, and easiest to validate?
|
||||
- What is essential now, and what can wait?
|
||||
|
||||
### Deliver
|
||||
|
||||
- What is the smallest useful thing we can put in front of users?
|
||||
- Is it a sketch, prototype, or MVP?
|
||||
- Who do we need to test with?
|
||||
- What would make us continue, change direction, or stop?
|
||||
|
||||
## 9. A Beginner-Friendly Example
|
||||
|
||||
Suppose you want to build an AI tool that helps students prepare resumes for job applications.
|
||||
|
||||
Many people would jump straight into the second diamond and start asking:
|
||||
|
||||
- should there be one-click beautification?
|
||||
- should there be AI rewriting?
|
||||
- should it auto-match job descriptions?
|
||||
- should it generate self-introductions?
|
||||
|
||||
The Double Diamond suggests a better process.
|
||||
|
||||
### First diamond
|
||||
|
||||
**Discover**
|
||||
|
||||
- talk to recent graduates about the last time they edited a resume
|
||||
- watch how they move from an old resume to a new version
|
||||
- see whether their pain is “I can't write,” “I can't revise,” or “I can't judge quality”
|
||||
|
||||
**Define**
|
||||
|
||||
- narrow down to something more concrete
|
||||
- not “students cannot make resumes”
|
||||
- but “students applying for internships for the first time struggle to turn existing experiences into role-fit wording, so they delay applying”
|
||||
|
||||
### Second diamond
|
||||
|
||||
**Develop**
|
||||
|
||||
- compare directions: templates, AI rewriting, job comparison, resume scoring, examples
|
||||
|
||||
**Deliver**
|
||||
|
||||
- build only one narrow version first, such as “rewrite bullet points using a job description”
|
||||
- test it with five students and see whether it helps them submit faster
|
||||
|
||||
When the first diamond is solid, the second diamond becomes much clearer.
|
||||
|
||||
## 10. Summary
|
||||
|
||||
The real strength of the Double Diamond is that it breaks a messy process into four clearer moves:
|
||||
|
||||
- first expand the problem space
|
||||
- then narrow the problem definition
|
||||
- then expand the solution space
|
||||
- finally narrow toward delivery
|
||||
|
||||
It does not make you slower. It helps you avoid spending a lot of energy on the wrong direction.
|
||||
|
||||
This matters even more in the AI era, because building things is getting easier. When making becomes cheap, choosing the right problem becomes even more valuable.
|
||||
|
||||
<a id="dd-ai"></a>
|
||||
## 11. How AI Can Help You Use the Double Diamond [↩ Back to top](#top-dd)
|
||||
|
||||
AI is useful here not as the decision-maker, but as a helper for research, synthesis, and comparison.
|
||||
|
||||
### 11.1 Discover: Build a rough problem map
|
||||
|
||||
Before interviews and deeper research, AI can help you scan the problem space:
|
||||
|
||||
- common substitutes
|
||||
- frequent public complaints
|
||||
- typical situations and user groups
|
||||
- what current tools ignore
|
||||
|
||||
Simple input:
|
||||
|
||||
```text
|
||||
I want to build something that helps students improve resumes.
|
||||
Do not give me features yet.
|
||||
First help me map the most common problems people seem to face.
|
||||
```
|
||||
|
||||
Possible AI output:
|
||||
|
||||
```text
|
||||
Initial problem map:
|
||||
1. Not knowing what to include
|
||||
2. Not knowing how to tailor for different roles
|
||||
3. Not knowing when the resume is good enough
|
||||
4. Depending on others for feedback
|
||||
5. Delaying applications because of uncertainty
|
||||
```
|
||||
|
||||
This does not replace research, but it helps you enter Discover faster.
|
||||
|
||||
### 11.2 Define: Narrow the problem
|
||||
|
||||
```text
|
||||
Here are the issues I collected:
|
||||
1. people don't know what to write
|
||||
2. people don't know how to revise
|
||||
3. people keep delaying because they are unsure it is good enough
|
||||
|
||||
Help me decide which one is the best first problem to focus on.
|
||||
```
|
||||
|
||||
Possible AI output:
|
||||
|
||||
```text
|
||||
Recommended first problem:
|
||||
"Students applying for internships delay applications because they cannot tell when their resume is good enough to submit."
|
||||
```
|
||||
|
||||
That kind of output is useful because it turns a pile of fuzzy issues into a more testable first problem.
|
||||
|
||||
### 11.3 Develop: Generate multiple directions
|
||||
|
||||
```text
|
||||
My problem definition is:
|
||||
"Students delay applications because they are unsure whether their resume is ready."
|
||||
|
||||
Please suggest 4 different solution directions.
|
||||
```
|
||||
|
||||
Possible AI output:
|
||||
|
||||
```text
|
||||
1. Resume readiness checklist
|
||||
2. Role-specific rewrite assistant
|
||||
3. Risk and gap detector
|
||||
4. Example comparison library
|
||||
```
|
||||
|
||||
This helps you compare rather than overcommit too early.
|
||||
|
||||
### 11.4 Deliver: Generate a lightweight test script
|
||||
|
||||
```text
|
||||
I built a simple prototype where users upload a resume and get "not ready yet" feedback.
|
||||
Please generate a 15-minute user testing script.
|
||||
```
|
||||
|
||||
Possible AI output:
|
||||
|
||||
```text
|
||||
15-minute test script:
|
||||
|
||||
1. Ask the user to describe their last resume-editing experience
|
||||
2. Let them upload a resume on their own
|
||||
3. Observe whether the feedback is understandable
|
||||
4. Ask which parts feel useful and which parts feel confusing
|
||||
5. Ask whether they would want to use this before their next application
|
||||
```
|
||||
|
||||
### 11.5 Use AI as a stage guard
|
||||
|
||||
One of the biggest Double Diamond risks is jumping stages. AI can help by acting like a process coach:
|
||||
|
||||
```text
|
||||
Act as a product process coach.
|
||||
Here is my current project state: [your description]
|
||||
Please tell me whether I am mainly in Discover, Define, Develop, or Deliver.
|
||||
Also tell me:
|
||||
1. whether I am jumping too early
|
||||
2. what the most important action in this stage is
|
||||
3. what I should not do yet
|
||||
```
|
||||
|
||||
That is especially useful for beginners who tend to prototype before the problem is clear.
|
||||
|
||||
## Assignments
|
||||
|
||||
1. Pick one product idea and map it into Discover, Define, Develop, Deliver
|
||||
2. Write one clear problem definition
|
||||
3. Generate at least 3 different solution directions
|
||||
4. Define one small validation version you could test within a week
|
||||
|
||||
## Further Reading
|
||||
|
||||
- [Design Council: The Double Diamond](https://www.designcouncil.org.uk/our-resources/the-double-diamond/)
|
||||
- [Design Council: Framework for Innovation](https://www.designcouncil.org.uk/our-work/skills-learning/tools-frameworks/framework-for-innovation-design-councils-evolved-double-diamond/)
|
||||
- [Design Council: History of the Double Diamond](https://www.designcouncil.org.uk/our-resources/the-double-diamond/history-of-the-double-diamond/)
|
||||
@@ -0,0 +1,488 @@
|
||||
---
|
||||
title: 'Jobs to Be Done: Find What Users Are Really Trying to Get Done'
|
||||
description: 'A beginner-friendly introduction to Jobs to Be Done. Learn how to turn a vague idea into a clearer user scenario, a sharper need, and a more grounded MVP direction.'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = 'About <strong>1.5 hours</strong>'
|
||||
</script>
|
||||
|
||||
# Jobs to Be Done: Find What Users Are Really Trying to Get Done
|
||||
|
||||
<a id="top-jtbd"></a>
|
||||
|
||||
## Introduction
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['JTBD', 'User Needs', 'Product Thinking', 'Discovery']"
|
||||
coreOutput="1 JTBD statement that feels closer to a real user need"
|
||||
expectedOutput="Turn a vague idea into a clearer user scenario and a more grounded MVP direction"
|
||||
>
|
||||
|
||||
Many beginners start product thinking from the wrong place: features. You see another product with AI summaries, tags, agents, or workflows, and your first instinct is to ask, “What features should I add too?”
|
||||
|
||||
But users rarely choose a product because a feature name sounds cool. Most of the time, they are trying to make progress in a specific situation, and they temporarily “hire” a tool to help them move forward.
|
||||
|
||||
That is the core reminder behind **Jobs to Be Done (JTBD)**: users are not buying features. They are hiring a solution to help them make progress.
|
||||
|
||||
This article explains JTBD in plain language and turns it into something you can actually use when shaping an AI product.
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info Minimal SOP
|
||||
**Goal**: After this, you should be better at turning a vague idea into a real user need instead of just a pile of feature names.
|
||||
|
||||
**Action**: Write one rough product idea, talk to 3 possible users about the last time they dealt with this problem, then rewrite it as one JTBD sentence.
|
||||
|
||||
**Result**: You will leave with a clearer need hypothesis and a better sense of what your first version should solve.
|
||||
|
||||
**Quick links**: [What JTBD is](#jtbd-what) · [One-sentence formula](#jtbd-formula) · [How AI can help](#jtbd-ai)
|
||||
:::
|
||||
|
||||
## What You Will Learn
|
||||
|
||||
1. What Jobs to Be Done means in plain language
|
||||
2. How to separate “what users say they want” from “what they are really trying to get done”
|
||||
3. How to turn a vague idea into a situation, trigger, progress, workaround, and success condition
|
||||
4. How JTBD connects to AI product thinking, interviews, and prompt-based analysis
|
||||
|
||||
<a id="jtbd-what"></a>
|
||||
## 1. What Jobs to Be Done Means [↩ Back to top](#top-jtbd)
|
||||
|
||||
Jobs to Be Done, often shortened to **JTBD**, is built around a simple idea: users “hire” a product to get something done.
|
||||
|
||||
That “something” is usually not just a surface task. It is a kind of **progress**.
|
||||
|
||||
Examples:
|
||||
|
||||
- Not “I want an AI meeting-note tool,” but “I want to turn a messy meeting into a clear summary with owners and next steps before I forget everything.”
|
||||
- Not “I want a budgeting app,” but “I want to stop feeling anxious at the end of the month because I finally understand where my money went.”
|
||||
- Not “I want a resume optimizer,” but “I want to feel confident enough to send my application instead of endlessly tweaking my resume.”
|
||||
|
||||
JTBD helps you focus less on feature names and more on what users are trying to move toward.
|
||||
|
||||
It also changes how you see competition. If the job is “make a long PDF easier to understand,” your competition is not just another AI tool. It may be a colleague, an intern, manual skimming, or even delaying the task.
|
||||
|
||||
## 2. JTBD vs Personas and Feature Lists
|
||||
|
||||
Many beginners start by writing personas: 25 years old, white-collar worker, likes productivity tools, willing to try new apps. That information is not useless, but it usually does **not explain why someone acts right now**.
|
||||
|
||||
JTBD pushes you toward more useful questions:
|
||||
|
||||
- What situation triggered action?
|
||||
- What problem felt urgent?
|
||||
- What are they trying to move toward?
|
||||
- What clumsy workaround are they using now?
|
||||
- What result would make them say “this actually helped”?
|
||||
|
||||
That is the difference:
|
||||
|
||||
- a persona tells you roughly who the person is
|
||||
- JTBD tells you what they are trying to get done right now
|
||||
|
||||
Feature lists have a similar trap. Users may ask for export, rewrite, voice input, or smart tags. Those are surface requests. JTBD asks what sits underneath them:
|
||||
|
||||
- Why export to Word instead of PDF?
|
||||
- Why rewrite: because the tone is weak, or because it must fit a different audience?
|
||||
- Why voice input: because typing is annoying, or because they usually capture thoughts while walking, commuting, or leaving meetings?
|
||||
|
||||
Sometimes a feature is just a temporary translation of a deeper job.
|
||||
|
||||
## 3. A Beginner-Friendly Example
|
||||
|
||||
Imagine someone buys coffee and a sandwich every morning on the way to work.
|
||||
|
||||
On the surface, they are buying breakfast. In JTBD terms, they may really be trying to:
|
||||
|
||||
- solve breakfast with as little mental effort as possible
|
||||
- avoid being hungry before arriving at work
|
||||
- keep their morning routine moving without disruption
|
||||
|
||||
The product they “hire” is not really a sandwich. It is a reliable way to keep the morning moving.
|
||||
|
||||
The same logic applies to AI products. If you want to build an AI meeting summary tool, JTBD helps you step back from feature brainstorming and ask:
|
||||
|
||||
- What moment actually hurts?
|
||||
- What are users trying to make happen after the meeting?
|
||||
- What would make the output feel trustworthy enough to share?
|
||||
|
||||
If the job becomes clear, priorities become clearer too. Maybe the first version does not need twelve export formats. Maybe it mainly needs:
|
||||
|
||||
- a clear structure
|
||||
- stable action-item extraction
|
||||
- easy sharing
|
||||
- output good enough to forward without embarrassment
|
||||
|
||||
That is JTBD at its best: it brings you back from “which capabilities should I stack?” to “what progress am I helping the user make?”
|
||||
|
||||
## 4. A Practical JTBD Template
|
||||
|
||||
If you are a beginner, do not overcomplicate this. Start with five parts.
|
||||
|
||||
### 4.1 Situation
|
||||
|
||||
In what moment or context does the user look for help?
|
||||
|
||||
- right after a meeting
|
||||
- late at night before submitting a resume
|
||||
- when the boss suddenly asks for a document
|
||||
- at the end of the month when money feels tight
|
||||
|
||||
If you cannot describe the situation, the need is probably still too vague.
|
||||
|
||||
### 4.2 Trigger
|
||||
|
||||
What makes them act now?
|
||||
|
||||
- a long document they do not know how to start reading
|
||||
- a deadline tomorrow and messy material today
|
||||
- a progress question from a manager that exposed their confusion
|
||||
- repeated friction in a manual workflow
|
||||
|
||||
Triggers often come with emotion. That emotion matters.
|
||||
|
||||
### 4.3 Progress
|
||||
|
||||
What state are they trying to move toward?
|
||||
|
||||
- from chaos to clarity
|
||||
- from anxiety to confidence
|
||||
- from delay to action
|
||||
- from friction to flow
|
||||
- from vague output to something they can actually deliver
|
||||
|
||||
Many people are not really buying tools. They are buying **state change**.
|
||||
|
||||
### 4.4 Current workaround
|
||||
|
||||
What are they doing right now without your product?
|
||||
|
||||
- copy-pasting manually
|
||||
- using Excel or Notes to hold things together
|
||||
- asking a colleague
|
||||
- procrastinating
|
||||
- bouncing between multiple tools
|
||||
|
||||
The workaround is often your real competition.
|
||||
|
||||
### 4.5 Success condition
|
||||
|
||||
What would make the user say this was truly helpful?
|
||||
|
||||
- getting a shareable result within 10 minutes
|
||||
- not needing a second major rewrite
|
||||
- making fewer mistakes
|
||||
- immediately knowing what to do next
|
||||
|
||||
If you cannot say what “useful enough” means, the direction is probably still not focused enough.
|
||||
|
||||
<a id="jtbd-formula"></a>
|
||||
## 5. A One-Sentence Formula You Can Reuse [↩ Back to top](#top-jtbd)
|
||||
|
||||
Use this sentence pattern:
|
||||
|
||||
> When __________, I want to __________, so that I can __________.
|
||||
> Right now, I have to __________.
|
||||
|
||||
Example:
|
||||
|
||||
> When I am preparing to apply for internships, I want to quickly turn my existing resume into a version that fits a specific role, so that I can submit applications without getting stuck in endless revisions.
|
||||
> Right now, I have to rewrite things manually and ask friends for feedback.
|
||||
|
||||
That is already much more useful than “I want to build a resume AI.”
|
||||
|
||||
## 6. Three Layers of a Job in AI Products
|
||||
|
||||
Many AI products look powerful in demos but fail to keep users. A common reason is that they solve only the surface task, not the deeper job.
|
||||
|
||||
You can roughly look at a job in three layers:
|
||||
|
||||
### 6.1 Functional layer
|
||||
|
||||
What is the surface task?
|
||||
|
||||
- summarize a document
|
||||
- rewrite text
|
||||
- extract action items
|
||||
- generate an image
|
||||
|
||||
This is the easiest layer for users to say out loud.
|
||||
|
||||
### 6.2 Emotional layer
|
||||
|
||||
What discomfort do they want to reduce, or what feeling do they want to gain?
|
||||
|
||||
- less panic
|
||||
- less embarrassment
|
||||
- less “starting from zero”
|
||||
- more confidence
|
||||
- more control
|
||||
|
||||
Willingness to pay often has a lot to do with this layer.
|
||||
|
||||
### 6.3 Social layer
|
||||
|
||||
Who do they want to look like in front of others?
|
||||
|
||||
- more reliable
|
||||
- more organized
|
||||
- more professional
|
||||
- more capable
|
||||
|
||||
If you only solve the functional layer, you are easier to replace. If you understand the emotional and social layers too, your product direction often becomes much stronger.
|
||||
|
||||
## 7. Use JTBD to Filter Product Directions
|
||||
|
||||
Sometimes you do not already have a product. You have three to five ideas and do not know which one deserves attention. JTBD is useful here too.
|
||||
|
||||
Ask each idea:
|
||||
|
||||
1. Is the situation concrete enough?
|
||||
2. Are users already using some clumsy workaround?
|
||||
3. Is the job painful enough or frequent enough?
|
||||
4. If I solved it well, would users clearly feel a better state?
|
||||
5. Can version one focus on just one important step in the job?
|
||||
|
||||
If an idea still sounds like “kind of interesting” after this, but you cannot explain the trigger, workaround, or success condition, it is probably still a vague idea rather than a good starting direction.
|
||||
|
||||
## 8. Interview Questions You Can Use Right Away
|
||||
|
||||
Many people run interviews by asking: “What features do you want?” That usually gets surface answers.
|
||||
|
||||
JTBD-style questions are better:
|
||||
|
||||
- When was the last time this problem happened to you?
|
||||
- What were you doing at the time?
|
||||
- Why did you get stuck?
|
||||
- How did you solve it?
|
||||
- What part felt slow, frustrating, or risky?
|
||||
- If a tool helped, what result would make you say it was actually useful?
|
||||
- What alternatives have you tried, and why were they not good enough?
|
||||
|
||||
These questions pull the conversation back into real experience instead of imagined preference.
|
||||
|
||||
## 9. Use AI to Help You Break Down JTBD
|
||||
|
||||
JTBD is not an AI invention, but AI is very useful for organizing and clarifying JTBD.
|
||||
|
||||
For example, if you already collected 5 to 10 user quotes, you can ask AI to summarize them like this:
|
||||
|
||||
```text
|
||||
Please act as a product research assistant.
|
||||
I will give you raw user quotes.
|
||||
Do not give feature ideas yet.
|
||||
First organize them using Jobs to Be Done:
|
||||
|
||||
1. What situation is the user in?
|
||||
2. What event triggered action?
|
||||
3. What progress are they really trying to make?
|
||||
4. What is the current workaround?
|
||||
5. What success condition matters most?
|
||||
6. What emotional words show up repeatedly?
|
||||
|
||||
Then turn the result into 3 JTBD hypotheses worth validating first.
|
||||
```
|
||||
|
||||
If you already have an idea, you can also use AI to do the first pass of narrowing:
|
||||
|
||||
```text
|
||||
I want to build [your product idea].
|
||||
Do not give me a feature list yet.
|
||||
Use Jobs to Be Done to help me analyze:
|
||||
|
||||
1. What concrete situations this product might serve
|
||||
2. What core job exists in each situation
|
||||
3. What alternatives already exist
|
||||
4. Which job is the best starting point for an MVP, and why
|
||||
5. Write the final recommendation as one clear JTBD sentence
|
||||
```
|
||||
|
||||
This helps prevent the classic AI trap: jumping straight to “brainstorm 50 features” before the direction is clear.
|
||||
|
||||
## 10. Four Common Beginner Mistakes
|
||||
|
||||
### 10.1 Writing the job as a feature
|
||||
|
||||
“AI summary,” “smart classification,” and “auto generation” are not jobs. They are possible solutions.
|
||||
|
||||
### 10.2 Making the audience too broad
|
||||
|
||||
“All professionals,” “all students,” and “all founders” are usually too wide. The wider it is, the harder it becomes to see a real situation.
|
||||
|
||||
### 10.3 Listening only to what users say
|
||||
|
||||
What people say matters, but their current workaround often reveals their priorities better.
|
||||
|
||||
### 10.4 Trying to build the full platform too early
|
||||
|
||||
JTBD works best when you focus on one important step in one concrete situation and make that part feel much better.
|
||||
|
||||
## 11. Summary
|
||||
|
||||
The real value of JTBD is not the label. It is the shift in perspective:
|
||||
|
||||
- stop looking first at features
|
||||
- start looking at the progress users are trying to make
|
||||
|
||||
If you keep asking:
|
||||
|
||||
- In what situation does the user hire this?
|
||||
- What exactly are they stuck on?
|
||||
- What workaround are they using now?
|
||||
- What would “better” look like for them?
|
||||
|
||||
your idea usually becomes much sharper.
|
||||
|
||||
It also helps you avoid one of the biggest mistakes in AI products: falling in love with capability demos instead of user progress.
|
||||
|
||||
<a id="jtbd-ai"></a>
|
||||
## 12. How AI Can Help You Practice JTBD [↩ Back to top](#top-jtbd)
|
||||
|
||||
JTBD is not an AI invention, but AI can be a very helpful research assistant, organizer, and challenger. The key is this:
|
||||
|
||||
**use AI to organize and expand your thinking, not to invent user truth for you.**
|
||||
|
||||
### 12.1 Turn a vague idea into candidate JTBD statements
|
||||
|
||||
```text
|
||||
I currently have a vague product idea: [your idea].
|
||||
Do not give me a feature list yet.
|
||||
Use Jobs to Be Done to help me analyze:
|
||||
1. What situations might this idea fit?
|
||||
2. What progress might users want in each situation?
|
||||
3. What current alternatives might they be using?
|
||||
4. Which job feels best as an MVP starting point?
|
||||
Write each job as one clear JTBD sentence.
|
||||
```
|
||||
|
||||
You can also write a very beginner-style input like this:
|
||||
|
||||
```text
|
||||
I want to build something that helps college students find internships.
|
||||
I can't explain it clearly yet.
|
||||
Help me figure out what users might actually be trying to get done.
|
||||
```
|
||||
|
||||
Possible AI output:
|
||||
|
||||
```text
|
||||
Possible JTBD directions:
|
||||
|
||||
1. When I start internship applications, I want to know what I need to prepare first,
|
||||
so I do not keep delaying because everything feels confusing.
|
||||
|
||||
2. When I see a job post, I want to quickly judge whether it is worth applying to,
|
||||
so I do not waste energy on poor-fit roles.
|
||||
|
||||
3. When I am ready to apply, I want to adapt my resume to a specific role,
|
||||
so I can submit faster and feel more confident.
|
||||
```
|
||||
|
||||
The value here is that AI helps split one fuzzy idea into several clearer directions.
|
||||
|
||||
### 12.2 Organize raw interview notes
|
||||
|
||||
```text
|
||||
Below are raw notes from 5 user interviews.
|
||||
Do not suggest solutions yet.
|
||||
First organize them using JTBD:
|
||||
1. What situation is the user in?
|
||||
2. What event triggered action?
|
||||
3. What progress are they trying to make?
|
||||
4. What is the current workaround?
|
||||
5. What success condition matters most?
|
||||
6. What patterns repeat across users?
|
||||
|
||||
Then summarize 3 JTBD hypotheses worth validating first.
|
||||
```
|
||||
|
||||
A very simple beginner input can look like this:
|
||||
|
||||
```text
|
||||
I asked 3 people and they roughly said:
|
||||
|
||||
1. Every time I apply for internships, I have to redo my resume and it's annoying.
|
||||
2. I mostly worry that I still don't know if it's good enough.
|
||||
3. Right now I ask seniors for help, but I don't want to bother them too often.
|
||||
|
||||
Please help me summarize the real job they are trying to get done.
|
||||
```
|
||||
|
||||
Possible AI output:
|
||||
|
||||
```text
|
||||
Organized result:
|
||||
|
||||
- common situation: preparing internship applications
|
||||
- common pain: uncertainty about whether the resume is ready enough
|
||||
- current workaround: asking seniors, revising manually
|
||||
- possible JTBD:
|
||||
When I am preparing to apply, I want to know whether my resume is ready enough to send,
|
||||
so I stop getting stuck in endless revisions.
|
||||
```
|
||||
|
||||
This is useful because it turns messy quotes into something closer to a real need.
|
||||
|
||||
### 12.3 Do light web research before interviews
|
||||
|
||||
Before larger interview work, AI can help you do a light scan of outside information:
|
||||
|
||||
- how people complain about this problem in public communities
|
||||
- what existing tools mostly solve
|
||||
- what common workarounds people use
|
||||
- what users praise or dislike in current solutions
|
||||
|
||||
This does not replace real user interviews, but it is a good warm-up for the Discover phase.
|
||||
|
||||
Simple input:
|
||||
|
||||
```text
|
||||
Please look up common pain points students mention when editing resumes and applying for internships.
|
||||
Focus on forums, public communities, and real user complaints.
|
||||
Summarize the top 5 patterns.
|
||||
```
|
||||
|
||||
Possible AI output:
|
||||
|
||||
```text
|
||||
Top recurring pain points:
|
||||
1. Not knowing what to include
|
||||
2. Not knowing how to tailor a resume for different roles
|
||||
3. Feeling unsure whether the resume is good enough
|
||||
4. Lack of reliable feedback
|
||||
5. Delaying applications because the process feels heavy
|
||||
```
|
||||
|
||||
This kind of output is not final truth, but it helps you start interviews with a better map.
|
||||
|
||||
### 12.4 Ask AI to play the critic
|
||||
|
||||
Sometimes we get emotionally attached to our own ideas. AI can help by acting as a strict critic:
|
||||
|
||||
```text
|
||||
Act as a very strict product research advisor.
|
||||
Here is my JTBD hypothesis: [your hypothesis]
|
||||
Critique it from these angles:
|
||||
1. Is the situation still too broad?
|
||||
2. Is this actually a feature, not a progress statement?
|
||||
3. Are the alternatives too weak?
|
||||
4. Is the success condition too vague?
|
||||
5. What risk most needs validation?
|
||||
```
|
||||
|
||||
That kind of challenge helps you see whether you are really looking at user needs or just defending your favorite solution.
|
||||
|
||||
## Assignments
|
||||
|
||||
1. Pick one product idea and rewrite it into one JTBD sentence
|
||||
2. Add the five parts: situation, trigger, progress, workaround, success condition
|
||||
3. Talk to 3 potential users about the last time they faced this problem
|
||||
4. Give the interview notes to AI and ask it to summarize 3 possible JTBD hypotheses
|
||||
|
||||
## Further Reading
|
||||
|
||||
- [Christensen Institute: Jobs to Be Done](https://www.christenseninstitute.org/theory/jobs-to-be-done/)
|
||||
- [Harvard Business School Online: What Is Jobs to Be Done?](https://online.hbs.edu/blog/post/jobs-to-be-done)
|
||||
- [Intercom: Jobs-to-be-Done: A framework for customer needs](https://www.intercom.com/blog/jobs-to-be-done-framework/)
|
||||
- [Mural: Jobs to Be Done framework guide](https://www.mural.co/blog/jobs-to-be-done-framework)
|
||||
@@ -0,0 +1,513 @@
|
||||
---
|
||||
title: 'The Mom Test: How to Validate Demand Through User Interviews'
|
||||
description: 'A beginner-friendly introduction to The Mom Test. Learn how to stop collecting polite praise and start getting evidence from real behavior, real costs, and real user situations.'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = 'About <strong>1.5 hours</strong>'
|
||||
</script>
|
||||
|
||||
# The Mom Test: How to Validate Demand Through User Interviews
|
||||
|
||||
<a id="top-mom"></a>
|
||||
|
||||
## Introduction
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['User Interviews', 'Validation', 'Research', 'Product Discovery']"
|
||||
coreOutput="1 set of interview questions more likely to reveal real user information"
|
||||
expectedOutput="Stop treating polite encouragement as validation and start judging direction through real behavior"
|
||||
>
|
||||
|
||||
When beginners start product research, they often ask questions like:
|
||||
|
||||
- What do you think of this idea?
|
||||
- Would you use this if I built it?
|
||||
- Does this feature sound useful?
|
||||
|
||||
The answers usually sound encouraging. The problem is that they are often not useful. They are often just politeness, support, or a natural instinct to avoid discouraging you face-to-face.
|
||||
|
||||
That is exactly what **The Mom Test** is about: not how to get nicer conversations, but how to ask questions that reveal real evidence instead of polite support.
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info Minimal SOP
|
||||
**Goal**: After this, you should be better at talking to users in a way that gives you useful evidence, not just nice-sounding feedback.
|
||||
|
||||
**Action**: Rewrite 5 interview questions so they focus on real past behavior instead of opinions about your idea.
|
||||
|
||||
**Result**: You will leave with a clearer sense of what counts as evidence and what is just encouragement.
|
||||
|
||||
**Quick links**: [What The Mom Test is](#mom-what) · [Core principles](#mom-principles) · [How AI can help](#mom-ai)
|
||||
:::
|
||||
|
||||
## What You Will Learn
|
||||
|
||||
1. What problem The Mom Test is really solving
|
||||
2. Why many “user interviews” fail to produce useful truth
|
||||
3. How to rewrite weak, leading questions into stronger ones
|
||||
4. How The Mom Test connects with JTBD, validation, and MVP decisions
|
||||
|
||||
<a id="mom-what"></a>
|
||||
## 1. What The Mom Test Is [↩ Back to top](#top-mom)
|
||||
|
||||
The Mom Test comes from Rob Fitzpatrick's book of the same name. The title sounds playful, but the point is sharp:
|
||||
|
||||
Even your mom will struggle to tell you your idea is bad if you ask the wrong question.
|
||||
|
||||
The problem is not that users are trying to lie. The problem is that your question format often invites nice but weak answers.
|
||||
|
||||
It is not really “don't ask your mom.” It is:
|
||||
|
||||
**don't ask in a way that makes almost anyone give you a flattering answer.**
|
||||
|
||||
## 2. The Core Problem It Solves
|
||||
|
||||
The Mom Test helps you avoid a very common mistake:
|
||||
|
||||
**mistaking polite positive feedback for real demand.**
|
||||
|
||||
Questions like these are dangerous:
|
||||
|
||||
- What do you think of my app idea?
|
||||
- Would you use this if it existed?
|
||||
- Would you pay for this?
|
||||
|
||||
They ask for opinion, prediction, or encouragement. Those are much less reliable than actual behavior.
|
||||
|
||||
People also tend to overestimate their future selves. They imagine they will be more disciplined, more experimental, or more willing to pay than they really are.
|
||||
|
||||
That is why “I would probably use that” is usually much weaker than “last week I spent three hours doing this manually.”
|
||||
|
||||
<a id="mom-principles"></a>
|
||||
## 3. Three Core Principles [↩ Back to top](#top-mom)
|
||||
|
||||
### 3.1 Talk about their life, not your idea
|
||||
|
||||
Many weak interviews begin with too much explanation of your product. Once you explain too much, the other person often shifts into “supportive mode.”
|
||||
|
||||
Instead, ask about their actual experience:
|
||||
|
||||
- When was the last time this happened?
|
||||
- What were you doing?
|
||||
- How did you handle it?
|
||||
- Which part felt annoying or difficult?
|
||||
|
||||
### 3.2 Ask about facts, not opinions
|
||||
|
||||
“Sounds useful” is weak.
|
||||
“I spent 3 hours doing this last week” is much stronger.
|
||||
|
||||
Useful information usually looks like this:
|
||||
|
||||
- I spent two hours on this last week
|
||||
- I am currently holding it together with Excel and chat
|
||||
- I already paid for something related to this
|
||||
- My real fear is making mistakes, not moving slowly
|
||||
|
||||
### 3.3 Look for the problem, not their proposed solution
|
||||
|
||||
Users are usually better at describing pain than designing the right product.
|
||||
|
||||
If you ask:
|
||||
|
||||
- Would you like an AI to do this automatically?
|
||||
- Would a smart feature help?
|
||||
|
||||
you often get a vague opinion about your idea rather than evidence about the problem.
|
||||
|
||||
Better questions are:
|
||||
|
||||
- What do you do now?
|
||||
- Why do you do it that way?
|
||||
- What is frustrating about that method?
|
||||
|
||||
## 4. Why People Give Nice but Unhelpful Answers
|
||||
|
||||
If you understand this, you make fewer mistakes during interviews.
|
||||
|
||||
### 4.1 People want to be polite
|
||||
|
||||
Especially when the person knows you, they often do not want to say:
|
||||
|
||||
- this does not sound very strong
|
||||
- I would never use this
|
||||
- this is not a real problem for me
|
||||
|
||||
So they soften the truth.
|
||||
|
||||
### 4.2 People overestimate their future selves
|
||||
|
||||
They sincerely believe they will:
|
||||
|
||||
- be more disciplined
|
||||
- be more willing to try something new
|
||||
- be more willing to pay
|
||||
- be more proactive next time
|
||||
|
||||
That makes future-intention answers especially risky.
|
||||
|
||||
### 4.3 Your question can secretly lead the answer
|
||||
|
||||
When you ask:
|
||||
|
||||
- Does this sound useful?
|
||||
- This feature would help, right?
|
||||
|
||||
you are already hinting at the “good” answer.
|
||||
|
||||
That is one reason The Mom Test warns you not to turn interviews into a search for reassurance.
|
||||
|
||||
## 5. Weak Questions vs Better Questions
|
||||
|
||||
| Weak question | Better question |
|
||||
| --- | --- |
|
||||
| What do you think of this idea? | When was the last time this happened to you? |
|
||||
| Would you use this? | How do you handle this now? |
|
||||
| Would you pay for this? | Have you already spent time or money on this problem? |
|
||||
| Does this feature matter? | What part of the process feels slow, frustrating, or risky? |
|
||||
| Would you want an AI to do this? | Why have you not found a better workaround yet? |
|
||||
|
||||
The key shift is:
|
||||
|
||||
- from opinion to fact
|
||||
- from future to past
|
||||
- from your solution to their problem
|
||||
|
||||
## 6. A Simple Interview Flow You Can Use Right Away
|
||||
|
||||
### 6.1 Open as a learner, not a seller
|
||||
|
||||
For example:
|
||||
|
||||
> I'm trying to understand how people deal with this in real life. I'm not selling anything right now.
|
||||
|
||||
That lowers the pressure to encourage you.
|
||||
|
||||
### 6.2 Start from the last real incident
|
||||
|
||||
Good starting questions:
|
||||
|
||||
- When was the last time this happened?
|
||||
- What happened?
|
||||
- What did you do first?
|
||||
|
||||
Once the conversation enters a real event, information quality usually improves.
|
||||
|
||||
### 6.3 Then ask about behavior, costs, and alternatives
|
||||
|
||||
- What do you do now?
|
||||
- What is annoying about that method?
|
||||
- How much time, money, or energy does it cost?
|
||||
- What else have you tried?
|
||||
|
||||
### 6.4 Only then judge pain and priority
|
||||
|
||||
You do not need to ask “how painful is this?” directly. Look for clues:
|
||||
|
||||
- does it happen often?
|
||||
- are they already actively patching the problem?
|
||||
- have they already paid some cost?
|
||||
- do they speak about it with emotion?
|
||||
|
||||
## 7. A More Complete Example
|
||||
|
||||
Suppose you want to build an AI resume-improvement product for students.
|
||||
|
||||
### Weak questions
|
||||
|
||||
> What do you think of an AI resume optimizer?
|
||||
> If it automatically rewrote your resume for job descriptions, would you use it?
|
||||
|
||||
Likely answers:
|
||||
|
||||
- sounds good
|
||||
- probably useful
|
||||
- I would try it if it was free
|
||||
|
||||
Those answers do not tell you much.
|
||||
|
||||
### Better questions
|
||||
|
||||
Try this instead:
|
||||
|
||||
> When was the last time you edited your resume?
|
||||
> Why did you need to edit it?
|
||||
> How did you do it?
|
||||
> Which step felt hardest?
|
||||
> Did you ask anyone for help?
|
||||
> Have you ever spent money or a lot of time on this?
|
||||
|
||||
What you may learn:
|
||||
|
||||
- many people do not mainly struggle with writing, but with tailoring
|
||||
- the biggest pain is often not formatting, but not knowing what belongs
|
||||
- delay is often not laziness, but exhaustion from repeated revision
|
||||
- current workarounds include seniors, templates, AI tools, and friends
|
||||
|
||||
That is much closer to truth.
|
||||
|
||||
## 8. How The Mom Test Works with JTBD
|
||||
|
||||
If JTBD helps you see what progress users are trying to make, The Mom Test helps you:
|
||||
|
||||
**check whether that job is actually real.**
|
||||
|
||||
You can combine them like this:
|
||||
|
||||
1. use JTBD to draft a job hypothesis
|
||||
2. use The Mom Test style questions to ask about the last real situation
|
||||
3. judge whether that job is frequent, painful, and worth prioritizing
|
||||
|
||||
Example JTBD hypothesis:
|
||||
|
||||
> When I am preparing internship applications, I want to adapt my old resume into a role-specific version so I can submit faster.
|
||||
|
||||
Now validate it with questions like:
|
||||
|
||||
- When was your last internship application?
|
||||
- How did you edit your resume?
|
||||
- Which part was hardest to rewrite?
|
||||
- How did you judge whether it was ready?
|
||||
|
||||
That is how the two methods connect:
|
||||
|
||||
- JTBD helps define the hypothesis
|
||||
- The Mom Test helps validate it through conversation
|
||||
|
||||
## 9. Common Beginner Mistakes in Interviews
|
||||
|
||||
### 9.1 Turning the interview into a product presentation
|
||||
|
||||
If you explain too much, the other person starts helping you instead of telling you the truth.
|
||||
|
||||
### 9.2 Interviewing only friends
|
||||
|
||||
Friends are not useless, but they are more likely to encourage you. You need at least some people who are closer to real users and less emotionally invested in you.
|
||||
|
||||
### 9.3 Asking about features too early
|
||||
|
||||
If the problem is still unclear, detailed feature questions usually mean you are jumping into solutions too soon.
|
||||
|
||||
### 9.4 Treating “I would use it” as validation
|
||||
|
||||
Interviews help you judge direction, but they are not the whole validation step. Real validation still depends on real cost: time, switching effort, trial behavior, or payment.
|
||||
|
||||
### 9.5 Not organizing what you learned
|
||||
|
||||
If you do not整理 the conversation, it quickly becomes a blurry memory. Try to capture:
|
||||
|
||||
- repeated problems
|
||||
- emotional words
|
||||
- current workarounds
|
||||
- already-paid costs
|
||||
- your new judgment
|
||||
|
||||
## 10. A Reusable Question Checklist
|
||||
|
||||
If you want to start quickly, this set is broad enough for many interviews.
|
||||
|
||||
### Opening questions
|
||||
|
||||
- When was the last time this problem happened?
|
||||
- What exactly happened?
|
||||
|
||||
### Behavior questions
|
||||
|
||||
- How did you handle it?
|
||||
- Why did you do it that way?
|
||||
|
||||
### Cost questions
|
||||
|
||||
- How much time or energy does this usually cost?
|
||||
- Have you ever spent money to solve it?
|
||||
|
||||
### Alternative questions
|
||||
|
||||
- What other tools or methods have you tried?
|
||||
- Why did you stop using them?
|
||||
|
||||
### Closing question
|
||||
|
||||
- If this problem came up again, what would an ideal solution feel like?
|
||||
|
||||
This is okay to ask near the end, but not at the start. First you need facts, not wishes.
|
||||
|
||||
## 11. Summary
|
||||
|
||||
The Mom Test is not mainly about charm or conversation skills. It is about building better judgment.
|
||||
|
||||
Do not over-trust:
|
||||
|
||||
- compliments
|
||||
- future promises
|
||||
- “I would probably use that”
|
||||
|
||||
Trust more in:
|
||||
|
||||
- recent real behavior
|
||||
- current workarounds
|
||||
- real costs already paid
|
||||
- repeated pain patterns
|
||||
|
||||
Useful truth may sound less flattering, but it is far more valuable than encouraging noise.
|
||||
|
||||
<a id="mom-ai"></a>
|
||||
## 12. How AI Can Help with Interviews [↩ Back to top](#top-mom)
|
||||
|
||||
AI cannot replace real user interviews, but it can be a strong helper before, during, and after them.
|
||||
|
||||
### 12.1 Rewrite weak questions
|
||||
|
||||
```text
|
||||
I plan to ask users:
|
||||
1. What do you think of my AI resume tool?
|
||||
2. Would you use it?
|
||||
3. Would you pay for it?
|
||||
|
||||
Please rewrite these using The Mom Test style.
|
||||
```
|
||||
|
||||
A very beginner-style input is perfectly fine:
|
||||
|
||||
```text
|
||||
I want to ask users:
|
||||
1. What do you think of my AI resume tool?
|
||||
2. Would you use it?
|
||||
3. Would you pay for it?
|
||||
|
||||
Please turn these into better interview questions.
|
||||
```
|
||||
|
||||
Possible AI output:
|
||||
|
||||
```text
|
||||
Try asking:
|
||||
1. When was the last time you edited your resume?
|
||||
2. Why did you need to edit it?
|
||||
3. How did you do it?
|
||||
4. What part took the most effort?
|
||||
5. Did you ask anyone for help?
|
||||
6. Have you ever spent money or a lot of time solving this?
|
||||
```
|
||||
|
||||
This is useful because it turns opinion-seeking questions into behavior-seeking questions.
|
||||
|
||||
### 12.2 Create different interview guides for different user types
|
||||
|
||||
The same problem feels different to students, hiring managers, and senior peers. AI can help generate separate interview guides for each group.
|
||||
|
||||
Example input:
|
||||
|
||||
```text
|
||||
I want to interview two groups:
|
||||
1. students applying for internships for the first time
|
||||
2. seniors who often review resumes
|
||||
|
||||
Please create 6 interview questions for each group.
|
||||
```
|
||||
|
||||
Possible AI output:
|
||||
|
||||
```text
|
||||
For students:
|
||||
1. When was your last internship application?
|
||||
2. What part felt hardest?
|
||||
3. How do you judge whether your resume is ready?
|
||||
...
|
||||
|
||||
For seniors:
|
||||
1. When did you last review a junior's resume?
|
||||
2. What common issues do you see most often?
|
||||
3. Where do students usually get stuck?
|
||||
...
|
||||
```
|
||||
|
||||
### 12.3 Sort interview notes into facts vs opinions
|
||||
|
||||
```text
|
||||
Here are notes from one interview:
|
||||
- she said she would probably try such a tool
|
||||
- last week she spent one full evening editing her resume
|
||||
- she currently asks friends for feedback
|
||||
- she is not sure when a resume is "good enough"
|
||||
|
||||
Please separate facts from opinions.
|
||||
```
|
||||
|
||||
Possible AI output:
|
||||
|
||||
```text
|
||||
Opinion:
|
||||
- she would probably try such a tool
|
||||
|
||||
Facts:
|
||||
- she spent one full evening editing her resume
|
||||
- she currently depends on friends for feedback
|
||||
- she struggles to tell when a resume is good enough
|
||||
|
||||
Useful demand evidence:
|
||||
- the problem happened recently
|
||||
- she has already paid a meaningful time cost
|
||||
- her workaround depends on other people and is unstable
|
||||
```
|
||||
|
||||
That makes it much easier for beginners to see which notes support a decision and which ones are just conversational noise.
|
||||
|
||||
### 12.4 Do a light web search before interviews
|
||||
|
||||
Before you even begin interviews, AI can help with a light external scan:
|
||||
|
||||
- how people complain about the problem in public communities
|
||||
- what tools get criticized most often
|
||||
- whether users already spend money on related solutions
|
||||
- what alternatives already exist
|
||||
|
||||
Example input:
|
||||
|
||||
```text
|
||||
Please look up:
|
||||
"What do students complain about most when editing resumes?"
|
||||
Summarize the 5 most common complaints in simple language.
|
||||
```
|
||||
|
||||
Possible AI output:
|
||||
|
||||
```text
|
||||
Common complaints:
|
||||
1. I don't know what belongs on the resume
|
||||
2. I have to rewrite it for every role and it's exhausting
|
||||
3. I keep editing but still don't know if it's good enough
|
||||
4. I don't have reliable feedback
|
||||
5. I keep delaying because I never feel ready
|
||||
```
|
||||
|
||||
This does not replace real interviews, but it helps you enter interviews with a better starting map.
|
||||
|
||||
### 12.5 Ask AI to review your interview technique
|
||||
|
||||
You can also paste one interview transcript and ask AI to critique your questioning:
|
||||
|
||||
```text
|
||||
Here is a transcript from one user interview.
|
||||
Please review it using The Mom Test:
|
||||
1. Which questions sound like I was seeking reassurance?
|
||||
2. Which ones were leading?
|
||||
3. Where should I have asked more about facts?
|
||||
4. How could I ask this better next time?
|
||||
```
|
||||
|
||||
That is especially helpful for beginners because it trains the instinct to ask, “Am I collecting evidence or just collecting encouragement?”
|
||||
|
||||
## Assignments
|
||||
|
||||
1. Write 5 weak interview questions you might normally ask
|
||||
2. Rewrite them in The Mom Test style
|
||||
3. Interview 3 potential users about the last time the problem happened
|
||||
4. Sort your notes into facts, workarounds, costs, and repeated pain points
|
||||
|
||||
## Further Reading
|
||||
|
||||
- [The Mom Test official site](https://momtestbook.com/)
|
||||
- [Rob Fitzpatrick: The Mom Test](https://www.robfitz.com/the-mom-test/)
|
||||
Reference in New Issue
Block a user