引言#

产品经理最容易高估的能力，是「我懂用户」，这句话太好用了：转化不好，是用户没看懂；老板质疑需求，是用户需要。只要说得足够自信，会议室里就会出现一个看不见的人，替所有判断背书，这个人叫「用户」。但「用户」从来不是一个固定身份：有时候他是急着赶大促页面的运营；有时候他是等着明确指标的数据分析师；有时候他是明早要汇报数据的市场同学。当我们面对 C 端时，「用户」又变回沉默的大多数：地铁上单手划手机的白领，加载慢 3 秒就退出；反复比价的宝妈；对弹窗免疫、只想一键跳过的大学生。他们不参会，不发言，只用指尖滑动或卸载。我们在会议室里为一个按钮颜色争得面红耳赤时，真正的用户可能根本注意不到那个按钮在哪。更讽刺的是，无论这个「用户」是隔壁同事还是消费者，他们从不在会议室里，却都要为我们的「我懂」买单。

这一章想回答一个问题：我们凭什么认为自己理解用户？听起来像用户研究问题，其实是产品经理的判断问题。大多数错误，不是发生在「不听用户」的时候，而是发生在「以为自己听懂了」的时候。我们看了反馈、做了调研、拉过数据、画过画像，该有的都有了，然后团队踏踏实实地把本来就想做的东西做出来了。用户被翻来覆去地引用，但最后那个决定，跟用户没什么关系。

所以我越来越觉得，理解用户这件事，拼的不是谁更会共情、谁更会访谈，而是谁能管住自己。管住自己别急着下结论，别把「我见过」当成「用户也见过」，别把「我觉得合理」当成「用户能懂」。隔三差五得跟自己说一遍：我现在知道的，最多算个草图，离真相还差得远。用户研究里最难的一关，从来不在怎么问问题，而在你愿不愿意坐下来承认「我可能完全想错了」。更要紧的是我们能不能给用户留一个位置，让他真的参与到我们的思考里来，而不是只出现在我们写完的报告里。如果用户从来没有动摇过我们的任何一个决定，那我们其实还没让他进来过。

4.1 看穿功能——用户不是来用功能，是来完成自己的事#

我们很多产品经理在做判断的时候会进入一个误区：习惯性假设用户打开产品，是奔着某个功能来的。这个假设听起来好像没错：电商用户到确认订单页，当然是来确认订单的；运营打开数据看板，当然是来看数据的；私域运营点开群发工具，当然是来发消息的。但只要往真实场景里再多走一步，就会发现用户很少把使用功能当成自己的目标，甚至可以说基本不会。我们所谓的功能，只是用户在完成某件事过程中的一个手段，有时候甚至不过是他们犹豫、补救、确认、想避免出错时恰好路过的一个地方。如果产品经理把功能本身当成任务，就很容易把用户看窄了。你会忙着优化页面、补充模块、增加推荐、强化入口，却始终没看见用户当时想完成的那件事。

图 4-1　功能与任务的错位　上层是用户说出口的功能，下层是他真正要完成的任务；看不出错位，越用力越偏。

2021 年我在一家社交电商平台负责营销产品线，那段时间运营团队拉上产品团队，发起了一次关于确认订单页新增「加价购」的功能讨论。我们先还原一下这条链路：用户从购物车点「去结算」，进入确认订单页，核对地址、商品、优惠、总价，然后提交。这个页面原本很克制，核心任务就是让用户确认无误、完成支付。但业务增长压力摆在那里，团队希望在支付前再做一次客单价提升，于是提出在确认订单页加一个「加价购」模块。会议室里很快出现两套方案：

• 运营团队倾向于做「满 99 加 1 元换购」：纸巾、垃圾袋、棉签这类低价刚需品，勾一下就一起下单。理由很直接：行业里都在做，用户也熟悉，上了就能出 GMV。
• 产品团队则更倾向于「智能配件推荐」：买奶瓶推奶嘴，买奶粉推辅食碗，买洗衣液推洗衣球。这听起来更像是产品经理会喜欢的答案，因为它更精准，也更符合推荐系统的想象。

