案例拆解：B端的MVP产品方法论你懂吗？

• 愿景： 作为转行成为产品经理1年的产品人，结合产品方法论，在实践过程中的具体执行情况，希望分享出来，给人以启发。
• 目标人群：产品人&年龄<3岁
• idea：产品论方法的有效性及可行性
• 竞争对手：个人兴趣、时间、惰性

还是老规矩，在每次正式开始写之前，都想唠叨几句，反思前文，开启本文。在上一篇《惰性思维对产品人的伤害》中，着重论证了在产品人的工作过程中，如果没有一套科学的产品方法论，没有自己的产品思考，是很容易陷入泥淖之中，迷失在产品的这条道路上，导致对自己产品道路的怀疑。

那么，在这里，本文想谈谈，作为产品人的第一个产品方法论的MVP到底在我们的产品工作中是这么运作，到底应用之后会有什么样的效果？本文在这里将会结合笔者的实际工作内容，来谈谈MVP的产品方法论，供大家参考与交流。

废话不多说，我们切入正题，本文将从五部分进行描写，分别是：产品背景、产品反面教材、MVP的理论概念、MVP在实际工作中的应用、产品效果。

 一、产品背景

从笔者之前的文章就知道，当前笔者负责的项目是G端的大数据应用相关的产品，这款产品主要是为了实现对政府部门人员的执法监督、执法规范，但从这个点衍生出来的产品功能范围就特别宽。

• 首先需要识别风险（风险类型包括根据执法流程直接识别风险和数据挖掘分析隐藏的执法风险）；
• 其次是风险识别之后需要进行风险分类核查与处理（不同部门的核查方法和核查的风险数据种类都不同）；
• 再次是针对风险结果数据实现对部门、人员的纪律问责；
• 然后是根据纪律之后的整改情况、风险执法情况等维度对部门、人员进行统一考核考评；
• 最后是根据考核考评的内容实现对部门、人员的奖惩。

当然，笔者只是简要概述了产品的大体背景，不能详尽述说。

二、产品反面教材

笔者刚开始接触的客户是牵头负责该产品建设的甲方霸霸，甲方霸霸当时直接为我们梳理了在执法过程中的35个风险点，这让第一次接触这个行业的笔者感激涕零啊，甲方霸霸业没有那么“无理取闹”嘛！然后笔者就开始根据这些风险点，进行建设。

笔者遵循的产品设计优先级的原则是：

1. 客户痛点最痛（1～5分，5分最痛）
2. 数据来源（根据数据易处理性1～5分，5分最容易处理）
3. 开发难度（根据难度系数1～5分，5分最容易）

根据三者相加，计算每个风险点的优先级，按照优先级进行产品设计及开发（笔者这里是15分制，可以根据需求数量，扩展到100分制）。在风风火火启动项目2个月之后，建设完成27个风险点，很高兴地向甲方霸霸汇报项目情况。然后一挥手就开始在个别区县的进行试点使用，不定期的会有不同层级的领导过来视察，兄弟单位业会过来学习。

这试点的过程中，就被严重质疑，这个平台没用！原因是：

1. 数据不全，监督不到位；
2. 风险数据存在大量误报的情况；
3. 服务不到位，只是一种惩罚工具等等各种各样的问题。

这个时候，笔者知道，产品的路径规划完全错了！

三、MVP的理论概念

MVP的概念是Eric Ries在其创作的《精益创业》这本书中提出的概念，书中对其解释为“最轻量级的可行性产品（Minimum Viable Product）”，但将这一概念套用在笔者刚开始的产品设计中，笔者的产品规划应该也算是最轻量级的可行性产品啊，对执法流程分阶段实现了执法风险监督。但在试点的时候，却出现这么多的问题，笔者结合B端的产品特征进行分析，B端的主要特征是有工作流。

因此笔者对B端产品的MVP的定义是“最轻量级的可服务性产品”。可服务性，是指能够服务与该业务相关的所有参与人员。

四、MVP在实际工作中的应用

通过反思，笔者开始对大数据应用相关的产品按照mvp的策略来进行产品设计。

首先选择已建成的某个有特色的亮点、难点的监督领域A的风险（注意：这里不是某一个风险点，是某一类，包含了一个独立的风险种类！另外：如果是0到1的产品，可以在需求池中，通过需求的优先级进行选择），按照MVP的产品建设思路，对目前的产品进行设计完善，整个MVP产品可以通过如下的流程图展示：

通过上述的流程图，我们可以知道，与该类风险相关的部门/人员有3类：责任部门/人员、监督部门/人员、奖惩的部门/人员。

因此根据MVP的思路，上线的产品至少要满足这3类部门/人员的使用和诉求。且功能点需要设计风险识别、风险预警、风险异常、风险推送、风险核查、风险处理、风险整改、风险归档、风险报表统计等功能，这样才能形成一个完整闭环的MVP产品。

而且通过上述的分析，我们也明白这些服务的对象以及需要囊括进MVP的功能，实际上都是由于选定的监督领域A的风险而衍生出来的。但是这也是笔者在进行了前期的产品试错，以及产品试点和深入基层调研反思才明白的一个B端MVP产品设计的道理。

这里总结一下B端的MVP的产品工作方法就是两点：

1. 对客户的业务有一个宏观的了解；
2. 实现最轻量级的产品服务闭环。

五、产品效果

1. 迭代更新的产品上线之后，可以针对性的在固定区县，固定部门进行试点，降低系统的推广门槛。
2. 快速验证产品的运转模式，是否贴合业务部门/人员的实际需求。
3. 在给领导汇报、演示的时候，可以实现一类业务的完整闭环，对系统的价值以及系统服务的人群范围有一个直观的了解。
4. 有了基础框架，在后续的产品设计中，很容易进行产品升级迭代，而且整个设计的思维都会是一个闭环的思维。

最后：B端的产品，一定要有产品服务于业务闭环、服务于业务人员、服务于领导的特点。