高阶产品如何提出有效解决方案？（1 方法论 +2 案例 +1 清单）

编辑导语：每一件事情总有它的解决方案，在工作中亦是如此，而有效的解决方案，一定是具有系统性的。作者以一个工作案例为导入，分析有效解决问题，希望对你有所启发。

有效的解决方案，一定是系统性的解决方案。

什么是系统性解决方案？

从系统结构（或连接关系）入手，而不通过改变症状（即只解决当前问题）或原因（即通过改变人，包括自己与他人）解决问题的解决方案。

什么意思？

北京疫情要求全民核酸，前期每次社区志愿者都是通过移动式喇叭，从早到晚，间歇性的进行宣传，目的只是想让所有居民均参与核酸，避免有遗漏，从而导致疫情扩散。

志愿者不可谓不尽心尽力，居民不可谓之素质低下，可每次依然有不少遗漏之人。

后期则采用进出公共场合、办公楼以及乘坐公共公交，必须 72 小时内核酸（前期甚至是 48 小时）的政策。

同时推出两大赋能性措施：一是构建大量方舱，且提供免费核酸检测，便于常态化核酸的便利性；二是检测结果与地铁公交系统打通，以及所有公共场合严查 72 小时核酸，如不满足条件者，直接无法出行。

现阶段的疫情常态化防疫，保证 72 小时核酸检测正常方可进出公共交通、场所的政策，取得了阶段性的有效进展，这就是系统性的解决方案所发挥的应有作用。

【复盘】前期与后期的防疫解决方案，关键变化就是从通过改变人去解决问题（即要求志愿者更努力的催，居民更自觉检测），完全转变成系统性的解决方案（即改变居民出行、工作与核酸检测的关联关系）。

一、案例：如何在数据与资源受限情况下，通过有效解决方案实现业务目标？

假如你作为一名产品经理（简称 PM）入职一家新公司，负责构建其辅导老师工作台，基于【需求是 1，方案是 0】方法论指导，完成前期的调研，并完成了相关的用户体验地图以及产品架构图规划（如下图所示）。

你准备落地时，发现有两个关键性的限制条件：

1. 你所必需的数据均存储在中台产研侧，你方作为业务方无法直接读取与运用；

2. 你可用的研发资源有限，不足以支撑有效解决大版本迭代更新。

3. 如当前学员列表显示的是全部学员（包括在读以及退课、转班等），而辅导服务只针对在读学员即可，至于退课、转班等失效学员，列表中需剔除。

   即使如此小的一个需求，但受上述两个关键限制条件（即学员以及状态数据不在你方数据库，以及研发资源限制），技术判断为当前研发模式无法实现，或即使可以周期也非常长，且只能按照不完美方案执行。

此时，下面 3 种选择，你会怎么选？

1. 选择一：告辞，我不干了，此处不留爷，自有留爷处；

2. 选择二：将此问题上升，让你的上级与研发 leader 介入，协助解决此问题；

3. 选择三：改变自己的需求方式，提前构建需求缓冲池，保证整体需求可提前规划与排期。

我建议你哪个都别选，为什么？

选择一是一种逃避问题的解法，对于新入职的你，还不至于；

选择二是一种症状解。即上级领导的支援次数是稀缺的，此方案只能解决当前一个需求的问题，无法持续；

选择三是一种原因解。即我改变不了别人，那我至少可以改变自己的工作方式，但效果有限；

我建议你可以从系统层面去寻求根本解，而不是通过症状解（即仅解决当前问题）或原因解（即通过改变人，包括自己在内）去解决。

二、什么是系统？什么是才是系统根本解？

系统=目标*要素*连接关系

上述案例中，你作为业务 PM 的目标是：用最低成本、最高效率完成辅导工作台的构建，以此实现服务品质的规模化复制。

关键要素是：规模化团队（即辅导老师）、业务产研与中台产研；

连接关系是：辅导老师的规模化服务品质与人效的提升，依赖业务产研的支持；而业务产研因数据受限制于中台产研（双方却各自有自己的目标），资源受限制于编制与研发模式，导致难以有效进行工作台的建构，从而导致服务品质难以规模化，形成一个负向增强回路。

如果要形成系统性的解决方案，则需从三个关键要素的目标与关联关系入手，方可探寻到根本解。

中台产研的目标是：尽可能通用化所有能力，用最小投入赋能更多业务线；