两边都有道理，接下来讨论很快滑向方案细节：模块放哪儿、推荐几件商品、价格怎么展示、勾选框怎么设计、会不会影响优惠计算……但这些讨论都默认了一件事：用户到了确认订单页，还有心情再挑一件东西。作为产品团队负责人，我非常惧怕这种情况发生，我没急着拍板，而是事后做了一次黄金链路的漏斗分析，又看了确认订单页的热力图，发现几处刺眼的数据：

• 提交按钮的点击率只有 72%：将近 3 成用户已经进了确认订单页，却没有直接点「提交订单」¹。他们不是没有购买意图，能走到这一步，说明商品、价格、优惠、地址基本都确认过了，那他们停下来的那几秒钟，到底在做什么？
• 用户操作行为高度相似：集中在向上滑动页面和返回购物车。当时推荐模块还没上线，页面上没有任何可逛的推荐区域。用户在确认订单页往上滑，不是在看更多商品；反复返回购物车，也不像是在找优惠。这两个行为更像一种下意识的确认：我是不是漏了什么？

数据只能把问题推到这儿，要继续往下走，就不能再靠会议室里猜了。我让团队找了 10 余位高频出现这个行为的用户做电话回访，电话里只问一个很朴素的问题：他在确认订单页犹豫的那几秒，心里在想什么。

一位买奶粉和尿不湿的妈妈说，她总觉得少买了一样东西，往上滑回去看购物车，后来才想起来忘了加辅食；一位买洗衣液和洗发水的用户说，纸巾快用完了，但买洗衣液时完全没想起来，到了确认订单页才隐约觉得还有事没做；还有一位买牛奶的用户说，每次拆快递才发现又忘了买垃圾袋，单独买一包不够包邮，每次都后悔没顺手带上。一个很明确的模式浮出来：他们不是在想「我还想买什么」，而是在想「我是不是忘了什么」。这两句话差别非常大：「我还想买什么」对应的是推荐、促销、横滑商品列表、满减刺激和更多选择；「我是不是忘了什么」对应的是提醒、补漏、低决策成本和确定性。

这些线索指向同一个判断：确认订单页不是一个逛的时刻，而是一个收口的时刻。加价购不该是推荐你可能想买的，而是提醒你可能忘了的。我们把这个判断同步给运营团队后，得到了认可，最终方案简单到有些克制：系统根据用户过去几个月的购买记录推测消耗品周期，针对不同用户优先推荐他们当下可能需要的 1～3 件消耗品；推荐理由也不再是为你推荐、猜你喜欢，换成了「纸巾可能快用完了，补一提？」「家里垃圾袋用完了吗？」，没有横滑列表，没有更多选择，也没有复杂的推荐理由。

上线后的数据很干净：补货提醒的点击率 14.8%，明显高于以往结算页推荐模块的常见水平；勾选转化率 69%；A/B 测试里，补货提醒对比配件推荐是 14.8% 对 3.2%¹。而且补货提醒带来的 GMV 里，超过 7 成来自过去一个月没买过该品类的用户。这说明它不是把本来就会买的需求提前截走，而是把差点忘了的需求接住了。两个月后回访，有用户说以前经常忘了买纸巾，用完才想起来，单买又不够包邮，现在确认订单时看到提醒，顺手就加上了，感觉像有人帮她记着这些小事。

说服团队的时候，最有用的不是「我觉得用户会喜欢」，而是证据。我们把确认订单页的停留数据、热力图和用户录音放到评审会上，运营原本偏向满减换购，设计师也想过做一排横滑商品，但当大家看到用户在确认订单页平均只停几秒，再听到用户把「提醒」和「推销」分得那么清楚，讨论就从「加购模块怎么做得更丰富」自然转向了「怎样不破坏确认订单这个任务」。

