产品管理准则

需求探索

• 每周与用户交流——而非仅在项目启动时
• 观察行为而非收集观点——用户言行常不一致
• 先验证问题再验证方案——我们是否找准了关键？
• 聚焦用户目标：用户究竟想达成什么？
• 竞品展示可能性，而非提供复制模板

优先级排序

• 投入产出比仅是起点，而非最终答案
• 拒绝比接受更重要——专注本身就是产品特性
• 区分紧急与重要：利益相关方的压力不等于优先级
• 严格进行堆栈排序——"万物皆P1"等于没有优先级
• 情境变化时重审优先级——至少每季度一次

路线规划

• 成果重于产出——关注改变而非功能堆砌
• 时间维度：当前（已承诺）/近期（计划中）/远期（可能性）
• 坦诚沟通不确定性——路线图不是承诺书
• 依赖关系要尽早暴露——受阻的工作会浪费所有人的时间
• 现实变化时及时更新——过时的路线图会破坏信任

需求

• 用户故事：描述"谁"、"什么"、"为何"——而非"如何"
• 验收标准定义完成——模糊性会导致返工
• 边界情况要预先处理——而非在质量保证阶段才发现
• 范围蔓延是大敌——当下的够用好过未来的完美
• 技术限制真实存在——要与工程团队协作，而非回避

与工程团队协作

• 提供背景而非指令——解释"为何"，而非仅说明"是什么"
• 权衡取舍是共同决策
• 规范要在迭代前确定，而非中途——避免临时设计
• 保护专注时间——会议会打断心流状态
• 信任他们的估算，调整范围而非时间

与设计团队协作

• 共同研究，而非仅交接简报
• 对事不对人——评价作品而非设计师
• 设计评审要包含用户，而非仅限利益相关者
• 及早考虑移动端和边缘情况——而非事后补救
• 设计系统提升效率——请予以支持

利益相关方管理

• 定期更新可避免突发需求
• 数据平息观点之争
• 阐明权衡取舍，而非单纯辩护决策
• 建立反馈渠道避免越级沟通——让意见提交更便捷
• 重大项目需配备高管发起人

指标管理

• 一个北极星指标，辅以两至三个支撑指标
• 关注先导指标获取早期信号——无需等待滞后指标
• 仪表板应引发思考，而非仅展示数字
• 虚荣指标令人愉悦，但无助于决策
• 当数据优于直觉时，进行A/B测试

产品发布

• 小范围试运行可在全面推广前发现问题
• 成功标准应在发布前确定——而非事后
• 制定发布方案前先规划回滚预案
• 跨职能检查清单：文档、支持、营销
• 项目发布后复盘：成功之处与不足之处

常见错误

• 功能工厂模式：只交付产品而不汲取经验
• 过度细化需求：扼杀工程自主性
• 寻求共识：委员会式决策
• 忽视定性分析：仅凭数据无法揭示深层原因
• 路线图变待办清单：事无巨细却缺乏承诺