diff --git a/docs/.vitepress/config.mjs b/docs/.vitepress/config.mjs index d01f717..be4958c 100644 --- a/docs/.vitepress/config.mjs +++ b/docs/.vitepress/config.mjs @@ -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, diff --git a/docs/en/stage-0/index.md b/docs/en/stage-0/index.md index 8c7bb88..337500b 100644 --- a/docs/en/stage-0/index.md +++ b/docs/en/stage-0/index.md @@ -82,6 +82,33 @@ Master the Vibe Coding workflow, learn to deconstruct requirements, and independ /> +### 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 + + + + + + + ### 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. diff --git a/docs/en/stage-1/appendix-double-diamond/index.md b/docs/en/stage-1/appendix-double-diamond/index.md new file mode 100644 index 0000000..8fc5849 --- /dev/null +++ b/docs/en/stage-1/appendix-double-diamond/index.md @@ -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.' +--- + + + +# Double Diamond: First Choose the Right Problem, Then Build the Right Solution + + + +## Introduction + + + +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. + + + +::: 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 + + +## 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. + + +## 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. + + +## 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/) diff --git a/docs/en/stage-1/appendix-jobs-to-be-done/index.md b/docs/en/stage-1/appendix-jobs-to-be-done/index.md new file mode 100644 index 0000000..b2aae64 --- /dev/null +++ b/docs/en/stage-1/appendix-jobs-to-be-done/index.md @@ -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.' +--- + + + +# Jobs to Be Done: Find What Users Are Really Trying to Get Done + + + +## Introduction + + + +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. + + + +::: 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 + + +## 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. + + +## 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. + + +## 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) diff --git a/docs/en/stage-1/appendix-mom-test/index.md b/docs/en/stage-1/appendix-mom-test/index.md new file mode 100644 index 0000000..e0b04ea --- /dev/null +++ b/docs/en/stage-1/appendix-mom-test/index.md @@ -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.' +--- + + + +# The Mom Test: How to Validate Demand Through User Interviews + + + +## Introduction + + + +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. + + + +::: 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 + + +## 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.” + + +## 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. + + +## 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/) diff --git a/docs/public/sitemap.xml b/docs/public/sitemap.xml index b0289e1..03572b4 100644 --- a/docs/public/sitemap.xml +++ b/docs/public/sitemap.xml @@ -749,7 +749,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/appendix/ - 2026-03-14T22:17:12+08:00 + 2026-03-25T08:37:27+08:00 weekly 0.7 @@ -804,15 +804,22 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/1.0-finding-great-idea/ - 2026-03-06T17:59:01+08:00 + 2026-03-25T00:28:36+08:00 weekly 0.9 + + https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/1.0-finding-great-idea/index.temp-0114254/ + 2026-03-25T01:55:32.527Z + weekly + 0.9 + + https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/1.1-introduction-to-ai-ide/ - 2026-03-18T07:57:16-05:00 + 2026-03-25T08:37:27+08:00 weekly 0.9 @@ -820,7 +827,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/1.2-building-prototype/ - 2026-03-16T12:42:29+08:00 + 2026-03-25T00:28:36+08:00 weekly 0.9 @@ -828,7 +835,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/1.3-integrating-ai-capabilities/ - 2026-03-18T07:57:16-05:00 + 2026-03-25T00:28:36+08:00 weekly 0.9 @@ -884,23 +891,54 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-consumer-scenarios/ - 2026-03-06T17:59:01+08:00 + 2026-03-25T00:28:36+08:00 weekly 0.9 + + https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-double-diamond/ + 2026-03-25T06:31:44.977Z + weekly + 0.9 + + + + + https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-idea-sources/ + 2026-03-25T06:47:22.347Z + weekly + 0.9 + + https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-industry-scenarios/ - 2026-03-06T17:59:01+08:00 + 2026-03-25T00:28:36+08:00 weekly 0.9 + + https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-jobs-to-be-done/ + 2026-03-25T06:31:44.976Z + weekly + 0.9 + + + + + https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-mom-test/ + 2026-03-25T06:31:44.976Z + weekly + 0.9 + + + https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/ai-capabilities/2.1-dify-knowledge-base/ - 2026-03-24T08:44:49.470Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -908,7 +946,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/assignments/2.1-fullstack-app/ - 2026-03-24T07:00:25.007Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -916,7 +954,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/assignments/2.2-modern-frontend-trae/ - 2026-03-24T07:00:25.008Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -924,7 +962,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/backend/2.2-database-supabase/ - 2026-03-24T10:17:02.326Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -932,7 +970,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/backend/2.3-ai-interface-code/ - 2026-03-23T15:51:59.282Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -940,7 +978,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/backend/2.4-git-workflow/ - 2026-03-24T10:08:14.884Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -948,7 +986,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/backend/2.5-zeabur-deployment/ - 2026-03-24T01:20:30.534Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -956,7 +994,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/backend/2.6-modern-cli/ - 2026-03-24T09:29:56.836Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -964,7 +1002,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/backend/2.7-stripe-payment/ - 2026-03-24T07:00:25.008Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -972,7 +1010,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.0-lovart-assets/ - 2026-03-24T08:28:32.292Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -980,7 +1018,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.1-figma-mastergo/ - 2026-03-23T15:48:55.095Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -988,7 +1026,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.2-ui-design/ - 2026-03-24T07:00:25.008Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -996,7 +1034,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.3-multi-product-ui/ - 2026-03-24T05:49:47.526Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1004,7 +1042,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.4-llm-skills-beautiful/ - 2026-03-24T09:24:24.080Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1012,7 +1050,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.5-hogwarts-portraits/ - 2026-03-24T01:18:35.782Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1020,7 +1058,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.6-design-to-code/ - 2026-03-23T15:51:59.282Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1028,7 +1066,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/frontend/2.7-modern-component-library/ - 2026-03-24T10:12:29.711Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1036,7 +1074,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-2/ - 2026-03-14T22:17:12+08:00 + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1052,7 +1090,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/ai-advanced/3.a1-rag-introduction/ - 2026-03-24T07:30:22.563Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1060,7 +1098,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/ai-advanced/3.a2-langgraph-advanced-rag/ - 2026-03-24T07:00:25.008Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1068,7 +1106,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/agent-teams/ - 2026-03-24T16:19:04.205Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1076,7 +1114,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/basics/ - 2026-03-24T08:39:26.659Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1084,7 +1122,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/claude-agent-sdk/ - 2026-03-24T08:26:09.452Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1092,7 +1130,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/long-running-tasks/ - 2026-03-24T08:29:07.591Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1100,7 +1138,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/mcp/ - 2026-03-24T08:06:58.426Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1108,7 +1146,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/mobile-development/ - 2026-03-24T08:26:46.026Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1116,7 +1154,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/skills/ - 2026-03-24T08:27:00.403Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1124,7 +1162,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/spec-coding/ - 2026-03-24T08:15:15.558Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1132,7 +1170,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/superpowers/ - 2026-03-24T08:27:46.387Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1140,7 +1178,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/core-skills/workflow/ - 2026-03-24T10:34:29.162Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1148,7 +1186,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.1-choose-platform/ - 2026-03-24T06:11:17.435Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1156,7 +1194,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.10-electron-voice-to-text/ - 2026-03-24T06:30:57.078Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1164,7 +1202,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.11-nft-minting/ - 2026-03-24T06:30:57.087Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1172,7 +1210,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.12-vscode-extension/ - 2026-03-24T06:30:57.099Z + 2026-03-25T00:56:13+08:00 weekly 0.8 @@ -1180,7 +1218,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.13-qt-industrial-hmi/ - 2026-03-24T06:30:57.106Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1188,7 +1226,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.3-wechat-miniprogram/ - 2026-03-24T06:30:57.025Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1196,7 +1234,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.4-wechat-miniprogram-backend/ - 2026-03-24T06:08:37.178Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1204,7 +1242,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.5-android-app/ - 2026-03-24T06:30:57.033Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1212,7 +1250,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.6-ios-app/ - 2026-03-24T06:30:57.049Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1220,7 +1258,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.8-pwa-local-app/ - 2026-03-24T06:30:57.061Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1228,7 +1266,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/cross-platform/3.9-browser-ai-extension/ - 2026-03-24T06:30:57.068Z + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1236,7 +1274,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/ - 2026-03-07T14:11:01+08:00 + 2026-03-25T00:28:36+08:00 weekly 0.8 @@ -1252,7 +1290,7 @@ https://datawhalechina.github.io/easy-vibe/zh-cn/stage-3/personal-brand/3.7-personal-website-blog/ - 2026-03-24T08:04:35.919Z + 2026-03-25T00:28:36+08:00 weekly 0.8 diff --git a/docs/zh-cn/guide/introduction.md b/docs/zh-cn/guide/introduction.md index 94d08ab..861c2c5 100644 --- a/docs/zh-cn/guide/introduction.md +++ b/docs/zh-cn/guide/introduction.md @@ -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/) | 通过用户访谈验证需求的调研方法 | ✅ | ### 二、初中级开发工程师 diff --git a/docs/zh-cn/stage-0/index.md b/docs/zh-cn/stage-0/index.md index 9782c77..f23fcf9 100644 --- a/docs/zh-cn/stage-0/index.md +++ b/docs/zh-cn/stage-0/index.md @@ -82,6 +82,38 @@ /> +### 附录：用户研究与需求验证 + +**为什么需要**：当你已经有了产品点子，但还不确定它是不是真需求、该如何和用户聊、该优先验证什么时，这组内容能帮你把模糊感觉变成可验证的判断。 + +**什么时候看**： +- 当你说不清用户到底在“雇用”你的产品完成什么事时 +- 当你准备做用户访谈，却担心只得到礼貌性反馈时 +- 当你想把“感觉不错”的点子，变成更扎实的需求假设时 + + + + + + + + ### 附录：技术方案 **为什么需要**：在开发过程中遇到技术问题或想了解更优工具时，这些技术附录能提供即查即用的解决方案。 diff --git a/docs/zh-cn/stage-1/appendix-double-diamond/index.md b/docs/zh-cn/stage-1/appendix-double-diamond/index.md new file mode 100644 index 0000000..e7cccc4 --- /dev/null +++ b/docs/zh-cn/stage-1/appendix-double-diamond/index.md @@ -0,0 +1,544 @@ +--- +title: '双钻模型：先做对的事，再把事做对' +description: '面向零基础读者的 Double Diamond 入门文章。理解 Discover、Define、Develop、Deliver 四个阶段，避免在问题还没搞清楚时就急着做原型。' +--- + + + +# 双钻模型：先做对的事，再把事做对 + + + +## 本章导读 + + + +很多人第一次做产品时，最容易踩的坑不是“不够努力”，而是太快进入解决方案。 + +脑子里刚冒出一个方向，就开始想页面怎么画、按钮放哪、要不要接 AI、要不要做登录注册、原型用什么工具画。忙了一圈之后，才发现最根本的问题根本没想清楚：用户到底是不是真的有这个痛点？这个问题值不值得现在解决？你以为自己在推进项目，其实只是很努力地在错误方向上加速。 + +双钻模型（Double Diamond）就是用来避免这种情况的。 + +它最有价值的提醒是：**“做对的事情”和“把事情做对”，是两个完全不同的阶段。** 如果你还没搞清楚问题，就急着冲去做原型，通常只会把错误方向做得更完整。 + + + +::: info 最小 SOP +**目的**：看完后，你会更清楚做产品时什么时候该先想问题，什么时候才该开始想方案和原型，避免一上来就在错误方向上做得很认真。 + +**行动项**：按 `Discover → Define → Develop → Deliver` 四步往下走，每一步只做当前阶段该做的事。 + +**结果**：你会得到一个更清楚的问题定义、几种可比较的方案，以及一个可验证的最小版本。 + +**关键词跳转**：[双钻模型是什么](#dd-what) · [第一个钻石](#dd-first) · [AI 怎么帮你](#dd-ai) +::: + +## 你将学到以下内容 + +1. 双钻模型是什么，为什么它适合零基础做产品时使用 +2. Discover、Define、Develop、Deliver 四个阶段分别在做什么 +3. 怎样区分“现在应该继续发散”还是“现在应该开始收敛” +4. 如何把双钻模型用在 AI 产品、原型设计和需求验证里 + + +## 1. 双钻模型到底是什么 [↩ 回到开头](#top-dd) + +双钻模型是英国 **Design Council** 推广的一套经典设计流程框架。它把一个完整的设计与创新过程，画成两个连续的钻石形状。 + +之所以是“钻石”，是因为每个钻石都包含两种相反但都很重要的动作： + +- **发散**：先把视野打开，看更多可能性 +- **收敛**：再把范围缩小，做出判断和取舍 + +整个过程一共四步： + +1. **Discover**：广泛了解用户、问题、环境和市场 +2. **Define**：从大量信息里提炼出真正值得解决的核心问题 +3. **Develop**：围绕核心问题发散多种解决方案 +4. **Deliver**：筛选、原型、测试并交付更合适的方案 + +如果把这四步压缩成一句最容易记住的话，就是： + +- **第一个钻石**：先搞清楚到底要解决什么问题 +- **第二个钻石**：再决定用什么方案去解决它 + +这也是你刚才说得很准确的那句话： + +- **第一个钻石：做对的事情** +- **第二个钻石：把事情做对** + +## 2. 为什么双钻模型特别适合新手 + +新手做产品最常见的节奏，往往是这样的： + +- 想到一个点子 +- 觉得这个方向很酷 +- 马上开始画原型 +- 做着做着发现功能越来越多 +- 最后不知道自己到底在解决什么问题 + +双钻模型的价值，不在于让流程变复杂，而在于 **强迫你把“理解问题”和“设计方案”拆开** 。 + +这件事听起来很普通，但实际非常重要。因为很多失败的产品，不是执行不认真，而是： + +- 选错了问题 +- 误解了用户 +- 过早锁定了解决方案 +- 把大量时间花在细节打磨上，却没有验证方向 + +双钻模型就是在不断提醒你： + +- 不要因为想法顺手，就默认问题已经成立 +- 不要因为方案能做出来，就默认它值得做 +- 不要因为原型看起来完整，就默认用户会真的需要 + + +## 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 时代，做东西变得越来越快，双钻模型反而更重要。因为当“做出来”越来越容易时，真正稀缺的能力会变成：**你有没有在解决一个值得解决的问题，以及你有没有用合适的方式去解决它。** + +记住这一句就够了： + +**先做对的事情，再把事情做对。** + + +## 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/) diff --git a/docs/zh-cn/stage-1/appendix-idea-sources/index.md b/docs/zh-cn/stage-1/appendix-idea-sources/index.md new file mode 100644 index 0000000..de1f738 --- /dev/null +++ b/docs/zh-cn/stage-1/appendix-idea-sources/index.md @@ -0,0 +1,519 @@ +--- +title: '从哪里找点子：3 种最适合新手的参考来源' +description: '面向零基础读者的产品点子入门文章。学会从参考应用、行业趋势和投资机构清单里找到更具体的方向，并把“看起来很酷”收成一个能尝试的细分点子。' +--- + + + +# 从哪里找点子：3 种最适合新手的参考来源 + + + +## 本章导读 + + + +很多人卡在做产品的第一步，不是不想做，而是根本不知道该从哪开始想。 + +脑子里常见的状态是这样的： + +- 想做点 AI 相关的东西，但一时说不清要做什么 +- 刷了很多“创业灵感”“2026 大趋势”，看完还是很空 +- 看见别人做得很酷，觉得厉害，但不知道自己能从中切哪一小块 + +这时候，你最需要的往往不是再听一遍“要多观察用户”，而是先有一套更容易执行的起点：**去哪里看，怎么看，怎样把一个大方向收成一个更具体的小方向。** + +这篇文章讲的就是这个起点。它不会让你凭空发明一个完美点子，而是帮你学会从现成的参考里，慢慢收出一个更像真实产品方向的东西。 + + + +::: 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. 我能不能只切其中一步，先做一个很小但有用的版本？ + +下面这三种来源，就是帮助你一步步把方向收窄的。 + + +## 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、猪八戒这类平台上的“代做”“代整理”“代处理”服务 + +为什么这些地方特别有价值？ + +因为差评往往在说： + +- 现有产品哪里不好用 +- 哪一步还是得手工做 +- 为什么用户用了还是嫌麻烦 + +而“代做服务”在提醒你： + +- 这个需求已经有人在花钱解决 +- 但现在主要还是靠人工 +- 其中可能有一部分流程可以被产品化或自动化 + +所以，**先看参考应用，不只是为了模仿，而是为了看清楚“别人已经验证了哪一类问题”和“哪些地方还做得不够好”。** + + +## 3. 第二种：再看哪些方向正在起来 [↩ 回到开头](#top-idea-sources) + +如果第一种来源帮你看到“现在已经有人在做什么”，那第二种来源更像是在提醒你：**接下来哪些方向可能会越来越值得看。** + +比较典型的来源有： + +- Google Trends +- Exploding Topics +- 行业研究摘要 +- 垂直社区、论坛和行业媒体 + +看趋势最大的误区，是只停留在“这个词最近很火”。 +这对做产品帮助不大。你真正该看的是： + +- 哪个词在变热 +- 这个词落在哪些具体场景里 +- 哪些人会最早为它付出时间、切换成本或预算 + +比如你看到某个趋势方向在涨，不要停在： + +- AI voice +- AI healthcare +- AI sales + +而是继续问： + +- 是谁最先会为它买单？ +- 这个趋势会卡进哪个已有工作流？ +- 哪个子问题最像“现在就值得做”的切口？ + +### 3.1 趋势不是点子，它只是放大镜 + +趋势的价值，不是直接给你答案，而是帮你缩小搜索范围。 + +比如你原本完全没方向，后来看到： + +- 某类 AI 教育工具在持续增长 +- 某类行业自动化需求开始变热 +- 某类内容生产方式在快速普及 + +这时候你就知道：至少这个大方向现在不是冷门死角。接下来你应该做的不是停在“那我也做 AI 教育”，而是继续往下压： + +- 是面向学生、老师、家长，还是培训机构？ +- 是上课前、上课中，还是课后复盘？ +- 是提高效率、降低错误，还是提升转化率？ + +### 3.2 如果你想要“更业务”，就看更接近真实工作流的来源 + +有些趋势来源偏投资视角，能帮你看大方向；但如果你想再往“谁在真实花钱、谁在真实抱怨”靠近一点，可以继续看： + +- 政府采购和公开招标信息 +- 企业采购需求和项目招标平台 +- 行业论坛、职业社区、Reddit 垂直板块 +- 行业协会报告、行业年度报告 + +这些来源更“业务”的原因在于，它们离真实流程更近。你看到的不只是“未来可能值得做什么”，而是： + +- 现在谁已经愿意花钱 +- 预算大概在哪个区间 +- 需求写得有多具体 +- 哪些流程今天仍然靠 Excel、微信、纸笔、电话在硬撑 + +如果你能在一个趋势方向里，再补上这些业务信息，你得到的就不只是一个“看起来挺热”的方向，而是一个更像真实市场机会的方向。 + + +## 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 清单适合帮你找方向，不适合替你完成验证。** + + +## 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 清单更接近一个真正能尝试的产品方向了。 + + +## 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/) diff --git a/docs/zh-cn/stage-1/appendix-jobs-to-be-done/index.md b/docs/zh-cn/stage-1/appendix-jobs-to-be-done/index.md new file mode 100644 index 0000000..cc51f9c --- /dev/null +++ b/docs/zh-cn/stage-1/appendix-jobs-to-be-done/index.md @@ -0,0 +1,496 @@ +--- +title: '用 Jobs to Be Done 找到用户真正想完成的事' +description: '面向零基础读者的 Jobs to Be Done 入门文章。理解用户不是在买功能，而是在特定场景里“雇用”你的产品完成进展，并学会用 JTBD 拆解产品方向、访谈问题与 AI 提示词。' +--- + + + +# 用 Jobs to Be Done 找到用户真正想完成的事 + + + +## 本章导读 + + + +很多人刚开始做产品时，最容易犯的一个错误是把注意力全部放在“我要做什么功能”上。看别人有智能分类，你也想加；看别人有自动总结，你也想接；看别人做了 Agent、多模态、工作流，你也觉得自己不能少。 + +但现实里，用户很少是因为“这个功能名字很酷”才决定用一个产品。他们更多是在某个具体时刻，想把一件事情推进下去，于是临时“雇用”了一个工具、一个服务，甚至一个人，来帮自己完成这一步。 + +这正是 **Jobs to Be Done（JTBD）** 这套方法想提醒我们的事情：**用户不是在购买功能本身，而是在雇用某种解决方案，帮助自己完成一个进展。** + +本篇文章会用尽量直白的语言，带你从零理解 JTBD，并把它变成你做 AI 应用时能直接拿来用的分析工具。 + + + +::: info 最小 SOP +**目的**：看完后，你会更清楚怎样把一个模糊点子，收成一句真正有用户场景的需求，而不是脑子里只有一堆功能名。 + +**行动项**：写 1 句模糊点子，找 3 个潜在用户聊“最近一次怎么处理”，再整理成 1 条 JTBD 句子。 + +**结果**：你会得到一个更清楚的需求假设，知道第一版该先解决什么。 + +**关键词跳转**：[JTBD 是什么](#jtbd-what) · [一句话公式](#jtbd-formula) · [AI 怎么帮你](#jtbd-ai) +::: + +## 你将学到以下内容 + +1. 什么是 Jobs to Be Done，为什么它比“功能脑暴”更接近真实需求 +2. 如何区分“用户说想要的功能”和“用户真正想完成的事” +3. 怎样用一套简单模板，把一个模糊点子拆成场景、触发、障碍和成功标准 +4. 如何把 JTBD 用在 AI 产品、访谈提问和提示词整理里 + + +## 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 分钟内得到可分享的结果 +- 不需要二次大改就能发给别人 +- 不容易漏项、出错、忘事 +- 第一次用就知道下一步怎么走 + +如果你连“用户怎么判断值不值”都说不清，那这个方向大概率还没有收敛好。 + + +## 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 能帮你把注意力拉回到真正重要的地方：**用户为什么需要你，以及你到底在帮他完成什么进展。** + + +## 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) diff --git a/docs/zh-cn/stage-1/appendix-mom-test/index.md b/docs/zh-cn/stage-1/appendix-mom-test/index.md new file mode 100644 index 0000000..f93eab5 --- /dev/null +++ b/docs/zh-cn/stage-1/appendix-mom-test/index.md @@ -0,0 +1,589 @@ +--- +title: 'The Mom Test：如何通过用户访谈验证需求' +description: '面向零基础读者的 The Mom Test 入门文章。学会避免礼貌性反馈，围绕真实行为、具体事实和已有问题做用户访谈，把“听起来不错”变成更可靠的需求判断。' +--- + + + +# The Mom Test：如何通过用户访谈验证需求 + + + +## 本章导读 + + + +很多人第一次做产品调研时，以为最重要的是“找人聊聊”。于是他们去问朋友、同事，甚至家人： + +- 你觉得我这个想法怎么样？ +- 如果有这样一个产品，你会不会用？ +- 这个功能听起来是不是还不错？ + +对方往往也会给出非常鼓舞人的反馈： + +- 挺好的啊 +- 听起来很有用 +- 我觉得你可以试试 + +问题在于，这些回答通常并不能帮你做判断。它们更像是礼貌、支持，或者一种不想当场扫你兴的自然反应。你以为自己得到了“市场验证”，其实只是收集了一堆很难用来决策的安慰。 + +The Mom Test 这套方法，就是专门用来解决这个问题的。它提醒我们：**不是用户在故意骗你，而是你问问题的方式，天然会把对方引向好听但没用的回答。** + + + +::: 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 判断连起来使用 + + +## 1. The Mom Test 到底是什么 [↩ 回到开头](#top-mom) + +The Mom Test 来自 Rob Fitzpatrick 的同名书籍。它的名字听起来有点像玩笑，但点得非常准： + +**就算是你妈妈，也很难直接告诉你“这是个烂想法”。** + +原因不是她不诚实，而是： + +- 她不想伤害你 +- 她会下意识鼓励你 +- 她很容易顺着你的表达方式回答 + +其实不只是妈妈，朋友、同事、前同学，甚至很多陌生人，在面对你的产品想法时，也常常会给出类似的“正向反馈”。这不代表需求真的存在，只代表你把问题问成了一个很容易得到好听答案的形式。 + +所以，The Mom Test 的重点从来不是“别问妈妈”，而是： + +**别把问题问成任何人都会顺着你回答的样子。** + +这套方法真正想教你的，是如何通过对话，拿到更接近真实需求的信息，而不是收集一堆让自己感觉良好的评论。 + +## 2. 它解决的核心问题是什么 + +The Mom Test 主要解决的是一种非常常见的认知错觉： + +**把礼貌性的积极反馈，当成真实需求。** + +比如你问： + +- 你觉得这个 App 想法怎么样？ +- 如果我做一个 AI 帮你写简历的工具，你会用吗？ +- 这个功能是不是很有价值？ + +这些问题的共同特点是： + +- 它们都在问“意见” +- 它们都带着一点暗示 +- 它们都在谈一个还没发生的未来 + +而人对“意见”和“未来假设”的回答，通常都不稳定。很多人会高估自己的兴趣、高估自己的执行力，也会高估自己未来的购买意愿。 + +所以 The Mom Test 提醒你： + +- 不要太相信别人对你点子的评价 +- 不要太相信别人对未来行为的预测 +- 要尽量回到用户已经发生过的真实行为里 + +因为和“你会不会用”相比，“你上次怎么处理这件事的”往往更接近真相。 + + +## 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 最重要的贡献，不是给你一套“更会聊天”的技巧，而是帮你建立一种更清醒的判断方式： + +- 不要太快相信别人对你点子的夸奖 +- 不要把“如果有我会用”当成真实需求 +- 不要让访谈变成你在寻找认可 + +真正有价值的访谈，应该尽量回到这些东西上： + +- 用户最近一次真实经历 +- 他现在怎么处理 +- 他已经付出了什么成本 +- 他在哪些地方明显不舒服 + +当你开始这样问，你得到的信息虽然有时没那么好听，但通常更有用。 +而做产品时，**有用的真相，永远比好听的鼓励更重要。** + + +## 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/)