这个案例不止是一个加价购模块，它暴露了一个产品经理很容易踩进去的陷阱：我们习惯按页面功能来思考问题，但用户从来没有按页面功能过日子。同一个确认订单页，有人想快速收口走人，有人还在犹豫漏没漏东西，有人只是想核对地址，他们共享一个页面，但各自在完成不同的任务。所以首先要判断用户此刻处在什么任务场景里，然后再决定产品应该扮演什么角色。角色找准了，方案自然就准了；否则越精细的优化，越是在错误的方向上用力。

4.2 跨出系统——走到用户旁边，才看见产品外的那半段#

很多产品方案在系统内部看是完整的，放到用户真实的工作里，却只是半段。产品经理最容易看见的，永远是自己负责的那一段：用户进入页面，点击按钮，查看数据，提交表单，完成配置。但任务往往不在这里结束：使用者可能还要复制数据、打开表格、找人确认、写汇报、发群聊、等审批、向上汇报，或者把这次经验沉淀下来。如果产品只优化自己能记录到的那半段，就会误判用户价值。

图 4-2　产品内半段与产品外半段　任务在系统边界处被切成两段；产品只覆盖前一段，后一段靠用户自己拼。

2021 年我所在团队负责过一套 CMS 系统，本质上是一个低代码搭建平台，运营和市场同学用它快速搭建活动页、专题页和大促页，拖拽组件就能配置发布。这套系统已经把页面搭建效率从需要 3 人日压缩到 1 小时左右¹，团队很有成就感。工具越成功，团队就越容易沿着自己的逻辑往下推。当时我们准备新增「数据分析看板」，推理链条非常顺：运营搭完页面，当然想知道效果好不好，过去找 BI 跑数要等大半天甚至一两天。既然页面是 CMS 搭出来的，页面级和组件级的数据自然也能被抽象出来，比如 PV、UV、点击量、转化数据，让运营打开数据看板就能看。我们甚至规划了 8 个图表面板，单看产品形态是很完整的，但这里面藏着一个典型误判：我们理解的是运营应该怎么看页面数据，却没理解运营在真实工作中如何使用数据。

数据看板上线后，PV 远低于预期，很多高频搭建用户明明每天都在 CMS 里做页面，却没有像我们想象中那样反复进入看板、查看数据，再据此优化页面。这一次，我们没有直接沿着入口不明显、图表不够丰富这些解释往下优化，而是约了两个高频搭建用户，坐到他们旁边看真实操作：

• 电商运营同学：她点进数据看板，鼠标快速划过趋势图，停在「表单提交量」上看几秒，然后切回编辑器调整了表单文案。这一步和我们的想象还比较接近。但接下来，她关掉页面，打开一个 Excel 表，把 CMS 里的表单提交数填进去，又打开营销自动化后台，查短信打开率和优惠券核销率，再一起填进表格。我问她，这些能不能都在我们这看。她说，我们只告诉她页面上表单提交了多少，但她做这个活动的目的不是收表单，是发券让人去核销；她得把前后的数据连起来，才能算出这个页面到底有没有带来生意。我们的数据，她看到一个数就得自己搬走去和别的数拼起来。我们以为自己给她做了一块完整的页面数据看板，但她并没有把看板当成复盘终点。CMS 数据对她来说不过是活动复盘链路里的一个输入项，需要和营销自动化数据、活动目标拼在一起，才能回答那个问题：这个活动有没有带来业务结果？
• 用户运营同学：他的操作更让我意外，他根本没有点开数据看板。做 A/B 测试时，他每次都在飞书群里@数据分析师，请对方跑个数。我问为什么不直接在 CMS 看板里看转化率。他说，他得知道 A 和 B 的差异是不是统计显著，不是光看谁数字大；而且公司要求 A/B 实验必须由分析师用标准方法跑，不能他自己看了就拍板。我们以为看板服务的是一个运营自己看数据、自己做决定，没想到数据决策是一个协作流程：运营提问题，分析师判断口径，产品或设计理解页面差异，业务负责人拍板。CMS 里的转化率不是没价值，但它不能替代这个协作机制。

