用户研究与需求验证
本章导读
上一讲结束时，研习团队写完了一页《产品立项判断》，最关键的那条假设落在用户问题上：考研学生是不是真的需要自动归集错题。
可这句话不会因为被记进了立项页，就自动变成事实。它到现在还只是一句「我们认为」。想把它往前拱一步，就得真走出去，跟真实用户待在一起，看他们说什么、做什么，再看我们怎么解释这两者之间的落差。
这一讲就专门干这件事。我跟产品经理小林走一遍完整过程：起初他信心满满发问卷，以为结论已经定了；一路走下来，他才发现自己差点被问卷骗了。走完你会发现，为什么不能把「用户说了」当成「用户需要」，为什么要分清楚用户说的、做的，还有我们自己猜的。最后你会拿到三样能直接用的东西——一张需求证据表、一条能被检验的假设，和一个具体到「某类用户或某条数据」的反例。
下一讲《定位、竞争与产品边界》会用到这张表里「当前替代」那一行，把问题从「这需求是不是真的」推向「我们凭什么比用户现在用的替代方案更好」。
说明：本讲的故事、角色和数字都是教学案例或教学假设。除了来源一节列出的腾讯公开材料外，不指向任何真实产品或腾讯数据。
开篇：问卷说需要，行为说不需要
立项通过后，小林带着一个问题出发：用户真的需要错题自动归集吗？
他做的第一件事，是发问卷。问题写得很直接：「是否需要错题自动归集功能？」回收了六百份有效回答，约六成的人选了「非常需要」，还有约两成选了「需要」（教学假设）。
小林把结果截图发进群里，配了一句话：「八成用户需要，这个方向没问题了。」团队据此决定继续开发。
只有老周在第二天早上泼了一盆冷水。他把行为日志拉出来，放到同一张表里对比。过去三十天里，样本用户中上传过任何一张错题图片的人，只占大约百分之七；而每天打卡记录学习的人里，只有大约一成曾经打开过「错题本」页面（教学假设）。
一边是八成说需要，一边是百分之七真的在做。这个差距大到不能再忽略。小林有点坐不住了，他说：「问卷和日志肯定有一个错了。」老周回他：「也可能两个都没错，只是它们在回答两个不同的问题。」
为了搞清楚，小林去做了十场一对一访谈。其中一场，让他彻底改变了对「用户表达」的看法。
用户小周是大三学生，准备考研。访谈刚开始，他说得很清楚：「我确实希望自动整理错题，不用自己抄。」小林几乎要把它记成一条有力证据了。但继续追问下去，画面就变了：小周每周只打开研习一次，主要是看收藏的笔记；他从不打卡，也从不手动记错题——换句话说，他从来就没有「整理错题」这个动作。
小林问：「那如果你不用手动整理，你会开始整理错题吗？」小周愣了一下，说：「可能……会吧。」
那一刻小林明白了：用户说「需要整理」，但并没有表现出「已经在整理」。表达的愿望和真实行为，分离了。
第一幕：直接问用户，为什么会失效
小林最初的做法，其实是最合理的简单做法：直接问用户「是否需要这个功能」。
这种问法在一种条件下是有效的：用户清楚自己的行为，愿意如实回答，而且他的回答能对应到真实的使用场景。比如你问一个每天都手动抄错题的学生「抄错题累不累」，他能立刻给你讲出具体在哪一步觉得烦。
但它会在另一种条件下失效：用户回答的是一个想象中的好功能，而不是自己实际会做的动作。人们很容易对「自动」「免费」「帮我省事」这类词给出肯定回答，因为回答「要」几乎不需要任何成本。可这个「要」，并不反映他今天是否真的在做这件事。
问卷没有失效，失效的是把一句表达直接翻译成功能。
「需要」是一个很轻的词。它不需要用户付出任何东西，也不承担任何后果。真正的问题是：用户今天为了这件事，已经在付出什么？如果他什么都没付出，那「需要」可能只是一句礼貌的想象。
所以每当你听到一句肯定的「需要」，先别高兴，先追问一句：那你现在是怎么做的？如果对方答不上来，这句话就要打折扣。
第二幕：把证据分成四层
要避免被一句「需要」带跑，最有效的办法，是把所有材料分成四层，然后严格分开记录。
《腾讯8分钟产品课》把理解用户概括为定义用户、接近用户、了解用户和尝试成为用户。腾讯用户研究专题进一步强调研究设计、多源数据、执行质量和无效样本识别。本课程把这些材料合并为四层证据。
第一层，用户说了什么。 这是访谈、问卷、评论与客服反馈里的原始表达。记的时候保留原话，不先替用户翻译。小周说的是「自动整理错题，不用自己抄」，就原样记下来，不要写成「用户需要错题管理功能」。
第二层，用户做了什么。 这是路径、停留、失败、放弃和替代行为。小周说需要整理，行为却是每周只看收藏、从不打卡、从不手动记错题。行为不会说谎，但它需要你去日志里找。
第三层，事情发生在什么场景。 包括时间、地点、角色、触发条件和限制。错题整理发生在每天结束学习之后，还是只在考前一周才爆发？这两种场景下的需求强度完全不同。
第四层，我们怎样解释。 这是产品判断，说明用户想取得的进展，以及阻碍进展的原因。比如：「用户想减少抄写成本，让错题在考前可以被复习。」
前三层是材料，第四层是产品判断。二者必须分开记录，混在一起，团队就会把「用户说了」直接当成「用户需要」。
回到研习案例，小林犯的错就很清楚：他把第一层的表达（八成说需要），直接跳到了第四层的解释（用户需要这个功能），中间跳过了一层最硬的证据——用户做了什么。而那一层的数据是百分之七。
第三幕：先找到会让研究失败的地方
研究不是随便找几个人聊聊天。很多研究在开始之前，就已经注定会得出片面的结论。所以在设计研究时，要先问自己：我的做法，最可能在什么地方失败？
一个只访问活跃用户的研究，通常看不到已经流失的人为什么离开。研习如果只邀请每天打卡的用户做访谈，就会漏掉那些已经不用的人。而这些流失用户，恰恰最可能藏着「需求不成立」的证据。
一个只收集问卷的研究，通常看不到用户口头选择与真实行为的差异。小林第一次研究就落在这里。
一个只看总体数据的研究，通常会把新用户、熟练用户和付费用户的不同问题平均掉。百分之七的上传率里，付费用户和免费用户可能完全不同——付费用户也许有百分之二十在上传，免费用户只有百分之三。只看总体，这个差别就被抹平了。
因此，一份研究计划至少写清四件事：需要覆盖哪些用户角色；哪些人容易被样本选择遗漏；访谈、行为数据和现场观察分别回答什么问题；什么结果会推翻当前的需求解释。
做完一次研究，你可以问自己三个问题：我是不是只采访了最容易找到的人？我是不是只看了一类数据来源？我看到的结论，换一批人、换一个时间段，还成立吗？
三个问题里只要有一个答不上来，就要把结论的范围写小一点，而不是把它说成「用户都需要」。
第四幕：从需求句子到可验证假设
有了四层证据，下一步是把一句模糊的「用户希望」，改写成一条可以被检验的假设。
研习的原始表达是：用户希望自动整理错题。
需求解释是：用户因为手动抄写成本高，而无法持续积累错题，导致复习时无题可看。
可验证假设可以写成：对过去三十天至少手动记录过五次错题的用户，在练习提交后自动生成归类并进入复习计划，可以提高三十天内的错题复习完成率，同时不会显著增加用户关闭归集功能的比例。
这个改写增加了人群（过去三十天手动记录过五次错题的用户）、行为（练习提交后自动归集并进入复习计划）、时间（三十天）、结果（复习完成率）和副作用（关闭比例）。需求因此从一句意见，变成了可检查的判断。
注意，这里的所有数字仍然是教学假设。改写假设不是为了把假设变成事实，而是把假设写得可以被事实检验。
如果你的假设能被写成「如果……那么……，否则……」，它就是可验证的。如果它写来写去只能落到「用户可能会喜欢」，那它还不算一条假设，只是另一种形式的「我觉得」。
第五幕：现场观察：看他做，而不是听他说
访谈和日志能告诉你很多，但它们都还隔着一层。用户说自己会整理错题，日志却显示他没整理，到底哪个环节出了问题？要回答这个，得去看他真正做一次。
小林约了三位用户，请他们当场把昨天的学习内容整理一遍。他没有提问，只是坐在旁边看。
第一位用户打开手机相册，里面已经积了上百张错题截图。她翻到昨天做的那几张，一张一张点开看，然后把还不会的题截下来、发给自己的微信文件传输助手，再在纸质本上抄下题号。整个过程用了十一分钟。
第二位用户直接打开一个纸质错题本，从书包里拿出来，翻到最后一页，用手抄。他抄得很快，但只抄了题号和不完整的题干，问他为什么不全抄，他说「抄多了浪费时间，我只要记得哪道题不会就行」。
第三位用户什么都没做。他说「我一般做完就算了，错题都在卷子上，考前翻卷子」。
三场观察下来，小林心里有数了：确实有人在整理错题，但方式各不一样，而且没有一个人的方式是「自动归类」。更重要的是，第三位用户代表的那一类人——根本不做任何整理——在问卷里很可能也会点「需要」，因为「自动整理」听起来总比「考前翻卷子」好。
现场观察的价值，不是让你证明自己对了，而是让你看到用户嘴里没说出来的那些动作，以及每个动作背后的代价。
需求证据表
把四层证据落到一张表里，可以避免研究做到一半就散掉。这张表可以直接用：
| 字段 | 记录内容 |
|---|---|
| 用户与角色 | 谁在使用，谁在决策，谁承受结果 |
| 场景与触发 | 问题在什么条件下出现 |
| 原始表达 | 保留用户用词，不先替用户解释 |
| 行为事实 | 实际操作、绕行、失败和放弃 |
| 当前替代 | 用户现在怎样完成任务 |
| 需求解释 | 我们认为用户真正想取得什么进展 |
| 反例 | 哪类用户或行为不符合解释 |
| 验证方法 | 访谈、原型、日志、灰度或实验 |
以研习案例填一行作为示范：
| 字段 | 示例（教学假设） |
|---|---|
| 用户与角色 | 考研学生，本人使用，本人承受复习结果 |
| 场景与触发 | 每天结束学习后整理当天错题，考前集中复习 |
| 原始表达 | 「拍个照就能自动整理错题，不用自己分类」 |
| 行为事实 | 过去三十天，样本中只有约百分之七上传过错题图片 |
| 当前替代 | 纸质错题本、相册截图合集、考前翻卷子 |
| 需求解释 | 用户想减少抄写成本，让错题在考前可被复习 |
| 反例 | 小周说需要，但从不记错题，只看收藏笔记 |
| 验证方法 | 行为日志、十场访谈、三场现场观察 |
逐步执行：需求验证流程
把前面的内容收成六步。每一步都配一句「研习是怎么做的」。
第一步，定研究问题。 不是「用户是否需要功能」，而是「用户在什么场景下因什么受阻」。研习的问题不是「要不要做归集」，而是「整理错题这件事，在什么时候、因为什么，让用户觉得难」。
第二步，选样本。 明确覆盖新用户、流失用户、重用户，并写清谁会被遗漏。小林后来补访了流失用户，才发现他们离开的原因和活跃用户完全不一样。
第三步，收集两种以上来源的证据。 至少包括用户表达与行为数据，尽量加上现场观察。单一来源最容易骗人。
第四步，分离前三层材料与第四层解释。 把原始表达、行为事实、场景分别记下，再单独写解释。混在一起，判断就失真了。
第五步，改写为可验证假设。 写清人群、行为、时间、结果与副作用。
第六步，找一个反例。 它必须具体到某类用户或某项数据，而不是一句「这是特殊用户」。
常见误区及其可见后果
第一种误区，用问卷确认代替需求验证。可见后果是上线后无人使用，因为用户回答的是想象而非行为。
第二种误区，只研究活跃用户。可见后果是产品一直为留下来的人优化，流失原因始终看不清。
第三种误区，把总体平均数当成全部用户。可见后果是决策被重用户拉高，普通用户的需求被平均掉。
第四种误区，把「用户提出」当成「用户需要」。可见后果是团队开发了用户随口一说、自己都不会用的功能。
第五种误区，解释得通就停止。可见后果是遇到第一个反例就无法处理，因为解释没有写清边界。
课堂练习
给出一段材料：八位用户在访谈中说希望「读书笔记支持语音转文字」，但行为日志显示其中六位过去一个月从未记录过任何读书笔记。
请在十分钟内完成三件事：
- 写出这八条表达属于四层证据中的哪一层；
- 为「希望语音转文字」写一条可验证假设；
- 找出至少一个反例，并说明它特殊在哪里。
最终作业
选择一个真实需求，收集至少两种不同来源的证据，完成一张需求证据表、一条可验证假设和一个反例。
反例需要具体到某类用户或某项数据。如果反例能被一句「这是特殊用户」排除，作业还没完成；要说明特殊在哪里，以及产品是否真的不需要服务这类人。
评分标准
| 字段 | 评分要点 |
|---|---|
| 原始表达 | 是否保留用户用词，是否先解释后记录 |
| 行为事实 | 是否有具体路径、次数或比例，而不是「用户很少用」 |
| 场景与触发 | 是否写清时间、地点、角色和触发条件 |
| 需求解释 | 是否与前三层分开，是否说明进展与阻碍 |
| 反例 | 是否具体到某类用户或数据，能否被轻易排除 |
| 可验证假设 | 是否含人群、行为、时间、结果和副作用 |
| 数字来源 | 是否标明教学假设或来源事实 |
本课不能证明什么
需求研究不能证明这个需求值得做。值得做涉及价值与时机，那是立项课和定位课的事。
它也不能证明用户会为这个需求付费，不能证明功能能被做出来。它只能证明：某个问题，在某一类用户和场景下，真实发生。
研究里的一次验证通过，也不能推广到全部用户。样本边界写在哪里，结论就只覆盖到哪里。
与下一课的连接
当我们确认问题真实存在，下一讲转向定位、竞争与产品边界：在同一批用户和问题上，我们选择做什么、不做什么，以及凭什么比用户的替代方案更好。
下一课会用到本课的四层证据，尤其是「当前替代」这一行。它从需求验证直接通向竞争判断。