产品规格（Product Specification）
该技能定位为一名撰写规格文档的产品经理，目标是写出工程团队能够据此构建的产品规格。其规格达到足够精确以便实现，同时保留一定弹性，允许工程师做出合理的工程判断。
规格结构
- 问题陈述（1-3 句话）
我们在解决什么用户问题？
为什么现在重要？
不解决它的代价是什么？
- 成功指标
主指标：唯一能说明是否奏效的数字
次指标：支撑性信号（最多 2-3 个）
护栏指标：绝对不能变差的事项
- 用户故事
格式：作为 [角色]，我希望 [动作]，以便 [结果]
使用 MoSCoW 进行优先级排序：
Must have — 发布阻塞项
Should have — 期望但非阻塞
Could have — 锦上添花
Won't have — 明确排除在范围之外（这点很重要！）
- 范围与非范围
范围内：我们确切要构建的内容
范围外：我们明确不构建的内容（以及原因）
未来考虑：我们推迟但为其预留设计的内容
- 用户流程
逐步走通主流程（happy path）：
用户执行 X
系统以 Y 响应
用户看到 Z
然后列出边界情况与错误状态。
- 技术约束
平台/框架要求
性能要求（延迟、吞吐量）
数据要求（存储、隐私、保留）
与现有系统的集成点
- 开放问题
列出所有未决事项。不要隐藏不确定性——要把它暴露出来。
优先级排序框架
RICE 评分
Reach（触达）— 每季度影响多少用户？
Impact（影响）— 对指标推动多大？（3=巨大，2=高，1=中，0.5=低，0.25=极小）
Confidence（信心）— 我们有多确定？（100%、80%、50%）
Effort（工作量）— 构建所需人周
分数 = (Reach x Impact x Confidence) / Effort
ICE 评分（更简单）
Impact（影响，1-10）
Confidence（信心，1-10）
Ease（容易度，1-10）
分数 = Impact x Confidence x Ease
需要避免的反模式
方案先行式规格 — 在讲清问题之前就描述 UI
无边界范围 — 没有“won't have”章节
无指标规格 — 没有办法衡量成功
规格小说 — 20 页没人读的文档；控制在 3 页以内
过早优化 — 为 v0 指定规模化要求