产品需求如何做好场景？产品经理入门指南与操作步骤

产品需求写着“增加批量导出”，开发按时交付，用户却继续截图、复制、粘贴，问题往往不在功能做得不够快，而在需求没有说清楚“谁在什么情况下，为什么要导出，导出后要完成什么事”。我判断需求场景是否合格，通常不先看功能清单，而是看团队能不能据此还原用户当时的处境、目标、限制和可验证结果。场景不是需求文档里的装饰段落，而是决定做什么、不做什么，以及如何验收的判断依据。

一、先讲结论：场景不是背景介绍，而是需求成立的条件

1. 一个好场景，至少回答五个问题

我会把需求场景压缩成一条可以讨论、可以验证的因果链：什么人在什么触发条件下，遇到什么阻碍，想完成什么目标，受到什么约束，最终怎样判断问题被解决。这五个问题缺一项，需求就容易从真实问题滑向功能愿望。

例如，“用户需要批量导出订单”只说了用户想要的动作，没有解释为什么要导出、导出哪些字段、数据量有多大、后续拿文件做什么，以及现有方式哪里不够用。换成场景表达，可以是：“每周一上午，区域运营需要从过去一周的订单中筛出异常退款记录，交给财务复核；目前只能逐页复制，约有数百条记录，复制过程中容易漏掉退款时间和门店编号。”这时，批量导出只是可能的方案之一，问题本身才是决策中心。

场景还需要一个边界：谁不在本次解决范围内。比如，财务要的是可追溯的审计文件，运营要的是便于筛选的表格，商家要的是自己门店的数据。把三类人都写成“导出用户”，容易做出一个人人都能点、却没有人满意的按钮。

2. 用场景决定需求，而不是用场景包装结论

团队常见的倒置做法是先决定“做批量导出”，再补一句“用户为了提高效率”。这类场景并没有帮助团队判断方案，只是在为既定方案找理由。真正有用的场景要允许结论被推翻：如果用户只需每周一次、数据量很小，保存筛选条件或自动发送报告可能更合适；如果导出涉及敏感信息，权限与审计可能比按钮位置更重要。

场景描述的价值，不是让需求看起来更完整，而是让团队可以据此拒绝错误方案。如果场景无论怎样写都只能得出同一个功能结论，通常意味着问题定义已经被方案绑架。

3. 快速检查：场景能不能指导设计和验收

拿一条需求给没有参加访谈的人看，请他回答：用户是谁、何时发生、要完成什么任务、目前如何处理、最主要的限制是什么、成功后有什么变化。如果不同人给出的答案差异很大，说明场景还不够具体。再让他写出一个验收条件；如果只能写“功能正常”，场景通常也没有落到可验证的目标上。

二、为什么场景容易写虚：从用户的一句话到真实工作现场

1. 用户说的是方案，背后可能是不同问题

用户经常用熟悉的功能名表达不便：“加个筛选”“支持导出”“做一个看板”“增加提醒”。产品经理若把原话直接转成需求，等于把诊断权交给了用户。用户通常最了解自己的工作，却未必知道系统里最合适的解决方式；产品经理需要理解任务，而不是照单全收方案。

以“增加提醒”为例，它可能对应完全不同的场景：采购员忘了审批待办，仓库人员不知道补货阈值已触发，客户成功经理需要在续约前跟进，或者负责人担心异常没有被处理。四种情形分别涉及任务遗漏、库存监控、客户经营和风险升级。若只做一条通用站内通知，可能一个问题也没真正解决。

2. 场景要落在工作流的具体节点

用户不是在抽象的“使用产品”，而是在一段工作流里完成某项任务。一个场景通常有前置条件、触发事件、操作过程、判断节点和结果去向。比如，仓库主管不是单纯“查看库存”，而是在盘点后发现某类耗材低于安全库存，判断是否受促销或供应延迟影响，再决定补货数量，并把决定同步给采购。

访谈时，我会把“你想要什么功能”换成“上一次发生这件事是什么时候”。追问具体时间、参与角色、当时打开了哪些工具、在哪一步停下来、怎样绕过问题、出错后谁来处理，通常比问“你觉得需要什么”更容易得到可用信息。用户能复述最近一次真实经历时，团队才有机会区分事实、推测和偏好。

3. 不要把所有用户压进同一个平均场景

