solution-interview

解决方案访谈

在开发完整产品之前，先测试你的解决方案是否真正解决了经过验证的问题。掌握向用户展示概念和原型的技巧，从而获得关于解决方案契合度的真实反馈。

何时使用此技能

• 问题访谈之后：测试你的解决方案是否解决了经过验证的问题
• 开发 MVP 之前：验证核心价值主张
• 原型测试：获取对概念和模型图的反馈
• 功能验证：测试新功能是否解决了实际问题
• 转向时：测试解决同一问题的替代方案
• 定价探索：了解用户的付费意愿

方法论基础

方面	详情
来源	Cindy Alvarez -《Lean Customer Development》（2014），Steve Blank - Customer Development
核心原则	“展示，而非讲述。让客户对具体的东西做出反应。他们的反应——而非言语——才能揭示真相。”
为何重要	人们无法准确预测自己的行为。通过展示原型并观察反应，你可以获得真实信号，了解你的解决方案是否有效。

Claude 的工作与由你决定的事项

Claude 的工作	由你决定
规划制作工作流	最终创意方向
建议技术方案	设备和工具选择
创建模板和检查清单	质量标准
指出最佳实践	品牌和风格决策
生成脚本大纲	最终脚本审批

此技能的作用

1. 规划解决方案演示 - 如何有效展示概念
2. 收集真实反应 - 获取真实反馈，而非礼貌性的回应
3. 发现差距和问题 - 找出缺失或错误之处
4. 测试付费意愿 - 及早验证定价
5. 衡量解决方案契合度 - 这是否真正解决了问题？
6. 生成产品洞察 - 明确要开发什么、跳过什么

使用方法

准备解决方案访谈脚本

I've validated this problem: [problem]
My proposed solution: [solution concept]
Create a solution interview script to test fit.
Include how to demo and what reactions to look for.

分析解决方案访谈结果

I showed my prototype to [X] people. Here's the feedback: [summary]
Analyze solution fit. Should I proceed to MVP?

创建解决方案访谈原型

Help me create the minimum viable demo for solution interviews:
Problem: [validated problem]
Solution concept: [idea]
What should I show? What level of fidelity is needed?

说明

第 1 步：先确认问题已得到验证

## Pre-Requisite Check

### Do NOT start solution interviews until:
- [ ] Completed 10+ problem interviews
- [ ] Problem validation scorecard passes:
  - [ ] >70% mentioned problem unprompted
  - [ ] Average severity >7/10
  - [ ] >30% actively seeking solutions
- [ ] Clear problem statement documented
- [ ] Target persona defined

### Why This Matters
If you test solutions without validated problems, you'll get:
- False positives ("sure, that looks nice")
- No ability to connect solution to real pain
- Wasted time building the wrong thing

### Problem Summary for This Interview
**Validated Problem:** ________________________________
**Severity Score:** __/10
**Who Has It:** [Persona description]
**What They Do Today:** [Current solution]

---

第 2 步：创建解决方案演示

## What to Demo

### Fidelity Levels

| Level | What It Is | When to Use | Time to Create |
|-------|------------|-------------|----------------|
| **Concept** | Verbal description + whiteboard | Very early, exploring directions | 30 min |
| **Paper** | Sketches, wireframes | Early concept validation | 2-4 hours |
| **Clickable** | Figma/InVision prototype | Testing workflows and features | 1-2 days |
| **Wizard of Oz** | Human behind the curtain | Testing value prop before building | 1-3 days |
| **Concierge** | You do it manually for them | Testing if solution works at all | 1+ week |
| **MVP** | Basic working product | Testing if they'll pay | 2+ weeks |

### What to Show

**DO Show:**
- Core value proposition in action
- The main workflow/interaction
- How it solves their specific problem
- Just enough to get a reaction

**DON'T Show:**
- Every feature you plan to build
- Polished design (distracts from function)
- Pricing (usually—test separately)
- Your roadmap (creates false expectations)

### Demo Script Template

"Before I show you anything, let me make sure I understand your problem.
[Recap validated problem in their words]
Does that sound right? [Confirm]

What I want to show you is rough—it's not a real product yet.
I'm interested in your honest reaction, even if it's negative.
The worst thing you could do is be polite.

[Demo the core concept - 2-3 minutes max]

