06 真需求不是用户说的话

专业解读

这张图片使用三层结构说明战略需求、用户需求和产品需求之间的关系。战略需求关注业务目标与长期价值，用户需求关注真实场景中的困难与动机，产品需求关注具体功能、流程和实现方式。右侧的行为数据、付费意愿、留存复用和 MVP 反馈提供验证方向，底部流程把用户提出的方案转化为持续研究与验证任务。

产品经理需要理解用户表达的内容，也需要观察表达背后的工作过程。一个按钮建议可能对应信息获取困难、重复操作、责任不清楚或结果确认成本。研究的目标是说明这些问题发生的条件、影响和已有处理方法，并判断怎样改善完整任务，使产品方案拥有可以追踪的依据。

一、战略需求需要连接组织目标

战略需求回答组织为什么投入资源，以及希望取得什么业务结果。产品经理需要与业务负责人讨论目标用户、任务范围、价值方向和资源条件，确认当前问题与组织目标之间的联系。目标应当能够进入实际任务和结果检查，帮助团队判断哪些研究与设计工作值得开展。

战略材料可以包含业务背景、现有流程、问题影响和预期变化。讨论中需要区分已经确认的事实与仍然等待验证的假设，说明由谁提供证据以及谁负责最终判断。需求研究可能发现目标条件发生变化，产品经理应及时把相关信息带回业务讨论，使组织决策能够根据实际情况持续调整。

二、用户需求需要理解场景与动机

用户需求关注用户在真实场景中希望完成什么，以及当前遇到了什么困难。产品经理需要观察任务发生的时间、地点、参与角色、信息条件和工作流程。访谈应结合具体事件，让用户说明最近一次怎样完成任务、哪里需要额外处理以及采用了什么方法，从而获得可供核验的研究线索。

动机研究还需要理解用户为什么重视这个结果。时间压力、质量要求、协作责任和工作环境，都可能影响需求的重要程度。不同用户表达相似的功能建议，背后的任务与限制可能存在差异。研究材料应记录这些条件，并通过实际观察和业务记录核验，帮助团队形成准确的用户问题说明。

三、产品需求需要形成可验证的方案

产品需求描述团队准备提供什么功能、流程和信息结构，以及方案需要满足哪些质量要求。它应连接已经确认的问题，说明如何改善用户任务。设计材料需要包含角色、输入、处理、输出、状态变化和异常情况，使工程、测试和运营人员能够理解方案怎样进入真实工作。

同一个用户问题可能存在多种解决方式，产品经理需要说明各方案的价值、投入、依赖和使用条件。对于 AI 产品，还应检查模型能力、知识资料、人工确认和系统接入条件。把这些条件写进需求与验收材料，可以帮助团队通过实际使用和场景评测判断方案是否达到预期。

四、追问需要围绕具体事件展开

图中的追问环节强调持续理解用户提出方案的原因。产品经理可以询问任务目标、当前操作、遇到的困难和问题影响，并请用户描述实际发生的情况。问题应帮助用户补充事实，避免引导对方认可预设方案。研究过程也应给用户充分表达的空间，记录仍然需要进一步核验的内容。

追问可以沿着任务流程展开：信息怎样获得，谁需要处理，结果怎样确认，什么情况下会出现问题，以及发生问题之后怎样补救。对于机构场景，还需要理解其他角色与系统的影响。完整的问题链能够帮助团队识别用户表述中的方案、真实任务中的困难以及组织条件中的限制。

五、行为证据需要说明适用范围

行为数据可以帮助观察用户怎样进入任务、完成操作、采用结果和重复使用，但数据必须具备清楚的定义与采集条件。产品经理需要理解记录覆盖哪些对象、哪些过程，以及数据缺失会影响什么判断。行为观察应与访谈和业务记录共同使用，使分析能够解释用户行为发生的实际条件。

付费意愿、持续使用和结果采用情况，可以提供不同方面的需求证据。面向机构的产品还需要理解采购审批、预算安排和服务责任，确认使用意愿与采购条件之间的关系。单个行为指标需要结合任务价值和环境解释，研究材料应说明它支持哪些结论，以及哪些问题仍然需要补充证据。

六、优先处理明确且重要的问题

图中的痛点优先强调聚焦高频和高价值问题。产品经理需要说明问题出现的情况、影响范围、处理成本和失败后果，并结合组织目标判断重要程度。频繁出现的操作困难需要研究其累计影响，发生次数较少的重要风险也需要结合业务责任讨论，保证排序依据能够反映真实任务价值。

问题排序应保留研究证据、判断条件和相关人员的意见。对于医疗工作流程，产品经理需要与专业人员共同确认质量、安全和责任要求，避免仅从操作时间判断价值。排序结果应能够解释当前准备处理什么问题、为什么投入资源以及怎样验证改善效果，让团队围绕清楚的问题开展工作。

七、MVP 验证需要明确范围与标准

MVP 可以帮助在限定场景中验证关键假设。验证计划需要说明目标用户、实际任务、方案范围、参与条件、观察指标和结束后的判断方式。产品经理应确认参与人员能够理解当前能力范围，并提供必要的培训与问题反馈渠道，使验证过程能够产生真实、有用的使用证据。

验证记录需要覆盖任务完成情况、失败案例、额外人工处理和用户反馈。对于模型参与的任务，还应保存输入条件、知识来源与确认过程，帮助团队解释效果变化。验证结束后，应组织业务与工程人员共同评估结果，说明哪些假设得到支持、哪些需要继续研究，以及后续方案应怎样调整。

八、把需求证据保存为持续档案

需求档案可以按照问题来源、用户任务、研究材料、判断依据、产品方案和验证结果组织。每条需求需要能够追踪到具体的证据与责任人员，并记录使用条件和结论范围。需求发生变化时，应更新相关判断与验收安排，让后续团队能够理解变化怎样影响业务目标和产品范围。

图中的行动验证提醒我们，研究与交付需要形成连续联系。产品经理应持续检查方案是否解决最初的问题，用户是否能够稳定采用结果，以及新的使用条件是否带来不同需求。通过保留这些证据，团队可以减少无依据的功能扩张，并逐步提高识别问题、组织方案和验证价值的能力。

工作检查时，可以逐项确认需求是否有明确对象、真实场景、可追踪证据和可验证结果。对于仍然存在疑问的部分，应写出研究问题与验证安排，并由相应人员负责处理，使需求判断始终具备清楚的工作依据。