案例拆解：B端的MVP产品方法论你懂吗？
愿景：作为产品经理一年的产品经理，整合产品方法论，希望在实践过程中分享实际实施情况，给人灵感。
目标群体：产品人&年纪<3岁
idea：商品论的实效性和可行性
竞争对手：个人兴趣、时间、惰性
或者老规矩，在每次正式开始写作之前，都想说几句话，思考上面，打开这篇文章。在最后一篇文章《惰性思维对产品人的伤害》中，重点讨论了在商品人的工作过程中，如果没有一套科学的产品方法，没有自己的品牌思维，很容易陷入泥潭，迷失在产品的道路上，引起对自己商品道路的怀疑。
所以，在这里，本文想谈谈作为产品人的第一个产品方法论MVP这样在我们的产品工作中运行，使用后会有什么效果？本文可以整合作者的具体工作内容，谈谈MVP产品方法论，供大家参考和交流。
废话不多说，我们进入主题，本文将从五个部分进行描述，分别是：产品背景，产品反面典型，MVP理论概念，MVP在日常工作中的应用，商品效果。
一、产品背景
从小编之前的文章可以看出，目前小编负责的项目是G端大数据应用相关产品。本产品的主要目的是完成对政府机构人员的执法监督和规范，但从这一点衍生出来的产品功能范围特别广。
首先识别风险（风险类型包括根据执法过程直接识别风险和数据挖掘分析隐藏的执法风险）；
二是风险分析后进行风险分类审查处理（不同单位的审查方法和风险数据类型不同）；
第三，对单位和人员完成风险结果数据的纪律问责；
然后根据纪律后的整改情况、风险执法单位、人员进行统一考核；
最后，根据考核内容完成对单位、人员的奖惩。
自然，小编只是简要概述了商品的一般背景，不能详细说明。
二、商品反面典型
小编第一次接触的客户是负责本产品建设的甲方霸主。当时，甲方霸主直接梳理了执法过程中的35个风险点，这让第一次接触这个行业的小编感激不已。甲方霸主行业没那么好“无理取闹”嗯！随后小编开始按照这些风险点进行施工。
客户痛点最痛（1~5分，5分最痛）
数据源(根据数据易处理性1~5分，5分最容易解决)
开发难度(根据难度系数1~5分，5分最容易)
根据三者的总和，计算每个风险点的优先级，并优先进行商品设计和开发（这里是15点系统，可以根据需求数量扩展到100点系统）。项目启动2个月后，建设完成27个风险点，很高兴向甲方报告项目情况。然后挥手开始在一些县和地区进行试点应用，不时会有不同层次的领导来检查，兄弟单位会来学习。
在试点过程中，受到严重质疑，该平台无用！原因是：
数据不全，监督不到位；
风险数据有大量乱报；
服务不到位，只是一种处罚工具等等。
这时，小编明白，产品路径规划是完全错误的！
三，MVP的理论概念
MVP的概念是EricRies《精益创业》一书中提出的概念在书中解释为“最轻量级的可行性商品（MinimumViableProduct）”但将这一概念纳入小边最初的设计产品中，作者的产品规划也应被视为最轻的可行性产品啊，分阶段完成执法过程的执法风险监督。
但在试点过程中，有这么多问题，小边整合了B端产品的特点进行分析，B端子的主要特点是有工作流。
因此，笔者对B端产品的了解MVP的概念是“最轻量级的可服务商品”。服务型是指能够服务所有与业务相关的参与者。
四，MVP在日常工作中的应用
根据思考，小编开始根据大数据应用相关商品mvp设计产品的对策。
首先，选择一个有特色的亮点，监督行业A的风险（注：这不是一个风险点，而是一个类别，包括一个单独的风险类型！此外：如果是0到1的商品，可以根据需求池中的需求优先选择）MVP商品建设理念，为当前商品设计完善，整体MVP商品可通过以下流程表显示：
因而依据MVP网上商品至少要满足这三类单位/人员的使用和需求。此外，功能点必须设计风险分析、风险预警、风险异常、风险推送、风险审查、风险处理、风险整改、风险归档、风险报表统计等服务，形成完整的闭环MVP商品。
通过以上分析，我们也了解了这些服务的对象和需要包括进入的内容MVP这些功能实际上是由所选监管行业A的风险衍生出来的。但这也是小边在早期商品试错、商品试点和深入基层研究思考中理解的B端MVP设计产品的真相。
这里总结一下B端MVP商品工作方法有两点：
宏观把握客户业务
完成最轻量级商品服务闭环。
五、商品效果
迭代更新产品上线后，可在固定县区、固定部门进行试点，降低系统推广门槛。
快速验证产品的运行方式，是否符合业务部门/人员的实际需要。
在向领导汇报和演试时，可以实现一类业务的完整闭环，直观掌握系统的价值和服务程序的群体范畴。
有了基本框架，在后续的设计产品中，很容易进行商品升级迭代，整个设计理念将是一个闭环理念。
相关文章：
相关推荐：