功能假共识
项目组只在功能名称上达成一致，却未在业务目标、真实问题和解决口径上达成一致的现象。所有人都在说同一个词（“驾驶舱""预警""报表”），但心里的画面完全不同——客户以为做的是管理工具，实际交付的是展示页面；客户以为做的是异常闭环，实际交付的是消息提醒。这是项目后期出现价值落差的最常见根源。
简介
功能假共识是 B端产品经理 在项目中最容易踩中的陷阱之一。张二十三在 2026-06-18-woshipm-project-pm-three-sentences 中指出，项目组通常会对模糊需求比较警惕（客户说”不太好用""希望更智能”时PM会继续追问），但一旦客户说出明确的功能名（报表、预警、驾驶舱、移动端），项目组反而容易放松——因为”这些词太熟了，熟到每个人都觉得自己已经明白”。
这种假共识的危害在于：项目就这样顺着功能名往下走（PM整理需求、项目经理排计划、研发拆任务、客户也觉得诉求被承接了），但功能名清楚不代表业务目标清楚。等系统真正上线后，分歧才会彻底暴露：轻则功能没人持续使用（“吃灰”），重则客户发现系统没解决原本问题，只能重新提改造需求——此时沟通成本、开发成本和项目风险都被放大。
功能假共识与 产品需求分析 中的”症状 vs 病因”框架同源——客户说出来的功能名是”症状”，PM要穿透表象找到”病因”。区别在于，功能假共识更聚焦于项目已推进时的校准场景：功能已经进入方案、合同和项目清单，PM不能推倒重来，但需要在继续往下拆之前先校准理解。
核心特性
功能假共识的典型场景
功能假共识通常出现在两种项目场景中：
- 功能刚说出口的阶段：客户在调研会、启动会、方案沟通会上临时提出（“这里最好能加一个预警""领导希望有个驾驶舱”）
- 功能已进入项目材料的阶段：写进了售前方案、合同范围或项目清单（能源驾驶舱、能耗统计报表、异常预警、设备台账等）
两种场景的共同点：产品经理不能只停留在功能名上。
功能假共识的四个角色视角差异
以”驾驶舱”为例，不同角色的理解完全不同：
| 角色 | 对”驾驶舱”的理解 | 真正关心的事 |
|---|---|---|
| 客户领导 | 开会时能看到管理结果 | 汇报效果 |
| 业务部门 | 每天能发现异常 | 日常监控 |
| 销售 | 方案里有一个能打动客户的大屏 | 方案亮点 |
| 项目经理 | 合同里有这个模块，按期交付 | 交付节点 |
| 研发 | 几个图表组件加一个页面 | 技术实现 |
功能假共识的后果
- 轻则：功能做了但没人持续使用，系统慢慢被放在一旁”吃灰”
- 重则：客户发现系统并没有解决原本的问题，只能重新提改造需求
- 根本原因：项目组把功能名称当成了需求共识，却没有进一步说清楚——这个功能到底服务什么目标、要解决什么问题、当前项目准备解决到哪一层
破解方法：三句改写法
张二十三提出的破解工具是三句改写法（详见 2026-06-18-woshipm-project-pm-three-sentences）：
- 目标句：这个功能服务谁的什么业务目标？
- 问题句：当前是什么原因导致这个目标无法达成？
- 口径句：当前项目准备解决到哪一层，哪些不在本期解决范围内？
这三句话的作用是把分散的理解重新拉回同一个平面，让项目在继续往前走之前，先看见那些可能影响交付和价值的偏差。
不同素材中的观点
- 2026-06-18-woshipm-project-pm-three-sentences：张二十三首次系统描述了功能假共识的现象、成因和破解方法。核心洞察是”越明确的功能越容易让项目组放松警惕”——模糊需求反而让PM追问，明确功能名反而让PM跳过判断。三句改写法是项目推进中快速介入的动作，不是为了文档规范，而是为了让不同角色的理解回到同一个平面。