临走前我还注意到一个细节：两位同学都会在历史页面上停留，指着效果好的页面说，想参考它的结构，但已经忘了具体好在哪了；老板问起最近页面效果怎么样，他得临时翻好几个地方凑数据写总结。这说明还有第三个问题：数据看过一次就流失了，散落在 CMS、自动化后台、飞书群、Excel 复盘表里。用户需要的不是一块更大的看板，而是能让数据沉淀、被带走、被协作的能力。现场观察之后，我们暂停了数据看板二期迭代，把方向从做一个更全的看板，调整为把数据嵌入运营工作流，具体做了三件事。

• 增加数据导出能力：让运营可以把某个数据块导出为带口径注释的 Excel 表格，直接粘进复盘表
• 把页面对比和协作分享做进系统：整理好问题描述、页面范围和核心指标，帮运营和分析师减少来回沟通成本
• 增加页面案例的数据快照和归档：优秀页面可以存入案例库并标注标签，下次搭新页面时直接调出来参考

这些改动都不炫技，导出一个数据表、分享一个页面对比、给历史页面加一个数据快照，听起来都不像重大发明，但它们比继续堆图表更接近用户的真实任务。数据也验证了方向，最朴素的「导出数据为 Excel 表格」反而跑得最好：每 100 次看板访问触发约 32 次导出，日均导出次数是截图操作的 4.2 倍¹。30 天内运营发起了 28 次申请统计检验，其中 26 次得到分析师回复，平均响应时间从过去的半天左右缩短到约 2.3 小时。案例库 60 天内自发存入了 41 个页面案例，其中 12 个被其他运营至少调用过一次。改版后看板访问频率提升了约 1.7 倍，但停留时长反而下降了 18%¹。用户不是更愿意泡在看板里，而是更快拿到自己要的东西，然后去完成下一段工作。

做内部工具，最容易高估系统内闭环的价值：我们会很自然地把用户任务想象成一条从登录到退出的完整路径，然后在这条路径上把所有功能做全。但用户真实的路径几乎不会在系统边界内闭合，他们会频繁地跨系统搬运数据、跨角色对齐判断、跨时间复用经验。真正决定一个工具好不好用的，往往不是它内部的功能密度，而是它在这些「跨」的时刻有没有主动搭把手。我们习惯盯着用户在产品里做了什么，但更要紧的问题是：他离开产品之后，还要继续做什么？如果那半段任务始终要靠用户自己拼凑，系统里的前半段做得再漂亮，也只是半段。很多功能没被用好，根源不在那一段做得不够完整，而在它没有接住用户产品外的那半段任务。功能的价值有时候不取决于它自己多完整，而取决于它能否让用户任务真正闭环。

4.3 算进成本——低使用率背后，常常藏着用户潜在压力#

很多低使用率功能，第一眼看上去都是体验问题：入口不明显、路径太长、提示不清、操作成本高。产品经理很容易顺着这个方向优化，因为它们都能被界面改造解决，也都能很快进入版本计划：按钮外露一点、流程缩短一点、默认值聪明一点、文案清楚一点，数据大概率会有提升。问题是，用户不用一个功能，原因未必是不会用。有时恰恰相反，他完全知道怎么用，只是不敢用、不愿用，或者用了之后要承担一个产品经理没有看见的后果。这类问题在 B 端、内部工具和运营平台里尤其常见，因为用户不是一个孤立的人，他还嵌在组织关系里：他要对老板负责，对客户负责，对数据口径负责，对群发内容负责，对异常结果负责。一个功能如果只降低了他的操作成本，却增加了他的担责风险，用户未必会用。