平均用户往往并不存在。新手和熟练用户、单店与连锁门店、白班与夜班、网络稳定与离线环境，可能在同一功能上有截然不同的目标。把差异揉成一个“典型用户”，会让需求看似全面，实际却掩盖重要约束。

我更愿意先按任务和约束分组，而不是按人口属性堆标签。年龄、职级、部门名称未必直接影响方案；是否需要跨门店汇总、是否能查看敏感字段、是否必须在移动端完成，往往更能影响产品行为。分组的标准应该是“不同组是否需要不同方案或不同验收条件”。

4. 一个具体场景示例：订单异常复核

下面的例子是用于说明方法的情景模拟，不代表某家企业的实际经营数据。某区域运营每周需要把异常退款记录交给财务复核。表面需求是“批量导出订单”，但沿工作流拆开后，至少能看到三种问题：记录查找耗时、导出字段不全、复核结果无法回写。

如果团队只解决导出，用户依然要手动补充退款原因，财务也无法确认某条记录是否已核验。若场景证据表明，主要耗时来自反复筛选与遗漏字段，那么保存查询条件和固定字段模板可能比扩大导出权限更有效；若主要风险来自缺乏复核记录，则应优先设计状态流转和操作留痕。

三、常见误区：场景写得很长，判断力却没有增加

1. 把功能描述改写成用户故事，不等于理解了需求

“作为一名运营，我希望批量导出订单，以便提高效率”看起来有结构，但信息依然不足。“运营”范围太广，“提高效率”不可验收，“批量导出”已经预设了解法。模板能帮助统一表达，却不能代替观察和追问。

更好的做法是把模板当作缺口提示，而不是合格证。补充用户角色、触发情境、当前替代办法、失败代价和成功标准之后，再讨论功能是否必要。否则，团队只是把模糊需求排版得更整齐。

2. 把“用户说了”当成“用户验证了”

用户说“我肯定会用”是一种态度，不等于发生过使用行为。访谈中的意愿容易受到礼貌、想象和提问方式影响。相比之下，用户最近一次如何完成任务、用了多久、找谁帮忙、是否重复操作，更接近可核验的证据。

我会区分三类信息：用户的原话、可以观察到的行为、产品团队的推断。原话保留语境，行为说明事实，推断用来形成假设。把三者混在同一段结论里，容易让团队误把推测当成用户证据。

3. 把角色画像写得详细，当作场景充分

“三十多岁、注重效率、熟悉数字工具”的画像，未必能帮助团队设计流程。相比这些抽象特征，“每周一需要核对上周退款，必须在财务关账前完成，数据来源分散在两个后台”更能指导产品决策。画像不是不能用，而是必须与任务、环境和约束相关。

4. 把边界条件留到开发阶段再问

数据权限、网络条件、时区、并发操作、异常恢复、历史数据范围，看上去像技术细节，实际上常常决定场景是否成立。比如，夜班人员无法依赖白天审批；跨区域团队可能有不同的工作日；批量操作遇到部分失败时，用户需要知道哪些记录成功、哪些需要重试。

如果这些情况直到开发联调才出现，团队通常要在“加功能”“改权限”和“接受风险”之间仓促取舍。因此，在需求阶段至少应把高影响、高不确定性的约束列为待验证项，而不是假设环境永远理想。

5. 用一个成功故事替代总体判断

一个用户成功完成任务，不代表所有目标用户都如此；一个客户提出强烈需求，也不代表需求普遍存在。反过来，一个受访者没有遇到问题，也不能证明问题不存在。关键不在于讲多少故事，而在于样本覆盖了哪些条件、观察到了什么行为，以及结论适用于谁。

样本小的时候，不要把比例写成市场事实。可以明确说“在本轮访谈的六位一线运营中，有四位提到重复筛选”，同时交代受访者来自什么团队、如何招募、是否只覆盖某类用户。这个表述比“多数用户都需要”更诚实，也更利于后续补充样本。

四、专业判断逻辑：从场景证据到需求优先级

1. 先分清事实、解释和方案

一份可靠的需求分析应当能沿着证据往回追。用户在某次任务中操作了三套系统，这是观察事实；切换系统造成遗漏，这是基于证据的解释；增加统一工作台，是待评估的方案。若三者在文档里混为一谈，评审就会把方案偏好误当成事实结论。

2. 评估场景的五个维度

