产品管理规范

探索（Discovery）

• 每周与用户交流——不仅限于项目启动阶段
• 观察用户行为，而非仅收集观点——用户常说一套、做一套
• 先验证问题，再验证方案——我们是否在解决正确的问题？
• 待完成的工作（Jobs to be Done）：用户真正试图达成的目标是什么？
• 竞品揭示的是“可能性”，而非“应复制的对象”

优先级排序（Prioritization）

• 影响 vs 投入仅是起点，而非最终答案
• 说“不”的频率应高于说“是”——聚焦本身就是一项功能
• 区分紧急与重要——利益相关方的压力不等于优先级
• 严格进行优先级堆叠排序（Stack rank）——“所有事项都是 P1”意味着没有任何事项是真正优先的
• 当上下文发生变化时及时重新评估优先级——至少每季度一次

路线图（Roadmapping）

• 关注成果（Outcomes），而非交付物（Outputs）——关注“什么将发生改变”，而非“我们将构建什么”
• 时间维度：当前（已承诺）、下一步（已规划）、后续（有可能）
• 坦诚沟通不确定性——路线图不是承诺
• 尽早暴露依赖关系——被阻塞的工作会浪费所有人的时间
• 当现实发生变化时及时更新路线图——过时的路线图将摧毁信任

需求（Requirements）

• 用户故事需明确：谁（Who）、做什么（What）、为什么（Why）——不规定如何实现（How）
• 验收标准定义“完成”——模糊性将导致返工
• 边缘场景需前置处理——不应留到 QA 阶段才发现
• 范围蔓延是大敌——“现在足够好”优于“将来完美”
• 技术约束真实存在——须与工程团队协作，而非绕过他们

与工程团队协作

• 提供背景信息，而非仅下达指令——解释“为什么”，而不仅是“做什么”
• 权衡取舍（Tradeoffs）应为协同决策
• 在冲刺开始前完成方案设计（Spec），而非冲刺中临时设计——拒绝边做边想
• 保护专注时间——会议会破坏心流（Flow）
• 信任工程师的预估；对范围提出质疑，而非对工期施压

与设计团队协作

• 共同开展研究，而非仅交付设计简报（Brief）
• 针对设计方案提出批评，而非针对设计师本人
• 邀请真实用户参与设计评审，而不仅限于利益相关方
• 移动端适配与边缘场景需前置考虑——不可作为事后补充
• 设计系统（Design System）可提升交付速度——应主动支持其建设与演进

利益相关方管理

• 定期同步进展，防止突发性需求
• 数据可平息基于主观意见的争论
• 清晰阐释各项权衡，而非仅辩护已有决策
• 建立顺畅的反馈渠道以避免绕过流程（End-runs）——让输入变得简单易行
• 重大举措需配备高管发起人（Executive Sponsors）

指标（Metrics）

• 设定 1 个北极星指标（North Star Metric），辅以 2–3 个支撑性指标
• 重视领先指标（Leading Indicators）以获取早期信号——勿只等待滞后指标（Lagging Metrics）
• 仪表盘（Dashboards）应能引发思考与提问，而不仅是罗列数字
• 虚荣指标（Vanity Metrics）虽令人愉悦，但无法驱动有效决策
• 当数据优于直觉时，务必执行 A/B 测试

上线（Launch）

• 灰度发布（Soft Launch）可在规模化前发现潜在问题
• 上线前即明确定义成功标准——而非上线后补定
• 上线前必须制定回滚方案（Rollback Plan）
• 跨职能上线核对清单：文档、客服支持、市场推广等
• 上线后复盘：哪些做得好，哪些存在问题

常见错误

• 功能工厂（Feature Factory）：持续交付却缺乏学习与验证
• 过度细化需求（Overspeccing）：扼杀工程师的自主性
• 追求共识（Consensus Seeking）：通过委员会机制做决策
• 忽视定性研究：单靠数据无法揭示“原因”
• 将路线图当作待办列表（Backlog）：事无巨细全写入，却无任何承诺