Now I want to understand your reaction..."

---

第 3 步：开展解决方案访谈

## Solution Interview Structure (30-45 minutes)

### Part 1: Problem Recap (5 min)
"Last time we talked about [problem]. Since then, has anything changed?"
"What have you tried to solve this?"
Goal: Re-anchor to the problem, confirm it's still relevant

### Part 2: Solution Demo (5-10 min)
"I want to show you something we're exploring..."
[Demo core concept]
"What's your initial reaction?"
Goal: Present solution, capture immediate reaction

### Part 3: Feedback Deep Dive (15-20 min)
"What stood out to you?"
"What concerns you?"
"What's missing?"
"How would this fit into your current workflow?"
Goal: Understand fit, gaps, objections

### Part 4: Comparison to Current (5 min)
"How does this compare to what you do today?"
"Would this replace [current solution] or add to it?"
"What would have to be true for you to switch?"
Goal: Understand switching behavior

### Part 5: Commitment Testing (5 min)
"If this existed today, what would you do?"
"Would you be willing to try an early version?"
"What would it be worth to you if it worked?"
Goal: Test real interest with commitment asks

### Part 6: Next Steps (2 min)
"Can I follow up when we have something more complete?"
"Who else should I show this to?"
Goal: Get permission for follow-up, referrals

---

第 4 步：各访谈阶段的关键问题

## Solution Interview Questions

### Reaction Questions (Initial)
- "What's your first reaction?"
- "What stood out to you?"
- "What surprised you?"
- "What concerned you?"

**Watch for:**
- Immediate positive vs. confused
- Questions they ask (what do they care about?)
- Body language (leaning in vs. back)

### Understanding Questions (Comprehension)
- "In your own words, what does this do?"
- "How would you explain this to a colleague?"
- "What problem does this solve?"

**Red flags:**
- They can't explain it = too complex
- They describe it differently than intended = messaging problem
- They describe features, not benefits = not connecting to their problem

### Fit Questions (Solution-Problem Fit)
- "Does this solve the problem we discussed?"
- "What would be different about your day/week if you had this?"
- "Where does this fit in your current workflow?"
- "What would you stop doing if you had this?"

**Strong signals:**
- They can immediately see where it fits
- They describe specific situations it would help
- They identify things they'd stop doing (replacing current behavior)

### Gap Questions (What's Missing)
- "What's missing?"
- "What would prevent you from using this?"
- "What would make this a no-brainer?"
- "What's the most important thing we should build first?"

**Listen for:**
- Must-have features vs. nice-to-haves
- Deal-breaker gaps
- Unexpected use cases

### Concern Questions (Objections)
- "What worries you about this?"
- "What could go wrong?"
- "What would your [boss/team/IT] think?"

**Listen for:**
- Technical concerns (security, integrations)
- Organizational concerns (adoption, approval)
- Personal concerns (learning curve, change)

### Comparison Questions (vs. Alternatives)
- "How does this compare to what you do today?"
- "How does this compare to [competitor]?"
- "What would make you switch from your current solution?"

### Commitment Questions (Action)
- "If this was available today, what would you do?"
- "Would you be willing to try an early version?"
- "Would you pay for this? How much would it be worth?"
- "Can I add you to our beta list?"

---

第 5 步：评估解决方案契合度

## Solution Interview Scorecard

### Per Interview Assessment

**Interview #___**
**Participant:** _______________

| Criteria | Rating (1-5) | Notes |
|----------|--------------|-------|
| Understood what it does | | |
| Connected to their problem | | |
| Saw clear value | | |
| Would use/try it | | |
| Would pay (some amount) | | |
| Referred others | | |

