有些时候，产品经理可能会觉得自己在工作中处于被动地位，总是被动地接受需求，这个时候，产品经理可以怎么做呢？这篇文章里，作者就结合结构化思维，讲了讲如何掌握需求主动权这件事，一起来看看吧。

各位B端产品经理，特别是企业自研产品经理，会不会有这样的困惑？

“为什么业务总是说什么就做什么？”

“为什么我感觉自己只是开发和业务之间的传声筒？”

虽然我们能够评估需求合理性，对需求进行大致的规划排期。但是很多时候，仍然是业务想要什么，我们就做什么。

长期以往，我们很难感受到工作的价值，甚至开始对工作产生怀疑。

面对这种情况，B端产品经理又该如何化被动为主动呢？

刚好前段时间我做了一个优惠模块的需求，并顺利落地。这个需求和其他需求不一样，是完全由产品侧提出并最终落地的需求。

从被动接受需求到主动发起需求，引领业务节奏，我只是用了一个简单的思维方法——结构化思维。

这篇文章会为大家介绍这种思维方式，并且结合我做过的项目，为大家说明如何将这个方法实际运用起来。这个方法不仅适用于企业自研B端产品，对商业化B端产品、C端产品也有参考价值。

前排提示：

本文仅讨论如何产品经理发起需求，也就是：如何把自己的想法推出去。

如何协作各部门，如何落地是另外一个更大的话题，我会单独开另一篇文章讲述。

想快速阅读的读者们，可以仅阅读加粗字体。

一、结构化思维是什么？

结构化思维是一种重点突出、逻辑清晰的思维方式，可以帮助我们高效思考、表达、解决问题，它来自经典的麦肯锡培训书籍《金字塔原理》。

结构化思维的基本结构是：结论先行，以上统下，归类分组，逻辑递进。

它是一种十分底层的思考框架，可以被应用在许多领域。

我们本次主要讨论结构化思维如何应用在「解决问题」的领域。

在《金字塔原理》中，介绍了解决问题的逻辑为：

…序言的作用就是界定问题，金字塔结构则用来说明通过分析问题和寻找解决方案得出的步骤或理由（有时是演绎推理的结果）。

这之后还需要经过长时间的思考，才能得出可供交流的思想。以下是一个理想的流程示意：

所以我们可以得出，「解决问题」的方法大概分为4步：

1. 对问题进行正确的界定。
2. 拆解问题构成的要素，对其分析。
3. 寻找对策，制订行动计划。
4. 与相关方交流你的方案。

二、为什么结构化思维可以帮我们把握需求主动权？

相信大家都有听说过产品经理的本质工作其实就是：发现问题-定义问题-解决问题。

我们会发现这三个步骤里，后两个和解决问题的结构化思维是高度重合的。

「定义问题」其实就是结构化思维内的「界定问题」；

「解决问题」其实就是结构化思维内的「构建分析框架」和「找到解决方案」；

所以我们完全可以利用结构化思维，来帮助我们完成「定义问题」、「解决问题」的工作。

可能小伙伴有疑问：那「发现问题」又该怎么做呢？

发现问题是一个更大的领域，同时也需要产品经理拥有较强的洞察力和深刻业务理解力。

这并不是一蹴而就的能力，需要产品经理长时间的沉淀和理解。所以本篇文章暂不展开说明，我们主要说后面的「定义问题」和「解决问题」。

三、如何利用结构化思维主动发起需求？

1. 对问题进行正确的界定

界定问题的第一步，需要确认我们的「现状」和我们希望达到的「目标」是否存在差距。

现状和目标的差距，就是我们需要解决的问题。

以上界定问题的方法称为连续分析（统计学上称为序列分析），这是一种有效地解决问题的技巧。

例如我目前发现了系统优惠模块可能存在问题，那么这时候我的现状与目标是：

现状：目前系统优惠模块无管控无规则，部分订单优惠金额过大。

目标：管控优惠模块，财务部门可及时了解优惠造成的成本支出情况并可及时管控。

2. 对拆解构成问题的要素进行分析