我不会只凭“需求声音大”决定优先级，而会从五个维度判断：发生频率、问题代价、目标用户覆盖、当前绕行成本和证据可信度。频率高但代价极低的问题，未必优先；低频但涉及重大合规风险的问题，可能必须处理。维度之间不是机械相加，而是帮助团队明确取舍理由。

• 频率：任务每天、每周还是偶发？是个人习惯，还是业务流程固定节点？
• 代价：失败会造成时间损失、收入损失、错误决策、客户流失，还是合规风险？
• 覆盖：影响多少目标用户？是否集中在关键客户或高价值工作流？
• 绕行：用户目前靠人工、表格、消息提醒还是重复录入完成任务？成本是否可量化？
• 证据：结论来自访谈回忆、现场观察、行为日志、客服记录还是实验？是否存在反例？

3. 让需求优先级建立在证据强度上

团队可以用轻量评分帮助对比，但分数不是客观真理。我会把评分当作讨论入口，例如给频率、代价、覆盖和证据可信度分别打1至5分，再记录打分依据。真正重要的是团队能解释为什么某一项是3分而不是5分，以及新增什么证据会改变排序。

对于高风险或高投入需求，单靠访谈通常不够。可以组合使用任务观察、日志分析、客服工单归类、原型测试和小范围灰度。若多个来源指向同一个问题，判断会更稳；若来源相互矛盾，矛盾本身就是下一步研究的对象。

4. 设定验收标准时，测用户结果而不只测功能存在

“导出按钮可以点击”是功能检查，不是需求验收。更接近用户价值的标准可能是：目标用户能够按指定条件找到记录；导出文件包含复核必需字段；批量任务失败时能识别失败项；完成任务所需时间降低。具体阈值应来自基线、业务风险和产品目标，不能为了显得精确而随意设一个数字。

如果没有既有数据，可以先做基线测量，再约定验证方式。例如在同一类任务中，记录完成时间、错误数和求助次数；上线后用相同定义复测。若样本量不足，应把结果称为方向性观察，而不是统计显著的改善。

五、实操步骤：把一句需求整理成可讨论、可验证的场景

1. 第一步：记录原始请求，不急着改写

先保留用户原话、提出时间、提出渠道和上下文。不要一收到“加个导出”就改成标准需求模板，因为原话里的情绪、使用词汇和触发背景都可能提供线索。若来自客服工单，保存工单类型和处理结果；若来自销售转述，记录客户角色及对话情境。

原始请求也不是最终需求。它的作用是保留证据链，避免团队在反复转述时把用户表达改写成符合内部方案的版本。后续任何推断都应能追溯到请求、访谈或行为证据。

2. 第二步：围绕最近一次真实经历做访谈

访谈尽量围绕具体事件，不要只讨论理想功能。可以按“最近一次，任务过程，卡住位置，应对方式，后果，例外情况”的顺序追问。比如：“上一次你需要复核退款是什么时候？”“当时从哪里开始找？”“哪一步最容易出错？”“如果系统不可用，你会怎么做？”

避免诱导性提问，如“如果有批量导出是不是会方便很多”。这句话暗示了答案，也把用户带进方案讨论。更稳妥的问法是：“你最后怎样把记录交给财务？”“中间有没有重新整理或补字段？”“哪一项最影响按时完成？”

3. 第三步：观察实际操作和绕行办法

用户的口头描述可能遗漏重复操作、切换窗口和临时协作。条件允许时，请用户演示任务，而不是让产品经理凭记忆复述。观察者记录操作步骤、等待时间、失败恢复、外部工具和求助行为；不要只记“觉得麻烦”这类结论。

观察也要尊重权限和隐私。涉及客户信息、财务记录或个人数据时，应使用授权环境、脱敏样本和最小必要记录。研究资料要限定访问范围，并在报告中说明样本与数据处理方式。

4. 第四步：把场景写成结构化句子

场景句式可以帮助团队补齐要素，但不要为了填满模板而编造细节。一个实用结构是：“当【角色】在【触发条件】下需要完成【任务】时，因为【当前阻碍或约束】，所以会采取【现有做法】，造成【可观察后果】；若成功，应该能够【目标结果】。”

以订单复核为例，可以写成：“当区域运营在每周关账前整理异常退款时，需要筛选并交付符合条件的记录；目前查询条件无法复用，导出字段也不稳定，因此运营需要手工补表并逐条确认；成功标准是财务能依据统一字段完成复核，运营能够定位未处理记录。”这句话仍需数据验证，但已能把讨论从按钮转向任务。

