toc|从商业视角看MVP在SaaS中的落地与实践( 六 )

文章插图
如果要满足这样的业务需要一个怎样的闭环产品呢，大家看左边的这个图。从资产收录环节开始到收益分配环节结束，经历了至少6个节点，我们都是做产品的，完成这样的一个系统工作量可想而知，而且还没有经过MVP的验证，一单出错成本非常可观。
那最小业务闭环呢，大家看右边的这张图。
从资产上线环节开始到数据监控环节结束，仅经历了4个环节，我们对比可以发现一个特点，较大的闭环是以企业单位的，而做小业务闭环是以角色为单位的。

文章插图
所以找到最小业务闭环的方法其实就是聚焦在某一个角色下的行为闭环。

文章插图
这样我们就得出了一个结论，SaaS产品是不存在“小步快跑快速迭代”的，最小业务闭环不满足的情况下，很难验证需求的准确性，很可能会因为功能的缺陷导致了商家给出不好的反馈结果，每个环节都做了一部分，而每个环节中的最新小闭环大概率都没闭住，你认为持续迭代就行，可是用户根本不买账，用不起来。
我们就误以为求证失败，实际上根本还没到验证那一步就被弃用了，所以小步快跑快速迭代也是以最小闭环为单位的。
而tob业务下即便在小的闭环，也比TOC产品大的多。
所以我们做SaaS的产品经理一定要警惕老板或技术要求我们小步快跑。
到这里，我们已经明确了MVP的求证点，还通过最小业务闭环的方式，打造了一个小型的MVP产品，还剩下最后一个要格外留意的维度，就是避免场景冲突。

文章插图
我们都应该有过这样的经历，你推出了一个SaaS产品，你的客户试了试对你说，你的XXX功能有怎样的问题，我用不起来。
这既是场景冲突，也就是说虽然我们满足了整体的一个业务闭环，但是在实际的运营中有我们没有考虑到的场景细节，导致商家无法全员推广或使用该产品。

文章插图
也就是说，在特定场景下，某一个需求的不满足，需求与业务场景存在冲突，并因该冲突导致整个业务链条无法正常运行的情况。我们就可以称之为场景冲突。
最典型的案例就是权限问题，给不该看的角色展现了过多的信息。比如上面举例的物管公司，会分为业主端和运营端，业主端如果过多展示经营信息，过于实时的表现出经营状态，就会让业主更深度和高频的关注和参与经营，给托管公司造成运营上的困扰。
再比如，我们做了一个帮助用户顺利入住民宿的工具，因为民宿很多是隐藏在小区里的需要引导。然后这个工具需要匹配订单，而用户这边获得指引工具的方式是通过手机号，这就有可能出现一个问题，预订人不是入住人，如果该问题不解决，这个工具并不会帮助运营人员减少工作量，反而会让他们提心吊胆，半夜客人没到房间不敢睡觉。这个功能就完全起不到作用用不起来。
大家注意一下这个点就好，主要是需要在特定的业务场景中要提前找到可能出现的场景冲突规避掉MVP在触达商户使用时被用起来的几率。

文章插图
到这里我们就完成了整个MVP内容我们来总结一下。
第一步：找到案关键求证点
（以北极星指标反推，找到与指标关联的核心业务环节加以求证）
第二步：设计最小的业务闭环
（以组织中的某个角色为单位展开业务流程下的产品设计就是最小业务闭环）