用户研究与 JTBD

一、开场：一个常见的教学困境

假设你是产品经理。有一个数据让你非常焦虑：

你们的运动手表新用户中，有超过 30% 的人在购买后的 30 天内，就没有再完成过任何一次有效的运动记录。换句话说——他们买了表，用了两周，然后就放弃了。

你老板把这个数据拍在桌子上说："用户买我们的手表，30 天内就流失了。你去搞清楚为什么。下周给我方案。"

好，你的任务来了：搞清用户为什么在购买后 30 天内流失。

你会从哪里开始？

大多数人可能会有这样的第一反应：

• "发一个问卷给所有 30 天内停用的用户，问他们为什么不用了。"

• "对比留存的用户和流失的用户，看看他们在年龄、性别、运动习惯上有什么差异。"

• "找几个流失用户做深度访谈，听听他们的故事。"

这些方法都对，但都不完整。你用的每一种研究方法，都只能告诉你一部分真相。

今天这一讲，我们解决一个问题：当你不确定用户到底想要什么、为什么离开、什么能留他们——你该怎么找到答案？

---

二、核心概念：用户研究的完整框架

2.1 用户研究框架

用户研究不是教你"怎么发问卷"，而是教你如何在正确的时间、用正确的方法、研究正确的问题。

这个框架的核心是三个维度的决策：

维度一：数据类型——态度 vs 行为

这是用户研究中最基本的区分。

把态度和行为结合起来看，是用户研究的第一原则。 只看态度，你会被用户的善意欺骗；只看行为，你只看到了结果却不知道原因。

维度二：结果类型——定性 vs 定量

这可能是大家最熟悉的分类了。

这里要强调一个非常重要的原则：定性和定量不是"二选一"，而是"先后关系"。

先做定性研究，理解"用户为什么会这样"；再做定量研究，验证"这样的情况有多普遍"。反过来也可以：先通过定量数据发现异常（比如"30 天留存骤降"），再用定性研究理解背后的原因。

维度三：使用情境——自然 vs 非自然 vs 混合

2.2 用户研究的五个常用武器

我把这个框架里的五种核心研究方法展开来说，因为这是你日常工作中最常用的工具。

武器一：深度访谈

什么时候用：你想理解用户的动机、决策过程、情感反应时。 怎么做：一次 1 对 1 的半结构化访谈，持续 45-90 分钟，由访谈提纲引导但不机械执行。 关键技巧：

• 多用"为什么"，少用"是不是"

• 追问具体场景："上次你遇到这个情况是什么时候？"

• 不要引导："你觉得这个功能怎么样？" 好过 "这个功能很方便对不对？"

• 邀请用户展示："你能打开 App 给我演示一下你是怎么看的吗？"

武器二：问卷调查

什么时候用：你想大范围验证某个假设或量化某个比例时。 怎么做：设计结构化的问卷，通过 App 推送、邮件、社群等渠道发放。 关键技巧：

• 问卷设计是专业活——不要自己瞎写。建议找用研团队配合。

• 注意问题顺序：先问开放式问题，再问封闭式问题。

• 用户填问卷时是"善意模式"——他们会说自己应该做的而不是实际会做的。

• 问卷不能回答"为什么"——它只能回答"多少人这么觉得"。

武器三：后台数据分析

什么时候用：你想了解用户真实行为、发现数据异常时。 怎么做：通过埋点、日志、数据库查询等方式获取用户行为数据。 关键技巧：

• 数据不会骗人，但人会选数据——注意确认偏误。

• 把数据分段看（按用户类型、按时间阶段、按地区），不要只看平均值。

• 数据告诉你"是什么"，但一般不告诉你"为什么"——需要结合定性研究。

武器四：可用性测试

什么时候用：你想在功能上线前发现可用性问题、改进交互体验时。 怎么做：邀请目标用户完成一系列指定任务，观察他们操作过程中遇到的困难。 关键技巧：

• 让用户操作，让产品经理观察——不要在用户操作时插嘴解释。

• 用户遇到困难时，他的表情和犹豫时间比他的回答更有价值。