2022 年我们团队接手过一套企微私域工作台，里面有一个触达模块，运营可以把软文、种草内容、活动消息选择「立刻群发」或「定时群发」。从功能设计上看，这个能力很基础，也很合理：内容准备好了，可以立刻发；如果想在第二天早上、周一早高峰或活动开始前固定时间触达，就设置定时。但后台数据显示，定时群发的使用率不到 5%，90% 以上内容都选择立刻发送¹。

如果只看数据，最容易得出的结论是：定时群发入口不明显或者操作太麻烦。负责企微的产品同学最开始也是这样判断，于是准备做一版体验优化：把「定时群发」按钮外露，改成更大的日期选择器，再加上明天 9 点、周一早高峰这类快捷选项，让定时变得和立刻发送一样顺手。这个方案听起来没问题，它确实在降低操作成本，也符合产品经理处理低使用率功能的常规反应，可是它默认了一个前提：用户不用定时，是因为定时不够方便。

这位产品同学后来去一个 30 人左右的内容和私域团队现场蹲点，坐在运营旁边看他们发内容。一个运营准备好一篇软文后，仍然选择立刻群发，问他为什么不用定时，他说不是不想用，是不敢用：如果设了明早 9 点发送，晚上 10 点领导突然说标题要改，或者客户临时要加一段话，等他第二天醒来才发现，事情就麻烦了。另一个运营说，他只有在怕自己忘记发送时，才会用定时，但设完之后反而更焦虑，一晚上打开手机看好几次，怕出问题。还有同学补了一句更关键的话：他们内部的习惯是软文、活动尽量立刻发。不是不需要定时，而是「定时」只解决了什么时候发，没有解决发送前如果情况变了怎么办。

原来我们以为用户缺的是更方便的时间选择器，现场看下来，用户缺的是发送前的控制感。对运营来说，一条群发内容不是一个孤立消息，它背后有领导审核、客户要求、活动节奏、文案风险、用户投诉和业绩压力。只要内容在未来某个时间点自动发出，中间那段等待时间就会变成一种不确定性。用户不是不会设置定时，而是不愿把一条可能变化的内容交给一个不可逆的定时器。「立刻发送」被大量使用，主要因为它更可控：点下去，事情当场发生，如果要改，至少在发之前自己还握着控制权。定时发送表面上让运营更省事，实际上让他多了一段悬空时间。只要组织里存在最后一刻改标题、换利益点、补业务要求的情况，这段悬空时间就会变成心理负担。

后来方案没有继续优化日期选择器，而是改成「预约发送 + 发送前 30 分钟二次确认」。运营设定发送时间后，内容进入预约状态，在预约期间可以随时撤回修改，不会锁死；发送前 30 分钟，系统再推送一条确认通知，运营可以确认发送，也可以取消退回草稿。这个改动上线后，定时群发使用率从不到 5% 提升到 22%¹。这不是因为日期选择更方便了，而是因为产品补上了「还能反悔」的安全感。

有些产品问题不在操作路径，而在责任结构。只盯着界面，问的是「怎样让他更快完成」；看见责任，才会问「他为什么不敢完成」。这两个问题会导向完全不同的方案。很多 B 端产品、内部工具和运营系统，真正决定用户行为的不是功能本身，而是功能之后的后果。一个报表导出功能，点击导出的人可能是一线运营，但真正读报表的是主管，质疑口径的是财务或数据同学，最终拿着报表做判断的是业务负责人。产品如果只让一线运营更快导出，却没有把指标口径、统计周期、权限边界和版本时间写清楚，导出越方便，后面的解释成本可能越高。用户会觉得功能好用，但不一定敢用，因为他知道一旦报表被质疑，第一个要解释的人就是他自己，系统不会替他出面。

一个审批或群发功能也是如此，使用者关心的不只是能不能提交，还关心提交之后有没有修改余地、谁会收到通知、系统是否留下记录、出错后能不能撤回。我们经常把这些能力归到异常流程里，实际它们对用户来说可能就是主流程的一部分。因为用户并不是生活在理想流程里，他生活在会临时改需求、会有人追责、会有口径争议、会有突发变化的组织里。

