需求承接十问
产品经理接手一个需求时，按背景 → 目标 → 用户与场景 → 范围 → 业务规则 → 数据指标 → 技术影响 → 优先级 → 交付验收 → 风险边界十个维度逐项问清楚的提问清单。它的目标不是写一份更厚的 PRD，而是把”我要一个功能”翻译成”谁的什么问题、为什么现在做、做到什么程度算成功”，让 PM 从需求传声筒变成能提前识别风险的决策者。
简介
需求承接十问来自简谙在 2026-06-26-205707-tg-f6dca0 中总结的方法论。它的起点是一句几乎人人都听过的话——“这个很简单，你帮我加个功能就行”。作者指出，很多需求事故都从”很简单”起头：前面没人把问题问清楚，后面就变成研发问”规则是什么”、测试问”异常怎么处理”、老板问”为什么做完没效果”。
这套清单要替代的是 PM 的默认动作：接到需求就急着翻译成页面和按钮。作者给出的替代动作是”先问清楚：它到底解决谁的什么问题，为什么值得做，做到什么程度才算成功”。十个问题覆盖的正是这三句话展开后的全部信息面——前十问中，第 1 问拆背景来源，第 2 问定业务/用户价值与指标，第 3 问锁定角色与场景，第 4 问划本期范围，第 5 问抠业务规则，第 6 问定数据与指标口径，第 7 问评估技术影响与回滚，第 8 问算投入产出与 MVP 拆解，第 9 问对齐验收人与验收标准，第 10 问前置四类风险。
它与其他需求方法论的分工很清晰：需求真伪识别（四问）回答”该不该做”，十问的第 1 问回答”该不该现在做”；产品需求分析 的三要素（症状→偏方→病因）是十问里”先问背景”那一步的深度诊断工具；需求池管理 是十问跑完之后需求该落进去的地方。三者构成”结构化采集 → 真伪过滤 → 深度诊断 → 入库维护”的连续动作，而十问是这条链最前端的输入采集器。
关键信息
- 类型：方法论 / 需求澄清提问清单（Checklist）
- 领域：产品管理、需求工程、B 端产品交付
- 出处：2026-06-26-205707-tg-f6dca0（作者 简谙，人人都是产品经理，2026-06-24）
- 核心问题：如何在需求进入排期之前，把模糊的一句话需求问成可讨论、可开发、可验收的需求输入
- 核心判据：第 1 问的”为什么现在必须做”——“很多需求不是不能做，而是不该现在做”
- 关联方法：需求真伪识别（该不该做）· 产品需求分析（病因诊断）· 需求池管理（入库与淘汰）· 需求冷冻机制（暂不做的解冻条件）
- 适用角色：新人 PM、从其他岗位转岗的 PM、需要同时面对业务/研发/测试/老板的 B 端 PM
核心特性
十个维度的提问清单（可直接照用）
- 背景：这个需求从哪里来？当前具体有什么问题？为什么现在必须做？
- 目标：业务价值与用户价值分别是什么？上线后想让哪个指标变好？用户现在卡在哪里？
- 用户与场景：用户是谁（C 端/运营/销售/客服/管理员/商家/老板）？什么时间用？从哪个入口进？当时在完成什么任务？高频刚需还是低频重要？
- 范围：本期解决什么？明确不做什么？涉及多端、多角色、多地区、历史数据兼容吗？
- 业务规则：条件、状态、计算方式、限制、优先级、失败/超时/重复提交/撤销/驳回/误操作、功能权限 vs 数据权限、通知渠道。
- 数据指标：采集哪些数据？要不要埋点/报表/看板/导出？指标口径怎么定义？是否与历史对比？隐私合规要求？
- 技术影响：改哪些系统/模块？依赖哪些第三方（接口、数据中台、支付、消息、CRM、ERP）？性能、稳定性、容量？灰度、开关、回滚？部署形态（SaaS/本地化/政务云）？
- 优先级：预估收益是否匹配研发/设计/测试/运营成本？有没有更轻量的替代方案？能否拆成 MVP 先验证核心价值？
- 交付与验收：上线时间？谁是最终决策人？谁验收？验收标准（功能可用/指标达成/流程跑通/客户确认）？是否需要培训、公告、客服话术、帮助文档？
- 风险边界：业务风险（规则争议、投诉、运营成本）、技术风险（接口稳定性、数据一致性、性能）、合规风险（隐私、支付、合同、内容审核、监管）、协作风险（排期冲突、资源）。
三个可复用的执行技巧
- “暂不做”要写理由与解冻条件：不要只写”暂不支持”，而要说明”为什么暂不做 + 什么条件下再考虑”，例如”本期只支持运营后台手动配置，不做用户端自助修改，因为当前主要验证运营策略是否有效；若使用率超过 X，再评估用户自助能力”。这样写能减少扯皮，也让开发提前预留口子。
- 一个词要往下拆一层：“支持审批”背后是待处理/处理中/已通过/已驳回/已取消/已撤回/已过期的一整套状态机，以及每个状态能否编辑、能否再次提交、通知谁、数据算在哪一天、权限变了历史单据怎么办。
- “体验优化”不能当万能胶：遇到这类回答要继续追问”用户少点几步？少等多久？少问几次客服？“，把目标问细才有验收依据。
不同素材中的观点
- 2026-06-26-205707-tg-f6dca0：这篇素材是十问的原创出处。它主张需求承接的本质是接责任而非记录信息——只把需求承接理解成”记录别人说了什么”，PM 就会变成传话筒（业务说一句我写一句、研发问一句我再回去问一句、测试发现口径不清再临时补一句）。它同时给出两条关键纪律：其一，PM 不是需求收纳箱；其二，“上线不是剪彩仪式，上线是系统开始接受真实世界的暴打”，所以技术影响与回滚必须前置。素材还提供了一个反面案例：一位来者不拒的新人 PM 把系统越做越重，最终影响大部分客户的正常业务流程，被迫叫停瘦身。
实用信息
- 快速上手步骤：
- 常用提问话术：
- “这个功能，具体是为了解决谁的什么问题？”
- “为什么现在必须做？现在不做会怎样？”
- “这个功能上线后，到底想让哪个指标变得更好？”
- “本期明确不做什么？什么条件下我们再做？”
- 注意事项/避坑指南：
- “用户”二字的指向必须锁定到具体角色，否则多角色场景会被一个导出按钮掩盖（运营要趋势、销售要筛选、财务要核对金额、管理者只看汇总）；
- 提需求的人、决策人、使用人、验收人常常是四个不同的人，只对齐其中一个就会经历”重新理解需求”；
- 十问是采集清单不是判决书，问完之后仍需 产品需求分析 做深度诊断，避免把”问全了”误当成”想透了”。