Applicable Scenarios
When users propose needs, do not directly accept the surface description. Use this methodology to deeply uncover what users truly want, identify needs users have not spoken aloud, and even discover needs users themselves are not aware of.
Core Methods
Needs Hierarchy Model
User needs are divided into four levels, with value increasing from bottom to top:
┌─────────────────┐
│ 惊喜需求 │ ← 超出预期，带来 "Wow"
│ (Delighters) │
├─────────────────┤
│ 潜在需求 │ ← 用户尚未意识到
│ (Latent) │
├─────────────────┤
│ 隐性需求 │ ← 用户想到但未说
│ (Implicit) │
├─────────────────┤
│ 显性需求 │ ← 用户明确表达
│ (Explicit) │
└─────────────────┘
Definitions of the Four Levels of Needs：
-
Explicit Needs: Needs explicitly expressed by users
- Extract directly from users' own words
- This is the starting point of needs analysis, not the endpoint
-
Implicit Needs: Needs users have thought of but not expressed
- What users consider "a matter of course" and therefore do not mention
- What users are embarrassed to say
- What users assume you will know
-
Latent Needs: Needs users are not yet aware of but will need
- Needs discovered based on scenario deduction
- Needs discovered based on competitor analysis
- Needs anticipated based on industry trends
-
Delightful Needs: Needs that exceed user expectations and can bring a "Wow" experience
- Innovative features or experiences
- Make users feel "This is amazing!"
- This is the key to product differentiation
5W2H Deep Questioning
For each need, systematically ask the following 7 dimensions:
| Dimension | Question | Purpose |
|---|---|---|
| What | What does the user say? What do they truly want behind it? | Identify real needs |
| Why | Why is this needed? What problem does it solve? | Understand motivation |
| Who | Who will use it? In what scenarios will it be used? | Clarify users |
| When | When will it be used? How often? | Understand scenarios |
| Where | Where will it be used? What is the environment like? | Understand context |
| How | How is it solved now? What pain points are there? | Discover opportunities |
| How much | How much are they willing to pay? (time/money/learning cost) | Evaluate value |
Questioning Techniques：
- Ask "why" at least 5 times until reaching the root motivation
- Do not settle for the first answer
- Pay attention to users' emotions and tone, which often hide real needs
Needs Priority Matrix
Based on value and cost, divide needs into 4 priority levels:
高价值
│
┌──────┼──────┐
│ 必做 │ 优先 │
│ P0 │ P1 │
低成本 ────┼──── 高成本
│ 可做 │ 谨慎 │
│ P2 │ P3 │
└──────┼──────┘
│
低价值
- P0 (Must Do): High value + Low cost = Must do
- P1 (Priority): High value + High cost = Prioritize doing
- P2 (Can Do): Low value + Low cost = Can do
- P3 (Cautious): Low value + High cost = Do not do for now
Output Requirements
After completing needs penetration, the following content should be output (usually as Chapter 2 of the PRD):
2. Needs Penetration Analysis
2.1 User Original Needs
[User's original statement, keep the exact wording]
2.2 Requirement Penetration
Explicit requirements (explicitly expressed by the user)
| Requirement | User's exact words | Interpretation |
|---|---|---|
| [Requirement 1] | "[exact words]" | [your interpretation] |
| [Requirement 2] | "[exact words]" | [your interpretation] |
Implicit requirements (what the user thinks of but does not express)
| Requirement | Basis for inference | Why it matters |
|---|---|---|
| [Requirement 1] | [basis] | [importance] |
| [Requirement 2] | [basis] | [importance] |
Latent requirements (those the user is not yet aware of)
| Requirement | Source of insight | Expected value |
|---|---|---|
| [Requirement 1] | [source] | [value] |
| [Requirement 2] | [source] | [value] |
Delight requirements (innovation points that exceed expectations)
| Requirement | Innovation point | Expected reaction |
|---|---|---|
| [Requirement 1] | [innovation point] | "Wow, this is amazing!" |
| [Requirement 2] | [innovation point] | [expected reaction] |
2.3 Requirement Priority Matrix
| Priority | Requirement | Value | Cost | Decision |
|---|---|---|---|---|
| P0 | [Requirement] | High | Low | Must do |
| P1 | [Requirement] | High | High | Do first |
| P2 | [Requirement] | Low | Low | Can do |
| P3 | [Requirement] | Low | High | Do not do for now |
Key Principles
- Do not rush to give answers: understand the problem first, then provide a solution
- Challenge assumptions: what the user says is not necessarily correct, verify it
- Focus on pain points: real requirements come from real pain
- Pursue delight: a good product does not just satisfy requirements, it must exceed expectations