01先定义真正的问题
评审不是收集更多意见，而是把分散信号压缩成一个可以被验证的判断。
1.1 三个判断维度
用户价值
问题是否高频、明确，并且值得用户改变现有习惯。
业务杠杆
方案是否推动留存、效率或收入，而不只是增加功能数量。
交付把握
团队是否拥有足够证据、能力和时间把承诺兑现。
一个清晰的问题陈述，应该让团队知道现在不做什么。评审原则
1.2 证据清单
- 用户信号
访谈、行为数据与支持请求中的重复模式。
- 业务约束
目标、成本、合规边界与时间窗口。
- 成功标准
上线前约定可观察的领先指标和停止条件。
02把选择放在同一张桌面上
比较方案时保持相同的评价维度，避免一个方案谈愿景、另一个方案只谈成本。
2.1 方案比较
| 方案 | 用户价值 | 实施复杂度 | 优先级 |
|---|---|---|---|
| 优化现有路径 | 高 | 中 | P0 |
| 增加引导层 | 中高 | 低 | P1 |
| 重建完整流程 | 高 | 高 | P2 |
示例数据仅用于展示正式评审文档的层级与组件。
意见驱动
先讨论偏好，再寻找能够支持偏好的理由。
证据驱动
先约定判断标准，再用相同证据比较不同方案。
2.2 形成决策记录
- 01收集信号保留来源与时间
- 02提出假设明确尚未验证的部分
- 03比较方案使用同一组标准
- 04记录决定写清负责人和复盘时间
Decision
结论必须同时包含选择、理由、风险与下一次重新判断的条件。