产品做什么 · 为什么做 · 验证什么

每个阶段要回答的问题不同，也要事先定下什么情况下继续、暂停或退回。上一阶段没有查清的事项可以带到下一阶段，但原型做得漂亮，不能证明问题真实存在；已经投入开发，也不能反过来证明产品判断正确。

立项判断

说明为什么现在值得投入、服务谁，以及不处理会付出什么代价。

问题验证

确认真实任务、现有做法、发生条件和问题影响。

方案验证

用范围可控的试验检查价值、可用性和关键风险。

工程设计

把已确认的对象、流程、规则、异常和验收条件交给工程。

先写清为谁解决问题、问题在什么情况下发生、现在付出什么代价、还有哪些替代办法，以及为什么值得投入。团队也要事先约定，希望改变什么，出现什么结果就停止投入。

政策变化、技术进步、组织调整和一线需求都可能带来机会，但最终必须落到具体问题和具体承担者。只说一个热门趋势，不能成为立项理由。

先请使用者回到最近一次真实经历：事情怎么发生，他拿到什么信息，经过哪些步骤，在哪里等待、返工、求助或放弃。访谈中说出的偏好，还要和实际行为记录对照。

还要记下现在怎样解决：用表格、聊天、电话、纸面登记，还是靠人协调。新产品要算两笔账：能省下什么，又会增加多少学习和切换成本。

先分清谁发起、谁办理、谁审核、谁查看结果，再梳理他们共同处理的业务对象、字段和状态。角色和对象没有理清，页面很容易按部门名称堆成一排菜单。

除了顺利办完的主流程，还要考虑资料缺失、审核退回、重复提交、转交失败和权限不足。系统怎样发现问题、谁来处理、从哪一步恢复，都要在产品定义中写清。

要核对问题在什么情况下发生、影响多大、现在付出什么代价、使用者是否愿意改变。观察、访谈、历史记录和小样本数据可以相互印证，不能拿一次强烈意见概括所有情况。

证据还不够，就把判断写成假设，并注明下一步要观察什么。把问题、使用者和预期价值查到足以作当前决定时，再比较解决办法。

最小可行产品（MVP）先验证风险最高的假设。可以用原型核对自己是否理解了问题和流程，也可以暂时保留人工环节，先看数据和判断是否有用。

试验前要写清覆盖哪些人、观察哪些指标、出现什么结果就停止。结论只适用于实际试过的场景，一次演示不能作为全面上线的依据。

开始工程设计前，要交接已经确认的问题、目标使用者、核心对象、正常流程与异常情况、范围、验收条件、未决事项和明确不做的内容。技术团队据此讨论数据、权限、接口和运行限制。

试验结果与预期不符，就先修改问题定义、范围或方案。增加功能需要新的理由和验证，不能因为已经开发了很多，就回避前面的判断有误。