5. 第五步：补充例外、权限和失败路径

场景不只描述顺利流程，还要记录任务失败时会怎样。筛选结果为空怎么办？导出数据过大怎么办？权限不足时用户看到什么？部分记录处理失败时能否重试？用户误操作后能否撤回？这些问题不一定都要在首版解决，但必须知道它们的风险和取舍。

可以按发生概率和后果严重程度筛选边界情况。高概率、低影响的情况适合做清晰提示；低概率、高影响的情况可能需要防护、审计或人工兜底。不要把所有极端情况都做成复杂功能，也不要把高风险情况藏进“后续优化”。

6. 第六步：形成待验证假设，而不是直接跳到功能清单

场景梳理后，至少提出一个解决假设和一个反证条件。例如：“保存筛选条件能减少周度复核的重复操作”；反证条件可以是“用户主要耗时其实在确认字段和追踪状态，保存筛选条件无法明显缩短总任务时间”。有反证条件，团队才知道什么结果意味着方案不成立。

方案可以并列比较：保存查询、定时报告、批量导出、复核工作台。对比时要看能解决哪个问题、依赖什么数据或权限、实施成本多大、失败风险是什么。不要只比较开发工时，还要考虑长期维护、用户学习、权限治理和迁移成本。

7. 第七步：用小规模测试验证关键行为

在投入完整开发前，可以用低保真原型、人工服务或受限灰度验证关键假设。比如先让一组运营使用固定字段模板，观察是否减少返工；或者用可点击原型测试用户能否找到筛选条件。测试的重点不是问“你喜不喜欢”，而是观察用户能否完成任务、在哪里犹豫、是否采用替代路径。

样本不必一味追求大，但必须覆盖关键差异。如果产品面向多种角色，就不要只测试最熟悉系统的管理员；如果任务发生在移动端和桌面端，就要在真实设备和环境中验证。测试结果应记录样本条件，避免将小范围发现泛化到全部用户。

8. 第八步：上线后按原场景复盘

上线不是需求结束，而是验证场景判断是否正确。沿用前期定义的任务结果指标，观察使用覆盖、任务完成率、错误率、人工处理时长和求助量。若点击量上升而任务时间不变，说明功能被看见但未必解决问题；若只有少数管理员使用，也要检查权限、培训和触发时机。

复盘时同时寻找副作用：是否增加了不必要的通知，是否让数据导出范围过宽，是否把原来的手工错误转移成新的审批等待。一个需求只有在用户结果改善、风险可控且维护成本合理时，才算真正完成。

六、案例拆解：把“做一个看板”还原成真实决策场景

1. 原始请求与初步判断

某业务负责人提出：“希望做一个运营看板，最好能展示订单量、退款率和处理时长。”这句话包含了三个指标和一个方案，却没有说明谁每天看、看完做什么、发现异常后由谁处理。此处案例为情景模拟，重点是展示如何拆解，而不是引用某企业实际经营结果。

如果产品经理直接安排页面设计，结果很可能是把指标铺在大屏上。看板上线后访问量不低，但团队仍然通过群聊确认异常，说明产品满足了“看见数据”，没有满足“采取行动”。

2. 追问之后发现的三类场景

进一步拆解后，可能发现三种工作：值班人员每天早上检查异常订单，区域负责人每周比较门店表现，管理者在月度复盘时看整体趋势。三类角色的决策时间、数据粒度和下一步行动不同，不宜直接合并为一张通用看板。

值班人员更关心需要马上处理的异常和责任归属；区域负责人需要比较门店、发现变化并追踪整改；管理者更关注趋势、原因和目标偏差。若页面只展示总量，值班人员无法定位问题，负责人无法找到变化来源，管理者则可能得到过度细碎的信息。

3. 从“展示指标”改为“支持决策”

我会先把看板拆成三个任务视图，而不是先定页面布局。异常处理视图需要筛选、分派和状态更新；区域比较视图需要时间范围一致、口径一致、可下钻；管理复盘视图需要趋势和目标对照。每个视图都应回答一个具体决策问题，而不是把所有可用数据都塞进来。

