# 产品决策推理引擎

当用户的问题复杂、信息不足、症状很多、内部意见冲突或涉及资源取舍时，读取本文件。这里是后台工作手册，最终回答仍要转成中文产品语言，不要暴露方法来源。

## 目录

1. 决策闭环
2. 事实与假设
3. 核心阻塞
4. 主导机制与变化条件
5. 阶段判断
6. 证据质量与充分性
7. 用户、相关方与冲突形式
8. 行动模式
9. 实验与验证
10. 资源集中与停止清单
11. 输出组装
12. 常见误判

## 1. 决策闭环

后台按这个顺序想：

1. **目标**：用户到底想改变哪个结果。
2. **现象**：表面症状是什么，是否只是用户的说法。
3. **机制**：是什么用户行为、产品机制、市场变化、数据口径或组织机制导致了现象。
4. **核心阻塞**：当前最决定结果的瓶颈是什么。
5. **主导机制**：核心阻塞内部，哪项力量、行为或规则当前主导结果。
6. **阶段**：产品、业务、项目或团队处在哪个阶段。
7. **约束**：资源、时间、权限、供给、流量、信任、数据、激励中哪个最硬。
8. **相关方**：谁背结果、谁执行、谁否决、谁承担成本、谁受益。
9. **证据**：来源是否可靠，哪些事实够用，哪些只是推断，哪些必须验证。
10. **变化条件**：什么信号出现时加码、停止、回滚或换打法。
11. **行动**：现在该决策、诊断、验证、排序、谈判、停止还是升级。
12. **复盘信号**：用什么指标或事实判断下一步有效。

不要把这 12 步原样输出给用户，除非用户明确要求方法框架。

## 2. 事实与假设

先把信息分成四类：

- **硬事实**：已发生的行为、数据、上线记录、合同、资源、截止时间。
- **一线材料**：用户原话、客服/销售反馈、运营观察、研发阻塞、真实使用路径。
- **判断假设**：用户或团队对原因的解释。
- **解决方案诉求**：别人已经提出的功能、活动、投放、流程或组织动作。

处理原则：

- 不把“用户说想要功能”直接当成需求，要追到场景、行为和结果。
- 不把“老板说要做”直接当成优先级，要追到业务压力和代价。
- 不把“数据涨跌”直接当成业务结论，要先查口径、分层和贡献段。
- 信息不足时，不要追问一堆问题；先给基于当前信息的判断，再给最小取证动作。
- 不照搬行业案例或所谓最佳实践；先检查案例前提是否和当前人群、阶段、渠道、资源一致。
- 不用少量高声量反馈代替行为证据，也不因只有数据就忽略真实操作路径。

## 3. 核心阻塞

一个问题可以被判定为核心阻塞，通常满足至少两条：

- 解决它，多个其他问题会随之缓解。
- 不解决它，其他优化效果都很弱。
- 它解释了为什么之前的办法没用。
- 它离用户行为或业务结果足够近，而不是内部偏好。
- 它在用户当前权限或可升级范围内能被改变。

好的表述：

- “新用户没有在 10 分钟内到达第一次价值体验。”
- “内容供给不稳定，导致留存动作没有承载物。”
- “团队还没确认真正愿意付费的目标人群，就在优化付费按钮。”
- “Roadmap 争论本质是资源分配冲突，不是功能排序冲突。”

差的表述：

- “体验不好。”
- “数据要完善。”
- “团队要协同。”
- “需要做增长。”

## 4. 主导机制与变化条件

找到核心阻塞后，再判断是什么在阻塞内部主导结果。这一步防止把两个相关现象直接拼成因果。

常见的主导机制：

- **供需关系**：是有效需求不足，还是供给数量、质量或稳定性不足。
- **价值与摩擦**：是用户没有感知价值，还是路径、价格、信任、性能阻止用户到达价值。
- **增量与承接**：是流量不足，还是激活、留存、履约能力接不住流量。
- **目标与激励**：是团队不知道做什么，还是知道但考核、权责、成本结构让其不愿做。
- **规则与行为**：是个别执行问题，还是流程、分配、准入或决策规则持续制造同类问题。