所以在观察低使用率功能时，不要只问用户为什么不用，也不要急着让他评价功能好不好。更有价值的问题是：如果用了，最坏会发生什么？谁会知道，谁要解释？有没有回退，有没有记录？这几个问题听起来不像交互问题，却经常比交互本身更接近用户行为的根因。产品经理常说要降低用户成本，但成本不只是点击次数、学习时间和页面跳转，还包括责任成本、解释成本、等待成本、出错成本和心理负担：

表 4-1　五类隐性成本

只看见操作成本，看不见责任成本，就会反复优化一个无用的功能。你把前一种成本降下来了，却把后一种成本转嫁给用户，他当然会绕开你的功能。有些不用，不是冷漠，而是自我保护。

4.4 放回事件——可靠的用户证据，要能回到具体事件#

用户研究最危险的地方，不是用户会说谎，而是产品经理太容易把用户的话当成完整事实。大多数用户并不是故意误导我们，他们会真诚地表达自己的偏好、抱怨和解释，也会努力回答产品经理提出的问题。但人对自己行为原因的理解，本来就不是完整透明的：人可以复盘自己的感受、判断和选择，却未必能完整表述出这些判断背后的心理过程。回到产品工作里，问题不在用户可不可信，而在于用户的解释需要被尊重，但不能被直接当成因果。

这也是为什么「你希望我们做什么」「你觉得这个方案怎么样」「如果上线你会不会用」这类问题很容易把产品经理带偏。用户会基于礼貌、想象、当前情绪、对产品的理解，给出一个听起来合理的答案。这个答案可能有参考价值，但它往往离真实行为还隔着一段路：他过去是否真的遇到过这件事，当时怎么处理？付出了什么代价，有没有绕路，有没有人催他？如果你提供新方案，他是否愿意改变原来的习惯？

产品经理需要区分「声音」和「证据」。声音很重要，它告诉你哪里不舒服、哪里可能藏着机会，但它要变成证据，就得被放回具体事件里。用户说「这个页面不清楚」，要追问上一次不清楚发生在哪里；用户说「想要导出」，要追问上一次导出后拿去给谁看；用户说「希望更智能」，要追问他现在为了完成这件事用了哪些笨办法；用户说「这个功能我一定会用」，要追问他过去有没有为同类问题主动付出过成本。没有具体事件，用户原话就只是一种情感宣泄；有了具体事件，哪怕样本不大，也可能足以推翻一个看起来很合理的产品假设。那么证据有哪些具象的表现？

表 4-2　四类用户证据

我并不是要说用户访谈没有作用，也不是说只有情景访谈、现场观察这类方法才起作用，我想表达的是：不同证据解决不同问题。大样本数据告诉你哪里异常、影响有多大；访谈告诉你用户如何理解自己的处境；现场观察告诉你行为如何发生；业务结果告诉你方案是否真的改变了任务完成。真正可靠的用户判断，通常不是来自某一种证据，而是来自几类证据互相校验成的一条证据链：数据先指出异常，访谈提出解释，现场观察校准解释，上线后的行为再回头验证。任何一环都可能出错：数据可能只告诉你问题冒出来的位置，访谈可能被用户事后解释加工，现场观察可能样本太小，上线数据也可能被短期激励污染。产品经理要做的，是看它们能不能互相支撑，别迷信其中某一种证据。一旦证据链成立，用户原话就不再是孤立的一句话，它会被放回时间、动作、责任和代价里，成为一个可以被讨论的判断依据。

这个时候，团队争论的重心也会发生变化：不再是「用户到底是不是这么说过」，而是「我们是否理解了这句话发生的场景以及产品应该介入哪一段」。产品经理不能因为用户未必说得完整，就摆出一副比用户更懂用户的姿态，那会变成另一种傲慢。更成熟的态度是：用户比我们更懂自己的处境，但他未必能把处境翻译成产品答案；产品经理比用户更懂产品系统，但未必懂用户在系统外承担的生活、工作和组织代价。用户研究的价值，就在这两种「不完整」之间建立证据。

