产品经理需求挖掘实战：EMUC框架与五次追问法

1. 这个话题为什么值得产品经理单独开一堂课先抛一个很多年总结下来的观察绝大多数产品经理并不是不会做需求而是根本不知道该从哪里开始找需求。需求评审会上最常见的场景是——产品经理打开一张需求清单逐条解释用户想要这个竞品有这个功能所以我们也要有老板说下个版本必须上。等到功能上线数据表现惨淡用户根本不买账于是复盘变成互相甩锅开发说需求不合理运营说功能没人用老板说产品不懂业务。问题出在哪出在大家把需求当成了用户嘴里说出来的话或者竞品页面上摆着的功能而没有真正去理解需求背后那套完整的因果链条。打个比方用户说我想要一个更快的搜索框如果你真的去做一个更快的搜索框大概率是白费功夫。因为用户真实的需求可能是我在搜索结果里找不到想要的那个文件根因是排序逻辑有问题而不是输入框响应慢了 100 毫秒。这就是表面需求和真实痛点的差距。需求挖掘的核心工作不是收集意见而是穿透意见找到用户行为背后那个非做不可的理由。这也是我想写这篇文章的初衷把一套我自己在实际项目中反复验证过的需求挖掘方法完整拆开讲清楚。这套方法由两部分组成——EMUC 框架用来结构化描述需求全貌五次追问法用来穿透表象找到真正的痛点根源。两者配合使用基本可以覆盖从不知道做什么到明确知道为什么做、给谁做、做到什么程度的完整过程。适合谁看刚转行做产品的新人正在为需求评审发愁的在职产品经理以及带团队时总感觉需求质量参差不齐的产品负责人都能从中拿到可以直接落地的东西。如果你目前正处于需求文档写得挺厚但总感觉差点灵魂的状态这篇文章大概率能帮你找到那个灵魂在哪。2. EMUC 框架把模糊的想法变成可评审的需求描述2.1 EMUC 到底是什么EMUC 是我在多个项目里逐步沉淀出来的一个需求分析框架四个字母分别代表四件事EEntity需求主体、MMotivation行为动机、UUsage Scenario使用场景、CCore Value核心价值。一句话概括就是任何一条需求都必须能清楚回答这四个问题——谁、为什么、在什么情况下、得到了什么。很多产品经理写需求习惯性地只写What和How。比如说首页增加一个签到功能个人中心增加消息通知入口设置页增加深色模式开关这些描述本质上只是功能清单不是需求。你拿着这种描述去评审开发当然会问签到功能给谁用为什么要做签到用户什么时候会打开签到页签到到底给用户和业务带来了什么答不上来需求就被打回。EMUC 就是逼着你在写需求之前先把这四个问题想清楚。举一个真实的例子。某电商 App 要做订单列表增加筛选功能如果只用传统写法需求描述就是在订单列表页顶部增加状态筛选标签支持按待付款、待发货、待收货、已完成、已取消筛选。这条需求看起来很清晰但评审的时候一定会被问为什么要做。用 EMUC 重新组织之后它变成这样E需求主体在 90 天内下过 3 单以上、且有过一次退货行为的活跃用户。M行为动机当用户想查看某个特定状态订单时现有列表需要不断下滑翻找超过 5 屏时用户放弃查找的比例明显上升。U使用场景用户刚完成一笔退货想确认退款进度但最近 30 天订单很多找不到那笔退款订单。C核心价值将找到目标订单的平均耗时从 90 秒降低到 15 秒以内减少用户因找不到订单而产生的不满。同一个功能两种写法给研发和测试的指导意义完全不同。后者不仅说明了做什么还告诉团队为什么要这么做、做到什么程度算成功。2.2 四个维度的落地细节与常见误区先看 E需求主体。这里的常见误区是把用户画像写得太泛。比如所有注册用户一二线城市的年轻白领这种颗粒度放到需求描述里几乎没有任何指导价值。我建议在 EMUC 框架里写的是行为画像而不是人口属性画像。你要回答的是这批用户在系统里做过什么、最近状态是什么、和这个功能相关的历史行为有哪些。写近 30 天有 3 次以上搜索行为且搜索后未点击结果的用户就比写对搜索体验敏感的用户有用得多。再看 M行为动机。动机不是用户想要什么而是用户为什么会产生这个想要。做深访或者说用户调研的时候你可以直接问用户你想要什么功能但你不能把答案直接当作动机来写。比如用户说我希望搜索结果能按时间排序这是表面诉求背后的动机可能是我找的是昨天刚发布的那篇公告但默认排序把它埋在了很后面。动机要能解释行为也要能预测行为——当场景条件成立时用户大概率会触发这个行为。然后是 U使用场景。场景写作有一个容易被忽略的细节要写包括前置条件的完整场景链。什么是前置条件就是用户进入这个场景之前已经处于什么状态。看上面那个退货的例子用户不是随机打开订单列表然后突然想筛选而是先发生了退货行为再产生查看退款进度的需求。如果场景描述里没有这层前置事件开发同学在理解功能边界时就容易产生偏差甚至会把这个筛选做成通用的、全状态的筛选结果首页直接把所有筛选条件都丢出来页面路径反而变复杂。最后是 C核心价值。这个最容易写成口号——提升用户体验提高用户满意度都是无效描述。核心价值必须满足两个条件可衡量、有时限。可衡量是要有明确的指标维度比如时长、点击次数、转化率、留存率有时限是指在多长时间内达到什么程度比如上线后两周内将订单查找时长降低 40%。没有时限的指标没有约束力项目排期、复盘都会变成一笔糊涂账。2.3 用 EMUC 把老板的拍脑袋需求变成可验证的项目做产品的人几乎都会遇到老板拍脑袋提需求的情况。这类需求最大的问题是没有明确的主体和动机甚至没有清晰的场景只有一句我们要做XX。我之前在一个团队遇到过这样一个需求老板说我们要做一个会员等级体系。当时团队的第一反应是直接开干——设计等级、规划权益、开发页面。但如果你用 EMUC 框架过一遍就会发现这个需求根本还没成型。E 先问会员等级体系是给谁看的是给高活跃用户以激励还是给沉默用户以召回M 再问用户为什么要关心等级等级能帮用户完成什么目标U 接着问用户会在什么场景下感知到等级的存在和变化C 最后问做了等级体系之后业务指标上要看到什么变化这一轮问下来需求就从我们要做一个会员等级体系变成了我们要通过等级体系提升月活跃用户中高价值用户的登录频次目标是在三个月内将月活用户中近 30 天有购买行为用户的回访率提升 15%。这两种表达团队的执行动作和验收标准会完全不一样。3. 五次追问法穿透表象找到用户真正的痛点3.1 每次追问的聚焦点是什么如果说 EMUC 框架解决的是如何结构化描述需求那五次追问法解决的就是如何找到那个值得被描述的需求。它的核心逻辑很简单对用户陈述的每一个诉求连续追问五次为什么每一次追问都把问题的层次往深处推一层直到找到那个无法再往下追问的根因。很多人听到连续追问五次会觉得这不就是刨根问底吗谁不会。但实际操作中大部分人追问到第二三次就停了原因是他们分不清追问用户的表层回答和追问用户的深层动机。表层回答往往是用户基于常识给出的合理化解释深层动机才是用户行为背后的真实驱动力。五次追问法的关键是每一层都要基于已有信息继续往下而不是换一个问题重新开始。我把五次追问拆成五个递进的层次分别对应不同的关注点第一问事实层用户说的是什么把用户的原始陈述复述准确。 第二问诉求层用户真正想要的结果是什么剔除表达方式只看目的。 第三问动因层用户为什么在意这个结果什么压力或期待在推动他 第四问情境层用户在什么条件下才会产生这种压力或期待前置事件和场景是什么 第五问根因层有没有一个更本质的问题让前面所有层次都变成它的表象用这五层去对照你会发现大多数需求文档只写到了第一层或第二层能写到第三层的已经算不错的了。后面两层才是决定产品差异化的地方。3.2 从用户一句抱怨到产品方案的完整追问链用一个我自己做过的例子来演示。当时是一个文件管理类产品用户在我们内部反馈渠道留言我希望文件夹能支持多选移动现在一个个移动太麻烦了。如果只看第一层这条需求翻译过来就是增加多选移动功能。很多产品经理到这里就已经提需求去了。但按照五次追问法往下走会发现完全不同的东西。第一问事实层用户说希望支持多选移动因为现在只能单文件逐个操作。第二问诉求层用户真正想要的是更高效地把一批文件转移到另一个位置。他要的不是多选这个交互形式而是批量完成转移这个结果。第三问动因层为什么需要批量转移深挖之后发现这位用户是做项目资料整理的他每天要从下载目录把几十个文件归入不同的项目文件夹。这个动作重复且耗时他希望能缩短整理时间。第四问情境层什么情况下会产生这种大批量归集行为答案是当他从邮件、聊天工具、网页等多个来源下载素材后素材全部堆在默认下载目录需要一次性分发到不同项目目录中。第五问根因层到这里真正的问题浮出水面——用户的痛点不是移动文件不够方便而是多来源下载的素材没有按照项目维度自动归集。如果能在下载环节就提供选择目标项目文件夹的选项或者在下载完成后弹出一个一键归集的引导用户根本不需要经历下载到默认目录再批量移动这个痛苦流程。最终这个项目没有优先做多选移动而是做了一个下载后定向保存的功能用户在下载触发时可以选择目标目录系统记住他最近常选的目录下次默认匹配。上线后这个功能的日活使用率比预期高出不少而最初喊得最响的多选移动反而没有排进前三。这就是穿透表象的价值——用户以为他要的是 A但真正解决问题的是 B。3.3 追问过程中最容易走偏的三类陷阱第一类陷阱叫过分相信用户的表达。用户在反馈问题时往往会用解决方案式的语言来表述需求比如你们应该加一个夜间模式能不能做一个一键分享。这些是用户基于自身经验给出的方案建议不是需求本身。你如果照单全收产品就会变成用户零散建议的拼接体。正确的做法是把这些建议当作线索去还原他试图解决的那个原始问题。第二类陷阱叫用竞品答案替代用户答案。做竞品分析时看到某大厂做了某个功能就觉得这是用户的真实需求。这种逻辑最大的漏洞是大厂做的功能针对的用户群、业务阶段和资源禀赋都和你不同。竞品功能只能作为假设来源之一不能作为需求成立的依据。任何从竞品来的想法最终都必须回到真实用户身上做验证。第三类陷阱叫追问成了逼问。有些产品经理在用户访谈时会用连续追问的方式让用户给一个自己从来没想过的答案这种被逼出来的答案往往不是真实动机而是用户为了结束对话随口编的。追问的本质不是审讯而是引导。一个有效的追问应该给用户足够的思考空间甚至允许他回答我没想过这个问题。如果没有这个空间追问出来的结论在方向上就可能是错的。4. 结合实操EMUC 和五次追问法怎么配合使用4.1 两套方法的分工逻辑先穿透再结构化我经常被问到的一个问题是这两套方法到底先做哪个是先 EMUC 还是先五次追问我的习惯是先用五次追问法挖掘痛点再用 EMUC 框架组织需求。这个顺序是固定的不能反过来。道理其实不难理解。五次追问法的作用是做减法——把一个模糊的、宽泛的问题域收窄到真正值得解决的根因上。这个过程产出的是一个点一个核心痛点。而 EMUC 框架的作用是做加法——围绕这个核心痛点把需求主体、行为动机、使用场景和核心价值补充完整让它变成一个可以进入评审流程、可以排期开发、可以验收效果的需求描述。如果你先用 EMUC 去写你会在动机是什么、场景是什么这些维度上卡住因为你还没有找到那个根因所有描述都会是空泛的写出来等于编。反之先穿透到根因你带着一个明确的判断来补全 EMUC四个维度就有了实实在在的信息可以填。拿前面那个文件管理产品的例子来说五次追问得出的结论是下载环节缺少定向归集能力那么 EMUC 就围绕这个结论来写E 是高频下载且需要做项目资料整理的用户M 是整理下载目录耗时太长、容易归错文件夹U 是用户从多个来源下载素材后需要集中归入项目目录C 是将文件从下载完成到进入正确项目目录的操作时间降低 50%。你看每一个维度都有明确内容评审时任何人都能快速理解这条需求的价值。4.2 一套可以直接套用的需求挖掘五步流程把两套方法合并到实际项目中我总结了一个五步流程做需求前期分析时按照这个顺序走一遍基本不会遗漏关键信息。第一步收集原始素材。从用户反馈、客服记录、数据分析、访谈纪要、竞品观察中把和问题相关的原始陈述全部列出来。这一步先不要做筛选记录要完整因为后面的追问需要依赖这些原始表达来还原事实。第二步逐条进行五次追问。对每一条原始素材按照事实层、诉求层、动因层、情境层、根因层的顺序往下追问。这一步需要注意的是不同原始素材可能会收敛到同一个根因说明这个根因是值得重点关注的如果一个素材追问不到根因果断标记为低优先级。第三步筛选出高频根因。把所有素材的根因汇总按出现频次排序。高频根因意味着它是多个用户共同面临的问题解决它的杠杆效应最大。这里的频次不要只看绝对数量还要结合业务目标判断哪些根因和核心指标关联度更高。第四步用 EMUC 写出需求描述。针对筛选出的根因用一个标准的 EMUC 模板来组织需求描述。如果一条需求无法完整填写 EMUC 的四个维度说明这个需求还没想透暂时不要进入评审。第五步进行内部评审前自检。写完 EMUC 之后在正式评审之前自己先做一次质疑这条需求的主体到底是真实用户还是我编造出来的动机有没有数据或访谈支撑场景是不是真实发生的核心价值到底能不能被验证如果这四个问题里有任何一个回答不了回到第三步或第二步重新来。4.3 一个从 0 到 1 的模拟项目完整演示为了让这套方法更容易理解和复现我用一个模拟场景从头到尾走一遍。假设我们正在做一个企业内部的知识管理工具收到三条典型反馈反馈一文档搜索总是搜不到我想找的内容感觉还如直接用系统文件夹找。反馈二我想把收藏的文章分享给同事但每次都要先下载再上传到聊天工具太麻烦了。反馈三新建文档时想要一个模板但模板库里大多是行政类模板技术类模板很少。按照五步流程走第一步原始素材收集完成就是上面三条。第二步逐条追问。反馈一的追问链用户搜不到内容→因为搜索结果的匹配逻辑和用户记忆中的文件名不一致→因为用户倾向于通过业务关键词搜索而非精确文件名→因为内容归档时没有按业务语义打标签→根因是知识入库时缺少语义标签体系。反馈二的追问链分享文章太麻烦→因为知识库分享链路断开→因为知识库和聊天工具没有打通→因为内容在不同系统间流动需要手动中转→根因是知识库缺少与其他协作工具的集成能力。反馈三的追问链模板库匹配不上→因为模板库内容偏行政→因为缺少技术类模板的积累机制→因为模板来源单一、没有发动全员贡献→根因是模板库缺乏面向不同业务线的运营机制。第三步高频根因排序。三条反馈对应三个不同根因没有一个重复。这时候需要结合业务目标来判断优先级如果这个阶段的核心目标是提升知识检索效率反馈一对应的根因优先如果目标是促进知识流转分享反馈二优先如果目标是提高文档产出效率反馈三优先。这个排序本身就值得和团队讨论一次。第四步和第五步就是用 EMUC 把选中的根因写成完整需求并完成自检。这里我以反馈一为例写一个完整的 EMUC 版本E在知识库中每周搜索超过 5 次、且搜索后 30 秒内未打开任何文档的用户。M用户搜索时习惯用业务关键词但文档归档时没有统一的标签规范导致匹配率低。U用户记得文档讲的大致内容比如上季度的数据复盘但不记得文档标题和具体文件位置于是在搜索框输入业务关键词。C将搜索后 30 秒内未打开文档的比例从当前的 45% 降低到 25%并在两星期内完成验证。到这里一条原本只是搜索体验差的模糊反馈已经变成了一条主体明确、动机合理、场景真实、价值可衡量的需求。5. 我在真实项目中验证这套方法的几个发现5.1 最意外的发现高频需求不等于高价值需求用过一段时间这套方法之后我最大的一个认知更新是高频出现的问题未必是优先级最高的问题。以前我习惯性地认为既然很多用户都反馈了同一个问题那这个问题一定是核心痛点。但把五次追问法用起来之后我发现有些高频反馈追问到根因层时指向的是一个存在感强但对业务结果影响有限的伪痛点。举个例子。某个产品上页面加载速度慢是反馈最多的关键词之一。如果只停在这个层面团队大概率会投入大量精力去做性能优化。但追问下去之后发现大部分用户抱怨加载慢的场景发生在弱网环境下而这类用户的产品使用深度本来就很低。相比之下搜索结果不准确的反馈数量只有前者的三分之一但追问到根因后发现它直接影响核心付费转化路径。两个问题摆在一起后者反而更值得优先投入。高频反馈代表的是感知强度不等同于业务杠杆。需求优先级的判断必须同时看根因影响力和根因与核心指标的关联度而不是简单看反馈条数。5.2 团队协作方式的变化从产品定需求到全员共建需求链以前在团队里需求分析基本是产品经理一个人的活儿。产品经理想出来后写一份文档拉着研发和测试评审。研发和测试更多是执行角色对于为什么要做这个其实是缺乏参与感的。用了 EMUC 和五次追问法之后我把访谈后的原始素材和追问链条直接共享给团队让大家在评审前就能看到从用户原话到根因的完整推导过程。这个变化带来的效果出乎意料研发开始主动对场景提出质疑测试会基于场景设计出之前根本没想到的边界用例运营也会补充他们在一线看到的用户反馈实例。需求的推导过程一旦透明团队就从被动接需求变成了共同验证需求。这不是什么管理方法而是工具本身带来的协作红利——因为 EMUC 框架的四个维度天然开放给不同角色去填充谁都能贡献自己的那部分信息。5.3 这套方法解决不了的问题必须诚实说写了这么多也得说说这套方法的边界。它解决的是如何把模糊信息变成准确需求的问题但它不能替代业务判断也不能替代数据验证。有一个很容易被忽视的坑是五次追问法产出的根因本质上仍然是一种假设。它建立在访谈样本和观察基础上不等于全量用户的事实。所以每次做完追问和 EMUC 描述都不要跳过验证环节。能用数据验证的场景就用数据验证不能数据验证的至少用小范围用户测试快速试错。带着假设去上线同时提前设计好验证指标这是一种健康的做法。另外这套方法对访谈能力有一定要求。很多人在实战中第一次使用会在第二层、第三层就卡住因为用户回答变得模糊或者开始绕圈子。这不是方法的问题而是访谈技巧的问题。建议新人在前期先找个搭档一起做访谈一个负责追问一个负责观察记录用户的微表情和犹豫点比自己硬撑要有效得多。6. 一些可以直接拿走的模板和检查清单6.1 EMUC 需求描述模板写需求时可以直接复制这个结构需求主体E用行为画像描述包含行为特征、最近状态、和相关历史行为的边界条件。行为动机M说明用户产生诉求的真实原因要能解释行为并预测行为。写法模板是当用户在某状态下因为某原因所以希望某结果。使用场景U完整描述包括前置事件在内的场景链。写清楚用户从什么状态进入、做什么动作、遇到什么障碍、期待什么结果。核心价值C必须包含可衡量的指标和目标时限。写法模板是将某指标从 A 值提升/降低到 B 值在 X 时间内完成验证。6.2 五次追问记录表访谈或者反馈分析时用这个表格记录每一层的追问结果追问层级关注点记录内容第一问事实层用户原始陈述是什么第二问诉求层用户真正想要的结果是什么第三问动因层用户为什么在意这个结果第四问情境层什么条件触发了这种动机第五问根因层更本质的问题是什么6.3 评审前自检清单每次需求评审前逐个过一遍下面的问题任何一项不通过都不要急着上会需求主体是否具体到可以识别能否描述出这个用户最近做了什么行为动机是否来自真实访谈或行为数据而不是主观猜测使用场景是否包含了前置事件团队拿到描述后是否能还原出完整的用户操作路径核心价值的指标是否可采集、能否验证目标时限是否明确从用户原话到根因的追问链是否完整有没有跳层是否有数据或小规模测试的结果支撑根因假设个人经验里最后一条最容易被忽略。很多需求评审时被挑战根源就在于追问链不完整或者根因没有实证支撑。花点时间把证据链补齐评审会能少开一半。7. 我在实际使用这套框架过程中的三个体会最后分享几个单纯从实践中得来的体会不保证适用所有团队但对大多数做产品的人来说应该能有所参考。第一个体会是不要急着在这套框架里追求标准答案。我刚用 EMUC 和五次追问法时总想把每个需求都挖到特别深每个词都抠得很细结果项目节奏被拖慢团队也累。后来调整了用法对高优先级的核心需求用完整流程慢慢挖对中低优先级的需求只做一次快速追问能到第三四层就够用了。工具是为人服务的不是反过来被工具绑架。第二个体会是这套方法在需求前期花的时间账会在后期几十倍地赚回来。一次需求评审会动辄一个多小时如果需求描述不清开发做出来的东西又要返工来来回回的沟通成本远超前期分析的时间。用两周时间把需求的根因、场景、验证指标全部想清楚后续的开发验收反而会快很多。省在前期花在后期这才是真正的浪费。第三个体会是要敢于把提问这个动作本身变成团队文化的一部分。当团队里每个人都习惯先问用户为什么需要这个再问这个怎么做产品的讨论质量会自然地高出一截。工具性的框架只是起点真正起作用的是大家开始在意需求背后的因果逻辑不再把有反馈当作应该做的理由。需求挖掘这门课说到底不是教你一套提问技巧而是帮你建立一种职业本能面对任何一条需求先问它是从哪来的、为什么存在、为谁服务然后再动手。这个本能一旦建立它对你的帮助会覆盖你职业生涯的每一个阶段而不仅仅是一个项目、一次评审。