然后写出变化条件：

- 哪个指标或事实改变，说明主导机制已切换。
- 哪个阈值出现，应该加码、停止、回滚或升级。
- 哪个依赖解除后，下一优先级才有意义。
- 当前只是随机波动、持续积累，还是已经跨过会改变产品阶段或用户行为的阈值。
- 哪个领先指标能在结果指标明显恶化前发出信号。

例：社区 DAU 下滑的核心阻塞可能是内容供给，但真正主导结果的是核心创作者连续流失。只有创作者周留存和有效内容量恢复后，拉新活动才值得重启。

## 5. 阶段判断

同一个动作在不同阶段价值完全不同。先判断阶段，再给方案。

| 阶段 | 关键问题 | 优先动作 | 常见坑 |
|---|---|---|---|
| 探索期 | 问题是否真实存在 | 访谈、观察、人工服务、问题验证 | 太早做完整产品 |
| 验证期 | 用户是否愿意用或付费 | MVP、原型、烟囱测试、灰度 | 没证明价值就优化体验 |
| PMF 寻找期 | 哪个细分人群和场景会重复使用 | 收窄人群、打深核心链路 | 过早扩品类扩人群 |
| 增长期 | 哪个渠道或循环可放大 | 聚焦增长实验、建立节奏 | 多渠道平均用力 |
| 规模化期 | 系统和组织能否承载规模 | 标准化、自动化、稳定性 | 继续靠人工救火 |
| 成熟优化期 | 边际 ROI 最高在哪里 | 漏斗、留存、定价、效率优化 | 追新概念 |
| 危机期 | 先止住哪类损失 | 止血、保护核心用户、重排优先级 | 照常执行 Roadmap |
| 组织对齐期 | 谁需要改变行为 | 权责、激励、依赖、决策机制 | 把人和激励问题当成功能问题 |

阶段不明确时，先说明阶段假设，再问一个会改变判断的问题。

## 6. 证据质量与充分性

先判断证据来源，再判断数量是否足够：

1. **直接行为与结果**：交易、留存、日志、录屏、真实任务完成情况。
2. **一线材料**：用户访谈、客服工单、销售记录、运营观察、研发阻塞记录。
3. **可追溯汇总**：口径明确、能回到原始事件的数据和研究结论。
4. **二手判断**：会议转述、老板印象、竞品故事、行业文章。
5. **孤立个案**：单个强烈反馈或未经核验的异常样本。

关键决策尽量让不同来源互相印证。证据冲突时，先查定义、人群、时间窗口和采集链路，不做平均折中。

### 足够行动

适用：动作低风险、可回滚，或证据已经明显指向一个方向。

输出：明确建议、取舍、时间窗口、复盘指标。

### 需要快速验证

适用：方向可能对，但不确定性会影响投入。

输出：1 天到 1 个迭代内能产生决策证据的小实验。

### 需要先诊断

适用：同一个现象可能由多个机制导致，贸然行动成本高。

输出：窄口径诊断，不做泛调研。

只问会改变决策的问题：

- 目标用户或目标客户是谁。
- 当前基线指标和趋势是什么。
- 漏斗最大掉点在哪一步。
- 可用资源和硬截止时间是什么。
- 决策人、执行人、否决人是谁。
- 过去试过什么，为什么没成。

## 7. 用户、相关方与冲突形式

### 用户分层

按对结果的影响排序，不按声音大小排序：

- 高价值付费用户。
- 高频核心用户。
- 高潜转化用户。
- 供给侧关键用户，如创作者、商家、达人、服务商。
- 新用户和流失用户。
- 边缘低频用户。

反馈冲突时，按目标人群、行为证据、商业价值、战略阶段加权。

### 相关方地图

组织协作类问题要先看人和目标：

- **结果负责人**：最终背指标或业务结果的人。
- **执行负责人**：真正要做事的人。
- **否决人**：能卡住推进的人。
- **受益人**：成功后获得收益的人。
- **成本承担者**：承担时间、预算、信誉、运维成本的人。
- **中间人群**：没有强反对，但需要证据争取的人。

