当团队沦为功能工厂或路线图只是功能清单时…

当需要把按路线图执行的功能团队转为跨职能、持续做产品发现与交付并对业务结果负责的赋能型产品团队时使用。

适用场景

解决思路

1. 用赋能型产品团队 = 跨职能小组接收要解决的问题而不是要构建的功能，并端到端拥有 discovery 和 delivery。
2. 区分 feature team 与 empowered team：feature team 接收路线图并执行；empowered team 接收目标并自行发现解决方案。
3. 用传教士还是雇佣兵判断团队状态：让团队由愿景和同理心驱动，而不是由上级下发的 backlog 驱动。
4. 用 Quick Diagnostic 给产品团队结构、发现实践或交付流程打分：每满足一行得 1 分，总分 0-7，目标 7/7。
5. 始终说明当前分数，并列出具体未通过的诊断行，以修复到 7/7。
6. 按分数带诊断：6-7 分为赋能团队拥有 outcome 且发现与工程师持续并行；4-5 分为有发现但不一致，或团队只拥有 output 且部分对 outcome 负责；<=3 分为功能工厂，团队收到带日期的功能路线图并跳过发现。
7. 并行运行 discovery 和 delivery 两条轨道：discovery 在工程投入前处理风险并决定构建什么，delivery 构建生产级软件。
8. 不要让产品工作从 idea 直接跳到 backlog 再到 sprint，从而完全跳过 discovery。
9. 在 discovery 中回答四类风险：value，客户会用吗；usability，他们能弄明白吗；feasibility，我们能构建吗；viability，对业务可行吗。
10. 把 discovery 输出定义为有证据支持的已验证想法，而不是 PRD 或规格说明。
11. 对每个最终进入 delivery 的功能运行 10-20 次 discovery 迭代；接受大多数想法不会成功，并快速低成本失败。
12. 不要把 discovery 当成一个阶段；让它与 delivery 持续并行，并让工程师参与。
13. 新功能在承诺构建前验证全部四类风险，例如构建前用 5 个用户原型测试 onboarding flow。
14. 路线图优先级按最强的 discovery 证据，而不是按 CEO 的请求，例如发布 4/5 用户测试通过的功能。
15. Sprint planning 只让经过 discovery 验证的条目进入 backlog。
16. 不要挑选 discovery 证据来证明已经选好的结论；同时报告失败的测试和通过的测试。
17. 规划 discovery 周期时，参考 references/discovery-techniques.md：使用四类风险框架、5 阶段访谈脚本、原型技术和 'validated' 的具体证据阈值。
18. 组建小而持久、跨职能的团队：包含 product manager、product designer、engineers，给团队一个问题去解决。
19. 让团队端到端拥有 discovery 和 delivery，并对 outcome 而不是 output 负责。
20. 不要让 PM 当项目经理或 backlog 管理员；PM 拥有 value 和 viability，并需要深入掌握客户、数据、业务和行业。
21. 让 product designer 整体拥有用户体验，而不只是视觉设计。
22. 把工程师视为创新的最佳来源，因为他们知道技术上什么可行。
23. 保持团队持久，成员稳定，且高度协作。
24. 用 outcome 问责团队，例如采用、留存、收入，而不是 output，例如交付的故事数。
25. 围绕 outcome 而不是组件组织团队，例如让 'New user activation' 团队拥有整个第一周体验。
26. 招聘 PM 看能力而不是资历：评估客户知识、数据素养、商业敏锐度。
27. 用结果衡量绩效，而不是用速度：跟踪激活率提升，而不是每 sprint 的故事数。
28. 不要声称赋能团队却用高管指令覆盖他们的 discovery 发现；如果领导层指定解决方案，团队就不是赋能型。
29. 在配置或诊断团队时，参考 references/empowered-teams.md：按角色看能力拆解与红旗、传教士 vs 雇佣兵动态、教练方式，以及从功能工厂到赋能团队的转型表。
30. 系统化地用机会评估、客户访谈、原型和用户测试，针对四类风险测试想法，快速低成本产出证据。
31. 把原型作为主要工具：高保真原型用于可用性，live-data 原型用于可行性，Wizard of Oz 原型用于价值。
32. 用真实目标用户测试，不用同事；定性测试，5 个用户，发现问题，定量测试在大规模验证。
33. 访谈行为，他们做了什么，而不是观点，他们说自己想要什么。
34. 认识到数据揭示模式但不揭示原因；把数据与定性 discovery 配对。
35. 用 feasibility spikes 让工程师探索技术风险，而不进行完整实现。
36. 早期想法在设计工作前做机会评估：为谁做、解决什么问题、如何衡量成功？
37. 可用性验证使用高保真原型和 5 个目标用户，例如用可点击 Figma 原型测试任务完成。
38. 价值验证使用 fake door 或 Wizard of Oz 测试，例如为未构建功能放按钮并测量点击率。
39. 可行性验证使用工程 spike，例如用两天调查 real-time sync 风险。
40. 不要超出有效结果所需范围欺骗用户；Wizard of Oz 原型可接受，为不存在的产品收集付款不可接受。
41. 投资任何机会前，用结构化问题评估商业价值、客户需求严重度、市场环境和组织准备度。
42. 机会评估关键问题包括：服务什么业务目标？目标客户是谁？什么问题？如何知道成功？有哪些替代方案？
43. 优先看客户问题严重度，而不是解决方案的优雅程度。
44. 评估市场时机；太早和太晚一样危险。
45. 检查组织准备度：技能、技术、go-to-market 能力。
46. 广泛分享机会评估，以在投入资源前建立共识。
47. 季度规划时，用一致标准给所有候选机会打分：客户严重度、业务影响、可行性。
48. 面对利益相关者请求时用评估回应而不是承诺，例如说 'Let me assess this and share findings before we commit engineering'。
49. 把资源分配给评估最高的机会；严重痛点加清晰业务对齐胜过 nice-to-have。
50. 当高管或销售给来解决方案，或 HiPPO 主导路线图时，做利益相关者映射，把指令转成要评估的问题，进行布道，并建立高管信任。
51. 在设计工作前评估新机会规模时，使用完整评估问题集、市场时机评估和优先级评分。
52. 定义愿景：描述 2-5 年后要构建的未来；定义战略：排序目标市场、问题和解决方案来实现愿景，为赋能团队提供自主决策上下文。
53. 愿景要鼓舞人心且以客户为中心，描述你想创造的世界，而不是功能清单。
54. 战略排序困难选择：先服务哪些客户、先解决哪些问题、先做哪些解决方案。
55. 用产品原则作为战略未覆盖决策的护栏。
56. 用 OKR 把战略翻译成可衡量的团队目标；用 outcome-based roadmaps 传达意图而不规定解决方案。
57. 每年重访愿景，每季度重访战略；产品原则很少改变。
58. 公司对齐时，用愿景让所有团队对齐共同未来，例如 'Every small business can access world-class financial tools'。
59. 团队自主时，用战略限定每个团队焦点，例如 'This quarter: cut mid-market churn via top 3 pain points'。
60. 决策时，用产品原则解决权衡，例如 'When in doubt, choose simplicity over power'。
61. 不要展示明知不可实现的愿景来激励团队或吸引投资。
62. 起草或重访愿景和战略时，参考 references/product-vision.md：写清愿景、战略、产品原则，把战略转成 OKR，并构建 outcome-based roadmaps。
63. 把交付视为持续流动的小型、已验证增量，尽快交付给真实用户，而不是一次发布事件。
64. 小步且频繁地发布；把每次发布都当作学习机会。
65. 把 instrumentation 当作必须项；不能测量就不能从发布中学习。
66. 用 feature flags 将部署与发布解耦，实现受控发布和快速回滚。
67. 把 MVP 定义为测试假设的最小发布，而不是半成品产品。
68. 像管理金融债务一样管理技术债：有意识地进行权衡。
69. 发布规划时拆成可独立交付的增量，例如先基础搜索，再过滤器，再保存搜索。
70. 风险管理时用 feature flags 做受控发布，例如先发 5%，测量，再扩大或回滚。
71. 建立学习循环：为每次发布加埋点，把结果反馈给 discovery，例如低搜索使用触发 discovery 调查。
72. 不要发布无法回滚的变更；把任何有风险的东西放在可关闭的 flag 后面。
73. 在应用框架前，用 startup、growth、enterprise 阶段的实例检查这些原则如何落地。
74. 不要把 PM 当项目经理：招聘时看客户知识、数据素养、商业敏锐度，并让 PM 对 outcome 负责。
75. 不要跳过 discovery：要求想法进入 delivery backlog 前必须有已验证证据。
76. 不要衡量 output 而不是 outcomes：把成功定义为 adoption、retention、revenue impact。
77. 不要把解决方案交给团队而不是问题：分配 objectives and key results，让团队发现解决方案。
78. 不要把工程师与客户隔离：让工程师参与访谈、discovery、原型测试。
79. 不要做带日期和承诺功能的路线图：使用 outcome-based roadmaps，写要解决的问题而不是功能。
80. 如果 PM 不能直接观察并说出 top 3 customer problems，则安排每周客户接触：访谈、support shadowing、测试。
81. 如果不在构建前用真实用户测试想法，则对每个重要想法用 5 个目标用户做原型测试。
82. 如果工程师只参与 delivery 不参与 discovery，则邀请工程师参加访谈和原型会议。
83. 如果团队只拥有 output 而不是 outcomes，则用 outcome OKRs 替换功能路线图。
84. 如果团队成员不能解释愿景和战略，则创建并布道 vision doc 和季度战略。
85. 如果利益相关者带来解决方案而不是问题，则教练他们做 discovery，并用机会评估预先推销。
86. 如果发布已验证增量的频率低于每两周一次，则缩小增量，并投资 CI/CD 和 feature flags。

适用边界 · 注意事项

• 不适用于团队完全没有 discovery 权限、只能按固定合同范围交付的项目制或外包场景。
• 不适用于尚无真实用户、也无法接触目标用户的极早期阶段；此时先做问题与用户探索，而不是完整进行赋能团队改造。
• 不适用于只需一次性交付、没有持续产品迭代和 outcome 责任的组织。