接着定义数据口径：订单处理时长从哪个事件开始计时，退款率的分母包括哪些订单，跨门店比较是否排除停业日期，异常阈值如何设置。指标口径不一致时，图表画得再漂亮，也会让不同角色得出相反结论。

4. 验证结果要包括业务动作，不只是页面访问

在情景模拟中，可以先观察值班人员能否从异常列表找到待处理订单、分派责任并更新状态；再观察负责人能否在周会上定位变化门店和原因。对管理者，则验证数据口径是否被接受、趋势判断是否会触发后续行动。页面浏览量可以作为使用信号，但不能代替决策质量。

如果首轮测试发现用户只看总量、不点进明细，团队应追问是明细入口难找、异常定义不可信，还是用户根本不需要在该页面处理。不同原因意味着不同改法。此时直接增加更多图表，往往只会提高页面复杂度。

七、不同情况下的行动建议：研究深度要匹配风险和不确定性

1. 高频、低风险、已有明确证据

如果问题经常发生、影响可控，并且用户行为与日志都指向同一阻碍，可以快速做低成本方案验证。此时不必为每个小功能组织大型调研，但仍要写清目标用户、核心场景和回滚条件。对于成熟流程上的小改动，重点是避免影响原有高频路径。

例如，用户每次都要重新设置相同筛选条件，且系统记录显示重复查询明显，可以先测试保存筛选方案。上线范围先控制在目标用户群，观察复用率、任务完成时间和错误情况，再决定是否扩大。

2. 高频、高风险或跨团队协作复杂

涉及钱款、权限、客户承诺、合规记录或跨部门交接时，不能只凭高频就快速上线。需要补充边界场景、操作留痕、权限矩阵、异常处理和责任归属。风险越高，验收越应覆盖失败路径，而不是只验证理想流程。

如果一个操作会改变多个团队共享的数据，应先画清数据所有权和审批关系。产品经理要让业务、技术、安全及运营对关键约束达成一致，避免开发完成后才发现不同团队对“谁可以操作”有不同理解。

3. 需求声音很大，但证据薄弱

对于高声量、低证据的需求，最合适的下一步往往不是拒绝，也不是承诺，而是做定向验证。挑选真正执行任务的人，观察近期行为，比较不同用户组的差异，再用原型或人工服务验证是否有实际收益。

也要检查反馈来源是否集中。例如，多个请求可能来自同一位关键客户的不同联系人，或来自销售团队对客户诉求的转述。反馈数量不能简单等同于独立样本数量，产品经理需要识别请求的来源链和重复关系。

4. 低频但高后果的场景

低频任务容易在产品规划中被忽略，但涉及事故恢复、账务纠错、权限撤销或数据导出审计时，发生概率低不等于没有价值。此时可以关注风险暴露、损失上限和恢复能力，而不是只看月活或点击量。

若无法通过产品功能彻底消除风险，可以设计预警、审计、人工兜底和明确的恢复步骤。面对极少发生但后果严重的事件，完整可恢复通常比追求极简界面更重要。

5. 资源紧张、无法立即开发

资源受限时，仍然可以改善需求判断。用人工流程、操作指南、表格模板或服务团队代办，验证任务是否值得产品化；如果人工试验都无法改变任务结果，昂贵的自动化未必会带来预期收益。

人工验证也有边界：它可能隐藏系统自动化后的权限、规模和错误问题。因此，人工方案适合验证用户价值和流程，不适合证明高并发、复杂权限或长期运维能力。产品经理要把验证结论限定在被测试的范围内。

八、不同情况下的取舍：先解决主要矛盾，不追求场景大而全

1. 取舍用户覆盖与场景深度

首版既想覆盖所有角色，又想把每种流程都做深，往往会导致范围失控。可以选择一个高价值、证据清晰、边界可控的核心场景先做完整闭环，同时明确哪些用户暂不覆盖。明确不覆盖范围不是忽视用户，而是避免承诺无法兑现的通用方案。

当多个群体的任务确实高度相似，可以共享底层能力；但角色权限、默认视图、任务入口和验收条件仍可能不同。共享能力不等于强迫所有用户使用同一个界面或流程。

2. 取舍立即交付与深入验证

如果机会窗口短、失败成本低，可以采用快速验证并设置回滚；如果决策影响资金、合规或大量用户习惯，就应投入更多研究与测试。关键不是“研究越多越专业”，而是让验证成本与错误决策的代价相匹配。