对齐动作不是“加强沟通”，而是：

- 把方案连接到对方指标。
- 降低对方成本或风险。
- 做可回滚的小试点。
- 让取舍和后果可见。
- 区分原则问题和执行细节。

不同冲突要用不同处理方式：

- 数据冲突：统一口径并回到原始记录。
- 资源冲突：公开取舍、挤出项和决策人。
- 目标冲突：先确认共同结果，再谈方案。
- 权责冲突：明确谁拍板、谁承担后果，必要时升级。
- 假设冲突：用最小实验取证，不靠会议投票。
- 硬约束冲突：先满足合规、安全、现金流或交付底线，再优化体验。

## 8. 行动模式

每次优先选择一个主模式，不要什么都说一点。

| 模式 | 适用情况 | 输出重点 |
|---|---|---|
| 立即决策 | 事实足够，风险可控 | 明确建议、取舍和代价 |
| 快速验证 | 主要不确定性是用户反应或 ROI | MVP、A/B、灰度、人工验证 |
| 先诊断 | 根因不明 | 指标拆解、用户样本、日志或口径检查 |
| 排序 | 多件事都重要但资源不够 | 顺序、依赖、停止清单 |
| 谈判对齐 | 相关方冲突阻塞推进 | 相关方地图、共同目标、底线和替代方案 |
| 停止投入 | 继续做只会消耗资源 | 停止标准、沉没成本处理、对外说法 |
| 升级决策 | 权限和责任不匹配 | 决策备忘录、升级路径、需拍板事项 |

## 9. 实验与验证

好的验证要“小、快、能改决策”。

必须说清：

- 假设是什么。
- 目标人群是谁。
- 在哪里验证。
- 最小实现方式是什么。
- 成功指标是什么。
- 失败指标是什么。
- 持续多久或需要多少样本。
- 结果出来后怎么决策。

优先选择：

- 人工服务先于平台化建设。
- 落地页或烟囱测试先于完整功能。
- 分 cohort 留存先于总量活跃。
- 手工运营先于自动化。
- 灰度先于全量。
- 小范围真实客户试点先于全公司流程改造。

不要做无法改变决策的实验。

## 10. 资源集中与停止清单

资源不足时，优先一个决定性动作加一个取证动作。

判断维度：

1. **结果杠杆**：是否直接影响目标指标。
2. **阶段匹配**：是否符合当前阶段。
3. **约束解除**：是否解决核心阻塞。
4. **证据强度**：是否有数据、用户行为、失败经验支撑。
5. **执行成本**：人力、时间、复杂度、依赖。
6. **可逆性**：能否低成本回滚或学习。

停止清单常见对象：

- 当前阶段无法证明价值的完整平台建设。
- 没有承接能力的投放和补贴。
- 只为单个低复用客户做的产品主线改造。
- 没有成功/失败标准的 A/B Test。
- 没有负责人和代价说明的临时插入需求。
- 只制造短期数据噪音的全站活动。

## 11. 输出组装

默认输出：

1. **问题判断**：一句话指出真正问题。
2. **原因分析**：2-4 条，解释为什么是这个问题。
3. **行动建议**：1-3 个动作，包含时间、对象、指标或决策口径。
4. **风险提醒**：现在不要做什么。
5. **需要确认**：最多 3 个，只问会改变判断的事实。

短答也要保留“判断 + 下一步”。不要把内部框架完整讲出来。

## 12. 常见误判

- 把症状当原因。
- 找到核心阻塞后，没有继续判断当前真正主导结果的机制。
- 用二手汇报、行业故事或单个高声量反馈代替可追溯证据。
- 等所有数据齐了才敢判断。
- 用户还没到达价值，就开始优化转化。
- 一个细分场景没打透，就扩人群扩功能。
- 看到竞品动作就复制，不知道对方改变了什么用户选择。
- 把激励冲突说成沟通问题。
- 做最好做的需求，而不是最能改变结果的需求。
- 样本量、埋点或假设都不可靠时硬跑 A/B Test。
- 复盘只写责任和态度，不改变机制。
- 用英文咨询腔回答中文工作问题。