那些真正厉害的产品经理，都在死磕什么

很多项目都被这个模式阻碍了发展。产品方案一交付，老板就认为产品经理的工作已经完成，立刻把人抽走，安排去做下一个事情。表面上看起来很高效，但有实战经验的人都明白，产品方案只是第一步。

技术开始写代码，大量细节、边界情况、历史包袱和现实限制才会集中出现。这些问题不可能由开发自行拍板，最终都需要由产品经理做确认。只要方案有任何调整，就必须更新需求文档，确保所有人都基于最新方案推进。

对细节的处理能力，是区分产品经理水平的分水岭。下面几个场景，在真实项目中非常常见。

场景一，是新方案和历史代码的冲突。

很多老系统，代码复杂且高度耦合。需求评审时，开发不会翻看旧代码，凭经验判断问题不大。等改到那一块代码时，才发现新方案和旧逻辑无法兼容。

此时，产品经理就必须重新判断，是调整方案以兼容历史逻辑，还是推动技术做重构，或是在成本和进度压力下选择做阶段性妥协。这本质上是产品目标、风险和成本之间的权衡。

场景二，是开发不断发散异常情况。

优秀的开发会主动思考异常路径，但在长时间高强度工作下，很容易因疲劳而陷入逻辑混乱，甚至会钻进一些真实用户场景里不存在的极端情况。

产品经理需要帮开发理清思路，既要理解技术的担忧，又要守住产品的核心场景，极其耗费心力。

场景三，是第三方对接带来的连锁反应。

在方案阶段，第三方看起来文档齐全、接口说明清楚。但等到真正对接时，才发现文档里写的是返回 A，实际接口却返回 B，甚至字段含义完全不同。有些能力在文档中存在，但在真实环境中根本不可用。

这时候，原有方案无法小修小补，需要整体调整，甚至会完全改变业务流程。

除此之外，理解偏差，会贯穿整个研发周期。

即使文档已经写得很清楚，开发、测试、UI 设计师，依然可能有理解不到位的地方。他们会不断提问，产品经理需要反复解释。

也有不少问题是在验收阶段涌现，例如产品实现与预期不一致，这时要推动返工和修改。

这些看似零碎的沟通叠加起来，需要大量时间和精力的投入。

我这里只举了几个典型例子，真实项目的复杂度远不止如此。

产品经理是贯穿整个产品落地流程的角色。不可能闲下来，更不存在“方案交付完就没你什么事了”这种状态。

是不是没想到，跟进开发这四个字背后的工作量那么的大？

币圈一天，人间一年。不追光，只筑塔，每周复盘，登高一步。

认知迭代杂记（12）