• 少量、针对性的可用性测试，往往就能暴露一批重复出现的关键问题——不要因为样本还不够大，就迟迟不开始观察真实用户。

武器五：现场观察 / 日记研究

什么时候用：你想了解用户在真实生活场景中的完整体验时。 怎么做：观察用户在自然状态下使用产品，或让用户记录一段时间内的使用日志。 关键技巧：

• 运动手表尤其适合日记研究——让用户连续记录 2 周每次运动前后的感受。

• 现场观察能发现用户自己都没有意识到的行为模式。

• 成本较高，适合在关键决策点使用。

---

三、经典方法论拆解：JTBD——用户雇佣产品完成任务

3.1 什么是 JTBD

JTBD（Jobs To Be Done，待完成的任务）是用户研究领域最具影响力的理论框架之一。它的核心思想非常简洁：

用户不是购买你的产品，而是"雇佣"你的产品来完成一个任务。

这个框架最著名的系统化者是哈佛商学院的克莱顿·克里斯坦森（Clayton Christensen），他在《与运气竞争》（Competing Against Luck）一书中将其推广开来。Anthony Ulwick 等学者也对 JTBD 理论的发展做出了重要贡献。克里斯坦森在研究用户购买行为时发现：用户做购买决策的驱动力，不是产品的功能列表，而是"我有个任务需要完成"。

用户买运动手表，不是因为"它有一块高精度 PPG 传感器和 GPS 芯片"。用户买运动手表是因为：

• "我需要在下次马拉松之前安全地提升成绩"

• "我需要知道每天的运动量是否足够"

• "我需要一种方式让我坚持训练，不再半途而废"

• "我需要知道我的身体状况是否在改善"

JTBD 将你的思维从"做功能"切换到了"帮助用户完成任务"。

3.2 JTBD 与运动手表的深度结合

我们来做一下"运动手表"这个产品的 JTBD 分析。

当一个用户购买和使用运动手表时，他实际上在"雇佣"这个产品完成多个任务：

任务一：记录与量化

• "帮我精确地记录每一次运动，让我不用靠记忆来回顾。"

• "告诉我我跑了多远、多快、消耗了多少卡路里。"

任务二：评估与判断

• "帮我判断我今天的训练强度是否合理，有没有练过头。"

• "告诉我我的身体状态是进步了还是退步了。"

任务三：决策与规划

• "帮我决定明天应该做什么训练。"

• "帮我在比赛前制定一个科学的备赛计划。"

任务四：激励与坚持

• "当我偷懒不想运动的时候，提醒我、激励我。"

• "让我看到我的进步，给我成就感。"

• "让我在朋友的排行榜里不丢脸。"

任务五：身份与归属

• "让我感觉自己是一个认真对待运动的人。"

• "让我可以加入跑团、参加赛事，找到归属感。"

看到没有？用户购买运动手表，不是为了"拥有一个硬件"，而是为了完成上述这些"任务"。

用户不关心你的产品是什么，只关心产品能帮他完成什么。 这个理念和 JTBD 的核心思想完全一致。

3.3 JTBD 在产品研究中的用法

JTBD 最有价值的用法，是做竞品替代分析。

很多时候，你的竞争对手不一定是"另一个运动手表品牌"。JTBD 提醒我们：用户的"竞争对手"是所有可以帮他完成任务的其他选择。

举个例子。如果用户的核心任务是"判断今天训练强度是否合理"，那他的"选择"包括：

1. 用你的手表看"训练负荷"功能 → 这是你想让他做的

2. 凭自己的体感判断"今天累了，该休息了" → 竞争对手是"体感"

3. 问教练或朋友："我今天要不要休息？" → 竞争对手是"人工建议"

4. 在网上搜索"训练过度有哪些信号" → 竞争对手是"搜索引擎"

5. 什么也不做，累了就休息 → 竞争对手是"不作为"

当你意识到你和"体感""搜索引擎""不做任何事"在竞争时，你就知道你的产品面临的压力有多大。

