编辑导语：关于B端产品的相关知识，大家已经了解了不少，然而关于B端产品方法论，不同的人会有不同的见解。本文作者通过回顾自己4年的平台产品工作经验，总结了“2.5”个B端产品方法论，希望对你有所启发。

距离上次发表文章已经过去30+个月了，在当下这家公司负责了15+个项目（还没算上一些不成项目的流程优化），高效的工作效率/沟通效率让我能够同时负责多个项目且脑子不堵车。

接近4年的平台产品工作经验，又临近工作更换的节点，将这段时间的一些个人思考和收获梳理成型，和大家分享。

前言： 由于行业/公司/部门的情况不同，造成了不同产品岗位所需要的能力不同。但抽象一下，所有（产品）岗位提供的都是解决问题的能力。当然问题是五花八门的，但解决问题总有相同的方法/思路。

笼统来说，解决问题总共有三个步骤，且分先后：

1. 分析问题关键
2. 提供解决方案
3. 效果验证
4. …
5. 循环迭代（分析/解决/验证 新的问题）

一、分析问题

在分析问题上，有个很著名的梗<怎么把大象放进冰箱？>。答案大家都知道<打开冰箱门，把大象放进去，关上冰箱门>，不妨就以这个问题来展开讨论。

1. 细化流程

分析问题的首要步骤，毫无疑问是要先细化问题。一个天马行空的问题，不代表问题本身100%是天马行空的，一部坏的电视机可能只是某个零件出了问题，放大象进冰箱我们也可以帮忙开关门。

可惜的是，大部分人的第一反应是对问题本身全盘否认。而一旦否认问题后，问题解决者的价值也就一同被否认了（或者变成了否认提出问题的人的观点），毕竟没人愿意为一个解决不了的问题去投入成本。

回到放大象进冰箱的梗，细化流程之后，问题就清晰很多了。

1. 打开冰箱门——可行（成本低）
2. 把大象放进去——存在难度（成本高）
3. 关上冰箱门——可行（成本低）

再对第二步拆分，从某地把大象运到冰箱前，引导它进去。流程拆分得越细，要解决的问题就越清晰，相应的，解决问题的方法也就越清晰。

2. 到底要多细

我的答案是，细到能解决的地步，或者尽你所知道的程度就足够了。这分两步细到能解决，问题解决了，继续细没意义，除非再细下去能有替换方案降低成本。

尽自己所能的细，是自我安慰的选择。信息/知识 容纳量的大小，在一定程度上等于一个人的智商/能力/价值的水平，不要在超出自己能力范围的东西上对自己要求过高，否则只会给自己带来挫败感。

而尽自己所能的细，要做到这一步也不容易。这要求我们对自己所了解的东西融会贯通，做到举一反三。在工作场景中，这要求我们能够结合项目过往的内容/正在执行的方案/将来可能的规划，给出一个成本最低的答案。

再结合例子来看：

1. 从某地获得大象使用权（当然偷一个也行，不过违法的成本可能是无限大的）
2. 运到冰箱前
3. 引导它进去

如果公司有钱买下一头大象，那么使用权问题就解决了。如果公司刚好是海运行业，那么运输问题就解决了。如果公司里面有员工当过动物园饲养员而你又知道，那么引导的问题就解决了。

但公司能用的资源往往不是充足的，如果能创造出未有的方法（将成本无限大的问题转为成本有限的问题），或者选择更低成本的方法去解决，中间的gap就是问题解决者的价值所在了。

这个方法在现实情况中也是多种多样的，可能是员工的人脉关系，过往工作的知识储备等等。

3. 为什么要做？

在ab两点上，都是对问题提供解决方案的思考。

而在实际工作中，特别是产品经理，经常遇到上下游提出的各种需求。这要求产品经理在问题的出发点上进行更多的思考，做不做，为什么要做，做了后收益是否足够可观，而不是直接埋头去想怎么做。

如果仅是为了展示部门能力而把大象放入冰箱，那么将部门的资源拿去买大象（内部消耗）是否值得？但如果是为了向股东/客户展示能力而获得更多合作机会，那么听上去就是一个不错的方案了（不过我在工作上，很多时候都是先思考细化流程，分析发现成本过大，反推目的，梳理责任边界，然后拒需求的hhh）。