我以前带团队时，经常会要求产品同学在需求内审中回答这个问题：你做出这个判断，是有力的证据支撑吗？如果答案是用户说了很多次，我会继续问：用户上一次为这件事付出了什么？如果答案是数据下降了，我会继续问：你有没有看过用户在这个环节前后做了什么？如果答案是竞品也这么做，我会继续问：我们的用户任务和竞品的任务是否一致？如果答案是业务很着急，我会继续问：着急背后是用户有真实的痛点，还是只是停留在用户嘴上的表达，或者是你自己的焦虑？这个追问不是为了把人问住，而是为了让团队形成一种层层深入、挖掘证据的习惯。

产品经理可以有直觉，也需要直觉，但直觉要能被证据校准。不能每次都用「我感觉用户会」开始，用「上线后看数据」结束。上线后看数据当然重要，但如果上线前没有把假设说清楚，数据不好时团队很难知道，是用户判断错了、方案形态错了、场景选择错了，还是目标本身错了。

可靠的用户证据，最好能回答四个问题：谁在什么具体场景里，试图完成什么任务？他现在怎么做，付出了什么代价？现有方案为什么无法承接住？如果按照这个方案实现了，用户是不是不再会付出之前的代价？这四个问题答不完，也没关系。真实项目里不可能每次都研究到完美，关键是产品经理要知道自己哪里还不知道。知道证据缺口，至少会让你在评审里更谨慎，在方案里留验证点，在上线后知道该看什么，最怕的是证据很薄，语气却很满。用户研究不是让产品经理不犯错，而是让错误更早暴露、更小发生、更容易被修正。

4.5 重画边界——用户证据要动到方案的根#

很多团队做用户研究，是在给已经想好的方案找证据：功能想得差不多了，去问用户喜不喜欢；页面都画出来了，去看用户能不能用；方向内部已经达成一致，去找几句用户原话放进汇报里。这种研究你说没用吧，也不是，它能发现一些细节问题，帮团队少犯点明显的错。但你说它能产生产品判断吗？很难，因为它一上来就把最重要的问题绕过去了：我们到底是不是在解决一件正确的事？

用户研究值钱的地方，是它能改变方案的边界。什么叫边界？不光是功能做多大规模，而是产品到底该管什么、不该管什么；能力放在哪个环节、不放哪个环节；哪些事系统做、哪些事用户做、哪些事交给组织里的其他人做；哪些代价该降，哪些代价不能偷偷转嫁出去。很多方案之所以越做越重，是因为边界一开始就画歪了：你以为自己做的是推荐，其实用户要的是提醒；你以为自己做的是报表，其实用户要的是能带走的材料；你以为自己做的是效率工具，其实用户要的是出错之前还能控制一下。边界画错以后，团队越努力，产品越完整，偏差反而越大。

用户研究不能光问「用户还想要什么」，还得问「我们现在的方案哪里不对」。后面这个问题比加需求难多了，因为它逼着团队承认，之前的设想没那么稳：一个已经画好的推荐模块，可能得缩成一个提醒；一个已经规划成数据中心的看板，可能得退回工作流里的数据出口；一个原本打算优化入口和控件的功能，可能得先把撤回、确认和留痕补上。这不是把产品做小，是让它站对位置，产品失败，常常不是因为能力太少，而是能力放错了地方。用户研究的价值，就是把产品从它自认为正确的位置上挪开那么一点，挪到用户真实任务会经过的地方。