这个观点可以总结为一句非常精辟的话："用户不是你的用户，是情境的产物。" 用户的每一个行为，都取决于他当时所处的具体情境和想要完成的任务。不同的情境下，同一个用户可能"雇佣"完全不同的产品来完成同一个任务。

3.4 如何进行 JTBD 用户访谈

JTBD 最有特色的方法论是它的访谈方式。传统的用户访谈可能会问："你对我们的运动报告满意吗？" 而 JTBD 访谈会问：

• "跟我说说你上一次运动后的感觉。"

• "你当时心里在想什么？"

• "你为什么决定今天休息而不是继续训练？"

• "如果你没有我们的手表，你会怎么处理这个问题？"

JTBD 访谈的核心是追踪用户的"决策时刻"——用户在做某个选择时，他的内心活动是什么、他考虑了哪些选项、他最终为什么选择了这个。

---

四、业务深度案例：运动新手买表后 30 天流失——如何通过用户研究找到真因

现在回到开场那个让人焦虑的数据：超过 30% 的新用户在购买后 30 天内停止使用。

我们在第 2 讲和第 3 讲已经学会了用三标尺判断优先级、用 MECE 拆解模糊问题。这一讲，我们加上用户研究的方法，把这个案例完整推演一遍。

4.1 需求执行者的做法

需求执行者接到这个任务后的典型路径：

1. "30% 用户流失了？那我们去问问他们为什么不用了。"

2. 发一批问卷："请问您最近为什么没有使用我们的产品？（多选）"

3. 回收问卷，排名前三的原因是：

   • "太忙了，没时间运动"

   • "运动太累了"

   • "天气不好"

4. 需求执行者得出结论：用户因为"忙""懒""天气"不运动。这不是产品的问题。给老板汇报："建议运营做激励活动，提升用户运动意愿。"

5. 运营做了激励活动。数据没有改善。

这个过程中，需求执行者做了"正确"的事情——做调研、收集数据、给结论、推动行动。但问题解决了吗？没有。

为什么呢？因为问卷只能收集到用户"愿意说出口的"理由。而用户"愿意说出口的"理由，往往不是"真正的原因"。

用户不会告诉你"我看不懂你的运动报告，觉得没用所以不练了"——因为他们不想承认自己看不懂。用户也不会告诉你"第一天用了觉得误差很大，就不用了"——因为他们可能自己都没意识到。

4.2 价值负责人的做法

价值负责人会设计一套组合研究方法来找到真因。

第一步：先把"30 天流失"用数据拆清楚。

拉后台数据，先看流失用户的画像和行为特征。你需要回答这些问题：

• 流失用户集中在购买后的第几天停止使用？是第 3 天、第 7 天还是第 14 天？

• 流失用户在停止使用前，他们做了几次运动记录？0 次、1-2 次、还是 5 次以上？

• 流失用户和留存用户在首次运动体验上有什么差异？第一次运动后的数据查看率？第一次运动报告的理解度？

• 流失用户和留存用户在用户画像上有什么区别？年龄、运动基础、购买动机？

数据可能会告诉你全新的故事。比如：

• 85% 的流失用户在购买后的前 7 天内就没有完成第二次运动记录。

• 也就是说，他们可能只做了一次运动，或者一次都没做，就放弃了。

• 留存用户中，首次运动后查看报告的比例是 80%，而流失用户中这个比例只有 30%。

这个数据指向了一个更具体的假设：问题可能出在"首次运动体验"上——留存用户中 80% 会去看报告，而流失用户中 70% 连报告都没打开过。这说明首次运动后，用户要么没有被引导去查看报告，要么运动体验本身就没有给他足够的动力去看结果。

第二步：用定性研究理解"首次运动体验"出了什么问题。

基于数据洞察，你做用户访谈。注意要找两类用户：看了报告但流失的，和根本没看报告就流失的。你不问"为什么不用了"，你问：

• "第一次用手表记录运动的感觉怎么样？"

• "运动结束后，你接下来做了什么？有打开 App 看结果吗？"

• "（如果看了）你看到了什么？你当时心里怎么想的？"

