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

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