我用40万学会了做SaaS产品的MVP( 二 ) 编辑导语：SaaS是一种基于互联

那如何找到最小的业务闭环呢？
【我用40万学会了做SaaS产品的MVP】当我们在规划一款SaaS产品的时候，最容易犯的错误就是把一个完整的大闭环误以为是一个小业务闭环；所以业务闭环是以产品的使用人为单位的，而不是以一家企业为单位的。
我拿长租公寓来举个例子，我们要看的是长租公寓业态中，运营管理人员的某个业务环节，比如客人的签约入驻然后激活一系列硬件等等，而不是去看整个公司下的业务流。
聚焦在一个角色下的某一个行为的闭环，就是最小的业务闭环。
这样我们就得出了一个结论， B端产品是不存在“小步快跑快速迭代”的，最小业务闭环不满足的情况下，很难验证需求的准确性，很可能会因为功能的缺陷导致了商家给出不好的反馈结果；我们就误以为求证失败，很可能是闭环没闭住，根本还没到验证那一步就被弃用了。
现在我们找到了求证点，做好了最小业务闭环，下一步就是要聊产品了。
三、MVP产品要像“针”我们都知道，一款好的产品一定是极端值较高的产品，如果一个产品什么都满足了一点一定不是好产品——这是常识，放到MVP产品上需要把这个点打的更加极致，这也就是为什么说MVP产品是一根针的原因。
产品设计要非常小同时精准，一针扎下去要么扎不透说明没做对，要么一针见血说明打中了。
我们先来看看TOC和TOB的业务有什么不同——C端面向消费者行为链条短， B端面向企业，环节多行为链条长；所以做C端产品我们可以通过非常感性的维度去激活用户从而拿到反馈结果，这个结果往往是数据导向；而做B端就相反了，要做到可靠安全以及合理，这是非常理性的，而且是群体的理智容不得你有半点风险；B端的MVP结果就相对不太容易被数据反映出来，各多的是主观体验和主观选择。
B端还面临另一个问题，服务企业需求完全不同， A和B不同B和C不同， A和C也不同，你没有办法像服务C端用户一样去一个需求解决清一色所有人的问题。
这就需要我们有更强的标准化能力，我们要找到这些企业里我们要做的产品中所求证的那个点下的共有维度。
还有一个不得不提的关键字， “成本”我们做MVP的本质就是去求证，如果没有成本的限制mvp就失去了意义，就不够精益了；但是我们也不能为了做小产品而去为了小而小，必须要能够满足最小的业务闭环。
这里本来要写个案例的，但是我把我们三个失败的MVP写完的时候发现涉及到一些没办法公开的内容，所以很遗憾我找不到更好的纯TOB或SaaS案例来描述了。
C端的案例很多但是我并不想写在本文。
四、跨行业创业TOB产品如何做MVP在跨行业做产品的时候，我们无论如何深入的了解行业了解商家，都一定无法和行业里的资深从业者的认知平齐，那我们有什么好办法来解决跨行业产品的MVP问题呢？
可以试试“核心用户倒推法” ，我们先透彻了解商户的运营模式，找到你需要求证问题的最匹配的商家，然后去无脑满足他们的需求——这个方法很有风险，但是相对比较适合跨行业创业者；这个思想是来自“信任度加权” 是指我们给每个人都需要听取周边专业人士的意见，然后在不同维度给不同的专业人士贴上一个权重，在我们决策的时候可以去放弃自己的一些执念，选择去相信权重更高的人的意见，这样可以提升整体的成功率。
当一个跨行业创业者去做早期产品验证的时候，可以采用这个方法——我们把不同的商家在不同的维度打一个权重分，然后在抛出我们要验证的问题，在各个商家中吸收意见和需求；有的是正向的有的是负面的，然后根据商家的权重分进行对冲，最终会得到一个结论，这个结论大概率不是创业者心中的最佳答案，但它是值得去尝试的答案。
五、现值与价值是MVP结果的衡量标尺如何验证我们的核心问题是不是值得做呢？
从两个维度来看——现值和价值。
现值是指这个功能在现在市场值得是当前市场中的价值，当下行业中需求可能的确存在；但是是否会随着市场的发展开始萎缩，我们当下做的这件事情，在未来的发展轨迹上是否还会存在，是不是会被更高维度需求直接覆盖掉，这就非常考验创始人的决断力。
价值很简单可以理解，最近《价值》这本书也很火，我们更多把价值对标为长期价值，也就是相对忽略眼下的利益，把目光放到更长远的未来——这个是SaaS厂商这一端的视角。