• "（如果没看）为什么没去看？是忘了、找不到入口，还是觉得没必要？"

• "你觉得这次运动记录，让你下次还想继续训练吗？为什么？"

• "如果让你给你的朋友推荐这个手表，你会怎么说？你不推荐的原因是什么？"

通过 8-10 个用户的深度访谈，你可能发现以下真因：

发现一：看了报告的用户——看不懂数据，没有成就感。 用户跑完 5 公里，打开 App 看到一堆数据——配速、心率、步频、步幅、摄氧量、恢复时间——但用户不知道"这一堆数据意味着什么"。"我跑了 5 公里，配速 6 分 30 秒，这算好还是不好？"他们期待的是"你做得很好，继续加油"的正向反馈，但得到的是一张冷冰冰的数据报表。

发现二：没看报告的用户——要么被操作门槛拦住了，要么不知道为什么要看。 有些用户在第一次运动时就遇到了困难——不知道怎么开始运动模式、GPS 等了很久没定位成功、手表佩戴不舒服。"第一次的体验太糟糕了，之后就没动力再试了。"还有些用户顺利完成了运动，但觉得"反正就是跑了步，有什么好看的"，没有意识到报告的价值，也没有被引导去看。

发现三：缺少"下一次"的明确指引。 运动结束后，用户就从这个功能里"出来了"。没有提示"明天建议做什么"，没有提醒"明天继续"，没有"周训练计划"。用户感觉做了一次单项运动，而不是进入了一个"训练生活"。

第三步：定量验证真因的普遍性。

通过访谈归纳出 3 类真因之后，设计问卷或者通过后台数据验证它们的普遍性：

• 用后台数据验证：首次运动后未查看报告的用户占比是多少？查看了报告但快速退出的比例是多少？首次运动成功率（GPS 定位成功、完成记录）是多少？

• 用问卷验证：运动后你最希望获得什么？是一句话总结、数据详情、还是鼓励肯定？

• 用 A/B 测试验证：在首次运动结束后加一句鼓励性总结+引导查看报告，查看第二次运动转化率是否提升。

第四步：设计和验证解决方案。

基于验证结果，制定针对性的方案：

4.3 这个案例教给我们的

运动新手 30 天流失案例的核心启示：

1. 数据只能告诉你"什么发生"，不能告诉你"为什么发生"。 你从后台数据知道 30% 用户流失了，但数据不会告诉你原因。你需要用户研究来补上"为什么"这半块拼图。

2. 单一研究方法不可靠。 如果你的结论只来自问卷，你得到的是"用户说得出口的借口"。如果你的结论只来自后台数据，你看到的是行为但不知道动机。真正可靠的结论来自多种方法的交叉验证。

3. "30 天流失"不是 30 天才发生的。 经过数据拆解发现，问题在前 7 天的首次运动体验中就埋下了种子。产品的"死亡征兆"通常出现得比你想象的要早得多。

4. JTBD 视角是关键。 用户雇佣运动手表不是为了"看数据"，而是为了"知道自己练得怎么样、明天该怎么练、有没有变好"。如果你只交付了"数据"而没有交付"判断和指引"，用户的任务就没有完成。

4.4 忘记自己，变成用户

这个方法论反复强调一个原则："忘记自己，变成用户。"

这句话听起来简单，做起来极难。因为"忘记自己"意味着你要放下你作为产品经理的所有知识储备：

• 你知道"配速"是什么概念 → 但用户可能不知道

• 你知道"心率区间"的含义 → 但用户可能觉得这是医学概念

• 你知道"训练负荷"的价值 → 但用户可能只关心"我明天还能不能跑"

• 你知道如何解读运动报告 → 但用户第一次打开时完全是懵的

如果你不能"忘记自己"，你就永远无法理解用户为什么看不懂你设计的产品。

产品经理要承认自己不是用户，然后把用户当成一个完全不同的物种来研究。 这个态度，才是用户研究的正确出发点——不是"我懂用户"，而是"我不懂用户，所以我要去研究"。

---

