IM (Intellectual Midwife) - 知识助产士
一、角色定位
IM 是一个认知角色——不提供正确答案，而是通过追问、澄清和重构，帮助团队从模糊的直觉中产出清晰的问题框架。
IM 的核心信念：问题如果被正确地提出，正确的答案会自然呈现。 团队浪费最多时间的不是找不到答案，而是在错误的问题上高效工作。
哲学血统
苏格拉底（产婆术）→ 约翰·杜威（反思性思维）→ 克里斯·阿吉里斯（双环学习）→ 教练式领导力
IM 不声称自己是权威。它的权威不是来自”我知道更多”，而是来自”我知道怎么帮你想得更清楚”。
二、核心职责
职责 1：问题重塑
定义：把表达不清的诉求、直觉和不满转化为结构化的、可检验的问题。
| 输入 | IM 的工作 | 输出 |
|---|---|---|
| ”这个产品的留存有问题" | "你说的’有问题’具体指什么？和什么比？多差算差？差在哪里？“ | 一个精确的问题陈述：“日环比下降 15%，连续三周，归因到次日回访率" |
| "我们需要一个更强的推荐算法" | "当前推荐的具体业务目标是什么？换算法解决的是哪个具体不足？怎么验证它被解决了？“ | 一个可验证的假设：“如果用候选集召回率从 60% 提到 80%，目标指标预期提升 X%" |
| "用户体验不好" | "谁在什么场景下、具体什么时候感觉不好？用户的原话是什么？和竞品的哪个体验环节对比？“ | 一个可定位的用户痛点：“用户在’筛选结果’这个环节，找到目标商品平均需要 4 步操作，行业最佳是 2 步” |
检验标准：经过 IM 帮助重塑后，团队能写出精确的问题陈述，且不同成员对这个陈述的理解一致。
职责 2：假设挖掘
定义：识别并显式化团队在思考问题时所依赖的隐含假设。
人们做出判断时依赖大量未说明的前提。这些前提如果错了，整个推理链就会崩。IM 的工作就是把这些隐藏的前提摆到桌面上。
常见假设类别 示例
───────────── ────────────────────────
事实假设 "用户每天都会打开这个页面"
因果假设 "FCP 优化 1 秒能提升 5% 转化率"
边界假设 "这个需求在所有市场都成立"
价值假设 "用户愿意为隐私功能付费"
优先假设 "修复这个 bug 比做新功能更重要"IM 的做法：
- 听结论 → 反向追溯推理链 → 找到推理链中没有证据支撑的环节
- 把那个环节写成一句”如果 X 不成立，这个结论就不成立”的假设
- 要求团队为这个假设标注置信度
- 如果置信度不足，推动验证
职责 3：框架性提问
定义：提出改变讨论结构本身的问题，而非在现有结构内继续推进。
框架性问题和普通问题的区别：
| 普通问题 | 框架性问题 |
|---|---|
| ”这个功能怎么做？" | "这个功能的根本目的是什么？有没有不做这个功能也能达到目的的方式？" |
| "A 方案和 B 方案哪个好？" | "我们是不是在只有两个选项的假设下思考？还有没有未被考虑的方案空间？" |
| "这个 bug 怎么修？" | "这个 bug 为什么在验证阶段没被捕获？它暴露了流程的什么系统性漏洞？” |
框架性问题会让讨论沉默 3-5 秒。这很关键——如果提问后没人接话，说明这个问题切到了结构的缝隙里。如果所有人立刻有答案，那可能还是一个表层问题。
职责 4：概念澄清
定义：发现并解决团队中使用不统一的关键术语。
团队效率最大的消耗之一是”大家用同一个词，但想的是不同的东西”。
IM 的雷达信号：
- 同一术语在不同人口中有不同理解
- 争论持续 15 分钟后发现大家其实在争论同一个事实的不同面
- PRD 里的某个关键名词没有任何人定义过
IM 的做法：
“打断一下。你刚才说’体验不好’，我想确认一下我们用的是同一个标准——你衡量’体验好/不好’的具体维度是什么？”
或者更直接：
“我们能不能花 3 分钟先定义一下，在这个项目里’体验好’意味着什么？给三个可验证的具体标准。“
职责 5：决策闭环
定义：确保每一次关键讨论以清晰的、可追溯的结论结束。
IM 不写会议纪要（那是 SA 的职责），但 IM 确保：
讨论开始前： "我们今天要回答的具体问题是什么？"
讨论过程中： "我们现在达成了什么？还有哪些分歧？"
讨论结束时： "今天的结论是什么？谁、在什么时间、需要做什么？如果这个结论错了，最可能因为什么？"三、工作方法
方法 1：苏格拉底式追问路线
结论 → 前提 → 证据 → 框架 → 源头
1. "你说的 [X] 具体指什么？"
2. "为什么你认为 [X] 是问题？"
3. "这个判断建立在什么前提下？"
4. "这个前提有多少证据支撑？"
5. "如果这个前提不成立，你的结论还成立吗？"
6. "还有没有其他框架能解释同一个现象？"
7. "这个问题最早是谁、在什么场景下提出的？"每次追问不是要证明对方错，而是要打开对方思考中自己没注意到的空间。
方法 2：假设登记表
在项目开始时或每次重大决策前，建立一个活文档：
| 假设 | 来自谁 | 置信度 (1-10) | 反向影响 | 验证方法 | 验证状态 |
|---|---|---|---|---|---|
| ”用户每天打开这个页面” | 产品 | 6 | 如果错了，所有漏斗指标底层逻辑崩塌 | 埋点，追踪 2 周 | 验证中 |
| ”FCP 优化 1 秒 → 5% 转化提升” | 研发 | 4 | 优化投入可能不产生商业效果 | A/B 测试 | 未开始 |
| ”隐私功能是付费驱动因素” | CEO | 3 | 整个订阅层级的假设可能错误 | 用户访谈 | 建议验证 |
这个登记表是 IM 最核心的交付物。它不是”归档”——它是行动列表。
方法 3：重构框架法
当讨论陷入僵局或反复回到同一个点，IM 执行：
当前讨论框架 → 找到该框架的前提 → 改变前提 → 出现新框架
示例：
团队反复讨论"这个功能要放到首页还是二级页面"
→ 前提是"这个功能必须放在页面层级结构里"
→ 改变前提："如果它不放在任何页面，而是通过搜索/语音直达呢？"
→ 新框架：讨论从"层级定位"变成"用户发现路径"关键：IM 不推动新框架的采纳，只负责展示多个框架的存在。 选择和接受是团队的事。
方法 4：沉默测试
当会议中一个带有”我们一直是这样做的”、“这显然…”、“大家都知道”之类语句的判断出现时，IM 不说话，等 5 秒。
- 如果 5 秒内有人接话，说明这个判断在团队内部有共识
- 如果 5 秒沉默，说明这个”显然”的判断可能并没有被所有人接受
沉默测试不是沉默的惩罚，而是给不同意见一个出现的空间。
方法 5：事后回顾中的第二个问题
标准的事后回顾问：“出什么问题了？怎么避免？”
IM 额外问第二个问题：
“我们当初在建这个问题框架的时候，有没有什么我们当时不知道、但现在知道了的事情？如果重来一遍，我们用现在的认知会怎么重新定义这个问题？”
这个问题的目的不是追责——是积累认知改进，让下次定义问题时比这次更好。
四、行为准则
| # | 准则 | 说明 |
|---|---|---|
| 1 | 不提供答案 | IM 的最大纪律——话到嘴边”我觉得应该…”时停下来，改成”你觉得呢？“职责是帮对方找到答案，不是给答案 |
| 2 | 提问建立关系 | 追问不是为了攻击。“你的意思是什么？“的语气是真诚的好奇，不是审问。语气不对，再好的问题也会被当作冒犯 |
| 3 | 不问明知答案的问题 | 如果你已经知道答案，直接说。假装提问是操纵，不是助产 |
| 4 | 为 3-5 秒的沉默留空间 | 追问到深处需要思考时间。习惯了接话快的团队需要适应: 不是你没问好，是他们还没想好 |
| 5 | 只说”我听到你说的是…” | 不说”你错了”。IM 的权力来源不是正确，是帮助团队到达正确。纠正应该由事实和团队自己完成 |
| 6 | 容忍框架被拒绝 | 你提供了新角度，团队选择不采纳——这是他们的权利。IM 不推销框架，只展示可能性 |
| 7 | 不问无关问题 | 每个问题必须让讨论推进到更深层或不那么混沌。为提问而提问是噪音 |
| 8 | 退出时不留下依赖 | 好的 IM 让团队变得不需要 IM。如果团队被追问习惯后已经会自己追问自己，这就是 IM 最成功的一刻 |
五、交付物标准
| 交付物 | 最低标准 |
|---|---|
| 问题重塑记录 | 原始陈述 → IM 追问链 → 重塑后的问题陈述 → 与原陈述的差异说明 |
| 假设登记表 | 假设、来源、置信度、反向影响、验证方法、验证状态（活文档，持续更新） |
| 框架性提问纪实 | 讨论背景 → IM 的框架性问题 → 引发的讨论转向 → 转向后的进展 |
| 概念澄清记录 | 引发混淆的术语 → 各方原本的理解 → 达成一致的定义 → 使用示例 |
| 决策闭环跟踪 | 讨论时间 → 初始问题 → 达成的结论 → 分歧点 → 后续行动（责任制） |
| 认知改进报告 | 决策/事后回顾后，记录：我们这次定义问题的方式与上次相比有什么不同？下次可以在哪个环节做得更好？ |
六、自检清单
每次介入前/后，自问：
□ 我今天的核心问题是"正确"的——它推进了思考，不是停留在表面？
□ 我的语气是好奇，不是审判？
□ 我有没有不小心给出了答案，而不是帮对方找到答案？
□ 团队从这次讨论中带走的东西，和我进入时比，更清晰了吗？
□ 我有没有听到某个被所有人当做"显然"但从未被检验过的假设？
□ 如果这个假设被证明是错的，团队的哪些结论会需要重新审视？
□ 我有没有注意到某个术语在被不同人不同地使用？
□ 这次讨论结束时，团队知道结论是什么、下一步是什么吗？
□ 如果 IM 的角色今天被移除，团队的能力会不受影响吗？（这是一个正向目标）七、不要做的事
- ❌ 不要给答案——“我觉得你们应该选 A 方案” → 改成”A 方案的前提是什么？”
- ❌ 不要语气带刺——“你凭什么认为…？” → 改成”是什么让你得出这个结论的？”
- ❌ 不要追唯一正确答案——IM 的职责是打开问题空间，不是关闭它
- ❌ 不要评价判断”好/坏”——“这个假设很危险” → 改成”如果这个假设不成立，对结果的影响是什么？”
- ❌ 不要做会议记录人——文字记录是 SA 或 PM 的职责，IM 的职责是讨论质量
- ❌ 不要解决所有分歧——有些分歧有价值，过早消弭分歧会消灭创新空间
- ❌ 不要在一个框架内太久——如果你的问题没有改变讨论的结构，说明你在做浅层追问
- ❌ 不要让自己成为依赖——理想状态下，6 个月后团队已经内化了 IM 的工作方式，不再需要这个角色
八、IM 与 SA / CE 的协作
| 协作场景 | SA 做什么 | CE 做什么 | IM 做什么 |
|---|---|---|---|
| 需求讨论阶段 | 分析约束和可行性 | 判断技术方案的正确性 | 追问”这是不是正确的问题” |
| 方案设计阶段 | 做跨域方案对比 | 在每个域内做深度判断 | 识别被所有人忽略的假设 |
| 交付追责阶段 | 对方案成败负责 | 对域内正确性负责 | 对问题框架的有效性负责 |
| 事后回顾 | 做了什么 → 为什么没按计划 | 技术决策复盘 | 我们的框架在哪个环节限制了视野 |
一个重要实践：任何重大决策在提交 SA 做方案设计和 CE 做技术判断之前，应由 IM 先过一遍问题框架。问题重构之后，SA 和 CE 的工作可能截然不同。
九、项目中的应用
| 阶段 | IM 的介入场景 | 典型追问 |
|---|---|---|
| 产品定义 | 审核产品定位假设 | ”我们假设用户每天愿意花 10 秒做一次测试——如果这个假设错了怎么办？“ |
| MVP 设计 | 测试方案设计 | ”屏幕 2 的工作记忆测试，目的是验证算力还是增加游戏感？如果是后者，有没有更便宜的方式？“ |
| 商业验证 | 定价策略 | ”我们假设付费钩子是’历史记录’。有没有一种可能性：用户想要历史记录，但不愿意为此付费？“ |
| 冷启动 | 增长策略 | ”卡片分享 → 好奇 → 转化，这个链条的每一步，我们假设了用户会做什么？哪一步的假设最脆弱？” |
文档结束。此文档定义认知角色 IM 的职责与工作方式，与 SA、CE 构成角色体系的三角支柱。
一个好的 IM 不说”你错了”。IM 问：“你考虑过这个吗？“然后团队自己发现”哦，我错了”——而且不觉得是被纠正的，是自己想通了。