我用40万学会了做SaaS产品的MVP

编辑导语：SaaS是一种基于互联网提供软件服务的应用模式，做行业SaaS或其他TOB产品时总会遇到更加复杂和多元的问题，这就是缺少闭环；本文作者根据自身的创业经验，给我们分享了如何做SaaS产品的MVP，我们一起来看一下。

先跟大家问个好，好久不见，我真的太久没更新了，主要原因是最近个人状态有了一个比较大的变化，之前有说到过我从今年开始做自己的公司了；距离上一篇文章有小半年了，上次是第一笔融资到位之前，公司还没正式成立，有时间写写；现在公司走上了正轨，团队也较为稳定了同时第二笔资金到位，压力稍微得到了缓解，所以在周末抽出时间来写写这几个月经历的一些事情。

这个号还是会以产品内容为主，输出一些我深度的具有独立思考的内容；不一定是对的，但我希望是能够触发读者思考的，如果内容可以激发大家的讨论或辩论就再好不过了。

说正事。

从今年开始TOB被推上风口浪尖，SaaS作为主要的产品形态终于熬到了出头之日；我在16年就操盘做过SaaS产品，那个时候苦不堪言，商户没有付费习惯，资本市场还在TOC业务上砸钱，产品本身也没有定式，大家都在探索。

我作为产品经理第一次面对SaaS产品也是一脸懵逼，在摸索的过程里我们产品团队成功的浪费了公司的宝贵资金。

今年我创立自己的SaaS产品后，对资金的投入格外谨慎，在有限资金的压力下做决策是一个非常锻炼人的事情，也倒逼我们必须把事情一次做对；因为没有第二次试错的机会，一次搞不定可能公司没了；于是我们不得不更去找到一个TOB的MVP方法，来提高每个产品功能/模块与市场的匹配率。

一、MVP的核心是求证

没错，“求证”才是做MVP的最本质的价值。

我们并不是要为了做一个小产品而做MVP，也不是把一个产品做的很小就是MVP；真正的MVP甚至都不需要做什么产品，所以我们说只要能围绕着“求证”这件事展开的一系列低成本的验证方法，我们都可以认为是优秀的MVP。

举个例子：

我有一个好朋友，她是一名室内设计师，有一天她找我说想做一款可以帮助室内设计师群体快速解决样板间搭建的系统工具——可以通过组合产品中提供的优质软装产品快速搭建出一个设计方案，付一定的费用就可以拿到这个设计方案；并将相应的软装产品一并下单购买，做到高效产出设计、高效完成商品采买。

我们抛开这个案例在商业上的可行性，单纯的以MVP的视角来分析；如果做这个项目，最应该“求证”的那个关键问题是什么？

我们乍一看这个项目需要的维度还挺多，又需要工具，又需要丰富的商品，又需要线上支付，其实这些都不重要。

最终分析下来要验证的核心观点非常简单——就是看看能不能通过组合模板的方式来替代掉室内设计师原有的工作方式，仔细想想没错吧。

所以这个点来看验证方法其实很简单，可以借助第三方工具，通过表格把模板制作好；涉及到的软装商品直接从淘宝选购链接贴进来，然后以有赞商城为售卖节点来进行销售，在设计师群里进行推送和描述；也可以写一篇公众号的文章来介绍这样的工作方式，如果有设计师购买，我们就去淘宝下单；这样就轻松快速的验证了，设计师是否接受这样的全新工作方式。

好了，快速结束这个案例，毕竟聊B端的MVP才是本文的重点，经过上面的案例大家已经对MVP的核心概念达成了共识；但其实这个案例还是比较轻的，往往在我们做行业SaaS或其他TOB产品的时候会遇到更加复杂和多元的问题，比如你会听到商户说：“你XX功能都没有，这个功能我肯定也用不起来”，没错这就是B端场景下很典型的问题：“缺少闭环”。

二、B端MVP首要考虑最小业务闭环

什么是最小闭环呢？其实不难理解，一件事有清晰的落点能够结束就可以简单理解成闭环，那在TOB产品中，我们的闭环又该如何理解呢？

SaaS产品一定是服务于某些业务场景下的，SaaS产品的某个功能点能够在特定场景下解决商家工作人员的完整支持操作过程，这就是闭环，但是我们可能面临一个普遍现象，那就是“闭环过大”。

比如上面举的案例，如果做这样的一个软装设计师SaaS根本无法落地，这个闭环太大了；所以找到最小的”业务“闭环才是B端产品去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厂商这一端的视角。

还有一个视角是对商家的解释，我们都知道商家不会因为你比他的产品便宜一万块钱就去选择那个更便宜的，商家会看谁给我带来的价值最大化；这个商户眼里的价值就比较难衡量了，包含降本增效、品牌溢价、或者是单纯的创始人喜好，维度太多，我们有个感受就行。

那这两个维度和MVP的验证结果有什么关系呢？

我们公司目前还是创业阶段，还没有到可以加码增长的时候，这个阶段的SaaS最大的特点就是需求不完整，商户无法在你一家得到多个维度问题的解决；那么把单点问题切透让这一个单点成为行业中最大的价值输出产品，以这个核心视角去规划MVP去验证各类产品功能。

我们拿到求证结果后，就需要做一个对比，现值和价值的对比，完全偏向于长期价值可能会导致早期增长乏力PMF持续跑不通——过于偏向现值会导致经历分散，大量的MVP被验证通过，团队压力剧增，短期数据可观但很快到达增长极限，获客难度也会提高，你发现商户觉得你挺好但是就是用不起来。

所以去平衡一个求证点带来结果的现值和长期价值，最好的状态是结果在我们期望的战略发展道路上不偏不倚。

六、最后

本文和40万有啥关系，我们团队从创立到现在大约花了差不多40万，我们踩了很多坑，做了很多不能说坏也不能说很好的产品功能。

于是在一个焦虑睡不着的夜里，决定痛改前非，把过往的反思和尝试总结成了这篇文章，希望可以激发你的深度思考。

 

作者：张大伦，公众号：张大伦（ID：zhangdalun010）

本文由 @张大伦 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于 CC0 协议