五、反例与失败案例：没有用户研究、凭感觉做功能

5.1 事情经过

某运动平台的产品经理小张，负责"训练计划"功能。

小张自己是一个跑步爱好者，每周跑 4 次，全马 PB（个人最好成绩）330。他觉得运动手表最大的价值就是帮助跑者更系统地训练。

于是，他凭自己的直觉和跑步经验，设计了一个"AI 智能训练计划"功能：

• 用户输入目标（如"三个月后全马破四"）

• 系统自动生成一个 12 周的训练计划

• 计划包含每天的训练类型（间歇跑、节奏跑、长距离、恢复跑）

• 手表会根据计划自动显示当天的训练内容和目标配速

• 每周末生成一份"本周训练完成情况报告"

小张觉得自己做了一个"非常有用"的功能。他身边的跑友也都说"这个功能太棒了"。

5.2 结果怎样

上线后的数据：

• 用户创建训练计划的比例：12%

• 创建计划后按计划完成第一周训练的比例：不到 30%

• 完成全部 12 周计划的用户比例：不到 2%

• 差评集中点："计划太激进，跟不上就放弃了""我跑不了那么快，能不能调整""我只想随便跑跑，这个计划让我压力很大"

5.3 问题出在哪

这个案例是典型的"产品经理把自己当成用户"的错误。

第一，小张是严肃跑者，但他的用户不是。

小张每周跑 4 次，全马 PB 330。但购买他们手表的用户中，大多数是"每周跑 1-2 次、目标是完成第一个 10 公里或半马"的初级跑者。他们的训练频率、能力、目标和小张完全不同。

小张凭自己的经验设计的训练计划，对初级跑者来说太激进、太复杂、压力太大。

第二，小张没有做任何用户研究。

在功能设计之前，小张没有做：

• 用户访谈：问问初级跑者他们想要什么样的训练计划

• 数据分析：看看用户现有的训练频率和模式到底是什么

• 可用性测试：让初级跑者试用一下计划，看看他们能不能理解、能不能执行

他完全凭自己的直觉来做决策。而他的直觉，恰好代表的是用户中的极少数。

第三，小张没有理解用户的"真正任务"。

用 JTBD 的视角来分析：用户雇佣"训练计划"功能，到底想完成什么任务？

• 严肃跑者的任务："用最科学的训练方法，最大化提升成绩。"

• 初级跑者的任务："有一种轻松、可执行的计划，让我能坚持训练，不受伤、不放弃。"

这两个任务完全不同。小张做的是针对"严肃跑者"的方案，服务的是"初级跑者"的用户。

"羊群理论"在这里也非常适用。它提醒我们：用户的行为会受到"身边人"的巨大影响。 当小张身边的跑友都说"这个功能很棒"时，他误以为这是普遍需求。但实际上，他的跑友圈是"羊群中的一小撮"。真正的"大多数羊"并没有发声，所以小张听不到他们的声音。

5.4 如果重新做，应该怎么做

第一步：在动手之前先做用户研究。

• 做用户分层：你的用户中，严肃跑者、初级跑者、健康运动者各占多少比例？

• 做用户访谈：不同层级的用户，对"训练计划"的期待和担忧各是什么？

• 做数据分析：现有用户的训练频率、距离、强度分布是怎样的？

第二步：根据研究结果，定义 MVP。

如果发现 70% 的用户是"初级跑者"，他们的核心需求不是"AI 生成科学计划"，而是"告诉我今天简单跑一下就行"。

MVP 可能是：一个"今日训练推荐"的轻量功能。用户打开 App 就看到一句话——"今天建议进行 30 分钟轻松跑，配速控制在 6:30-7:00。" 不要求用户创建计划、不要求完成率、不给压力。

第三步：用数据验证后再迭代。

如果这个"今日训练推荐"的使用率高、用户满意度好，再考虑做第二步——把推荐扩展为"一周计划"。再下一步——"12 周备赛计划"。每一步都用数据验证是否真正满足了用户需求。

---

六、实操工具：用户研究方案选择清单