**Reaction Type:**
- [ ] Excited ("When can I have this?")
- [ ] Interested (asking good questions)
- [ ] Neutral (polite but not engaged)
- [ ] Confused (didn't understand)
- [ ] Negative (specific concerns)

**Key Verbatim:**
"[Quote showing reaction]"

### Aggregate Analysis (After 10+ Interviews)

| Metric | Target | Actual | Status |
|--------|--------|--------|--------|
| Understood the solution | >90% | | |
| Said it solves their problem | >70% | | |
| Would try/use it | >60% | | |
| Would pay something | >40% | | |
| Made commitment (beta signup, referral) | >30% | | |

### Decision Framework

**VALIDATED - Proceed to MVP if:**
- [ ] 7+ of 10 said it solves their problem
- [ ] 6+ would try an early version
- [ ] 4+ expressed willingness to pay
- [ ] 3+ made real commitment (beta signup, referral, LOI)
- [ ] No critical gaps identified
- [ ] Clear must-have features identified

**ITERATE - Before MVP if:**
- [ ] Solution fit is partial (some love it, some don't)
- [ ] Critical feature gap identified
- [ ] Significant objection pattern emerged
- [ ] Need to test alternative approaches

**NOT VALIDATED - Pivot if:**
- [ ] Fewer than 5 said it solves their problem
- [ ] Widespread confusion about value
- [ ] No one willing to try it
- [ ] Unanimous critical concern

---

示例

示例 1：SaaS 解决方案访谈

输入：

“我已验证营销经理难以进行跨渠道归因（严重程度为 8/10）。我想测试一个仪表盘解决方案。请创建解决方案访谈脚本。”

输出：

解决方案访谈：营销归因仪表盘

访谈前准备

**已验证的问题：**营销经理无法跟踪跨渠道的营销活动 ROI **严重程度：**8/10 **当前解决方案：**手动电子表格、登录多个工具、凭猜测判断

演示准备

**展示内容：**包含以下内容的仪表盘 Figma 原型：

• 在单个屏幕上显示所有渠道
• 按触点归因
• 一目了然地查看营销活动 ROI

**演示时长：**最多 3 分钟

---

访谈脚本

第 1 部分：回顾问题（5 分钟） “上个月我们聊过，你提到每周要花 6 小时汇总营销数据，而且你的 CFO 经常会问一些你无法立即回答的问题。现在还是这样吗？”

[等待对方确认并补充近况]

“从那之后有什么变化吗？你尝试过什么新方法吗？”

---

第 2 部分：解决方案演示（5 分钟）

“我想给你看一些我们正在做的东西。它还很粗糙——还不是一款真正的产品——我想听听你真实的看法。

[共享屏幕——展示原型]

想象一下，这是你的营销仪表板。你登录后，就能在一个地方看到所有渠道——Google、LinkedIn、Facebook、电子邮件。

[指向归因视图]

在这里，你可以看到哪些触点带来了转化。不只是最后一次点击，而是完整的用户历程。

[指向投资回报率]

这里会自动计算营销活动的投资回报率——你可以把它展示给 CFO。

你最初的反应是什么？”

---

第 3 部分：深入了解反馈（15 分钟）

反应：

• “什么最吸引你的注意？”
• “你有什么顾虑？”

理解：

• “用你自己的话说，这能为你做些什么？”

契合度：

• “这能解决我们之前讨论的问题吗？”
• “带我了解一下你周一早上会如何使用它……”
• “如果有了它，你会停止做什么？”

不足之处：

• “还缺什么？”
• “什么情况会让你无法接受？”
• “我们应该优先开发的最重要功能是什么？”

异议：

• “你对这种做法有什么担忧？”
• “如果再增加一款工具，IT 部门会怎么说？”
• “有什么因素会妨碍你的团队使用它？”

---

第 4 部分：比较（5 分钟）

• “这和你现在用的电子表格相比如何？”
• “你了解过其他归因工具吗？和它们相比如何？”
• “什么会促使你放弃目前的做法？”

---

第 5 部分：承诺（5 分钟）

• “如果今天就有这款产品，你会怎么做？”
• “你愿意试用早期版本吗——即使它还很粗糙？”
• “如果它有效，你愿意为它支付多少？大致说个范围就好。”
• “我可以把你加入我们的抢先体验名单吗？”
• “我还应该和你团队里的谁聊聊？”

---

我会留意什么

积极信号：

• “我能用上这个吗？”／“什么时候能用？”
• 询问产品具体如何运作
• 已经开始设想自己会如何使用
• 提到它能帮上忙的具体场景
• 无须引导便愿意付费

消极信号：

• “挺不错的”（出于礼貌）
• 只有笼统的称赞，没有具体内容
• “做好了告诉我”（被动）
• 说不清自己会如何使用

危险信号：

• 不清楚产品的用途
• “我们已经有类似的东西了”
• “我不确定我们的团队会不会用”
• 存在我无法解决的重大功能缺口

---

示例 2：分析解决方案访谈结果

输入：

“我把餐食准备应用的原型展示给了 10 位在职家长。这是总结。我要开发 MVP 吗？”

总结：

• 10 人中有 8 人表示理解了它的用途
• 10 人中有 6 人表示它会有所帮助
• 10 人中有 4 人表示会尝试使用
• 10 人中有 2 人表示愿意付费
• 主要反馈：“看起来不错，但我不确定自己真的会用”

输出：

解决方案访谈分析

评估表

指标	目标	实际情况	状态
理解解决方案	>90%	80%	⚠️
表示能解决问题	>70%	60%	❌
愿意尝试	>60%	40%	❌
愿意付费	>40%	20%	❌

诊断：尚未验证

每项指标都低于门槛。这是一个值得高度警惕的信号。

关键洞察

“看起来不错，但我不确定自己真的会用”是一个关键的信号。这通常意味着：

1. 这个解决方案和他们的实际问题关联不够紧密
2. 一开始这个问题就不够严重
3. 他们口头上说想要的，与实际会采取的行动之间存在差距

分析问题

1. 问题是否经过了实际验证？

• 回顾问题访谈
• 严重程度真的达到 7+ 吗？还是受访者只是在客气？
• 他们是否在主动寻找解决方案？还是只是在承认问题确实存在？

2. 细分群体是否不匹配？

• 那 2 个说愿意付费的人是谁？他们有什么不同？
• 也许“在职父母”的范围太广了
• 可能需要聚焦于：“已经为膳食服务付费的在职父母”

3. 问题没错，错的是解决方案吗？

• 他们说缺少什么？
• 什么能让这成为“必选项”？
• 也许他们不想要应用——也许他们想要的是代做好的餐食

后续建议

选项 1：找出差距 回访那 6 个说“这会有帮助”但不愿尝试的人。询问：

• “从‘这会有帮助’到真正使用，中间差了什么？”
• “需要满足什么条件，你才会真正尝试？”
• “还需要有什么？”

选项 2：找到你的拥护者 那 2 个说愿意付费的人——他们是你的早期采用者。了解他们：

• 他们有什么不同？
• 他们遇到的问题有什么不同？
• 专门为他们打造

选项 3：转变解决方案 如果问题已经验证，但解决方案尚未验证：

• 还有什么办法能解决“我没时间，所以没法健康饮食”？
• 也许重点不是膳食规划，而是备餐
• 也许重点不是应用，而是服务
• 通过新的解决方案访谈测试其他解决方案

先不要构建 MVP

你会花几个月构建一个 80% 的人都不会用的东西。先让解决方案契合度达到 60% 以上。

---

示例 3：绿野仙踪式解决方案测试

输入：

“我想在构建 AI 之前，测试客户是否愿意为 AI 生成的社交媒体帖子付费。没有产品的情况下，我该如何进行解决方案访谈？”

输出：

绿野仙踪式解决方案访谈

概念

“绿野仙踪”测试是指你手动提供体验，同时让客户以为这一切都是自动完成的。这样你就能在构建技术之前测试其价值。

准备工作

客户看到的内容：

• 上传主题/简报
• 在 24 小时内收到社交媒体帖子
• 看起来像是由 AI 生成的

实际发生的事：

• 你（或自由职业者）手动撰写帖子
• 通过电子邮件或简单的控制面板交付
• 跟踪反馈和使用情况

解决方案访谈流程

第 1 部分：确认问题 “你提到每周要花 4 小时撰写社交媒体帖子。现在还是这样吗？”

第 2 部分：介绍概念 “我们正在测试一种能帮你撰写社交媒体帖子的 AI。你提供主题，它就会生成一周份量的帖子。下面是它生成内容的示例……”

[展示你手动制作的示例输出]

“你最初的反应是什么？”

第 3 部分：提出测试 “我们正在开展一项试点。在接下来的 2 周里，我会为你生成社交媒体帖子。你把主题发给我，我会在 24 小时内把帖子发给你。

试点期间不收费。我只需要你：

1. 实际使用这些帖子（或者告诉我为什么不使用）
2. 告诉我哪些地方好、哪些地方不好
3. 结束时告诉我你是否愿意为此付费

你愿意试试吗？”

第 4 部分：观察实际行为 试点期间，跟踪：

• 他们是否真的给你提供主题？
• 他们是否真的使用这些帖子？
• 他们给出了什么反馈？
• 他们做了多少修改？

第 5 部分：付费意愿 试点结束后： “根据过去 2 周的体验，你愿意为此付费吗？” “价格要定在多少，才能让你觉得这是个不费脑子的选择？” “怎样才能让它更有价值？”

这项测试能验证什么

你能了解什么	了解方式
他们是否认可输出内容？	他们使用了这些帖子吗？
质量是否足够好？	他们做了多少修改？
是否节省时间？	他们提到节省时间了吗？
他们是否愿意付费？	直接询问 + 观察行为
哪些功能重要？	他们给出了什么反馈？

奥兹法的成功标准

满足以下条件时，继续构建 AI：

• 10 人中有 7 人以上使用了所有提供的帖子
• 只需少量编辑（修改内容少于 20%）
• 定性反馈积极
• 5 人以上愿意以可行的价格付费
• 没有关键质量问题

为什么这样做有效

• 无需编写代码即可证明价值
• 获取真实的使用数据，而不是预测
• 可以低成本迭代“算法”（即你的人工流程）
• 使用手动版本的客户也会使用自动化版本

---

检查清单与模板

解决方案访谈准备检查清单

## Before the Interview

□ Problem validation confirmed
□ Solution demo/prototype ready
□ Demo script practiced (under 5 min)
□ Questions prepared
□ Note-taking system ready
□ Commitment asks defined

## What to Demo

□ Core value proposition only
□ Not over-polished (avoid distraction)
□ Relatable to their specific problem
□ Interactive if possible

## During the Interview

□ Recap problem first
□ Set expectation for honest feedback
□ Demo in under 5 minutes
□ Watch for immediate reaction
□ Probe on concerns and gaps
□ Test commitment (beta, pay, referral)
□ Get permission to follow up

---

解决方案访谈记录模板

## Solution Interview #___

**Date:** _______________
**Participant:** _______________
**Problem Recap:** Still experiencing issue? Y/N

### Demo Reaction

**Initial reaction:** (excited/interested/neutral/confused/negative)

**First words after demo:**
"[Verbatim]"

**Questions they asked:**
1.
2.
3.

### Fit Assessment

| Question | Response | Signal Strength |
|----------|----------|-----------------|
| Solves problem? | | Strong/Med/Weak |
| Would use it? | | Strong/Med/Weak |
| Replaces current? | | Strong/Med/Weak |
| Would pay? | | Strong/Med/Weak |

### Gaps & Concerns

**Missing features:**
-

**Concerns:**
-

**Deal-breakers:**
-

### Commitment Outcome

□ Would try beta
□ Would pay (amount: $___)
□ Made referral
□ Gave follow-up permission
□ No commitment

### Key Insight
________________________________

---

技能边界

此技能擅长的方面

• 规划音频制作工作流
• 提供技术指导
• 创建质量检查清单
• 提出创意方法

此技能无法做到的事

• 取代音频工程专业知识
• 做出主观的创意决策
• 直接访问或编辑音频文件
• 保证商业成功

参考资料

• Alvarez, Cindy. 《Lean Customer Development》（2014）——解决方案访谈方法
• Blank, Steve. 《The Four Steps to the Epiphany》（2005）——客户开发
• Fitzpatrick, Rob. 《The Mom Test》（2013）——获取真实反馈
• Constable, Giff. 《Talking to Humans》（2014）——访谈技巧
• Torres, Teresa. 《Continuous Discovery Habits》（2021）——持续验证

相关技能

• problem-interview - 必须在解决方案访谈前完成
• mom-test - 获取真实反馈
• lean-canvas - 记录学习成果
• pricing-validation - 测试付费意愿
• customer-discovery - 整体框架

---

技能元数据

• 模式：cyborg

name: solution-interview
category: validation
subcategory: customer-research
version: 1.0
author: MKTG Skills
source_expert: Cindy Alvarez
source_work: Lean Customer Development
difficulty: intermediate
estimated_value: $2,000 product validation consulting
tags: [validation, interviews, solutions, prototypes, MVP, startups, YC]
created: 2026-01-25
updated: 2026-01-25