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
@@ -385,6 +385,24 @@ const productManagerSidebarEn = [
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
text: 'Appendix: User Research and Validation',
|
||||
collapsed: false,
|
||||
items: [
|
||||
{
|
||||
text: 'Jobs to Be Done',
|
||||
link: '/en/stage-1/appendix-jobs-to-be-done/'
|
||||
},
|
||||
{
|
||||
text: 'The Mom Test',
|
||||
link: '/en/stage-1/appendix-mom-test/'
|
||||
},
|
||||
{
|
||||
text: 'Double Diamond',
|
||||
link: '/en/stage-1/appendix-double-diamond/'
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
text: 'Appendix: Technical Solutions',
|
||||
collapsed: false,
|
||||
@@ -1174,6 +1192,28 @@ const productManagerSidebar = [
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
text: '附录：用户研究与需求验证',
|
||||
collapsed: false,
|
||||
items: [
|
||||
{
|
||||
text: '从哪里找点子：3 种最适合新手的参考来源',
|
||||
link: '/zh-cn/stage-1/appendix-idea-sources/'
|
||||
},
|
||||
{
|
||||
text: '双钻模型：先做对的事，再把事做对',
|
||||
link: '/zh-cn/stage-1/appendix-double-diamond/'
|
||||
},
|
||||
{
|
||||
text: '用 Jobs to Be Done 找到用户真正想完成的事',
|
||||
link: '/zh-cn/stage-1/appendix-jobs-to-be-done/'
|
||||
},
|
||||
{
|
||||
text: 'The Mom Test 用户访谈法',
|
||||
link: '/zh-cn/stage-1/appendix-mom-test/'
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
text: '附录：技术方案',
|
||||
collapsed: false,
|
||||
|
||||
@@ -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/)
|
||||
+88
-50
@@ -749,7 +749,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/appendix/</loc>
|
||||
<lastmod>2026-03-14T22:17:12+08:00</lastmod>
|
||||
<lastmod>2026-03-25T08:37:27+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.7</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/appendix/"/>
|
||||
@@ -804,15 +804,22 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/1.0-finding-great-idea/</loc>
|
||||
<lastmod>2026-03-06T17:59:01+08:00</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.9</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/1.0-finding-great-idea/"/>
|
||||
<xhtml:link rel="alternate" hreflang="en" href="https://datawhalechina.github.io/easy-vibe/en/stage-1/1.0-finding-great-idea/"/>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/1.0-finding-great-idea/index.temp-0114254/</loc>
|
||||
<lastmod>2026-03-25T01:55:32.527Z</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.9</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/1.0-finding-great-idea/index.temp-0114254/"/>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/1.1-introduction-to-ai-ide/</loc>
|
||||
<lastmod>2026-03-18T07:57:16-05:00</lastmod>
|
||||
<lastmod>2026-03-25T08:37:27+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.9</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/1.1-introduction-to-ai-ide/"/>
|
||||
@@ -820,7 +827,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/1.2-building-prototype/</loc>
|
||||
<lastmod>2026-03-16T12:42:29+08:00</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.9</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/1.2-building-prototype/"/>
|
||||
@@ -828,7 +835,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/1.3-integrating-ai-capabilities/</loc>
|
||||
<lastmod>2026-03-18T07:57:16-05:00</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.9</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/1.3-integrating-ai-capabilities/"/>
|
||||
@@ -884,23 +891,54 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-consumer-scenarios/</loc>
|
||||
<lastmod>2026-03-06T17:59:01+08:00</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.9</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-consumer-scenarios/"/>
|
||||
<xhtml:link rel="alternate" hreflang="en" href="https://datawhalechina.github.io/easy-vibe/en/stage-1/appendix-consumer-scenarios/"/>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-double-diamond/</loc>
|
||||
<lastmod>2026-03-25T06:31:44.977Z</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.9</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-double-diamond/"/>
|
||||
<xhtml:link rel="alternate" hreflang="en" href="https://datawhalechina.github.io/easy-vibe/en/stage-1/appendix-double-diamond/"/>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-idea-sources/</loc>
|
||||
<lastmod>2026-03-25T06:47:22.347Z</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.9</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-idea-sources/"/>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-industry-scenarios/</loc>
|
||||
<lastmod>2026-03-06T17:59:01+08:00</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.9</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-industry-scenarios/"/>
|
||||
<xhtml:link rel="alternate" hreflang="en" href="https://datawhalechina.github.io/easy-vibe/en/stage-1/appendix-industry-scenarios/"/>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-jobs-to-be-done/</loc>
|
||||
<lastmod>2026-03-25T06:31:44.976Z</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.9</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-jobs-to-be-done/"/>
|
||||
<xhtml:link rel="alternate" hreflang="en" href="https://datawhalechina.github.io/easy-vibe/en/stage-1/appendix-jobs-to-be-done/"/>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-mom-test/</loc>
|
||||
<lastmod>2026-03-25T06:31:44.976Z</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.9</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-mom-test/"/>
|
||||
<xhtml:link rel="alternate" hreflang="en" href="https://datawhalechina.github.io/easy-vibe/en/stage-1/appendix-mom-test/"/>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/ai-capabilities/2.1-dify-knowledge-base/</loc>
|
||||
<lastmod>2026-03-24T08:44:49.470Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/ai-capabilities/2.1-dify-knowledge-base/"/>
|
||||
@@ -908,7 +946,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/assignments/2.1-fullstack-app/</loc>
|
||||
<lastmod>2026-03-24T07:00:25.007Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/assignments/2.1-fullstack-app/"/>
|
||||
@@ -916,7 +954,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/assignments/2.2-modern-frontend-trae/</loc>
|
||||
<lastmod>2026-03-24T07:00:25.008Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/assignments/2.2-modern-frontend-trae/"/>
|
||||
@@ -924,7 +962,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/backend/2.2-database-supabase/</loc>
|
||||
<lastmod>2026-03-24T10:17:02.326Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/backend/2.2-database-supabase/"/>
|
||||
@@ -932,7 +970,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/backend/2.3-ai-interface-code/</loc>
|
||||
<lastmod>2026-03-23T15:51:59.282Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/backend/2.3-ai-interface-code/"/>
|
||||
@@ -940,7 +978,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/backend/2.4-git-workflow/</loc>
|
||||
<lastmod>2026-03-24T10:08:14.884Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/backend/2.4-git-workflow/"/>
|
||||
@@ -948,7 +986,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/backend/2.5-zeabur-deployment/</loc>
|
||||
<lastmod>2026-03-24T01:20:30.534Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/backend/2.5-zeabur-deployment/"/>
|
||||
@@ -956,7 +994,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/backend/2.6-modern-cli/</loc>
|
||||
<lastmod>2026-03-24T09:29:56.836Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/backend/2.6-modern-cli/"/>
|
||||
@@ -964,7 +1002,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/backend/2.7-stripe-payment/</loc>
|
||||
<lastmod>2026-03-24T07:00:25.008Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/backend/2.7-stripe-payment/"/>
|
||||
@@ -972,7 +1010,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.0-lovart-assets/</loc>
|
||||
<lastmod>2026-03-24T08:28:32.292Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.0-lovart-assets/"/>
|
||||
@@ -980,7 +1018,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.1-figma-mastergo/</loc>
|
||||
<lastmod>2026-03-23T15:48:55.095Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.1-figma-mastergo/"/>
|
||||
@@ -988,7 +1026,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.2-ui-design/</loc>
|
||||
<lastmod>2026-03-24T07:00:25.008Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.2-ui-design/"/>
|
||||
@@ -996,7 +1034,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.3-multi-product-ui/</loc>
|
||||
<lastmod>2026-03-24T05:49:47.526Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.3-multi-product-ui/"/>
|
||||
@@ -1004,7 +1042,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.4-llm-skills-beautiful/</loc>
|
||||
<lastmod>2026-03-24T09:24:24.080Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.4-llm-skills-beautiful/"/>
|
||||
@@ -1012,7 +1050,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.5-hogwarts-portraits/</loc>
|
||||
<lastmod>2026-03-24T01:18:35.782Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.5-hogwarts-portraits/"/>
|
||||
@@ -1020,7 +1058,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.6-design-to-code/</loc>
|
||||
<lastmod>2026-03-23T15:51:59.282Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.6-design-to-code/"/>
|
||||
@@ -1028,7 +1066,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.7-modern-component-library/</loc>
|
||||
<lastmod>2026-03-24T10:12:29.711Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.7-modern-component-library/"/>
|
||||
@@ -1036,7 +1074,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/</loc>
|
||||
<lastmod>2026-03-14T22:17:12+08:00</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/"/>
|
||||
@@ -1052,7 +1090,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/ai-advanced/3.a1-rag-introduction/</loc>
|
||||
<lastmod>2026-03-24T07:30:22.563Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/ai-advanced/3.a1-rag-introduction/"/>
|
||||
@@ -1060,7 +1098,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/ai-advanced/3.a2-langgraph-advanced-rag/</loc>
|
||||
<lastmod>2026-03-24T07:00:25.008Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/ai-advanced/3.a2-langgraph-advanced-rag/"/>
|
||||
@@ -1068,7 +1106,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/agent-teams/</loc>
|
||||
<lastmod>2026-03-24T16:19:04.205Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/agent-teams/"/>
|
||||
@@ -1076,7 +1114,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/basics/</loc>
|
||||
<lastmod>2026-03-24T08:39:26.659Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/basics/"/>
|
||||
@@ -1084,7 +1122,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/claude-agent-sdk/</loc>
|
||||
<lastmod>2026-03-24T08:26:09.452Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/claude-agent-sdk/"/>
|
||||
@@ -1092,7 +1130,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/long-running-tasks/</loc>
|
||||
<lastmod>2026-03-24T08:29:07.591Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/long-running-tasks/"/>
|
||||
@@ -1100,7 +1138,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/mcp/</loc>
|
||||
<lastmod>2026-03-24T08:06:58.426Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/mcp/"/>
|
||||
@@ -1108,7 +1146,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/mobile-development/</loc>
|
||||
<lastmod>2026-03-24T08:26:46.026Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/mobile-development/"/>
|
||||
@@ -1116,7 +1154,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/skills/</loc>
|
||||
<lastmod>2026-03-24T08:27:00.403Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/skills/"/>
|
||||
@@ -1124,7 +1162,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/spec-coding/</loc>
|
||||
<lastmod>2026-03-24T08:15:15.558Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/spec-coding/"/>
|
||||
@@ -1132,7 +1170,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/superpowers/</loc>
|
||||
<lastmod>2026-03-24T08:27:46.387Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/superpowers/"/>
|
||||
@@ -1140,7 +1178,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/workflow/</loc>
|
||||
<lastmod>2026-03-24T10:34:29.162Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/workflow/"/>
|
||||
@@ -1148,7 +1186,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.1-choose-platform/</loc>
|
||||
<lastmod>2026-03-24T06:11:17.435Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.1-choose-platform/"/>
|
||||
@@ -1156,7 +1194,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.10-electron-voice-to-text/</loc>
|
||||
<lastmod>2026-03-24T06:30:57.078Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.10-electron-voice-to-text/"/>
|
||||
@@ -1164,7 +1202,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.11-nft-minting/</loc>
|
||||
<lastmod>2026-03-24T06:30:57.087Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.11-nft-minting/"/>
|
||||
@@ -1172,7 +1210,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.12-vscode-extension/</loc>
|
||||
<lastmod>2026-03-24T06:30:57.099Z</lastmod>
|
||||
<lastmod>2026-03-25T00:56:13+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.12-vscode-extension/"/>
|
||||
@@ -1180,7 +1218,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.13-qt-industrial-hmi/</loc>
|
||||
<lastmod>2026-03-24T06:30:57.106Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.13-qt-industrial-hmi/"/>
|
||||
@@ -1188,7 +1226,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.3-wechat-miniprogram/</loc>
|
||||
<lastmod>2026-03-24T06:30:57.025Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.3-wechat-miniprogram/"/>
|
||||
@@ -1196,7 +1234,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.4-wechat-miniprogram-backend/</loc>
|
||||
<lastmod>2026-03-24T06:08:37.178Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.4-wechat-miniprogram-backend/"/>
|
||||
@@ -1204,7 +1242,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.5-android-app/</loc>
|
||||
<lastmod>2026-03-24T06:30:57.033Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.5-android-app/"/>
|
||||
@@ -1212,7 +1250,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.6-ios-app/</loc>
|
||||
<lastmod>2026-03-24T06:30:57.049Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.6-ios-app/"/>
|
||||
@@ -1220,7 +1258,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.8-pwa-local-app/</loc>
|
||||
<lastmod>2026-03-24T06:30:57.061Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.8-pwa-local-app/"/>
|
||||
@@ -1228,7 +1266,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.9-browser-ai-extension/</loc>
|
||||
<lastmod>2026-03-24T06:30:57.068Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.9-browser-ai-extension/"/>
|
||||
@@ -1236,7 +1274,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/</loc>
|
||||
<lastmod>2026-03-07T14:11:01+08:00</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/"/>
|
||||
@@ -1252,7 +1290,7 @@
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/personal-brand/3.7-personal-website-blog/</loc>
|
||||
<lastmod>2026-03-24T08:04:35.919Z</lastmod>
|
||||
<lastmod>2026-03-25T00:28:36+08:00</lastmod>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
<xhtml:link rel="alternate" hreflang="zh-CN" href="https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/personal-brand/3.7-personal-website-blog/"/>
|
||||
|
||||
@@ -42,6 +42,10 @@
|
||||
| :-------------------------------------------------------------------- | :---------------------------------------- | :--- |
|
||||
| [附录A：产品思维补充](/zh-cn/stage-1/appendix-a-product-thinking/) | 从想法评估到需求拆解与 MVP 的产品思维框架 | ✅ |
|
||||
| [附录B：常见报错及解决方案](/zh-cn/stage-1/appendix-b-common-errors/) | vibe coding 中的常见错误及排查方法 | ✅ |
|
||||
| [附录：从哪里找点子](/zh-cn/stage-1/appendix-idea-sources/) | 从参考应用、趋势和 VC 清单里收出细分方向 | ✅ |
|
||||
| [附录：双钻模型](/zh-cn/stage-1/appendix-double-diamond/) | 理解先定义问题，再展开方案设计的完整节奏 | ✅ |
|
||||
| [附录：Jobs to Be Done](/zh-cn/stage-1/appendix-jobs-to-be-done/) | 用 JTBD 方法看清用户真正想完成的事 | ✅ |
|
||||
| [附录：The Mom Test 用户访谈法](/zh-cn/stage-1/appendix-mom-test/) | 通过用户访谈验证需求的调研方法 | ✅ |
|
||||
|
||||
### 二、初中级开发工程师
|
||||
|
||||
|
||||
@@ -82,6 +82,38 @@
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
### 附录：用户研究与需求验证
|
||||
|
||||
**为什么需要**：当你已经有了产品点子，但还不确定它是不是真需求、该如何和用户聊、该优先验证什么时，这组内容能帮你把模糊感觉变成可验证的判断。
|
||||
|
||||
**什么时候看**：
|
||||
- 当你说不清用户到底在“雇用”你的产品完成什么事时
|
||||
- 当你准备做用户访谈，却担心只得到礼貌性反馈时
|
||||
- 当你想把“感觉不错”的点子，变成更扎实的需求假设时
|
||||
|
||||
<NavGrid>
|
||||
<NavCard
|
||||
href="/zh-cn/stage-1/appendix-idea-sources/"
|
||||
title="从哪里找点子"
|
||||
description="学会从参考应用、行业趋势和 VC 清单里，收出一个更具体的产品方向。"
|
||||
/>
|
||||
<NavCard
|
||||
href="/zh-cn/stage-1/appendix-double-diamond/"
|
||||
title="双钻模型入门"
|
||||
description="理解 Discover、Define、Develop、Deliver 四步，避免还没想清楚问题就急着做原型。"
|
||||
/>
|
||||
<NavCard
|
||||
href="/zh-cn/stage-1/appendix-jobs-to-be-done/"
|
||||
title="Jobs to Be Done 入门"
|
||||
description="用 JTBD 方法看清用户真正想完成的事，判断需求和产品方向。"
|
||||
/>
|
||||
<NavCard
|
||||
href="/zh-cn/stage-1/appendix-mom-test/"
|
||||
title="The Mom Test 用户访谈法"
|
||||
description="学会正确和用户聊天，避免只听到“听起来不错”的假阳性反馈。"
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
### 附录：技术方案
|
||||
|
||||
**为什么需要**：在开发过程中遇到技术问题或想了解更优工具时，这些技术附录能提供即查即用的解决方案。
|
||||
|
||||
@@ -0,0 +1,544 @@
|
||||
---
|
||||
title: '双钻模型：先做对的事，再把事做对'
|
||||
description: '面向零基础读者的 Double Diamond 入门文章。理解 Discover、Define、Develop、Deliver 四个阶段，避免在问题还没搞清楚时就急着做原型。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = '约 <strong>1.5 小时</strong>'
|
||||
</script>
|
||||
|
||||
# 双钻模型：先做对的事，再把事做对
|
||||
|
||||
<a id="top-dd"></a>
|
||||
|
||||
## 本章导读
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['Double Diamond', '设计思维', '需求分析', '方案设计']"
|
||||
coreOutput="1 个更清楚的问题定义和 1 个更合理的验证切口"
|
||||
expectedOutput="不再一上来就急着画原型，而是知道先想清楚问题，再比较方案"
|
||||
>
|
||||
|
||||
很多人第一次做产品时，最容易踩的坑不是“不够努力”，而是太快进入解决方案。
|
||||
|
||||
脑子里刚冒出一个方向，就开始想页面怎么画、按钮放哪、要不要接 AI、要不要做登录注册、原型用什么工具画。忙了一圈之后，才发现最根本的问题根本没想清楚：用户到底是不是真的有这个痛点？这个问题值不值得现在解决？你以为自己在推进项目，其实只是很努力地在错误方向上加速。
|
||||
|
||||
双钻模型（Double Diamond）就是用来避免这种情况的。
|
||||
|
||||
它最有价值的提醒是：**“做对的事情”和“把事情做对”，是两个完全不同的阶段。** 如果你还没搞清楚问题，就急着冲去做原型，通常只会把错误方向做得更完整。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 最小 SOP
|
||||
**目的**：看完后，你会更清楚做产品时什么时候该先想问题，什么时候才该开始想方案和原型，避免一上来就在错误方向上做得很认真。
|
||||
|
||||
**行动项**：按 `Discover → Define → Develop → Deliver` 四步往下走，每一步只做当前阶段该做的事。
|
||||
|
||||
**结果**：你会得到一个更清楚的问题定义、几种可比较的方案，以及一个可验证的最小版本。
|
||||
|
||||
**关键词跳转**：[双钻模型是什么](#dd-what) · [第一个钻石](#dd-first) · [AI 怎么帮你](#dd-ai)
|
||||
:::
|
||||
|
||||
## 你将学到以下内容
|
||||
|
||||
1. 双钻模型是什么，为什么它适合零基础做产品时使用
|
||||
2. Discover、Define、Develop、Deliver 四个阶段分别在做什么
|
||||
3. 怎样区分“现在应该继续发散”还是“现在应该开始收敛”
|
||||
4. 如何把双钻模型用在 AI 产品、原型设计和需求验证里
|
||||
|
||||
<a id="dd-what"></a>
|
||||
## 1. 双钻模型到底是什么 [↩ 回到开头](#top-dd)
|
||||
|
||||
双钻模型是英国 **Design Council** 推广的一套经典设计流程框架。它把一个完整的设计与创新过程，画成两个连续的钻石形状。
|
||||
|
||||
之所以是“钻石”，是因为每个钻石都包含两种相反但都很重要的动作：
|
||||
|
||||
- **发散**：先把视野打开，看更多可能性
|
||||
- **收敛**：再把范围缩小，做出判断和取舍
|
||||
|
||||
整个过程一共四步：
|
||||
|
||||
1. **Discover**：广泛了解用户、问题、环境和市场
|
||||
2. **Define**：从大量信息里提炼出真正值得解决的核心问题
|
||||
3. **Develop**：围绕核心问题发散多种解决方案
|
||||
4. **Deliver**：筛选、原型、测试并交付更合适的方案
|
||||
|
||||
如果把这四步压缩成一句最容易记住的话，就是：
|
||||
|
||||
- **第一个钻石**：先搞清楚到底要解决什么问题
|
||||
- **第二个钻石**：再决定用什么方案去解决它
|
||||
|
||||
这也是你刚才说得很准确的那句话：
|
||||
|
||||
- **第一个钻石：做对的事情**
|
||||
- **第二个钻石：把事情做对**
|
||||
|
||||
## 2. 为什么双钻模型特别适合新手
|
||||
|
||||
新手做产品最常见的节奏，往往是这样的：
|
||||
|
||||
- 想到一个点子
|
||||
- 觉得这个方向很酷
|
||||
- 马上开始画原型
|
||||
- 做着做着发现功能越来越多
|
||||
- 最后不知道自己到底在解决什么问题
|
||||
|
||||
双钻模型的价值，不在于让流程变复杂，而在于 **强迫你把“理解问题”和“设计方案”拆开** 。
|
||||
|
||||
这件事听起来很普通，但实际非常重要。因为很多失败的产品，不是执行不认真，而是：
|
||||
|
||||
- 选错了问题
|
||||
- 误解了用户
|
||||
- 过早锁定了解决方案
|
||||
- 把大量时间花在细节打磨上，却没有验证方向
|
||||
|
||||
双钻模型就是在不断提醒你：
|
||||
|
||||
- 不要因为想法顺手，就默认问题已经成立
|
||||
- 不要因为方案能做出来，就默认它值得做
|
||||
- 不要因为原型看起来完整，就默认用户会真的需要
|
||||
|
||||
<a id="dd-first"></a>
|
||||
## 3. 第一个钻石：做对的事情 [↩ 回到开头](#top-dd)
|
||||
|
||||
第一个钻石关注的是 **问题本身** ，而不是解决方案。
|
||||
|
||||
你可以把它理解成一句话：**先别急着做，先搞清楚到底值不值得做。**
|
||||
|
||||
### 3.1 Discover：先把问题空间打开
|
||||
|
||||
Discover 阶段的核心任务，是 **广泛调研，而不是快速下结论。**
|
||||
|
||||
这一步通常会做的事情包括：
|
||||
|
||||
- 看用户在真实场景里怎么做
|
||||
- 访谈潜在用户，了解他们最近一次遇到问题是什么时候
|
||||
- 观察他们现在怎么凑合解决
|
||||
- 看竞品和替代方案都在怎么处理
|
||||
- 收集市场、流程、约束、上下游信息
|
||||
|
||||
很多人会误以为 Discover 就是“多看点资料”。其实更关键的是：**你要理解人和场景，而不只是搜一堆信息。**
|
||||
|
||||
比如你想做一个“AI 帮忙整理会议纪要”的工具，在 Discover 阶段更应该关注的是：
|
||||
|
||||
- 用户开完会后到底哪里最痛苦
|
||||
- 是记录难，还是整理难，还是同步难
|
||||
- 他们现在是自己写、让实习生写、录音回听，还是干脆不整理
|
||||
- 哪些会议场景最需要纪要，哪些根本不需要
|
||||
|
||||
这一步最重要的目标不是得出答案，而是 **别太早以为自己已经知道答案。**
|
||||
|
||||
### 3.2 Define：从一堆信息里提炼出核心问题
|
||||
|
||||
如果 Discover 是打开视野，Define 就是开始收束。
|
||||
|
||||
Define 阶段要做的，不是把所有观察都保留下来，而是问：
|
||||
|
||||
- 真正最值得优先解决的问题是哪一个
|
||||
- 哪个问题最常出现、最痛、最有价值
|
||||
- 我们第一版到底只盯住哪一个场景
|
||||
|
||||
这一步的核心，是把一个宽泛话题，收敛成一个清晰问题定义。
|
||||
|
||||
比如你一开始说：
|
||||
|
||||
> 我想做一个提高开会效率的 AI 工具。
|
||||
|
||||
到了 Define 阶段，更好的表达可能会变成：
|
||||
|
||||
> 我们先解决项目型团队在 30 到 60 分钟协作会议结束后，无法在 10 分钟内输出带待办、责任人和截止时间的纪要这个问题。
|
||||
|
||||
这时候问题就开始变清楚了：
|
||||
|
||||
- 用户是谁
|
||||
- 场景是什么
|
||||
- 卡点是什么
|
||||
- 成功标准是什么
|
||||
|
||||
Define 的本质，就是 **从“问题很多”收敛到“这次先解决哪一个问题”。**
|
||||
|
||||
## 4. 第二个钻石：把事情做对
|
||||
|
||||
当你完成第一个钻石后，才真正适合进入第二个钻石。因为这时你解决的不是一个模糊方向，而是一个被收敛过的具体问题。
|
||||
|
||||
### 4.1 Develop：围绕核心问题发散方案
|
||||
|
||||
Develop 阶段的重点，是 **围绕同一个问题，探索多种可能方案。**
|
||||
|
||||
注意，这里的发散和 Discover 阶段不一样。
|
||||
|
||||
- Discover 的发散，是在探索问题空间
|
||||
- Develop 的发散，是在探索解决方案空间
|
||||
|
||||
比如还是会议纪要这个例子，到了 Develop 阶段，你可以开始想：
|
||||
|
||||
- 是做网页工具，还是会议插件
|
||||
- 是上传录音后处理，还是实时记录
|
||||
- 是只做摘要，还是重点做待办提取
|
||||
- 是强调个人效率，还是强调团队同步
|
||||
- 是给用户自由编辑，还是直接输出结构化模板
|
||||
|
||||
这一步很适合脑暴，也很适合和团队一起把方案拉开。
|
||||
|
||||
但这里有一个前提：**所有方案都必须服务同一个已定义的问题。**
|
||||
如果问题没定义清楚，Develop 很容易又重新变成功能乱飞。
|
||||
|
||||
### 4.2 Deliver：选择方案、做原型、测试和交付
|
||||
|
||||
Deliver 阶段是第二个钻石里的收敛阶段。
|
||||
|
||||
这时你要做的不是继续想更多，而是开始判断：
|
||||
|
||||
- 哪个方案最适合当前阶段
|
||||
- 哪个版本最小但最有用
|
||||
- 哪些功能必须先做，哪些可以以后再说
|
||||
- 怎么做原型、测试和小范围验证
|
||||
|
||||
很多人以为 Deliver 就等于“上线”。其实它更准确的意思是：**把一个方案变成可测试、可验证、可迭代的东西。**
|
||||
|
||||
它可能是：
|
||||
|
||||
- 一张低保真流程图
|
||||
- 一个 Figma 原型
|
||||
- 一个可运行的 MVP
|
||||
- 一次小规模用户测试
|
||||
- 一轮真实反馈后的迭代版本
|
||||
|
||||
Deliver 的重点不是“完美交付”，而是 **尽快把方案放进真实环境里验证。**
|
||||
|
||||
## 5. 一个最容易记住的对照表
|
||||
|
||||
如果你总是分不清四个阶段，可以直接记下面这个版本：
|
||||
|
||||
| 阶段 | 你在做什么 | 关键词 | 常见产出 |
|
||||
| --- | --- | --- | --- |
|
||||
| Discover | 理解问题 | 调研、观察、访谈、收集信息 | 用户洞察、场景笔记、问题清单 |
|
||||
| Define | 定义问题 | 提炼、聚焦、取舍、重写问题 | 问题定义、优先级、MVP 切口 |
|
||||
| Develop | 探索方案 | 脑暴、比较、共创、原型设想 | 方案列表、流程草图、原型方向 |
|
||||
| Deliver | 验证方案 | 原型、测试、迭代、交付 | 原型、测试反馈、优化版本 |
|
||||
|
||||
再压缩一点，就是这样：
|
||||
|
||||
- **Discover / Define**：解决“做对的事情”
|
||||
- **Develop / Deliver**：解决“把事情做对”
|
||||
|
||||
## 6. 双钻模型最常见的误区
|
||||
|
||||
### 6.1 还没 Discover，就直接 Deliver
|
||||
|
||||
这是最常见的一种。很多人刚有想法就开画原型、写 PRD、接模型、做页面。
|
||||
|
||||
问题不是你做得不认真，而是你可能根本还没确认问题值不值得解决。
|
||||
|
||||
### 6.2 Discover 很久，但始终不 Define
|
||||
|
||||
另一种极端是一直调研、一直看资料、一直访谈，却迟迟不敢收敛。
|
||||
|
||||
双钻不是让你无限发散，而是提醒你：发散之后必须进入判断和取舍。
|
||||
|
||||
### 6.3 Define 之后，又偷偷改问题
|
||||
|
||||
很多团队会在 Develop 时因为某个方案更容易做，就反过来修改问题定义，让它适配现有方案。
|
||||
|
||||
这很危险。因为你可能不是在解决问题，而是在为自己偏爱的方案找理由。
|
||||
|
||||
### 6.4 把 Deliver 误解成“大而全上线”
|
||||
|
||||
Deliver 不是说必须把完整产品都做完才算结束。很多时候，一个可以测试的原型、一轮真实用户试用，已经是很好的 deliver。
|
||||
|
||||
## 7. 在 AI 产品里，双钻模型怎么用
|
||||
|
||||
AI 产品特别容易掉进“能力先行”的坑里，因为模型能力看起来太诱人了。你会很想直接去想：
|
||||
|
||||
- 要不要接多模态
|
||||
- 要不要做 Agent
|
||||
- 要不要加工作流
|
||||
- 要不要接语音、图像、联网搜索
|
||||
|
||||
但双钻模型会逼你先问：
|
||||
|
||||
- 用户到底在哪个环节真的卡住了
|
||||
- 这个卡点是不是非 AI 不可
|
||||
- 如果不用 AI，现有办法到底哪里最差
|
||||
- AI 加进去之后，最核心的进展是什么
|
||||
|
||||
这能帮你避免一种常见情况：**能力很强，价值很弱。**
|
||||
|
||||
一个实用的顺序是：
|
||||
|
||||
1. 在 Discover 阶段观察用户现在怎么处理任务
|
||||
2. 在 Define 阶段把最痛的一个场景写成一句清晰的问题定义
|
||||
3. 在 Develop 阶段再去比较哪些 AI 能力最适合服务这个问题
|
||||
4. 在 Deliver 阶段做一个最小版本，让真实用户测试
|
||||
|
||||
## 8. 可以直接套用的双钻模板
|
||||
|
||||
如果你正在做自己的产品，可以先按这个顺序往下写：
|
||||
|
||||
### Discover
|
||||
|
||||
- 我观察到的用户是谁？
|
||||
- 他们最近一次遇到这个问题是什么时候？
|
||||
- 他们现在怎么解决？
|
||||
- 他们最烦、最慢、最不放心的地方是什么？
|
||||
|
||||
### Define
|
||||
|
||||
- 这堆问题里，最值得优先解决的是哪一个？
|
||||
- 哪个场景最高频，或者最关键？
|
||||
- 我们第一版先只服务谁、只解决什么？
|
||||
- 成功解决后，用户状态会发生什么变化？
|
||||
|
||||
### Develop
|
||||
|
||||
- 针对这个问题，有哪些可能方案？
|
||||
- 哪些方案最轻、最快、最容易验证？
|
||||
- 哪些是必须做，哪些是以后再说？
|
||||
|
||||
### Deliver
|
||||
|
||||
- 我们最小可以交付什么来验证这个方向？
|
||||
- 是流程图、原型，还是 MVP？
|
||||
- 需要找谁测试？
|
||||
- 测试后怎样判断要继续、修改还是放弃？
|
||||
|
||||
## 9. 一个从零基础也能看懂的例子
|
||||
|
||||
假设你想做一个“帮大学生准备求职简历”的 AI 工具。
|
||||
|
||||
很多人一开始就会直接进入第二个钻石，开始想：
|
||||
|
||||
- 要不要一键美化
|
||||
- 要不要智能改写
|
||||
- 要不要自动匹配 JD
|
||||
- 要不要生成自我介绍
|
||||
|
||||
但按双钻模型，更好的过程会是这样：
|
||||
|
||||
### 第一个钻石
|
||||
|
||||
**Discover**
|
||||
|
||||
- 去聊应届生最近一次改简历是什么时候
|
||||
- 看他们怎么从旧简历改成新版本
|
||||
- 了解他们最困扰的是“不会写”“不会改”，还是“不会判断好不好”
|
||||
|
||||
**Define**
|
||||
|
||||
- 最后收敛出一个更具体的问题：
|
||||
- 不是“大学生不会做简历”
|
||||
- 而是“第一次投递实习的学生，很难把已有经历改写成贴合岗位的表达，因此拖延投递”
|
||||
|
||||
### 第二个钻石
|
||||
|
||||
**Develop**
|
||||
|
||||
- 想几种方案：模板库、AI 改写、岗位对照、简历评分、案例参考
|
||||
|
||||
**Deliver**
|
||||
|
||||
- 第一版只做“根据岗位描述改写经历 bullet points”
|
||||
- 给 5 个学生试用，看他们会不会更快投出第一版简历
|
||||
|
||||
你会发现，一旦第一个钻石做扎实，第二个钻石会清楚很多。
|
||||
|
||||
## 10. 小结
|
||||
|
||||
双钻模型最有力量的地方，是它帮你把一整团混乱拆成了四个更清楚的动作：
|
||||
|
||||
- 先发散理解问题
|
||||
- 再收敛定义问题
|
||||
- 再发散探索方案
|
||||
- 最后收敛交付方案
|
||||
|
||||
它不是让你变慢，而是让你 **少走很多看起来很忙、其实方向不对的弯路。**
|
||||
|
||||
尤其在 AI 时代，做东西变得越来越快，双钻模型反而更重要。因为当“做出来”越来越容易时，真正稀缺的能力会变成：**你有没有在解决一个值得解决的问题，以及你有没有用合适的方式去解决它。**
|
||||
|
||||
记住这一句就够了：
|
||||
|
||||
**先做对的事情，再把事情做对。**
|
||||
|
||||
<a id="dd-ai"></a>
|
||||
## 11. 如何利用 AI 帮你跑双钻流程 [↩ 回到开头](#top-dd)
|
||||
|
||||
双钻模型本身不是 AI 工具，但 AI 很适合在四个阶段里充当“加速器”。关键不是让 AI 替你决策，而是让它帮你扩展视野、整理信息、比较方案和生成验证材料。
|
||||
|
||||
### 11.1 在 Discover 阶段，用 AI 先做一轮信息铺垫
|
||||
|
||||
在正式访谈和调研前，你可以先让 AI 帮你做一些轻量级问题扫描，比如：
|
||||
|
||||
- 市面上常见替代方案有哪些
|
||||
- 用户在公开社区里最常抱怨什么
|
||||
- 这个问题常见于哪些场景和人群
|
||||
- 现有产品通常忽略了什么
|
||||
|
||||
这一步不能代替真实调研，但很适合帮你快速搭一个问题地图。
|
||||
|
||||
一个很简单的小白输入可以是：
|
||||
|
||||
```text
|
||||
我想做一个帮大学生改简历的工具。
|
||||
你先别帮我想功能，先帮我看看大家在这个问题上最常遇到什么麻烦。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
初步问题地图：
|
||||
|
||||
1. 不知道该写什么经历
|
||||
2. 不知道怎么针对岗位修改
|
||||
3. 改了很多版还是不确定是否够好
|
||||
4. 需要别人帮看，但不方便总麻烦别人
|
||||
5. 因为不确定，所以一直拖着不投
|
||||
```
|
||||
|
||||
这种输出的作用不是替你下结论，而是让你更快进入 Discover。
|
||||
|
||||
### 11.2 在 Define 阶段，让 AI 帮你收敛问题定义
|
||||
|
||||
很多人收集了一堆资料之后，最难的是把问题收成一句真正清楚的话。你可以把调研笔记交给 AI，让它帮你压缩成几个候选问题定义：
|
||||
|
||||
```text
|
||||
下面是我在 Discover 阶段收集到的用户反馈和调研笔记：
|
||||
[贴上内容]
|
||||
|
||||
请你帮我做三件事：
|
||||
1. 归纳最常出现的问题模式
|
||||
2. 按问题频率、痛感和可验证性，整理出 3 个值得优先解决的问题
|
||||
3. 把每个问题写成一句具体的问题定义
|
||||
```
|
||||
|
||||
这样你会更容易进入 Define，而不是一直停留在“问题好多”的状态里。
|
||||
|
||||
你甚至可以把输入写得非常简单：
|
||||
|
||||
```text
|
||||
我现在收集到的问题有：
|
||||
1. 大家不知道简历写什么
|
||||
2. 大家不知道怎么改
|
||||
3. 大家总觉得没改好，不敢投
|
||||
|
||||
你帮我看看，第一版最适合先解决哪个问题。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
建议优先解决的问题：
|
||||
|
||||
“第一次投递实习的学生，不确定简历是否已经达到可投递水平，因此会反复修改并拖延投递。”
|
||||
|
||||
原因：
|
||||
1. 这个问题更具体
|
||||
2. 它能解释拖延行为
|
||||
3. 更容易设计一个小版本去验证
|
||||
```
|
||||
|
||||
这类输出很有用，因为它帮你从一堆模糊问题里收出一个更像 MVP 起点的定义。
|
||||
|
||||
### 11.3 在 Develop 阶段，用 AI 发散多个方案
|
||||
|
||||
很多人一定义完问题，就只盯着脑子里第一个想到的方案。AI 在这一步很适合帮你强制发散：
|
||||
|
||||
```text
|
||||
我已经定义了一个核心问题：[你的问题定义]
|
||||
请你不要直接给我一个最终答案，而是从以下角度各提出 2-3 种解决方向：
|
||||
1. 最轻量的 MVP
|
||||
2. 最适合验证需求的方案
|
||||
3. 最适合提高体验的方案
|
||||
4. 不依赖 AI 的方案
|
||||
5. 依赖 AI 的方案
|
||||
最后请对比每种方案的优点、风险和验证成本。
|
||||
```
|
||||
|
||||
这样你就不会太早被单一方案绑住。
|
||||
|
||||
一个简单输入可以是：
|
||||
|
||||
```text
|
||||
我现在的问题定义是：
|
||||
“大学生不确定简历是否已经可以投，所以一直拖着不投。”
|
||||
|
||||
请你帮我想 4 种不同解决方案，不要只给我一种。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
方案 1：简历可投递检查清单
|
||||
方案 2：根据岗位描述做针对性改写
|
||||
方案 3：让用户上传简历后给出风险提示
|
||||
方案 4：提供优秀案例对照，帮助用户判断差距
|
||||
```
|
||||
|
||||
这时你就更容易进入“比较方案”，而不是一上来只盯着 AI 改写一个方向。
|
||||
|
||||
### 11.4 在 Deliver 阶段，用 AI 帮你生成原型文案和测试材料
|
||||
|
||||
当你进入 Deliver 阶段，AI 非常适合帮你加快这些工作：
|
||||
|
||||
- 生成低保真原型里的页面文案
|
||||
- 整理用户测试脚本
|
||||
- 生成可对比的多个版本标题、按钮、说明语
|
||||
- 整理测试后的反馈和问题列表
|
||||
|
||||
比如你可以让 AI 帮你生成一个 20 分钟用户测试脚本，或者帮你把 5 个用户反馈归纳成“继续做 / 修改方向 / 暂停”的判断依据。
|
||||
|
||||
比如一个最小输入可以是：
|
||||
|
||||
```text
|
||||
我做了一个很简单的原型：
|
||||
用户上传简历，系统告诉他哪些地方还不适合投递。
|
||||
|
||||
请帮我生成一份 15 分钟的用户测试脚本。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
15 分钟测试脚本：
|
||||
|
||||
1. 先请用户描述最近一次投简历经历
|
||||
2. 让用户独立完成上传简历
|
||||
3. 观察他是否看得懂反馈结果
|
||||
4. 询问：这些提示里哪些最有帮助，哪些让你困惑
|
||||
5. 询问：如果下次投递前，你会不会想再用一次
|
||||
```
|
||||
|
||||
这种输出很实用，因为它能帮你从“我做完原型了”走到“我接下来怎么测”。
|
||||
|
||||
### 11.5 让 AI 扮演“阶段守门员”
|
||||
|
||||
双钻模型最常见的问题，是人会跳阶段。你可以直接让 AI 充当一个守门员，提醒你现在到底在哪一步：
|
||||
|
||||
```text
|
||||
请你扮演产品流程教练。
|
||||
下面是我当前的项目状态：[你的描述]
|
||||
请你判断我现在更像处于 Discover、Define、Develop 还是 Deliver。
|
||||
并告诉我：
|
||||
1. 我是不是过早跳到了下一阶段
|
||||
2. 当前阶段最该补的动作是什么
|
||||
3. 哪些事情现在先别做
|
||||
```
|
||||
|
||||
这对新手特别有帮助，因为你很容易在“还没想清楚问题时就开始画原型”。
|
||||
|
||||
## 📚 Assignments
|
||||
|
||||
请你根据上文内容，完成下列作业：
|
||||
|
||||
1. 选一个你最近想做的产品点子，写出它的 Discover、Define、Develop、Deliver 四步草稿
|
||||
2. 在 Define 阶段，强迫自己把问题缩成一句具体的话
|
||||
3. 在 Develop 阶段，至少列出 3 种不同方案，而不是只盯着第一个想到的做法
|
||||
4. 在 Deliver 阶段，写出一个一周内能交付的最小验证版本
|
||||
|
||||
## 延伸阅读
|
||||
|
||||
这篇文章主要参考了 Design Council 关于 Double Diamond 的官方资料，适合继续往下看：
|
||||
|
||||
- [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,519 @@
|
||||
---
|
||||
title: '从哪里找点子：3 种最适合新手的参考来源'
|
||||
description: '面向零基础读者的产品点子入门文章。学会从参考应用、行业趋势和投资机构清单里找到更具体的方向，并把“看起来很酷”收成一个能尝试的细分点子。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = '约 <strong>1.5 小时</strong>'
|
||||
</script>
|
||||
|
||||
# 从哪里找点子：3 种最适合新手的参考来源
|
||||
|
||||
<a id="top-idea-sources"></a>
|
||||
|
||||
## 本章导读
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['找点子', '产品方向', '需求发现', '行业观察']"
|
||||
coreOutput="1 个更具体、能开始验证的细分产品方向"
|
||||
expectedOutput="不再只会刷一堆灵感链接，而是知道怎么从参考里收出一个自己真能试的点子"
|
||||
>
|
||||
|
||||
很多人卡在做产品的第一步，不是不想做，而是根本不知道该从哪开始想。
|
||||
|
||||
脑子里常见的状态是这样的：
|
||||
|
||||
- 想做点 AI 相关的东西，但一时说不清要做什么
|
||||
- 刷了很多“创业灵感”“2026 大趋势”，看完还是很空
|
||||
- 看见别人做得很酷，觉得厉害，但不知道自己能从中切哪一小块
|
||||
|
||||
这时候，你最需要的往往不是再听一遍“要多观察用户”，而是先有一套更容易执行的起点：**去哪里看，怎么看，怎样把一个大方向收成一个更具体的小方向。**
|
||||
|
||||
这篇文章讲的就是这个起点。它不会让你凭空发明一个完美点子，而是帮你学会从现成的参考里，慢慢收出一个更像真实产品方向的东西。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 最小 SOP
|
||||
**目的**：看完后，你会知道没灵感的时候，应该先去哪里刷，怎么把“一个看起来不错的方向”收成“一个我能尝试的细分点子”。
|
||||
|
||||
**行动项**：先挑 1 个参考应用，再看 1 组趋势来源，最后看 1 轮 VC / 加速器清单；每看完一轮，都写下“谁在什么场景下，愿意为哪一步效率买单”。
|
||||
|
||||
**结果**：你会得到 1 个更具体的尝试方向，而不是只留下“AI + 某行业”这种很空的想法。
|
||||
|
||||
**关键词跳转**：[先看参考应用](#idea-apps) · [再看行业趋势](#idea-trends) · [最后看 VC 清单](#idea-vc) · [怎么收成细分点子](#idea-narrow) · [AI 怎么帮你](#idea-ai)
|
||||
:::
|
||||
|
||||
## 你将学到以下内容
|
||||
|
||||
1. 为什么很多人不是没有点子，而是不会把模糊灵感收成可尝试的方向
|
||||
2. 三种最适合新手的参考来源：参考应用、趋势来源、VC / 加速器清单
|
||||
3. 每种来源该看什么，不该只看什么
|
||||
4. 怎样从“大方向”进一步收成一个更具体的细分场景和第一版切口
|
||||
|
||||
## 1. 为什么“刷了很多 idea”还是想不出来
|
||||
|
||||
很多人以为自己缺的是灵感，其实更常见的问题是：**看到了很多方向，但没有把方向继续往下压。**
|
||||
|
||||
比如你看到：
|
||||
|
||||
- AI for education
|
||||
- AI for healthcare
|
||||
- AI for finance
|
||||
- AI agent for business
|
||||
|
||||
这些都不算真正的点子，它们更像大类标签。问题在于，大类标签没法直接指导你做第一步。因为它没有告诉你：
|
||||
|
||||
- 是谁在用
|
||||
- 在什么场景下用
|
||||
- 现在怎么勉强解决
|
||||
- 哪一步最值得先切
|
||||
|
||||
所以找点子的关键，不是“看得更多”，而是学会把看到的东西继续往下问。
|
||||
|
||||
你可以反复问自己这 4 句话：
|
||||
|
||||
1. 这到底是谁的问题？
|
||||
2. 这个问题发生在什么具体场景里？
|
||||
3. 他们现在是怎么凑合解决的？
|
||||
4. 我能不能只切其中一步，先做一个很小但有用的版本？
|
||||
|
||||
下面这三种来源，就是帮助你一步步把方向收窄的。
|
||||
|
||||
<a id="idea-apps"></a>
|
||||
## 2. 第一种：先看别人已经在做什么 [↩ 回到开头](#top-idea-sources)
|
||||
|
||||
这是最适合新手的起点，因为它最具体。
|
||||
|
||||
如果你现在完全没有方向，那比起先看宏大趋势，更好的方法通常是：**先去看别人已经做了哪些产品、哪些小工具、哪些被真实用户讨论的需求。**
|
||||
|
||||
为什么这一步有用？
|
||||
|
||||
- 因为你不用从零想象
|
||||
- 因为你能直接看到产品是怎么描述自己的
|
||||
- 因为你能更快感受到“一个点子被做成产品之后，大概长什么样”
|
||||
|
||||
比较适合拿来刷的地方有三类：
|
||||
|
||||
### 2.1 直接看“别人希望有人做什么”
|
||||
|
||||
- Reddit 的 `r/SomebodyMakeThis`
|
||||
- Reddit 的 `r/AppIdeas`
|
||||
- Reddit 的 `r/Startup_Ideas`
|
||||
|
||||
这类地方的好处是，帖子通常很直接。很多就是用户在说：
|
||||
|
||||
- 我希望有人做一个……
|
||||
- 有没有工具可以帮我……
|
||||
- 我最烦这个流程的地方是……
|
||||
|
||||
它的价值不在于每个帖子都能直接拿来做，而在于你能快速进入一种更真实的需求语境。
|
||||
|
||||
### 2.2 直接看“别人已经做出来并且可能在赚钱什么”
|
||||
|
||||
- Starter Story
|
||||
- Indie Hackers Products
|
||||
- Product Hunt
|
||||
|
||||
这类来源和前面不一样。前面更像“有人在提需求”，这里更像“已经有人把某个需求做成产品了”。
|
||||
|
||||
你看这类网站时，不要只看最火的大产品，更建议看：
|
||||
|
||||
- 月收入不算夸张、但已经有人付费的小产品
|
||||
- 某个行业里反复出现的一类工具
|
||||
- 看起来不酷，但明显在解决具体麻烦的小工具
|
||||
|
||||
很多适合新手切入的方向，恰恰不是那种“会震惊全场”的大项目，而是：
|
||||
|
||||
- 一个流程里很烦的一步
|
||||
- 一个行业里总有人重复在做的整理工作
|
||||
- 一个已有需求但产品还不顺手的细分角落
|
||||
|
||||
### 2.3 不只看产品本身，也看差评和“代做服务”
|
||||
|
||||
这一步非常重要，因为它会让你从“看产品”转向“看没被解决好的地方”。
|
||||
|
||||
你可以去看：
|
||||
|
||||
- G2
|
||||
- Capterra
|
||||
- 国内外一些 SaaS 点评区
|
||||
- 淘宝、闲鱼、Fiverr、Upwork、猪八戒这类平台上的“代做”“代整理”“代处理”服务
|
||||
|
||||
为什么这些地方特别有价值？
|
||||
|
||||
因为差评往往在说：
|
||||
|
||||
- 现有产品哪里不好用
|
||||
- 哪一步还是得手工做
|
||||
- 为什么用户用了还是嫌麻烦
|
||||
|
||||
而“代做服务”在提醒你：
|
||||
|
||||
- 这个需求已经有人在花钱解决
|
||||
- 但现在主要还是靠人工
|
||||
- 其中可能有一部分流程可以被产品化或自动化
|
||||
|
||||
所以，**先看参考应用，不只是为了模仿，而是为了看清楚“别人已经验证了哪一类问题”和“哪些地方还做得不够好”。**
|
||||
|
||||
<a id="idea-trends"></a>
|
||||
## 3. 第二种：再看哪些方向正在起来 [↩ 回到开头](#top-idea-sources)
|
||||
|
||||
如果第一种来源帮你看到“现在已经有人在做什么”，那第二种来源更像是在提醒你：**接下来哪些方向可能会越来越值得看。**
|
||||
|
||||
比较典型的来源有：
|
||||
|
||||
- Google Trends
|
||||
- Exploding Topics
|
||||
- 行业研究摘要
|
||||
- 垂直社区、论坛和行业媒体
|
||||
|
||||
看趋势最大的误区，是只停留在“这个词最近很火”。
|
||||
这对做产品帮助不大。你真正该看的是：
|
||||
|
||||
- 哪个词在变热
|
||||
- 这个词落在哪些具体场景里
|
||||
- 哪些人会最早为它付出时间、切换成本或预算
|
||||
|
||||
比如你看到某个趋势方向在涨，不要停在：
|
||||
|
||||
- AI voice
|
||||
- AI healthcare
|
||||
- AI sales
|
||||
|
||||
而是继续问：
|
||||
|
||||
- 是谁最先会为它买单？
|
||||
- 这个趋势会卡进哪个已有工作流？
|
||||
- 哪个子问题最像“现在就值得做”的切口？
|
||||
|
||||
### 3.1 趋势不是点子，它只是放大镜
|
||||
|
||||
趋势的价值，不是直接给你答案，而是帮你缩小搜索范围。
|
||||
|
||||
比如你原本完全没方向，后来看到：
|
||||
|
||||
- 某类 AI 教育工具在持续增长
|
||||
- 某类行业自动化需求开始变热
|
||||
- 某类内容生产方式在快速普及
|
||||
|
||||
这时候你就知道：至少这个大方向现在不是冷门死角。接下来你应该做的不是停在“那我也做 AI 教育”，而是继续往下压：
|
||||
|
||||
- 是面向学生、老师、家长，还是培训机构？
|
||||
- 是上课前、上课中，还是课后复盘？
|
||||
- 是提高效率、降低错误，还是提升转化率？
|
||||
|
||||
### 3.2 如果你想要“更业务”，就看更接近真实工作流的来源
|
||||
|
||||
有些趋势来源偏投资视角，能帮你看大方向；但如果你想再往“谁在真实花钱、谁在真实抱怨”靠近一点，可以继续看：
|
||||
|
||||
- 政府采购和公开招标信息
|
||||
- 企业采购需求和项目招标平台
|
||||
- 行业论坛、职业社区、Reddit 垂直板块
|
||||
- 行业协会报告、行业年度报告
|
||||
|
||||
这些来源更“业务”的原因在于，它们离真实流程更近。你看到的不只是“未来可能值得做什么”，而是：
|
||||
|
||||
- 现在谁已经愿意花钱
|
||||
- 预算大概在哪个区间
|
||||
- 需求写得有多具体
|
||||
- 哪些流程今天仍然靠 Excel、微信、纸笔、电话在硬撑
|
||||
|
||||
如果你能在一个趋势方向里，再补上这些业务信息，你得到的就不只是一个“看起来挺热”的方向，而是一个更像真实市场机会的方向。
|
||||
|
||||
<a id="idea-vc"></a>
|
||||
## 4. 第三种：最后看 VC / 加速器正在追什么 [↩ 回到开头](#top-idea-sources)
|
||||
|
||||
这一类来源，最典型的就是：
|
||||
|
||||
- Y Combinator 的 `Requests for Startups`
|
||||
- a16z 的 `Big Ideas`
|
||||
- 其他基金或加速器的年度方向清单、行业判断文章
|
||||
|
||||
这类内容很适合在你已经有一点感觉之后再看。因为它能帮你回答一个问题：
|
||||
|
||||
**接下来两三年里，哪些方向可能会被更多资源、技术和创业团队一起推动？**
|
||||
|
||||
它们的价值主要有三点：
|
||||
|
||||
### 4.1 帮你看见“浪往哪边打”
|
||||
|
||||
VC / 加速器通常会从技术变化、政策变化、产业变化里提炼出一些方向。
|
||||
这会让你知道：
|
||||
|
||||
- 哪些问题不只是你一个人觉得有意思
|
||||
- 哪些方向已经具备了“现在开始更有机会”的外部条件
|
||||
- 哪些赛道未来会吸引更多创业团队和资本进入
|
||||
|
||||
### 4.2 帮你快速进入一个赛道的语境
|
||||
|
||||
像 YC RFS 这种内容，往往不会只说“这个行业值得做”，而会直接给出某种更细的切口，比如：
|
||||
|
||||
- 哪类工作流会被 AI 重做
|
||||
- 哪类行业有明显的流程升级机会
|
||||
- 哪类基础设施还不够成熟
|
||||
|
||||
这对新手很有帮助，因为它相当于替你做了第一轮“方向拆解”。
|
||||
|
||||
### 4.3 但它不等于真实需求本身
|
||||
|
||||
这是最重要的一点。
|
||||
|
||||
VC 清单很容易让人产生一种错觉：
|
||||
|
||||
- 这个方向被大机构提了，所以一定能做
|
||||
- 这个概念很新，所以肯定值得做
|
||||
- 我只要顺着这个大词往下讲，就等于有点子了
|
||||
|
||||
其实不是。
|
||||
|
||||
VC / 加速器更擅长告诉你：
|
||||
|
||||
- 未来大浪可能往哪边打
|
||||
|
||||
但它不一定会告诉你：
|
||||
|
||||
- 具体哪个角色最痛
|
||||
- 哪一步流程最卡
|
||||
- 今天谁已经在为这件事付钱
|
||||
|
||||
所以更好的用法是：
|
||||
|
||||
- 先把它当成大方向灵感来源
|
||||
- 再回到真实应用、真实工作流和真实用户抱怨里做下钻
|
||||
|
||||
换句话说，**VC 清单适合帮你找方向，不适合替你完成验证。**
|
||||
|
||||
<a id="idea-narrow"></a>
|
||||
## 5. 怎样把“大方向”收成“我能试一个”的细分点子 [↩ 回到开头](#top-idea-sources)
|
||||
|
||||
这一段最重要，因为很多人问题不在于没看过来源，而在于不知道怎么收。
|
||||
|
||||
你可以直接套下面这个顺序：
|
||||
|
||||
### 5.1 先选一个你愿意继续看的方向
|
||||
|
||||
不是最宏大、最性感的方向，而是那个你看完之后会觉得：
|
||||
|
||||
- 我大概能理解这个场景
|
||||
- 我愿意继续查 1 小时
|
||||
- 我身边可能就认识一点相关的人
|
||||
|
||||
这一步不用追求完美，只要能进入下一步就够了。
|
||||
|
||||
### 5.2 把方向写成“谁 + 在什么时候 + 卡在哪一步”
|
||||
|
||||
比如不要只写：
|
||||
|
||||
- AI for education
|
||||
- AI for sales
|
||||
- AI for healthcare
|
||||
|
||||
而要尽量写成：
|
||||
|
||||
- 第一次准备投实习的学生，在改简历这一步特别卡
|
||||
- 小型外贸团队，在把供应商报价整理成客户报价单这一步特别慢
|
||||
- 诊所运营人员，在跟进患者方案确认这一步特别依赖人工催促
|
||||
|
||||
一旦你能写到这个程度，方向就已经开始变具体了。
|
||||
|
||||
### 5.3 再问：今天他们是怎么硬撑的
|
||||
|
||||
这一步很关键，因为它能帮你看见现实世界。
|
||||
|
||||
如果答案是：
|
||||
|
||||
- Excel
|
||||
- 微信
|
||||
- 备忘录
|
||||
- 电话
|
||||
- 手工复制粘贴
|
||||
- 找同事帮忙
|
||||
|
||||
那通常说明这里真的有一个可以继续观察的切口。
|
||||
|
||||
### 5.4 最后只切一小步
|
||||
|
||||
不要一上来就想做整个平台。
|
||||
一个更适合新手的思路通常是：
|
||||
|
||||
- 只做工作流里最烦的一步
|
||||
- 只服务一个更具体的人群
|
||||
- 只在一个小场景里把事情做顺
|
||||
|
||||
比如：
|
||||
|
||||
- 不做“求职平台”，先做“按岗位改写简历 bullet points”
|
||||
- 不做“全链路外贸系统”，先做“供应商报价转客户报价单”
|
||||
- 不做“诊所经营系统”，先做“患者方案讲解后的自动跟进提醒”
|
||||
|
||||
**一个更接地的点子，往往不是更大，而是更具体。**
|
||||
|
||||
## 6. 新手最常见的 5 个误区
|
||||
|
||||
### 6.1 把“行业”当“点子”
|
||||
|
||||
“做教育”“做医疗”“做 AI agent”都还是大类，不是点子。
|
||||
|
||||
### 6.2 只刷趋势，不看真实流程
|
||||
|
||||
趋势能给你方向，但不能替你找到具体卡点。
|
||||
|
||||
### 6.3 看见一个应用就想整套复刻
|
||||
|
||||
更有价值的动作通常不是“复制一个大产品”，而是找到它没覆盖好的一个细分场景。
|
||||
|
||||
### 6.4 只看概念，不看谁在付钱
|
||||
|
||||
如果你完全看不到谁在为这个问题投入时间、人工或预算，这个方向就还太虚。
|
||||
|
||||
### 6.5 一开始就想做很大的平台
|
||||
|
||||
新手更容易成功的起点，通常是一个很小但真有用的切口。
|
||||
|
||||
## 7. 小结
|
||||
|
||||
不会找点子，通常不是因为你不够聪明，而是因为你还没有形成一套稳定的“收方向”方法。
|
||||
|
||||
对新手来说，更实用的顺序通常是：
|
||||
|
||||
1. 先看别人已经在做什么，建立具体感觉
|
||||
2. 再看哪些方向正在起来，缩小搜索范围
|
||||
3. 最后看 VC / 加速器清单，补上更大的赛道视角
|
||||
|
||||
然后别停在“这个方向挺酷”，而是继续往下问：
|
||||
|
||||
- 谁最痛？
|
||||
- 在哪一步最痛？
|
||||
- 今天怎么硬撑？
|
||||
- 我能先切哪一小步？
|
||||
|
||||
当你能把一个方向写成“某类人，在某个场景里，被某一步流程卡住”，你就已经比单纯刷 idea 清单更接近一个真正能尝试的产品方向了。
|
||||
|
||||
<a id="idea-ai"></a>
|
||||
## 8. 如何利用 AI 帮你找参考点子 [↩ 回到开头](#top-idea-sources)
|
||||
|
||||
找点子这件事，AI 很适合当你的整理助手、比较助手和下钻助手。关键不是让 AI 凭空替你发明创意，而是让它帮你更快把“刷到的东西”收成一个更具体的方向。
|
||||
|
||||
### 8.1 让 AI 帮你把一批来源整理成方向清单
|
||||
|
||||
如果你已经刷了一些站点，可以直接把你看到的标题、链接描述或帖子原话贴给 AI，让它帮你归类。
|
||||
|
||||
一个很简单的小白输入可以这样写：
|
||||
|
||||
```text
|
||||
我最近刷到这些东西：
|
||||
1. 有人想做一个帮学生改简历的工具
|
||||
2. 有人在做会议纪要自动整理
|
||||
3. 有人说诊所患者跟进很麻烦
|
||||
4. 我看到 AI 销售自动化最近很火
|
||||
|
||||
你先不要帮我想很大的创业项目。
|
||||
请你帮我做三件事：
|
||||
1. 把这些方向按人群和场景分类
|
||||
2. 每个方向帮我写出“谁在什么场景卡在哪一步”
|
||||
3. 挑出 3 个更适合新手先试的方向，并说为什么
|
||||
```
|
||||
|
||||
AI 可能给出的有用输出会像这样：
|
||||
|
||||
```text
|
||||
适合先试的 3 个方向：
|
||||
|
||||
1. 第一次投实习的学生，在“把旧简历改成贴合岗位的版本”这一步卡住
|
||||
原因：场景具体、用户容易找到、第一版可以做得很小
|
||||
|
||||
2. 小团队开完协作会议后，在“整理待办和责任人”这一步卡住
|
||||
原因：痛点高频、现有替代方案多是手工整理、输出结果容易验证
|
||||
|
||||
3. 小型诊所运营人员，在“患者听完方案后的后续跟进”这一步卡住
|
||||
原因：业务动作清晰、流程重复、容易找到人工替代方案
|
||||
```
|
||||
|
||||
这种输出的价值，在于它能帮你从一堆散乱灵感里，先收出几个更像“真实场景”的候选方向。
|
||||
|
||||
### 8.2 让 AI 帮你把“大趋势”往下压成细分场景
|
||||
|
||||
有时候你只有一个很大的方向，比如“AI + 教育”或者“AI + 医疗”，这时 AI 很适合帮你做第一轮收窄。
|
||||
|
||||
```text
|
||||
我现在只想到一个很大的方向：[你的大方向]
|
||||
请不要直接给我 50 个功能。
|
||||
请你帮我把它拆成：
|
||||
1. 这个方向里常见的几类用户
|
||||
2. 每类用户最可能卡住的具体场景
|
||||
3. 哪些场景看起来更适合先做一个小工具
|
||||
4. 每个场景今天可能在用什么笨办法硬撑
|
||||
```
|
||||
|
||||
你甚至可以写得更口语一点：
|
||||
|
||||
```text
|
||||
我现在只觉得 AI + 教育好像可以做点什么，
|
||||
但我完全不知道该做给谁、做哪一步。
|
||||
你帮我往具体场景想一想。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
可继续下钻的场景：
|
||||
|
||||
1. 第一次准备投实习的大学生，不知道怎么针对岗位改简历
|
||||
2. 培训机构老师，上完课后整理学生反馈和后续跟进很慢
|
||||
3. 家长，在孩子课后想快速知道今天学了什么和哪里需要补
|
||||
```
|
||||
|
||||
这时候你就已经从“AI + 教育”走到了几个可以继续验证的方向。
|
||||
|
||||
### 8.3 让 AI 帮你做“值不值得继续查”的第一轮判断
|
||||
|
||||
当你已经有两三个方向时，可以让 AI 帮你做一个很轻量的比较。
|
||||
|
||||
```text
|
||||
我现在有 3 个方向：
|
||||
1. [方向 A]
|
||||
2. [方向 B]
|
||||
3. [方向 C]
|
||||
|
||||
请你从下面几个角度帮我比较：
|
||||
1. 场景是否具体
|
||||
2. 用户是否容易找到
|
||||
3. 现在是否已有替代方案
|
||||
4. 第一版是否能做得很小
|
||||
5. 哪个方向更适合我先做 1 周调研
|
||||
```
|
||||
|
||||
一个很小白的版本也可以：
|
||||
|
||||
```text
|
||||
我现在有 3 个想法，但不知道先查哪个。
|
||||
你别直接替我决定，
|
||||
先帮我看看哪个更具体、哪个更容易做第一版。
|
||||
```
|
||||
|
||||
AI 可能给出这种很有帮助的输出：
|
||||
|
||||
```text
|
||||
建议先查方向 B。
|
||||
|
||||
原因：
|
||||
1. 用户是谁更清楚
|
||||
2. 发生场景更具体
|
||||
3. 当前替代方案明显
|
||||
4. 不需要一开始做很大的系统
|
||||
|
||||
建议你下一步先去找 5 个相关用户，确认他们现在怎么处理这一步。
|
||||
```
|
||||
|
||||
这类输出最有价值的地方，是它能帮新手避免一上来就被“最大、最酷、最像创业故事”的方向吸走。
|
||||
|
||||
## 9. 延伸阅读
|
||||
|
||||
- [Y Combinator - Requests for Startups](https://www.ycombinator.com/rfs)
|
||||
- [a16z - Big Ideas](https://a16z.com/big-ideas-2025/)
|
||||
- [Reddit - r/SomebodyMakeThis](https://www.reddit.com/r/SomebodyMakeThis/)
|
||||
- [Starter Story](https://www.starterstory.com/)
|
||||
- [Indie Hackers - Products](https://www.indiehackers.com/products)
|
||||
- [Google Trends](https://trends.google.com/)
|
||||
- [Exploding Topics](https://explodingtopics.com/)
|
||||
@@ -0,0 +1,496 @@
|
||||
---
|
||||
title: '用 Jobs to Be Done 找到用户真正想完成的事'
|
||||
description: '面向零基础读者的 Jobs to Be Done 入门文章。理解用户不是在买功能，而是在特定场景里“雇用”你的产品完成进展，并学会用 JTBD 拆解产品方向、访谈问题与 AI 提示词。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = '约 <strong>1.5 小时</strong>'
|
||||
</script>
|
||||
|
||||
# 用 Jobs to Be Done 找到用户真正想完成的事
|
||||
|
||||
<a id="top-jtbd"></a>
|
||||
|
||||
## 本章导读
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['JTBD', '用户需求', '产品思维', '需求洞察']"
|
||||
coreOutput="1 条更像真实需求的 JTBD 句子"
|
||||
expectedOutput="能把模糊点子收成一个更具体的用户场景和 MVP 方向"
|
||||
>
|
||||
|
||||
很多人刚开始做产品时，最容易犯的一个错误是把注意力全部放在“我要做什么功能”上。看别人有智能分类，你也想加；看别人有自动总结，你也想接；看别人做了 Agent、多模态、工作流，你也觉得自己不能少。
|
||||
|
||||
但现实里，用户很少是因为“这个功能名字很酷”才决定用一个产品。他们更多是在某个具体时刻，想把一件事情推进下去，于是临时“雇用”了一个工具、一个服务，甚至一个人，来帮自己完成这一步。
|
||||
|
||||
这正是 **Jobs to Be Done（JTBD）** 这套方法想提醒我们的事情：**用户不是在购买功能本身，而是在雇用某种解决方案，帮助自己完成一个进展。**
|
||||
|
||||
本篇文章会用尽量直白的语言，带你从零理解 JTBD，并把它变成你做 AI 应用时能直接拿来用的分析工具。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 最小 SOP
|
||||
**目的**：看完后，你会更清楚怎样把一个模糊点子，收成一句真正有用户场景的需求，而不是脑子里只有一堆功能名。
|
||||
|
||||
**行动项**：写 1 句模糊点子，找 3 个潜在用户聊“最近一次怎么处理”，再整理成 1 条 JTBD 句子。
|
||||
|
||||
**结果**：你会得到一个更清楚的需求假设，知道第一版该先解决什么。
|
||||
|
||||
**关键词跳转**：[JTBD 是什么](#jtbd-what) · [一句话公式](#jtbd-formula) · [AI 怎么帮你](#jtbd-ai)
|
||||
:::
|
||||
|
||||
## 你将学到以下内容
|
||||
|
||||
1. 什么是 Jobs to Be Done，为什么它比“功能脑暴”更接近真实需求
|
||||
2. 如何区分“用户说想要的功能”和“用户真正想完成的事”
|
||||
3. 怎样用一套简单模板，把一个模糊点子拆成场景、触发、障碍和成功标准
|
||||
4. 如何把 JTBD 用在 AI 产品、访谈提问和提示词整理里
|
||||
|
||||
<a id="jtbd-what"></a>
|
||||
## 1. 什么是 Jobs to Be Done [↩ 回到开头](#top-jtbd)
|
||||
|
||||
Jobs to Be Done 常被简称为 **JTBD**。它背后的核心想法，和 Clayton Christensen 团队推广的那句经典表达有关：**用户会“雇用”某个产品来完成一件事。**
|
||||
|
||||
这里的“事”，不是待办清单里那种表面动作，而是用户希望自己状态发生的一种 **进展** 。比如：
|
||||
|
||||
- 不是“我要一个 AI 纪要工具”，而是“我想在会后 10 分钟内把重点、待办和责任人整理清楚，别再靠回忆补笔记”
|
||||
- 不是“我要一个记账 App”，而是“我想知道钱到底花去哪了，好让我月底别再焦虑”
|
||||
- 不是“我要一个简历优化器”，而是“我想更有把握地投出一份像样的简历，不想每次投递都怀疑自己写得太差”
|
||||
|
||||
所以，**JTBD 关注的不是产品长什么样，而是用户为什么在这个时刻需要它。**
|
||||
|
||||
这也是为什么很多看似不同的产品，实际上在竞争同一个 job。用户想“在上班路上不那么无聊”，可雇用的对象可能是短视频、播客、游戏、聊天，甚至打瞌睡。用户想“快速搞懂一份很长的 PDF”，可雇用的对象可能是 AI 摘要工具、实习生、同事、自己硬着头皮看，或者干脆先不看。
|
||||
|
||||
一旦你用这种视角看问题，你会发现自己真正的竞争对手，往往并不只是“另一个长得像你的 App”，而是 **用户当前所有可接受的替代方案** 。
|
||||
|
||||
## 2. JTBD 和用户画像、功能列表有什么不同
|
||||
|
||||
很多新手刚开始做需求分析时，会先写用户画像：25 岁，女生，一线城市，白领，喜欢效率工具，愿意尝试新产品。这样的信息不能说完全没用，但它通常 **不够解释一个人为什么会在此刻采取行动。**
|
||||
|
||||
JTBD 更关心的是下面这些问题：
|
||||
|
||||
- 他是在什么场景下决定找解决方案的
|
||||
- 当时到底卡住了什么
|
||||
- 他想把什么事情推进到下一步
|
||||
- 现在正在用什么笨办法撑着
|
||||
- 如果事情解决得好，什么结果会让他觉得“值了”
|
||||
|
||||
也就是说，**用户画像更像“这个人大概是谁”，JTBD 更像“这个人现在到底想完成什么”。**
|
||||
|
||||
同样地，功能列表也容易把人带偏。用户说“我想要导出 Word”“我想要 AI 改写”“我想要语音输入”，这些都只是表层表达。JTBD 会继续往下追问：
|
||||
|
||||
- 为什么你现在需要导出 Word，而不是 PDF？
|
||||
- 你想改写，是因为文风太差，还是因为需要适配不同对象？
|
||||
- 你想语音输入，是因为懒得打字，还是因为你经常在走路、开车、开会后马上记录？
|
||||
|
||||
很多时候，**功能只是 job 的一种临时翻译** 。如果你只收集功能，很容易把产品做成“用户说什么就堆什么”；如果你能看见背后的 job，才更有机会做出真正顺手、真正有竞争力的方案。
|
||||
|
||||
## 3. 一个零基础也能理解的例子
|
||||
|
||||
先不要急着想复杂的 AI 产品，我们从一个生活例子开始。
|
||||
|
||||
假设有人早上出门前总来不及吃早餐，于是经常在地铁口买一个三明治和咖啡。表面上看，他“购买”的是早餐；但如果用 JTBD 看，他真正想完成的事可能是：
|
||||
|
||||
- 在赶时间的早晨，用最省脑力的方式解决一顿饭
|
||||
- 让自己在到公司前不至于饿得发慌
|
||||
- 不因为吃早餐耽误通勤节奏
|
||||
|
||||
这时候，用户雇用的不是“某个固定品牌的三明治”，而是一个能帮他把早晨顺利推进下去的解决方案。如果隔壁便利店更快、更近、更稳定，他可能立刻换掉原来的选择。
|
||||
|
||||
把这个逻辑搬到 AI 产品里就更明显了。
|
||||
|
||||
比如你想做一个“AI 会议纪要工具”。如果只停在功能层面，你会很容易开始想：
|
||||
|
||||
- 要不要支持上传音频
|
||||
- 要不要接入说话人分离
|
||||
- 要不要导出 Markdown
|
||||
- 要不要自动生成待办
|
||||
|
||||
这些都没错，但还不够。用 JTBD 再问一层，用户真正想完成的可能是：
|
||||
|
||||
- 我想在会后 10 分钟内，把讨论结果同步给没参会的人
|
||||
- 我想把待办、责任人和截止时间提干净，别让团队靠记忆协作
|
||||
- 我想减少重复整理会议内容的时间，把精力留给决策和推进
|
||||
|
||||
一旦 job 被说清楚，很多功能优先级就会自动浮出来。第一版最重要的也许不是“支持 12 种导出格式”，而是：
|
||||
|
||||
- 纪要结构要足够清楚
|
||||
- 待办提取要稳定
|
||||
- 分享链接要方便
|
||||
- 输出结果要让人敢直接转发给团队
|
||||
|
||||
这就是 JTBD 的价值：**它能帮助你从“我要堆哪些能力”回到“我要帮用户推进什么进展”。**
|
||||
|
||||
## 4. 一个好用的 JTBD 模板
|
||||
|
||||
如果你是零基础，可以先不要试图把 JTBD 想得很学术。先抓住最实用的 5 个要素就够了。
|
||||
|
||||
### 4.1 场景
|
||||
|
||||
用户是在什么时刻、什么环境里想起这个产品的？
|
||||
|
||||
- 是开完会以后
|
||||
- 是老板临时要材料的时候
|
||||
- 是晚上准备投简历的时候
|
||||
- 是月底发现钱又不够花的时候
|
||||
|
||||
**没有场景的需求，通常都还不够真实。**
|
||||
|
||||
### 4.2 触发
|
||||
|
||||
是什么让他决定立刻找解决方案？
|
||||
|
||||
- 被长文档压住，不知道从哪开始看
|
||||
- 明天要交材料，今天才发现格式乱七八糟
|
||||
- 刚被领导追问进度，意识到自己没有整理清楚
|
||||
- 想坚持记录，但手写、复制、整理都太麻烦
|
||||
|
||||
触发点往往带着情绪。这个情绪很重要，因为它决定了用户为什么会在这一刻产生行动。
|
||||
|
||||
### 4.3 想完成的进展
|
||||
|
||||
他不只是想“做个动作”，而是想把自己推进到什么新状态？
|
||||
|
||||
- 从混乱到清楚
|
||||
- 从焦虑到安心
|
||||
- 从拖延到启动
|
||||
- 从低效到顺手
|
||||
- 从说不明白到能直接交付
|
||||
|
||||
这一步里，“进展”这个词非常关键。因为很多人真正买的不是工具，而是 **状态变化** 。
|
||||
|
||||
### 4.4 当前替代方案
|
||||
|
||||
现在没有你的产品时，他怎么做？
|
||||
|
||||
- 手工复制粘贴
|
||||
- 用 Excel 或备忘录硬撑
|
||||
- 找同事帮忙
|
||||
- 拖着不做
|
||||
- 在几个工具之间来回切
|
||||
|
||||
谁是替代方案，谁就是你的真实竞争环境。
|
||||
|
||||
### 4.5 成功标准
|
||||
|
||||
事情怎样才算真的被解决？
|
||||
|
||||
- 10 分钟内得到可分享的结果
|
||||
- 不需要二次大改就能发给别人
|
||||
- 不容易漏项、出错、忘事
|
||||
- 第一次用就知道下一步怎么走
|
||||
|
||||
如果你连“用户怎么判断值不值”都说不清，那这个方向大概率还没有收敛好。
|
||||
|
||||
<a id="jtbd-formula"></a>
|
||||
## 5. 直接套用的一句话公式 [↩ 回到开头](#top-jtbd)
|
||||
|
||||
当你想梳理一个产品方向时，可以先套这个非常实用的句式：
|
||||
|
||||
> 当 __________ 的时候，我想要 __________，以便于 __________。
|
||||
> 现在我只能通过 __________ 来勉强完成这件事。
|
||||
|
||||
比如：
|
||||
|
||||
> 当我开完一场信息量很大的项目会时，我想要快速得到一份带待办、责任人和截止时间的纪要，以便于我能马上同步团队并推进执行。
|
||||
> 现在我只能靠自己回忆、翻聊天记录和手工整理来勉强完成这件事。
|
||||
|
||||
再比如：
|
||||
|
||||
> 当我准备投递一个新岗位时，我想要快速把已有经历改写成更贴合岗位的版本，以便于我能更有把握地投出一份像样的简历。
|
||||
> 现在我只能反复复制旧简历、手改措辞，改到最后越来越不确定。
|
||||
|
||||
如果你能把一句话写到这种清晰程度，后面的页面设计、提示词设计、功能优先级判断，都会容易很多。
|
||||
|
||||
## 6. 做 AI 产品时，特别要看的三层 job
|
||||
|
||||
很多 AI 产品在功能演示时看上去很强，但真正上线之后却留不住人，常见原因是只解决了表层动作，没有解决更深的 job。
|
||||
|
||||
你可以把一个 job 粗略分成三层来看：
|
||||
|
||||
### 6.1 功能层
|
||||
|
||||
最表面的任务是什么？
|
||||
|
||||
- 总结文档
|
||||
- 改写文案
|
||||
- 提取待办
|
||||
- 生成图片
|
||||
|
||||
这是用户嘴上最容易说出来的一层。
|
||||
|
||||
### 6.2 情绪层
|
||||
|
||||
用户希望减少什么不舒服，或者获得什么感受？
|
||||
|
||||
- 不想那么慌
|
||||
- 不想显得不专业
|
||||
- 不想每次都从零开始
|
||||
- 想更有掌控感
|
||||
|
||||
很多付费意愿，实际上和情绪层关系很大。
|
||||
|
||||
### 6.3 社会层
|
||||
|
||||
用户希望在别人眼里变成什么样？
|
||||
|
||||
- 看起来更靠谱
|
||||
- 在团队里更有组织能力
|
||||
- 在客户面前更专业
|
||||
- 在社交平台上更会表达
|
||||
|
||||
如果你只做功能层，产品很容易被替代；如果你同时理解了情绪层和社会层，你就更容易找到真正有黏性的价值。
|
||||
|
||||
## 7. 用 JTBD 反过来筛产品方向
|
||||
|
||||
有时候不是你已经有产品，而是你手里有 3 到 5 个点子，不知道做哪个。这时 JTBD 很适合拿来做筛选。
|
||||
|
||||
你可以拿着每个点子，分别问自己 5 个问题：
|
||||
|
||||
1. 这个点子对应的场景是不是足够具体？
|
||||
2. 用户现在是否已经在用某种笨办法解决？
|
||||
3. 这个 job 的痛感是否足够强，或者足够高频？
|
||||
4. 如果我做好了，用户会不会明显感受到“状态变好了”？
|
||||
5. 第一版能不能只围绕这个 job 的关键一步，做出一个很小但有用的版本？
|
||||
|
||||
如果一个方向讲到最后还是只能说“感觉挺有意思”，却说不清触发、替代方案和成功标准，那它大概率还只是一个模糊灵感，不是一个成熟方向。
|
||||
|
||||
## 8. 可以直接拿去访谈用户的问题
|
||||
|
||||
很多人一做调研就问：“你想要什么功能？”这种问法很容易得到表面答案。
|
||||
|
||||
JTBD 更适合问下面这些问题：
|
||||
|
||||
- 最近一次你遇到这个问题是什么时候？
|
||||
- 当时你在做什么，为什么会卡住？
|
||||
- 你最后是怎么解决的？
|
||||
- 这个过程里最烦、最慢、最不放心的地方是什么？
|
||||
- 如果有一个工具能帮你，什么结果会让你觉得真的有用？
|
||||
- 你试过哪些替代方法？为什么它们不够好？
|
||||
|
||||
这种问法有个好处：它会把对话拉回真实经历，而不是停留在想象中的偏好。
|
||||
|
||||
## 9. 用 AI 帮你做 JTBD 拆解
|
||||
|
||||
JTBD 本身不是 AI 发明的，但 AI 很适合帮你整理和提炼 JTBD。
|
||||
|
||||
比如你已经收集了 5 到 10 条用户反馈，就可以把它们丢给模型，让它按以下结构总结：
|
||||
|
||||
```text
|
||||
请你扮演产品研究助手。
|
||||
我会给你一些用户原话，请你不要先给功能建议，
|
||||
而是先按 Jobs to Be Done 的框架整理：
|
||||
|
||||
1. 用户处在什么场景
|
||||
2. 触发他采取行动的事件是什么
|
||||
3. 他真正想完成的进展是什么
|
||||
4. 当前替代方案是什么
|
||||
5. 他最在意的成功标准是什么
|
||||
6. 这些反馈里反复出现的情绪词有哪些
|
||||
|
||||
最后，请把这些内容整理成 3 个最值得优先验证的 JTBD 假设。
|
||||
```
|
||||
|
||||
如果你已经有一个点子，也可以让 AI 帮你做第一轮收敛：
|
||||
|
||||
```text
|
||||
我想做一个 [你的产品想法]。
|
||||
请不要直接给我功能列表，而是用 Jobs to Be Done 方法帮我分析：
|
||||
|
||||
1. 这个产品可能服务哪些具体场景
|
||||
2. 每个场景中用户想完成的核心 job 是什么
|
||||
3. 现有替代方案有哪些
|
||||
4. 哪个 job 最适合作为 MVP 的起点，为什么
|
||||
5. 请把最终推荐的 job 写成一句清晰的 JTBD 句子
|
||||
```
|
||||
|
||||
这样做的好处是，你不会一上来就被 AI 带去“脑暴 50 个功能”，而是先把方向讲清楚。
|
||||
|
||||
## 10. 新手最常见的 4 个误区
|
||||
|
||||
### 10.1 把 job 写成功能名
|
||||
|
||||
“AI 总结”“智能分类”“自动生成”都不是 job，它们只是可能的实现方式。
|
||||
|
||||
### 10.2 把人群写得很宽
|
||||
|
||||
“所有职场人”“所有学生”“所有创业者”通常都太泛。越泛，你越难看见真实场景。
|
||||
|
||||
### 10.3 只听用户说，不看用户怎么做
|
||||
|
||||
用户会描述自己想要什么，但他真正的优先级，常常藏在他现在如何凑合解决问题里。
|
||||
|
||||
### 10.4 一开始就想做完整平台
|
||||
|
||||
JTBD 的正确打开方式，通常不是“我来做一个包打天下的大平台”，而是先盯住一个场景里最关键的一步，把它做到非常顺手。
|
||||
|
||||
## 11. 小结
|
||||
|
||||
Jobs to Be Done 最有价值的地方，不是给你一个新名词，而是帮你换一个观察角度：**不要只盯着产品功能，而要盯着用户想把什么事情推进到下一步。**
|
||||
|
||||
当你开始反复问自己：
|
||||
|
||||
- 用户是在什么场景下雇用这个产品的
|
||||
- 他到底卡在了哪里
|
||||
- 现在正用什么办法硬撑
|
||||
- 事情解决后，状态会发生什么变化
|
||||
|
||||
你会发现，很多原本模糊的点子一下子变清楚了，很多原本很花哨的功能也一下子没那么重要了。
|
||||
|
||||
做产品，尤其是做 AI 产品，最怕的是一开始就沉迷能力展示。JTBD 能帮你把注意力拉回到真正重要的地方：**用户为什么需要你，以及你到底在帮他完成什么进展。**
|
||||
|
||||
<a id="jtbd-ai"></a>
|
||||
## 12. 如何利用 AI 帮你实践 JTBD [↩ 回到开头](#top-jtbd)
|
||||
|
||||
JTBD 不是 AI 发明的，但 AI 很适合在这套方法里当你的研究助手、整理助手和对照助手。关键是：**让 AI 帮你整理和扩展，而不是替你臆测用户。**
|
||||
|
||||
你可以这样用：
|
||||
|
||||
### 12.1 让 AI 帮你把模糊点子改写成 JTBD 假设
|
||||
|
||||
当你脑子里只有一句模糊描述，比如“我想做一个帮大学生找实习的工具”，可以先让 AI 帮你把它拆成几种可能的 job：
|
||||
|
||||
```text
|
||||
我现在有一个模糊产品点子：[你的点子]
|
||||
请不要直接给我功能列表，而是用 Jobs to Be Done 的方式帮我分析：
|
||||
1. 可能对应哪些具体场景
|
||||
2. 每个场景里用户真正想完成的进展是什么
|
||||
3. 当前替代方案可能是什么
|
||||
4. 哪个 job 最适合先做 MVP
|
||||
请最后把每个 job 写成一句清晰的 JTBD 句子。
|
||||
```
|
||||
|
||||
你甚至可以把输入写得很小白：
|
||||
|
||||
```text
|
||||
我想做一个帮大学生找实习的东西。
|
||||
我现在也说不清具体是做什么，你帮我想想用户到底想完成什么事。
|
||||
```
|
||||
|
||||
AI 可能给出的有用输出会像这样：
|
||||
|
||||
```text
|
||||
可能的 JTBD 方向：
|
||||
|
||||
1. 当我第一次准备投实习时，我想快速知道应该先准备哪些材料，
|
||||
以便我不要因为信息混乱一直拖着不投。
|
||||
|
||||
2. 当我看到一个实习岗位时，我想快速判断自己是否值得投，
|
||||
以便我不要在不合适的岗位上浪费太多时间。
|
||||
|
||||
3. 当我开始投递时，我想把现有简历改成更贴合岗位的版本，
|
||||
以便我能更快完成投递并提高通过率。
|
||||
```
|
||||
|
||||
这种输出的价值在于，它会把你原本一句很泛的想法，拆成几个更接近真实场景的方向。
|
||||
|
||||
### 12.2 让 AI 帮你整理访谈原话
|
||||
|
||||
如果你已经做了几次用户访谈，可以把访谈记录交给 AI，让它帮你提炼反复出现的场景、触发点、替代方案和成功标准。
|
||||
|
||||
```text
|
||||
下面是 5 位用户的访谈原话。
|
||||
请不要先给解决方案，而是按 JTBD 框架整理：
|
||||
1. 用户处在什么场景
|
||||
2. 触发他采取行动的事件是什么
|
||||
3. 他真正想完成的进展是什么
|
||||
4. 当前替代方案是什么
|
||||
5. 他最在意的成功标准是什么
|
||||
6. 哪些信息在多位用户中重复出现
|
||||
最后整理成 3 条最值得优先验证的 JTBD 假设。
|
||||
```
|
||||
|
||||
一个很简单的小白输入也可以这样写：
|
||||
|
||||
```text
|
||||
我问了 3 个人，他们大概是这样说的：
|
||||
|
||||
1. 每次要投实习我都得重新改简历，特别烦。
|
||||
2. 我其实最怕的是不知道自己写得对不对。
|
||||
3. 我现在会先找学长学姐帮我看，但每次都不好意思总麻烦别人。
|
||||
|
||||
你帮我整理一下，他们真正想完成的事情是什么。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
整理结果：
|
||||
|
||||
- 共同场景：准备投递实习前，需要处理简历
|
||||
- 共同困难：不知道如何修改到“够好”
|
||||
- 当前替代方案：找学长学姐帮看，自己反复修改
|
||||
- 可能的 JTBD：
|
||||
当我准备投递实习时，我想更快判断简历是否已经达到可投递水平，
|
||||
以便我不要一直卡在“再改一改”而迟迟投不出去。
|
||||
```
|
||||
|
||||
这种输出很有用，因为它帮你从零散原话里提炼出更像“需求”的东西。
|
||||
|
||||
### 12.3 让 AI 帮你做一轮轻量级网络调研
|
||||
|
||||
在你还没开始大规模访谈前，可以先让 AI 帮你做一些很轻的外部信息扫描，比如：
|
||||
|
||||
- 公开论坛或社区里，大家是怎么抱怨这个问题的
|
||||
- 市面上已有产品主要在解决哪一层问题
|
||||
- 用户最常见的替代方案是什么
|
||||
- 常见评价里，大家最满意和最不满意的点是什么
|
||||
|
||||
这种调研不能代替真实用户访谈，但很适合作为 Discover 阶段的热身，帮你先建立问题地图。
|
||||
|
||||
一个简单输入可以是：
|
||||
|
||||
```text
|
||||
请你帮我查一查：
|
||||
“大学生改简历、投实习时最常见的痛点是什么？”
|
||||
优先看公开论坛、经验帖、求职社区里大家自己说的话。
|
||||
帮我整理成 5 条最常见问题。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
常见痛点整理：
|
||||
|
||||
1. 不知道简历该写什么，经历太少
|
||||
2. 不知道怎么针对不同岗位修改
|
||||
3. 改了很多版，但始终不确定是否够好
|
||||
4. 找不到可靠的人帮忙看
|
||||
5. 投递流程复杂，容易拖延
|
||||
```
|
||||
|
||||
这类输出不能当最终结论，但很适合帮你先决定要优先访谈哪类问题。
|
||||
|
||||
### 12.4 让 AI 充当“反方”
|
||||
|
||||
很多时候，我们会对自己的想法太有感情。你可以专门让 AI 扮演一个挑刺的人，逼你把问题说得更清楚：
|
||||
|
||||
```text
|
||||
请你扮演一个非常严格的产品研究顾问。
|
||||
下面是我的 JTBD 假设：[你的假设]
|
||||
请从以下角度批判它：
|
||||
1. 这个场景是否过宽
|
||||
2. 这个 job 是否写成了功能而不是真正进展
|
||||
3. 替代方案是否太弱
|
||||
4. 成功标准是否不够清楚
|
||||
5. 这个假设最需要被验证的风险是什么
|
||||
```
|
||||
|
||||
这样做的好处是，你能更快发现自己是在看需求，还是只是在看自己喜欢的方案。
|
||||
|
||||
## 📚 Assignments
|
||||
|
||||
请你根据上文内容，完成下列作业：
|
||||
|
||||
1. 选一个你最近想做的产品点子，用一句 JTBD 公式把它写清楚
|
||||
2. 为这个点子补齐 5 个要素：场景、触发、进展、替代方案、成功标准
|
||||
3. 找 3 个潜在用户，至少问出一次“最近一次你遇到这个问题是什么时候”
|
||||
4. 把访谈原话交给 AI，整理成 3 条最值得优先验证的 JTBD 假设
|
||||
|
||||
## 延伸阅读
|
||||
|
||||
- [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,589 @@
|
||||
---
|
||||
title: 'The Mom Test：如何通过用户访谈验证需求'
|
||||
description: '面向零基础读者的 The Mom Test 入门文章。学会避免礼貌性反馈，围绕真实行为、具体事实和已有问题做用户访谈，把“听起来不错”变成更可靠的需求判断。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = '约 <strong>1.5 小时</strong>'
|
||||
</script>
|
||||
|
||||
# The Mom Test：如何通过用户访谈验证需求
|
||||
|
||||
<a id="top-mom"></a>
|
||||
|
||||
## 本章导读
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['用户访谈', '需求验证', '用户研究', '产品调研']"
|
||||
coreOutput="1 组更能问出真实信息的访谈问题"
|
||||
expectedOutput="不再把用户的礼貌性鼓励当成验证，而能用真实行为判断方向"
|
||||
>
|
||||
|
||||
很多人第一次做产品调研时，以为最重要的是“找人聊聊”。于是他们去问朋友、同事，甚至家人：
|
||||
|
||||
- 你觉得我这个想法怎么样？
|
||||
- 如果有这样一个产品，你会不会用？
|
||||
- 这个功能听起来是不是还不错？
|
||||
|
||||
对方往往也会给出非常鼓舞人的反馈：
|
||||
|
||||
- 挺好的啊
|
||||
- 听起来很有用
|
||||
- 我觉得你可以试试
|
||||
|
||||
问题在于，这些回答通常并不能帮你做判断。它们更像是礼貌、支持，或者一种不想当场扫你兴的自然反应。你以为自己得到了“市场验证”，其实只是收集了一堆很难用来决策的安慰。
|
||||
|
||||
The Mom Test 这套方法，就是专门用来解决这个问题的。它提醒我们：**不是用户在故意骗你，而是你问问题的方式，天然会把对方引向好听但没用的回答。**
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 最小 SOP
|
||||
**目的**：看完后，你会更清楚怎么和用户聊天，才不会只听到“听起来不错”，而是真的问出能帮你判断方向的信息。
|
||||
|
||||
**行动项**：把你原本想问的 5 个问题改掉，优先问“最近一次发生在什么时候”“你当时怎么处理”。
|
||||
|
||||
**结果**：你会更容易分清哪些是意见，哪些才是真正能支撑判断的证据。
|
||||
|
||||
**关键词跳转**：[The Mom Test 是什么](#mom-what) · [三个核心原则](#mom-principles) · [AI 怎么帮你](#mom-ai)
|
||||
:::
|
||||
|
||||
## 你将学到以下内容
|
||||
|
||||
1. The Mom Test 到底在解决什么问题，为什么很多“用户调研”其实没有调研到真实信息
|
||||
2. 这套方法最核心的几个原则：少问意见，多问行为；少问假设，多问事实
|
||||
3. 怎样把一个容易得到假阳性反馈的问题，改成更有价值的访谈问题
|
||||
4. 如何把 The Mom Test 和 JTBD、需求验证、MVP 判断连起来使用
|
||||
|
||||
<a id="mom-what"></a>
|
||||
## 1. The Mom Test 到底是什么 [↩ 回到开头](#top-mom)
|
||||
|
||||
The Mom Test 来自 Rob Fitzpatrick 的同名书籍。它的名字听起来有点像玩笑，但点得非常准：
|
||||
|
||||
**就算是你妈妈，也很难直接告诉你“这是个烂想法”。**
|
||||
|
||||
原因不是她不诚实，而是：
|
||||
|
||||
- 她不想伤害你
|
||||
- 她会下意识鼓励你
|
||||
- 她很容易顺着你的表达方式回答
|
||||
|
||||
其实不只是妈妈，朋友、同事、前同学，甚至很多陌生人，在面对你的产品想法时，也常常会给出类似的“正向反馈”。这不代表需求真的存在，只代表你把问题问成了一个很容易得到好听答案的形式。
|
||||
|
||||
所以，The Mom Test 的重点从来不是“别问妈妈”，而是：
|
||||
|
||||
**别把问题问成任何人都会顺着你回答的样子。**
|
||||
|
||||
这套方法真正想教你的，是如何通过对话，拿到更接近真实需求的信息，而不是收集一堆让自己感觉良好的评论。
|
||||
|
||||
## 2. 它解决的核心问题是什么
|
||||
|
||||
The Mom Test 主要解决的是一种非常常见的认知错觉：
|
||||
|
||||
**把礼貌性的积极反馈，当成真实需求。**
|
||||
|
||||
比如你问：
|
||||
|
||||
- 你觉得这个 App 想法怎么样？
|
||||
- 如果我做一个 AI 帮你写简历的工具，你会用吗？
|
||||
- 这个功能是不是很有价值？
|
||||
|
||||
这些问题的共同特点是：
|
||||
|
||||
- 它们都在问“意见”
|
||||
- 它们都带着一点暗示
|
||||
- 它们都在谈一个还没发生的未来
|
||||
|
||||
而人对“意见”和“未来假设”的回答，通常都不稳定。很多人会高估自己的兴趣、高估自己的执行力，也会高估自己未来的购买意愿。
|
||||
|
||||
所以 The Mom Test 提醒你：
|
||||
|
||||
- 不要太相信别人对你点子的评价
|
||||
- 不要太相信别人对未来行为的预测
|
||||
- 要尽量回到用户已经发生过的真实行为里
|
||||
|
||||
因为和“你会不会用”相比，“你上次怎么处理这件事的”往往更接近真相。
|
||||
|
||||
<a id="mom-principles"></a>
|
||||
## 3. 三个最核心的原则 [↩ 回到开头](#top-mom)
|
||||
|
||||
如果你只想先记住最重要的部分，可以先记下面这三个原则。
|
||||
|
||||
### 3.1 少谈你的点子，多谈用户过去的真实经历
|
||||
|
||||
很多无效访谈一开场就讲自己的方案，讲自己多么兴奋，讲自己准备做什么产品。问题是，一旦你讲得太多，对方就很容易切换到“配合你”“鼓励你”的状态。
|
||||
|
||||
相比之下，更好的方式是把重点放在对方的经历上：
|
||||
|
||||
- 最近一次遇到这个问题是什么时候？
|
||||
- 当时你在做什么？
|
||||
- 你最后是怎么处理的？
|
||||
- 哪一步最麻烦？
|
||||
|
||||
你会发现，这类问题能更自然地把对话带回现实，而不是停留在想象中的偏好。
|
||||
|
||||
### 3.2 少问抽象意见，多问具体事实
|
||||
|
||||
“我觉得这个功能挺好”“听起来不错”“好像有点用”，这些表达都太抽象了，很难指导产品决策。
|
||||
|
||||
更有价值的信息通常长这样：
|
||||
|
||||
- 我上周刚为了这件事折腾了 2 小时
|
||||
- 我现在是用 Excel 加微信硬撑
|
||||
- 我上个月已经为类似工具花过钱
|
||||
- 我最怕的是做错，不是做慢
|
||||
|
||||
这些才是真正能帮你判断问题强度、频率和付费可能性的信息。
|
||||
|
||||
### 3.3 少问用户想要什么方案，多看他现在怎么解决问题
|
||||
|
||||
用户很擅长描述自己的困扰，但不一定擅长设计解决方案。
|
||||
|
||||
如果你问：
|
||||
|
||||
- 你想不想要一个 AI 帮你自动做这个？
|
||||
- 你觉得加个智能功能有没有帮助？
|
||||
|
||||
你得到的，通常只是对某个方案的模糊态度，而不是需求本身。
|
||||
|
||||
更好的问题是：
|
||||
|
||||
- 你现在用什么方法处理这个问题？
|
||||
- 为什么你会选择这种方式？
|
||||
- 它哪里不够好？
|
||||
|
||||
看清现有替代方案，往往比直接问“你想要什么”更重要。
|
||||
|
||||
## 4. 为什么人们总会给你好听但没用的回答
|
||||
|
||||
如果你能理解这件事，做访谈时就会少很多误判。
|
||||
|
||||
### 4.1 人会下意识地保持礼貌
|
||||
|
||||
尤其当对话对象和你有关系时，对方很难直接说：
|
||||
|
||||
- 这个方向听起来不太行
|
||||
- 我根本不会用
|
||||
- 这个问题对我没那么重要
|
||||
|
||||
他更可能说“挺好的”“有机会可以做做看”。
|
||||
|
||||
### 4.2 人会高估未来的自己
|
||||
|
||||
很多人真心相信自己未来会：
|
||||
|
||||
- 更自律
|
||||
- 更愿意学习
|
||||
- 更愿意付费
|
||||
- 更愿意尝试新工具
|
||||
|
||||
所以“如果有的话我应该会用”这句话，常常并不等于未来真的会用。
|
||||
|
||||
### 4.3 你的提问方式本身就在引导答案
|
||||
|
||||
当你问：
|
||||
|
||||
- 我这个想法是不是挺好？
|
||||
- 这个功能对你来说是不是很有帮助？
|
||||
|
||||
你其实已经偷偷把“正确答案”塞进问题里了。
|
||||
|
||||
这也是为什么 The Mom Test 特别强调：**不要把访谈做成你在寻找认可。**
|
||||
|
||||
## 5. 直接对比：什么问题容易问废，什么问题更有价值
|
||||
|
||||
下面这些对照，几乎是每个新手都会用到的。
|
||||
|
||||
| 容易问废的问题 | 更有价值的问题 |
|
||||
| --- | --- |
|
||||
| 你觉得我这个想法怎么样？ | 你最近一次遇到这个问题是什么时候？ |
|
||||
| 如果有这个产品你会用吗？ | 你现在是怎么处理这件事的？ |
|
||||
| 你愿意为这个功能付费吗？ | 你上次为了这个问题花过钱吗？花在什么上？ |
|
||||
| 你觉得这个功能重要吗？ | 这个流程里最烦、最慢、最不放心的是哪一步？ |
|
||||
| 你想不想要一个 AI 帮你自动做？ | 你现在为什么还没有找到更顺手的解决办法？ |
|
||||
|
||||
这张表最重要的不是具体句子，而是背后的方向：
|
||||
|
||||
- 从意见走向事实
|
||||
- 从未来走向过去
|
||||
- 从你的方案走向用户的问题
|
||||
|
||||
## 6. 一个零基础也能立刻用的访谈节奏
|
||||
|
||||
如果你现在就想去找人聊，可以直接按下面这个顺序来。
|
||||
|
||||
### 6.1 开场：说明你在学习，不是在推销
|
||||
|
||||
比如：
|
||||
|
||||
> 我最近在研究大家怎么处理这类问题，想先了解真实情况，不是来卖东西的。
|
||||
|
||||
这种表达会让对方更容易放下“我要给你积极反馈”的心理负担。
|
||||
|
||||
### 6.2 从最近一次真实经历开始问
|
||||
|
||||
可以先从这类问题开始：
|
||||
|
||||
- 最近一次遇到这个问题是什么时候？
|
||||
- 当时发生了什么？
|
||||
- 你第一反应是怎么处理的？
|
||||
|
||||
一旦对话进入具体事件，信息质量通常会明显提升。
|
||||
|
||||
### 6.3 往下追问行为、成本和替代方案
|
||||
|
||||
继续问：
|
||||
|
||||
- 你现在用什么办法解决？
|
||||
- 这个办法最不舒服的地方是什么？
|
||||
- 你为此花过多少时间、钱或者精力？
|
||||
- 你试过别的方法吗？为什么没继续用？
|
||||
|
||||
### 6.4 最后再判断痛感和优先级
|
||||
|
||||
你不需要直接问“痛不痛”，可以从细节里判断：
|
||||
|
||||
- 他是不是经常遇到
|
||||
- 他是不是已经在主动补救
|
||||
- 他是不是已经愿意为此付出成本
|
||||
- 他在讲这件事时是不是带着明显情绪
|
||||
|
||||
这些都比一句“这是不是你的痛点”更有用。
|
||||
|
||||
## 7. 一个更完整的例子
|
||||
|
||||
假设你想做一个“AI 帮大学生改简历”的产品。
|
||||
|
||||
### 错误问法
|
||||
|
||||
你去问同学：
|
||||
|
||||
> 我想做一个 AI 简历优化工具，你觉得怎么样？
|
||||
> 如果它能根据岗位自动改简历，你会不会用？
|
||||
|
||||
这时候，对方很可能会说：
|
||||
|
||||
- 听起来挺好
|
||||
- 我觉得应该有用
|
||||
- 如果免费我会试试
|
||||
|
||||
这些回答几乎没有办法帮你判断需求到底强不强。
|
||||
|
||||
### 更好的问法
|
||||
|
||||
你可以改成：
|
||||
|
||||
> 你最近一次改简历是什么时候？
|
||||
> 当时为什么要改？
|
||||
> 你是怎么改的？
|
||||
> 哪一步最卡？
|
||||
> 你有没有找过别人帮你看？
|
||||
> 你以前为简历这件事花过钱或者花过很多时间吗？
|
||||
|
||||
通过这些问题，你可能得到的信息会是：
|
||||
|
||||
- 很多人不是不会写，而是不知道怎么针对不同岗位改写
|
||||
- 他们最痛的不是排版，而是“不知道哪些经历值得写”
|
||||
- 他们会拖延，不是因为懒，而是因为每次改简历都很消耗
|
||||
- 他们已经在用学长建议、模板网站、AI 工具和朋友帮看来勉强解决
|
||||
|
||||
这时候，你离真实问题就近得多了。
|
||||
|
||||
## 8. The Mom Test 和 JTBD 怎么配合用
|
||||
|
||||
如果说 JTBD 帮你看清“用户想完成什么进展”，那么 The Mom Test 更像是在教你：
|
||||
|
||||
**怎么通过访谈，确认这个 job 是不是真的存在。**
|
||||
|
||||
你完全可以把两者接起来使用：
|
||||
|
||||
1. 先用 JTBD 假设一个 job
|
||||
2. 再用 The Mom Test 的方式，去问用户最近一次真实经历
|
||||
3. 看看这个 job 是否真的高频、真实、值得优先做
|
||||
|
||||
比如你的 JTBD 假设是：
|
||||
|
||||
> 当我准备投递实习时，我想快速把旧简历改成贴合岗位的版本，以便尽快完成投递。
|
||||
|
||||
那你就可以用 The Mom Test 风格的问题去验证：
|
||||
|
||||
- 你最近一次投递是什么时候？
|
||||
- 当时你是怎么改简历的？
|
||||
- 哪一段最难写？
|
||||
- 你改完之后怎么判断它够不够好？
|
||||
|
||||
这样，方法就连起来了：
|
||||
|
||||
- JTBD 帮你定义需求假设
|
||||
- The Mom Test 帮你访谈验证假设
|
||||
|
||||
## 9. 新手做用户访谈时最常见的误区
|
||||
|
||||
### 9.1 把访谈做成产品介绍会
|
||||
|
||||
你一讲太多自己的想法，对方就容易开始配合你，而不是告诉你真实情况。
|
||||
|
||||
### 9.2 访谈对象全是熟人
|
||||
|
||||
熟人不是不能聊，但熟人更容易鼓励你。你至少需要混合一些更接近真实用户的人，而不是只找支持你的人。
|
||||
|
||||
### 9.3 过早追着问功能
|
||||
|
||||
如果你还没搞清楚问题，就开始追问按钮、界面、功能细节，通常是在太早进入解决方案。
|
||||
|
||||
### 9.4 把一句“我会用”当成验证结果
|
||||
|
||||
访谈最多帮你判断方向，不等于已经完成验证。真正的验证，最终还是要看用户是否愿意付出真实成本，比如时间、切换成本、试用行为，甚至付费。
|
||||
|
||||
### 9.5 访谈结束后不整理
|
||||
|
||||
如果你聊完就放着，信息很快会变成模糊印象。最好尽快整理：
|
||||
|
||||
- 出现频率高的问题
|
||||
- 用户原话里的情绪词
|
||||
- 当前替代方案
|
||||
- 已经付出的成本
|
||||
- 你自己的新判断
|
||||
|
||||
## 10. 可以直接复制去用的问题清单
|
||||
|
||||
如果你想尽快开始，这里有一组足够通用的问题。
|
||||
|
||||
### 开场问题
|
||||
|
||||
- 最近一次你遇到这个问题是什么时候？
|
||||
- 当时具体发生了什么？
|
||||
|
||||
### 行为问题
|
||||
|
||||
- 你当时是怎么处理的？
|
||||
- 你为什么会选择这种方式？
|
||||
|
||||
### 成本问题
|
||||
|
||||
- 这件事一般会花掉你多少时间或精力？
|
||||
- 你有没有为了解决它花过钱？
|
||||
|
||||
### 替代方案问题
|
||||
|
||||
- 你试过别的工具或办法吗？
|
||||
- 为什么最后没有继续用？
|
||||
|
||||
### 收尾问题
|
||||
|
||||
- 如果以后还遇到同样的问题，你觉得最理想的解决方式应该是什么样？
|
||||
|
||||
注意，这个收尾问题可以问，但最好放在后面。因为前面你更需要拿到事实，而不是愿望。
|
||||
|
||||
## 11. 小结
|
||||
|
||||
The Mom Test 最重要的贡献，不是给你一套“更会聊天”的技巧，而是帮你建立一种更清醒的判断方式：
|
||||
|
||||
- 不要太快相信别人对你点子的夸奖
|
||||
- 不要把“如果有我会用”当成真实需求
|
||||
- 不要让访谈变成你在寻找认可
|
||||
|
||||
真正有价值的访谈，应该尽量回到这些东西上：
|
||||
|
||||
- 用户最近一次真实经历
|
||||
- 他现在怎么处理
|
||||
- 他已经付出了什么成本
|
||||
- 他在哪些地方明显不舒服
|
||||
|
||||
当你开始这样问，你得到的信息虽然有时没那么好听，但通常更有用。
|
||||
而做产品时，**有用的真相，永远比好听的鼓励更重要。**
|
||||
|
||||
<a id="mom-ai"></a>
|
||||
## 12. 如何利用 AI 帮你做用户访谈 [↩ 回到开头](#top-mom)
|
||||
|
||||
The Mom Test 本质上还是一套“和真人聊”的方法，所以 AI 不能替代真实访谈。但 AI 非常适合在访谈前、中、后给你打辅助，尤其适合帮新手降低门槛。
|
||||
|
||||
### 12.1 让 AI 帮你把“容易问废”的问题改写掉
|
||||
|
||||
很多人知道自己不该问“你觉得我这个想法怎么样”，但一开口还是会回到这种句子。你可以先把自己准备问的问题交给 AI，让它帮你改写：
|
||||
|
||||
```text
|
||||
下面是我准备做用户访谈时想问的问题：
|
||||
[贴上你的问题]
|
||||
|
||||
请你用 The Mom Test 的原则帮我改写：
|
||||
1. 删掉意见型问题
|
||||
2. 删掉假设未来的问题
|
||||
3. 尽量改成围绕过去真实行为、已有替代方案和已付成本的提问
|
||||
4. 最后整理成一套 8-10 个可以直接访谈的问题清单
|
||||
```
|
||||
|
||||
一个很小白的输入也完全可以：
|
||||
|
||||
```text
|
||||
我想问用户：
|
||||
1. 你觉得我做一个 AI 改简历工具怎么样？
|
||||
2. 你会不会用？
|
||||
3. 你愿不愿意付费？
|
||||
|
||||
请帮我改成更好的问法。
|
||||
```
|
||||
|
||||
AI 可能给出的有用输出会像这样：
|
||||
|
||||
```text
|
||||
改写后的问题：
|
||||
|
||||
1. 你最近一次改简历是什么时候？
|
||||
2. 当时为什么要改？
|
||||
3. 你是怎么改的？
|
||||
4. 哪一步最花时间？
|
||||
5. 你有没有找别人帮你看？
|
||||
6. 你以前有没有为简历修改花过钱或花过很多时间？
|
||||
```
|
||||
|
||||
这种输出很有帮助，因为它直接把你原本“在问意见”的问题，改成了“在问真实行为”的问题。
|
||||
|
||||
### 12.2 让 AI 帮你生成不同对象的访谈提纲
|
||||
|
||||
同一个方向，面对不同人群，访谈重点会不一样。比如学生、HR、自由职业者，关心点完全不同。你可以让 AI 帮你针对不同对象各出一版提纲：
|
||||
|
||||
- 面向新手用户，重点了解最近一次真实经历
|
||||
- 面向重度用户，重点了解替代方案和痛感
|
||||
- 面向付费用户，重点了解是否已经为此付过成本
|
||||
|
||||
这样你在真正聊天时会更有节奏，而不会每个人都问同一套问题。
|
||||
|
||||
比如你可以直接这样输入：
|
||||
|
||||
```text
|
||||
我要聊两类人：
|
||||
1. 第一次找实习的大学生
|
||||
2. 已经帮别人看过很多简历的学长学姐
|
||||
|
||||
请分别给我一套访谈提纲，每套 6 个问题。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
对大学生：
|
||||
1. 最近一次投实习是什么时候？
|
||||
2. 当时最卡的是哪一步？
|
||||
3. 你怎么知道自己的简历能不能投？
|
||||
...
|
||||
|
||||
对学长学姐：
|
||||
1. 你最近一次帮别人看简历是什么时候？
|
||||
2. 你最常看到哪些明显问题？
|
||||
3. 学弟学妹最容易卡在哪一步？
|
||||
...
|
||||
```
|
||||
|
||||
这样一来，你不用自己从零编问题，访谈准备会轻松很多。
|
||||
|
||||
### 12.3 让 AI 帮你整理访谈记录
|
||||
|
||||
访谈做完之后，最容易出现的问题不是“没信息”，而是“信息太散”。AI 很适合帮你把碎片化对话整理成结构化笔记：
|
||||
|
||||
```text
|
||||
下面是我和 3 位用户的访谈记录。
|
||||
请按 The Mom Test 的角度整理：
|
||||
1. 哪些内容是事实，哪些只是意见
|
||||
2. 用户最近一次真实行为是什么
|
||||
3. 当前替代方案是什么
|
||||
4. 用户已经付出的时间、金钱或精力成本是什么
|
||||
5. 哪些问题被反复提到
|
||||
6. 哪些说法听起来积极，但证据不足
|
||||
```
|
||||
|
||||
这一步尤其有价值，因为它能帮你把“听起来不错”的内容和“真的能支撑判断”的内容分开。
|
||||
|
||||
一个简单输入可以是：
|
||||
|
||||
```text
|
||||
这是我和一个用户聊完后的记录：
|
||||
|
||||
- 她说如果有个工具应该会试试
|
||||
- 她上周为了改简历花了一个晚上
|
||||
- 她现在主要靠朋友帮看
|
||||
- 她说最难的是不知道改到什么程度算可以投
|
||||
|
||||
请你帮我分一下，哪些是意见，哪些是事实。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
意见：
|
||||
- 如果有个工具应该会试试
|
||||
|
||||
事实：
|
||||
- 上周为了改简历花了一个晚上
|
||||
- 当前替代方案是找朋友帮看
|
||||
- 最难点是不知道什么时候算“可以投”
|
||||
|
||||
可用于判断需求的重点：
|
||||
- 这个问题最近刚发生过
|
||||
- 用户已经投入了明显时间成本
|
||||
- 当前方案依赖他人，不稳定
|
||||
```
|
||||
|
||||
这个输出就能很直观地告诉新手：哪些话能拿来做判断，哪些话只能听听。
|
||||
|
||||
### 12.4 让 AI 先做一轮轻量级网络搜索
|
||||
|
||||
如果你还没开始访谈，可以先让 AI 帮你做一些很轻的外部调研，比如：
|
||||
|
||||
- 公开社区里，大家最近是怎么抱怨这个问题的
|
||||
- 现有工具被吐槽最多的是什么
|
||||
- 用户是不是已经为相似问题花过钱
|
||||
- 市场上有哪些替代方案已经存在
|
||||
|
||||
这类信息不能替代真人访谈，但能帮你更快进入状态，知道该从哪里切入问题。
|
||||
|
||||
比如一个简单输入可以是：
|
||||
|
||||
```text
|
||||
请你帮我搜一下：
|
||||
“大学生改简历时最常吐槽什么”
|
||||
帮我整理出 5 条最常见抱怨，用很白话的话写出来。
|
||||
```
|
||||
|
||||
AI 可能输出：
|
||||
|
||||
```text
|
||||
常见抱怨：
|
||||
|
||||
1. 不知道简历上到底该写什么
|
||||
2. 每投一个岗位都要改，太累
|
||||
3. 改了很多版还是不确定好不好
|
||||
4. 没人能给靠谱反馈
|
||||
5. 总觉得还没准备好，所以一直拖
|
||||
```
|
||||
|
||||
这种结果的价值在于，它会让你更容易找到访谈切入口。
|
||||
|
||||
### 12.5 让 AI 扮演“访谈复盘教练”
|
||||
|
||||
你还可以把自己刚做完的一场访谈记录丢给 AI，让它帮你挑刺：
|
||||
|
||||
```text
|
||||
下面是我的一段用户访谈记录。
|
||||
请从 The Mom Test 的角度帮我复盘：
|
||||
1. 我哪些问题问得太像在找认可
|
||||
2. 哪些问题带有明显引导
|
||||
3. 哪些地方本来可以继续追问事实
|
||||
4. 如果再来一次，这段对话可以怎么问得更好
|
||||
```
|
||||
|
||||
这对新手特别有帮助，因为你会更快建立一种“我到底是在收集证据，还是在收集鼓励”的敏感度。
|
||||
|
||||
## 📚 Assignments
|
||||
|
||||
请你根据上文内容，完成下列作业：
|
||||
|
||||
1. 选一个你最近想做的产品方向，先写出 5 个你原本会问的“容易问废”的问题
|
||||
2. 把这 5 个问题改写成更符合 The Mom Test 风格的提问
|
||||
3. 找 3 个潜在用户，至少问出一次“最近一次你遇到这个问题是什么时候”
|
||||
4. 访谈结束后整理 4 类信息：真实行为、替代方案、已付成本、反复出现的困难
|
||||
|
||||
## 延伸阅读
|
||||
|
||||
- [The Mom Test 官方网站](https://momtestbook.com/)
|
||||
- [Rob Fitzpatrick: The Mom Test](https://www.robfitz.com/the-mom-test/)
|
||||
Reference in New Issue
Block a user