这是本讲最重要的交付物。当你面对一个不确定的产品问题时，你需要决策：用哪种研究方法最合适？

6.1 研究场景与方案选择

6.2 用户研究四步法模板

不管使用哪种研究方法，都可以用这个四步法模板来组织你的研究工作：

第一步：明确研究目标

写下你想回答的 1-3 个核心问题。比如：

• "用户为什么在购买后 30 天内停止使用？"

• "用户首次运动后看报告时的真实感受是什么？"

研究目标必须具体、可回答。 "了解用户"不是一个研究目标。"了解用户在首次运动后的决策过程"才是。

第二步：选择研究方法

根据研究目标和约束条件（时间、预算、团队能力），选择最合适的研究方法。参考上面的"研究场景与方案选择"清单。

核心原则：

• 先定性，后定量。 先理解"为什么"，再验证"有多少"。

• 多用组合方法。 单一方法的结论总是不够可靠。尽可能用两种以上方法交叉验证。

第三步：实施研究

执行研究时的关键注意事项：

• 保持开放心态——不要带着答案去找问题。

• 深度访谈中，多用开放性提问，少用引导性问题。

• 可用性测试中，让用户操作，你观察，不要解释。

• 数据分析中，先看全量再看分层，避免被平均值欺骗。

第四步：分析和呈现结论

把研究结论组织成结构化的输出：

1. 核心发现（3-5 条，每条一句话 + 证据支持）

2. 用户痛点（按严重程度排序）

3. 机会点（从痛点推导出的产品改进方向）

4. 行动建议（具体的产品方案建议 + 优先级）

6.3 使用这个模板的三个原则

原则一：不要在开始研究之前就决定方案。 最常犯的错误是"先定了方案，再去做研究来证明自己的方案是对的"——这就是第 3 讲我们讲的确认偏误。

原则二：研究的结果不一定是你想要的。 如果研究结果和你的直觉冲突，请相信研究结果。这个方法论反复强调："忘记自己，变成用户。" 如果研究证明你错了，恭喜你——你避免了踩进去的一个坑。

原则三：用户研究不是一次性的。 用户需求在变，竞争环境在变，产品在变。对一个问题的理解会随着时间变化。好的产品负责人会持续做用户研究，而不是只在"上线前"做一次。

---

七、本讲重点总结

最后，我想和大家分享一个认知。

做产品经理 2-3 年的时候，你最容易陷入一个舒适区：觉得自己已经"很懂用户"了。 你做了几个功能，看了不少数据，和用户聊过几次天——然后你开始觉得自己对用户的理解是准确的。

但真相是：你对用户理解的深度，和你对用户研究的投入程度成正比。

你的直觉加了很多分——但如果你的直觉没有经过系统化的用户研究验证，它只是"感觉"而已。而"感觉"是不可靠的。

所以请记住一个简单但残酷的标准：如果你没有做任何用户研究，你对用户的理解大概率是错的。

下一讲，我们会进入"真需求"的讨论——当你说一个需求是"真需求"时，你在说什么？功能价值、情绪价值和资产价值，这三者如何共同构成用户真实的行动理由？

---

八、课后思考

1. 研究方法组合：想一想那个"30天流失"的问题——如果让你自己去研究用户为什么不用了，你会先用什么方法、再用什么方法？为什么这样安排顺序？不用写完整方案，能在脑子里理清楚路径就很好。

2. JTBD 视角：选一个你正在做的功能（比如"恢复建议""运动报告""睡眠分析"），用 JTBD 的视角看看——用户"雇佣"这个功能，到底想完成什么任务？试着列出至少 3 个不同的任务，看看有没有你之前没想到的。

3. 访谈提纲设计：针对"买表后 30 天流失"这个场景，试着设计一个深度访谈的提纲（至少 8 个问题）。关键是：问题要能挖出用户的真实动机，而不是"用户说得出口的借口"。

4. 自我盘点：回忆最近半年你做过的功能，有多少个在做之前做了正式的用户研究？有多少个是"凭直觉"做的？这两个数字的对比，可能比你想象的更加悬殊。

---