如何定义端产品的下

　　在上一篇文章如何定义B端产品的MVP（上）里面，我们谈到了定义MVP产品的前面三个步骤，确定产品定位，找到种子用户，确定产品路线，今天我们再来聊聊后面的几个步骤。
　　1。确定用户业务流程图
　　在产品路线确定完成之后，基于产品定义的路线，我们要基于业务目的来确定用户的业务流程图。
　　还是拿人事模块来进行举例，几个关键的用户业务流程图就包含比如说：员工入职流程，员工合同管理，员工异动流程（调职），员工离职流程等等。
　　确定用户使用流程图的目的是为了保证产品能够对各个角色的日常业务进行支持，在梳理的时候尽量完整，不要遗漏，也是为了后面梳理每块业务功能点清单以及定义优先级做好准备工作。这方面的文章也很多，笔者就不细说了。
　　2。确定功能点清单
　　基于产品的用户使用流程图，确定每个功能的线上功能点清单，类似下图所示：
　　在定义完成每个流程的功能点之后，要做一件事情，就是要确定哪些功能点事放在线上来实现，哪些功能点还是要维持线下的方式，这个也是很重要的一个步骤，可以参考一下如下的原则：
　　（1）线下处理极其灵活，没有什么规则，也很难通过梳理将目前的业务逻辑规范化的流程或者功能建议线下处理。
　　要知道软件的一个基本原则就是建立一套标准流程或者自动化的规则，如果线下处理极其灵活，很难将规则标准化，那么这样的功能是不太适合做成标准产品功能的，留一点标准的通用口子给到客户，让客户线下处理，将数据输入线上就可以了。
　　举一个例子，在薪资里面为什么有那么多税前调整项，税后调整项目，就是各种各样的情况太多，无法标准化，就留了一些口子给用户而已。
　　（2）线下处理比线上处理要方便很多。
　　每个业务流程如果你严格的去梳理功能点，发现会有各种各样的情况需要进行处理，这个时候非常考察B端产品经理化繁为简的能力，打一个大家都会碰到的公司里面请假的比方吧，会有很多人考虑设计如下的功能：
　　如果员工申请了休假，老板还没有批的时候，是否需要一个撤销功能，让员工可以撤销可以提交已经申请的单子啊？
　　如果老板长时间没有审批，是否要设置一个几天自动审批通过的功能，不同公司默认审批通过，审批拒绝是否还要设置一个参数啊？
　　如果申请休假，老板拒绝了，是否可以支持在原来的单子上面直接修改之后直接提交啊？
　　说实话，现实中笔者特别怕碰到这种逻辑严谨，又没有梳理能力的产品经理，盲目增加功能点，增加的功能点会带出很多其他的特殊情况，导致功能越来越复杂。实际在MVP阶段，这些场景统统不需要支持，但是要保证的一点是这些场景发生的时候，业务不至于走不下去。
　　事实这种情况MVP阶段只要保证支持最基本的业务流程，员工可以提交请假，老板可以审批通过或者拒绝，上次这三种情况前期就都可以支持：
　　对于场景a，用户可以跟老板口头或者微信说一下，让他拒绝就解决了。
　　对于场景b，不好意思，老板这么久没有批，现在通讯这么发达，微信跟老板说一声。
　　对于场景c，老板拒绝后，重新提交一张请假单子，输入日期和选择假种有那么大的工作量吗？
　　3。确定功能点的优先级
　　确定功能点的优先级一般来说需要依据如下几个维度：
　　（1）基于功能需求的强烈度
　　判断功能需求的强烈度，用户痛感强烈程度的指标是很重要的维度，比如说员工入职流程是否要支持员工自助入职（员工输入自己的基本信息），如果对于一个中小公司来说，一年也没有几个新员工入职，那么这种信息的输入完全放在HR端进行输入就可可以了。员工自助入职功能根本不需要，或者很后期才考虑就好。
　　如果目标客户是针对特大客户，每天新员工入职的量是很大的，如果这个是客户一个提升效率的主要诉求。那么前期的优先级就需要提高。切记所有的考量都要基于产品的定位以及业务场景，是任何判断的一个基准。
　　（2）基于功能使用的频率
　　频率也是功能优先级一个重要的指标维度，比如说组织架构调整的调整，有些公司可能一年都做不了一次组织架构的调整，那么组织架构调整的功能就可以优先级不要那么高。
　　笔者曾经看到一些项目的设计，前期就考虑了很多非常极端低频的事务处理。前期在极端情况处理的开发上面花费了大量时间，最后产品开发周期极其长。另外在产品设计上面，极端case的处理也揉在了正常流程中，导致产品极其难用。实际上这些极端低频的功能几年都用不了一次，完全可以放在后期。
　　另外前面一些年刮起了B端一切功能移动化的风潮，将很多低频使用，或者大多时候是用户坐在PC面前使用的功能移动化，实际上没有人用，浪费了很多人力物力，也因为复杂的功能让管理系统的移动端疲惫不堪，体验极差。在移动化如此盛行的今天，笔者想问您一句，您真的需要将功能移动化吗？
　　功能点的取舍是考验产品经理水平的一个很重要的衡量标准，不同的产品定位，不同的公司资源，不同的团队能力，同样的题目的最佳答案一定是不一样的。
　　（3）避免过度设计
　　有些产品经理考虑问题因为还是比较窄，也由于没有技术背景，不太了解不同设计对应的开发工作量，经常容易过度设计，那个提出app皮肤要根据手机壳颜色进行适配需求的产品人就是一个很典型的例子。
　　我也举一个非常简单的例子，在进行员工或者客户信息维护的时候，经常有员工或者客户的地址需要进行维护的情况，有些人有一个地址，有些人二个，最多有些人三个地址，于是可能有些产品设计很自然就设计对地址进行行级支持，支持无限添加扩展。
　　如果最极端的情况是三个地址，你的产品定位又不是支持可以全世界大客户，类似sap的定位，用列级支持最多三个地址就够了，开发工作量小，对于用户来说前端也挺易用。
　　整体来说，基于产品定位，业务场景，团队情况对于大小问题化繁为简，设计最佳，最简路径是非常重要的。通过上下篇这些步骤，希望可以帮助大家定义出一个B端产品的MVP功能。也欢迎大家留言讨论！
　　相关阅读
　　如何定义B端产品的MVP（一）