拆解构成问题要素的方法是提出假设。因为此时我们并不知道问题可能由什么组成，所以我们需要先提出假设，后验证假设。

如何提出假设？

提出假设前，先确定好分析框架。

分析的思路可以大致分为3种：

1. 前后因果关系：通过这种行动会产生某种预期的效果。确定希望获得什么结果或效果，然后指出为此必须采取的行动。
2. 将整体分割为部分：最常见的例子是组织架构图。绘制组织结构图或行业结构图时，通常需要将整体分割为部分，或将部分组合成整体。
3. 将类似的事务归为一组：将有关联性的因素归为一组。

以上3种逻辑顺序既可以单独使用，也可以结合使用，但每组思想都必须至少存在一种逻辑顺序。

还是举例我的情况：

订单优惠无法管控，部分优惠金额可能超出预算，那么这时候我们需要去拆解，究竟是什么影响了优惠金额？（此处我采用的是思路2：将整体分割为部分）

1. 优惠券
2. 用户本身会员折扣
3. 各类营销活动折扣

那么我们可以针对以上要素一一假设：

1. 因为优惠券券额过大。
2. 因为会员折扣设计不合理，会员等级高的用户优惠额度太高。
3. 因为营销活动优惠金额过高。
4. 以上三种因素同时影响，叠加使用最后导致优惠金额过高。

如何验证假设？

验证假设的方法有数据分析、业务调研等。

这一步的目的是：通过详尽的业务分析和调研，确定我们所假设的问题是否实际存在。

刚才我们假设了4种可能的情况，那么下面我们根据4种情况来进行数据分析。数据分析的过程比较复杂，这里不赘述。最终分析的结果如下：

1. 优惠券的总优惠金额仅占订单优惠前总金额的5%，说明了优惠券本身的券额并不高。
2. 抽取高等级会员的订单数据查看后，发现高等级会员的总优惠金额也仅占总金额的3%不到，说明会员折扣不存在问题。
3. 抽取营销活动的优惠金额对比订单总金额查看后，发现营销活动的优惠折扣大部分都在60%左右，大大超出了财务部门的预算。

通过以上结论，我们发现：其实问题并不出现在会员折扣和优惠券，而是在平时的营销活动上。

于是下一步，我们就可以列出解决方案了。

3. 提出解决方案

最后一步提出解决方案，需要运用「MECE法则」来分析问题。

MECE法则的全称是：Mutually Exclusive Collectively Exhaustive，中文意思是“相互独立，完全穷尽”。

这是一种对于一个重大的议题，能够做到不重叠、不遗漏的分类，而且能够借此有效把握问题的核心，并解决问题的方法。

回到我们上述的例子：

我们已经发现了问题出现在「营销活动优惠金额」上，那么此时我们可以根据「相互独立，完全穷尽”」的原则，对各种解决方案做系统的逻辑细分。

在削减优惠金额的解决方案上，除了直接削减优惠金额本身，还可以从提高商品原价和控制最终交易价格入手。

我们得出的最终解决方案有3个：

1. 提高商品原价：每件商品原价必须高于成本价*%，保证不会因为优惠金额过高导致跌破成本价。
2. 控制优惠金额：控制每场活动的优惠金额，或控制每个月营销活动的优惠金额。
3. 控制交易价格：控制每场活动的最终交易价格，从而达到控制优惠金额的效果。

四、写在最后

总结下来，B端产品主动发起需求分为三步：

1. 界定问题，拆解为现状和目标，找到当下问题点；
2. 拆解问题构成要素，提出假设，验证假设；
3. 列出解决方案，使用MECE法则，穷尽可能的解决办法。

如果是企业自研产品，此时将想法推出去以后，大概率不会那么顺利的被执行。

我们还需要找到落地解决方案的核心卡点，也就是最可能反对你的人是谁，或者找到你的“关键推手”。

关于如何落地执行和推进，则是另外一个话题，我会在下一篇文章更新。

如果你有疑问和更好的办法，欢迎与我一起沟通交流。