customer-interviews

掌握客户访谈

深入了解用户痛点和行为触发因素，打造人们真正需要的产品。

借助 Lenny 的播客和 Newsletter 中 11 位嘉宾及多篇文章的见解，帮助用户掌握客户访谈。

如何提供帮助

1. 明确目标 - 招募参与者前，确定你要探索的具体问题领域或用户群体。
2. 起草访谈提纲 - 设计开放式问题，聚焦过去的行为和遇到困难的时刻，而不是假设性的观点。
3. 综合研究发现 - 分析访谈记录，区分礼貌性的鼓励和用户真正的主动需求。
4. 验证痛点 - 评估已发现的问题是否足够痛，值得开发新方案或改变行为。

核心原则

聚焦因果触发因素

Bob Moesta：“因此，Jobs to Be Done 方法的核心在于理解，是什么原因促使人们说：‘今天就是我该做出改变的时候。’”

访谈应找出导致行为改变的具体事件和情境。了解用户陷入困境的时刻，能让看似不理性的用户选择变得合情合理。

观察用户未表达的痛点

Jag Duggal：“要确保在开始构建之前先进行客户探索。还要确保探索的重点不只是询问客户，而是代表客户进行创新。”

有效的研究不止于倾听用户明确提出的需求，还要观察他们在自然环境中的表现。这能揭示用户可能无法描述的摩擦点。

主动寻找反证

Shaun Clowes：“要避免可得性偏差或确认偏误。大多数时候，人们只会去找一直在交流的人，结果学不到什么新东西。他们不会综合分析从对话中得到的结果，也不会寻找反事实，不会寻找证明自己错了的证据。”

为了避免确认偏误，你必须有意寻找能够推翻当前假设的数据点。找到反事实视角时，学习效果最显著。

优先直接观察

摘自“How to develop product sense”：“不要只阅读团队研究人员撰写的报告，而要参加用户研究访谈，亲自了解用户体验和反应。关键是关注细节，并思考人们为什么会对你的产品做出这样的反应。”

直接观察用户行为能让你亲身了解他们的情感和功能需求。研究报告往往会忽略现场反应中蕴含的细微差别。

避免推销

摘自“Startup to exit: Lessons from a first-time founder”：“然而，我们意识到最初的几次‘访谈’其实是在推销（例如：‘这是个很酷的新东西，你觉得怎么样？’）。这种方式偏见太重，根本得不到任何真实信号。”

把探索访谈变成推销，会妨碍你获取真实信号。使用不带偏见的访谈提纲，不提及你的具体解决方案，看看客户是否会自然地谈起问题。

留意用户主动选择的迹象

摘自“What to do if your product isn’t taking off”：“和人交谈时，要关注两件事：痛点和主动选择。痛点说明存在解决问题的机会。主动选择则说明你确实解决了这个问题。”

不要被礼貌性的鼓励蒙蔽，要寻找强烈痛感的迹象。人们愿意付钱，或即使原型有缺陷仍持续使用，这才是用户真正主动选择的证据。

模板与框架

• Jobs-to-be-Done 访谈技巧（Robby Stein）- Clayton Christensen 用于了解用户为何选择某款产品的访谈／询问方法，可区分功能性任务与情感性任务
• 合理确定研究规模的 Nielsen 数（Shaun Clowes）- 7–14 次用户访谈是最佳范围的原则：少于 7 次意味着数据不足，多于 14 次则收益递减。
• 痛点与拉力的四个信号（如果你的产品没有起色，该怎么办）- 用于客户探索对话中的四个具体指标，可帮助判断产品是否解决了真实问题
• Gusto 的客户访谈情绪反应测试（如何验证你的 B2B 创业想法）- 根据情绪反应的强烈程度，评估客户访谈反馈是否表明真实需求的框架
• 基于故事的访谈技巧（Teresa Torres）- 通过询问客户最近一次具体经历并沿着时间线追问，收集具体行为故事的访谈方法
• 自动化客户访谈招募系统（Teresa Torres）- 自动安排每周客户访谈的系统，让产品团队无需手动招募也能保持持续的访谈节奏
• 用户对话中值得留意的七个信号（初创公司的优先级排序）- 与早期用户和潜在用户交流时应倾听的内容，以产生产品创意

完整清单及详情请参阅 references/artifacts.md。

帮助用户思考的问题

• “是什么具体事件或艰难时刻让你开始寻找这个问题的解决方案？”
• “你能逐步讲讲上次遇到这种情况时的经过吗？”
• “你现在是怎么解决这个问题的？这种做法具体有哪些地方让你烦恼？”
• “如果你有一根魔法棒，可以改变当前工作流中的任何事情，你会改变什么？”
• “如果你什么都不做，继续维持现状，会发生什么？”
• “你以前试过哪些工具或变通办法，但没有奏效？”

需要指出的常见错误

• 诱导受访者 - 询问客户是否喜欢某个想法，会引来礼貌性的肯定，而不是诚实的行为数据。
• 止步于功能需求 - 不了解背后的“任务”就接受一份功能清单，会导致产品臃肿，无法解决根本问题。
• 访谈对象过多或过少 - 少于 7 次访谈会导致数据不足，而超过 14 次通常会使新见解的收益递减。
• 把兴趣误当成意愿 - 用户常会出于客气称某个想法“很酷”，但只有花钱或花时间等“拉力”信号才能表明真实需求。

深入了解

11 位嘉宾提供的全部 14 条见解，请参阅 references/guest-insights.md

相关技能

• 持续探索
• 想法验证
• 产品实验
• 定义 Icp