评审时可以直接说明不确定性：哪些结论已由行为证据支持，哪些仍是团队假设，哪些风险暂时无法验证。把不确定性公开，能帮助决策者选择先做小范围试点，还是接受风险进入开发。

3. 取舍个性化与一致性

不同团队的流程差异很大时，个性化配置能提高适配度，却也会增加配置复杂性、测试组合和维护成本。若差异只是展示偏好，可以考虑轻量设置；若差异涉及审批、权限或数据定义，就需要治理机制，而不应把所有规则都交给用户自由配置。

产品经理要区分“用户希望自己决定”和“产品必须支持差异”。可以先观察差异是否稳定、是否跨组织重复、是否影响任务结果，再决定做系统配置还是提供约定好的默认流程。

4. 取舍自动化与人工控制

自动化可以减少重复劳动，却可能在规则不清时放大错误。对于可逆、低风险、判断标准明确的任务，可以优先自动化；对于高后果、规则变化频繁或需要专业判断的步骤，适合保留确认、抽样复核或人工兜底。

不要把“自动化率”当作唯一成功指标。还要观察误处理率、回滚成本、人工复核耗时和用户对结果的信任。自动完成得越多，不一定代表用户越安全或业务越高效。

九、把场景变成团队协作语言：需求文档与评审的实用模板

1. 一页场景卡应包括什么

文档不必越长越好，但要让产品、设计、研发、测试和业务围绕同一事实讨论。一张场景卡可以保留请求来源、目标用户、触发条件、任务目标、当前做法、核心阻碍、证据、约束、成功标准和待验证假设。

• 请求来源：谁提出、从何渠道提出，是否存在重复转述。
• 目标用户：实际执行任务的人，而不只是购买者或管理者。
• 触发条件：任务何时发生，由什么事件或业务周期触发。
• 当前做法：用户现在怎样完成任务，包括系统外的工具和协作。
• 核心阻碍：耗时、错误、等待、权限限制或信息不一致。
• 证据来源：访谈、观察、日志、工单、实验或业务记录。
• 目标结果：任务完成后用户或业务发生什么可观察变化。
• 边界与风险：不覆盖谁、哪些异常需要处理、有哪些敏感数据。
• 待验证假设：当前最不确定、且会影响方案选择的判断。

2. 评审会议要讨论判断，不要逐字朗读文档

会前把场景卡发给参与者，会议中优先讨论三个问题：证据是否足以支持问题判断、方案是否解决核心阻碍、验收能否观察到用户结果。若团队争论界面布局，却还没有统一任务定义，应先回到场景，而不是让每个人各自带着不同假设继续设计。

对于有争议的结论，记录反对意见和补证任务。反对意见不必在会议里被“说服掉”；如果它指出重要边界或相反证据，应该进入验证计划。好的评审不是让所有人当场同意，而是让团队清楚下一步需要证明什么。

3. 建立从问题到上线数据的追踪关系

需求上线后，团队应能从指标回到场景，从场景回到证据。比如，某功能使用率低，不能只得出“用户不需要”；还要检查触发条件是否出现、入口是否可见、权限是否覆盖目标用户、当前任务是否已被其他方案解决。

这条追踪关系还能减少“功能交付即成功”的偏差。若目标是减少重复操作，就保留上线前基线、目标用户范围和测量方式；若目标是降低漏处理风险，就关注遗漏率、追踪闭环和异常恢复，而不是只看页面停留时间。

十、结尾：场景做得好，团队才知道什么时候不该做功能

产品需求如何做好场景，核心不是把用户故事写得更像模板，而是让团队从真实任务出发，分清观察事实、问题解释和解决方案，并且知道哪些结论仍待验证。场景既要具体到角色、触发条件、约束和结果，也要足够开放，允许原先设想的功能被更合适的方案替代。

我建议下一步就拿一条正在排期的需求做练习：先保存用户原话，再找到最近一次真实任务，补齐当前做法、失败代价和成功标准；随后列出最关键的一项不确定性，用访谈、观察、日志或原型测试验证。不要一开始追求完整文档，先把最可能导致错误投入的假设找出来。

一个好场景最终应当同时帮助团队做三件事：判断问题值不值得解决，选择哪种方案更适合当前约束，以及上线后如何证明用户真的受益。如果它只能解释功能是什么，却不能帮助团队做出取舍，那它还不是一个足以指导产品决策的场景。