很多产品经理做用户研究，最放不下的就是自己的原方案：方案已经想了很久，原型可能都画了，评审会上也讲过好几轮。用户证据一旦要动边界，就意味着前面的努力有一部分要推翻，这时候人就会本能地把证据往原方案里塞：用户说要提醒，那就在原方案上加个提醒；用户说要导出，那就在看板上加个导出；用户说担心发错，那就在定时页加句提示。这些补丁可能有点用，但不一定解决问题。如果证据指向的确实是另一个方向，最好的改法往往不是加东西，而是换：换任务，换入口，换角色分工，换成功指标，甚至换掉原来那个听起来更完整的产品形态。这个动作不一定更大，很多时候反而更小，但它能让产品更贴近用户要完成的事。

一个产品经理成熟不成熟，很大程度上就看这一点：你敢不敢让用户证据动到方案的根，而不是只动到方案的皮。这事对团队也很关键，很多团队并不反感用户研究，但把它做成了流程节点：立项前调研一下，设计后可用性测一下，上线后回访一下，流程走了，判断未必发生。因为用户研究一旦被钉在验证方案这个位置上，它就没法挑战方案本身了。我更愿意把用户研究看成一种持续的校准，像前面那条证据链一样，它不是只在需求前做一次，而是要跟着方案一路走下去。

这也是为什么用户研究不能只是用户研究员的事，研究员可以帮你设计方法、找样本、做访谈、整理洞察，但产品经理不能把理解用户这件事外包出去。因为最后要改方案边界的人是你，要在评审会上解释为什么不按原方案做的人是你，要扛资源投入后果的人还是你。一个产品经理如果只把用户研究当材料，他会问：「报告里有没有能支持我方案的结论？」如果把用户研究当判断，他会问：「这些证据是不是要求我重新定义问题？」前者让研究变成背书，后者才让研究真正进入产品。

也别把用户研究神化，它不能替你搞定所有商业判断，不能替你摆平资源冲突，也不能保证方案一定成。用户证据只回答一部分问题：用户在什么场景下付出了什么代价，产品进去以后有没有可能把这个代价降下来。至于这个代价值不值得现阶段投入，符不符合产品定位，会不会破坏商业结构，能不能跟组织资源匹配上，这些还是要产品经理回到产品观和需求观里去接着判断。用户观不是要产品经理无条件站用户那边，而是要产品经理别拿自己想象的用户去给判断背书。产品观决定什么值得存在，需求观决定什么有资格进队列，用户观决定你对用户的判断离现场有多近。三个放在一起，产品经理才不会一边喊着用户价值，一边做出一款只有会议室用户才会用的产品。所谓超越共情的深度理解，就是离现场近一点，离那个会议室里想象出来的用户远一点。

闲言碎语#

「用户会」这三个字，凭什么说得那么笃定？做产品这些年，我说过很多次「用户会」：用户会从这里进入、用户会注意这个利益点、用户会理解这套规则、用户会愿意为了更好的体验多走一步。很多时候我说对了，也有很多时候只是没有人回来追问当时那句话。后来我越来越警惕这种表达，不是因为产品经理不能判断，而是因为「用户会」这三个字太轻了。它轻到可以绕过证据，轻到可以掩盖不确定，轻到可以让一个会议室里的方案显得顺理成章。

我更愿意把话说慢一点：基于目前这些数据、访谈，我判断用户可能会这样做；如果后续发现他们在某个场景里没有这样做，我愿意回来修改判断。这句话不够漂亮，也不够像一个很有把握的产品负责人，但我越来越觉得，产品经理真正的专业性，不是永远显得笃定，而是在不确定里仍然负责任地做判断。承认不知道，并不会削弱产品经理的价值，削弱价值的，是明明不知道，却因为会议需要一个答案，就迅速创造出一个用户替自己作证。

我也不喜欢把用户研究讲得太神圣，用户不会自动给你答案，访谈不会自动产生洞察，现场观察也不会自动让产品变好，你还是要判断、要取舍、要承担后果。只是当你愿意走到用户身边，看他真实完成一件事的全过程，你会变得没那么容易自信过头。很多时候，我们缺的只是在说「用户需要」之前，停下来问一句：我真的看见了吗？