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

SaaS张大伦 2023-07-26 14:24:02

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

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

说正事。

从今年开始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问题呢？

可以试试“核心用户倒推法”，我们先透彻了解商户的运营模式，找到你需要求证问题的最匹配的商家，然后去无脑满足他们的需求——这个方法很有风险，但是相对比较适合跨行业创业者；这个思想是来自“信任度加权” 是指我们给每个人都需要听取周边专业人士的意见，然后在不同维度给不同的专业人士贴上一个权重，在我们决策的时候可以去放弃自己的一些执念，选择去相信权重更高的人的意见，这样可以提升整体的成功率。

当一个跨行业创业者去做早期产品验证的时候，可以采用这个方法——我们把不同的商家在不同的维度打一个权重分，然后在抛出我们要验证的问题，在各个商家中吸收意见和需求；有的是正向的有的是负面的，然后根据商家的权重分进行对冲，最终会得到一个结论，这个结论大概率不是创业者心中的最佳答案，但它是值得去尝试的答案。