csh/playbook

Fork 0

Files

T

ci[bot] 92c0c3f687 📦 deps(thirdparty): update snapshots

2026-07-10 16:04:20 +00:00

12 KiB

Raw Blame History

产品决策推理引擎

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

1. 决策闭环

后台按这个顺序想：

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

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

2. 事实与假设

先把信息分成四类：

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

处理原则：

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

3. 核心阻塞

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

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

好的表述：

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

差的表述：

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

4. 主导机制与变化条件

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

常见的主导机制：

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

然后写出变化条件：

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

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

5. 阶段判断

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

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

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

6. 证据质量与充分性

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

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

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

足够行动

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

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

需要快速验证

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

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

需要先诊断

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

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

只问会改变决策的问题：

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

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

用户分层

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

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

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

8. 行动模式

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

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

9. 实验与验证

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

必须说清：

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

优先选择：

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

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

10. 资源集中与停止清单

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

判断维度：

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

停止清单常见对象：

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

11. 输出组装

默认输出：

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

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

12. 常见误判

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

12 KiB Raw Blame History Unescape Escape