在分析问题的方法上，分享一些我实际遇到的例子，解决方案足够旁大的都已经成为我简历上的项目了（我的经历在文末）：

1. 如何减少一线人员的划水情况？
2. 如何对比内外部模型水平差异？
3. 如何降低线上工作和质检工作环境的差异？
4. 如何设计一个评分弹窗？

实际上问题3在实际工作中没有暴露出这么明显，当时情况是质检准确率总是比较低，经过一番调研后才发现这个问题，这也比较符合大部分产品经理实际工作遇到的情况。

而问题4是我在面试中遇到的一个问题，它掠过了问题分析的步骤，要求直接提供问题的解决方案。但是评分弹窗何时出现，用户评分结果要用在哪里，都没有给出，设计起来就比较困难了，面试结果也不如人意。

那么如何设计一个评分弹窗呢？

二、提供解决方案

后台产品的设计往往是为了支撑上游业务，提供信息化的传输/协调能力，从而加快整体流程，达到节省成本的作用，规范/加快/简化业务流程是解决方案重要且基本的要求。

在此之上，节省开发成本的多少，是区分产品优劣的另一个因素。如何降低开发成本呢？有三种可能，且一般情况下优劣同先后顺序：

1. 当下开发成本为0

这意味着，用现有的流程去满足新的业务需求。

已有流程可能不完美，但如果能快速实现，且满足业务方的关键要求，对比之下便是最好的选择。还有一点是，紧急的流程可能是低频且不重要的流程，毕竟如果足够重要，往往早已实现，或在部门的大规划上。

入门的产品经理在面对业务需求时，对现有功能/历史情况不了解，即使明明有菜刀了，还要另外造一把匕首。

2. 有多个方案的情况下，选择开发成本最小的一种

运大象到冰箱前，还是运冰箱到大象前更简单？新规划一条航线去运大象，还是将原定航线上的船空出来一个位置比较节省成本？这个选择很简单，但可能会和3冲突。

3. 流程可兼容日后流程/规划，节省以后的成本

如果逼不得已要新建一个流程，最好将其做到足够通用（减少个性化）。而通用的要求是，先将多个流程的维度抽象出来，变成一个个个性化的值。这么说有点模糊，放出我一般梳理需求时都会用到的excel表：

（表1）

（表2）

表1是对表单设计时的信息梳理。后台的每个任务（电商入库，每个货物/包裹都是一张入库流水单；oa系统，每个用户/id都是一条记录。

如果信息过多，则通过uid将储存在不同库表的信息关联起来）都对应一条数据记录，而每条数据记录都有自己的信息，通过将实际的线下流程节点和记录的状态数据变更触发点关联起来，一个个流程便可以实现。

可以看到，我：

• 首先将每个任务需要记录的信息维度列出，比如任务名称/任务时间/…这要求我们对所有场景的流程需要用到的相同信息抽象出来；
• 再将信息维度归类，归为任务信息/业务范围/投放时机/…信息归类可以帮助产品自己对每个信息的用处有更深的了解，对开发同学设计库表，理解业务时也有帮助；
• 根据每个场景，制定每个维度里面都有什么值。

表2与表1的区别在于，表1是对一个个任务（如实物）的信息进行抽象，表2是对一个个流程（虚物）的将信息进行抽象。只要练习多了，就可以将不同对象都按照不同维度抽象起来。

实际上按照不同维度来抽象描述，这和技术同学的[面向对象编程]有相似之处，而日常在介绍各类内容时，我们也是按照一定逻辑/维度顺序的，比如时间顺序、空间顺序…

这个方法可是我的压箱法宝了，它帮助我在一天内就把这个容纳了双审/质检/培训的系统方案给梳理完善出来。当然，我所负责的业务的流程复杂程度相对而言是比较低的，有些行业的线下业务流程可要复杂得多，但抽象总是有用的。

以电商流程为例，如果抽象的流程为[入库]，那么购置的货物入库/退货入库/调仓入库/…是不是都可以使用同一套流程呢？只是货物来源不同，那么货物来源又可以定义为一个维度了。

三、效果验证

这part主要描述的内容是 [制定关键指标]（结果），以及不只看[关键指标]（关注过程）。就当0.5个，下次有机会再分享吧～

本文由 @Ien 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自unsplash，基于CC0协议