辅导团队的目标是：尽可能快的用上更高效的系统，以便尽快提升人效，实现服务品质规模化；

你作为业务 PM 的目标与辅导团队的目标一致，却与中台产研目标有所差异。

从系统论的解决思路中，核心就是从多方目标与连接关系入手。

首先，中台产研目标是最小成本的通用化，那你就可以将你的辅导工作台的建设目标，当做其通用化的子集，形成双方目标的一致性；

其次，从连接关系看，则可采用专项双方进行混合共建的研发模式，改变你们双方的研发模式，由双方各自为战的模式，变成双方协同作战的模式。

案例最终采用了专项形式共建通用化工作台的方案，虽工期与预期有差距，但最终也完成了上线，并实现了整体最优的策略。

此方案既达到中台产研通用化最小成本的目标；也实现了业务产研侧的辅导工作台的建设，双方一起实现了对辅导团队的规模化服务品质的系统层支撑，从而达到整个系统（即公司）的最优解。

三、扩展：如何有效解决需求方随意提需求，浪费产研资源问题？

作为一名业务型 PM，你可能会遇到业务方随意提需求的问题。有时苦口婆心 1 小时，方才拒绝了一个不合理小需求；有时你迫于无奈，被迫接受了一些需求，上线后发现无人使用，导致你被研发吐槽，公信力下降等问题。

此时如果有下面 3 个选择，你会选择哪个？

1. 选择 1：每个需求都当面对接，不合理需求就“动之以情，晓之以理”的柔性拒绝；

2. 选择 2：你努力提升自己辨别真假需求与说服人的能力，并定期给需求方的 KP（关键决策人）进行培训与宣贯，让他们具备识别需求、理解产研成本的意识；

3. 选择 3：你构建一个需求缓冲池，并建立一种周会制，与关键 KP 进行需求准入情况、优先级与进度共识与同步。

无论你选择哪个，均正常，它们可能是你所处不同阶段、不同业务环境所能采取的解决方案。

我想提供一个第 4 选择，供你参考。即让需求方与产研方共背双方的绩效目标与成本。

为什么呢？

选择 1 其实属于症状解，每次只能解决当前的问题；

选择 2 属于原因解，即通过改变你跟需求方的能力模型解决问题；

选择 3 属于弱化版的根本解，即通过改变需求方与产研方的连接关系，让需求方来匹配产研方的目标以及工作模式；

选择 4 是典型的根本解，即通过改变需求方与产研方的目标，让双方形成共同目标与连接关系，结构性的解决问题。

当然，受限于企业组织架构等问题，选择 4 的实操成本可能比较大，鉴于此我们至少可选择 3 作为可落地方案。

四、总结

方法论：从系统结构（或连接关系）入手解决问题，而不通过改变症状或原因。

即根本解才是系统性解决方案，而不是症状解跟原因解。

• 症状解就是只解决当前症状的解决方案。比如案例中只解决当前那个需求的方案；

• 原因解则是通过改变人（包括自己与他人）解决问题的方案。比如案例中 PM 自己构建缓冲需求池（或软磨硬泡洗脑研发要给力）；

• 根本解则是通过改变系统的目标、要素与要素之间的连接关系的解决方案（即系统=目标*要素*连接关系）。比如案例中业务产研与中台产研采取共建模式进行专项构建的通用化工作台方案。

实操清单：

1. 先识别系统（如一个企业或部门）中的关键要素（如企业角色）；

2. 梳理清楚关键要素的关键目标（如角色 A 目标是增收，角色 B 目标是降本增效等，或是角色对应 OKR 与北极星指标等）；

3. 梳理清楚关键要素之间的结构或连接关系（如因果链、增强回路、调节回路、滞后效应等）；

4. 确认关键要素之间目标的差异，并找到影响结果的关键要素之间的连接（重点关注负向增强回路与调节回路）；

5. 弱化关键要素之间目标的不同，基于相同目标重构双方共同目标，并基于此将负向增强回路或调节回路切断，形成新的增强回路；

6. 将目标、关键要素以及连接关系所生成的解决方案（一定不是依赖改变人，而是改变结构），与相关角色之间形成共识，并落地成为制度、流程、规则、策略等（如有必要可辅以产品化的工具支撑）；

落地执行，在执行中收集反馈进行优化迭代，最终形成一种可执行、可落地的方案。