实战解析:MVP(最小可行性产品)验证新业务
编辑导语:若想开拓新业务,并检验业务思路是否可行,MVP是一个有效的思路验证方法,这一方法可以帮助企业节省成本,更好地做出决策。不过,在进行MVP验证的时候也有一些事项需要注意。本篇文章里,作者结合实际案例,总结了MVP验证新业务的流程步骤,一起来看一下。
背景
公司属于初创期,除核心业务外,想开拓一些新业务,但是在资源投入上有限制。在这种情况下,如果想进行快速尝试,运用MVP(Minimum Viable Product,最小可行性产品)思路进行验证,是比较合适的方案。
思路如下。
一、业务流程
产品经理必须要懂业务,不然设计出的产品就是花架子,不顶用。
首先我们来理清业务流程,公司的主营业务是海外的商账催收和征信调查,依托这两大业务建立起了一个风控平台,平台的用户主要是两类:
- 国外的催收专家;
- 国内的中小型外贸企业。
公司现在想在平台上开拓法律咨询的业务,以更好地满足用户的需求,希望通过产品来实现,业务流程如下图:
通过对整个业务流程对梳理,我发现有3个节点比较重要。
1)发现兴趣点
如何让用户对新业务感兴趣,让用户能够在产品上留下信息。
2)塑造信任
如何让用户能够信任平台,愿意尝试进行法律咨询。
3)支付报酬
如何让用户愿意为咨询付费。
我将始终带着以上三个问题,来设计法律咨询的产品,并尝试将问题解决。
二、产品流程
依据业务流程,设计了一套简易的产品流程。
1. 删繁就简
因为我们要考虑如何做最小化,所以整个产品流程都是正向流程,且仅有两个节点需要分支,暂时不做逆向流程和过多分支,可以尽可能地缩短开发时间。
根据业务和产品流程,我们再列出需求清单,并做优先级排序,需求尽量越多越好,因为我们后面要把他们砍掉(出于工作原因,这里就不放出具体清单了)。
注:MVP不是想得少,而是想得多,只不过是把多余的想法给暂时砍掉了而已。正因为想得多,所以才能放心大胆地砍掉不重要的需求。
2. 设计思路
理出流程和清单后,我们要开始着手画图了。那么主导设计思路的,除了MVP之外,还要带着之前三个未解决的问题:发现兴趣点、塑造信任、支付报酬。带着问题去设计,就有可能通过设计来解决问题。
这里用第一个问题来举例:如何让用户对新业务感兴趣,让用户能够在产品上留下信息。
通过分析页面和后台数据,我发现平台的用户转化率不高(具体数据不方便透露);通过进行用户调研,发现用户对产品的体验较差(具体数据不方便透露)。当然作为一个初创产品,我们也不能对其要求太高。我决定从转化率和用户体验上着手解决问题。
1)增加下单入口
新增客服对话消息可点击直接跳转,增加客服头像动画效果。通过好看的客服头像吸引用户点击,然后通过对话可点击跳转来吸引用户下单。
2)减少用户决策时间
- 之前的下单路径是:入口——填写表单(3个以上字段)——提交;
- 现在的下单路径是:入口——业务介绍(无必填字段)——提交。
精简了操作步骤,同时提供了更多信息,让用户能够更快地做出下单的动作。
注:MVP的设计思路绝不是简单,而是在简单的同时解决实际问题,让用户体验更好。
三、结果验证
MVP上线后,需要进行验证,才能知道业务是否值得继续推行,产品是否值得继续投入。验证的方法有很多,主流的分为定性和定量两种。
1. 定性验证
定性验证是探索性的研究,致力于确定用户需求,可以理解为“是不是”以及“是什么”,主要的方法有:用户访谈、情境访谈和卡片分类法。
放到这件案例中,定性验证的就是:法律咨询是不是用户的真实需求,用户对于法律咨询的需求是什么?需要使用什么方法来提供什么服务?解决什么问题?
2. 定量验证
定量验证就是通过一些数据指标来验证我们的猜想,可以理解为“怎么样”,主要的方法有:问卷调查、数据分析、A/B测试。
放到这件案例中,定量验证的就是:有法律咨询需求的用户占比多少?用户可接受的付费区间是多少?
因为本文主要讨论MVP的设计思路,这里就不对调研方法展开赘述了。
四、总结
在敏捷开发、快速迭代的互联网行业现状下,MVP作为一种设计理念,既能节省企业成本,又能快速拿到测试结果,十分适合想要开展新业务的企业使用。但是因为产品本身的不完整、样本量较小、周期较短,可能会产生以下问题:
- MVP是错的;
- MVP是对的,转成正式产品时效果不理想;
- 无法验证MVP的结果。
其实我们无需局限于MVP这一种设计理念,只要保持清醒的头脑,减少拍脑袋做决策,用数据和结果说话,我想,这就是科学的工作态度吧。
以上,谢谢观看!
本文由 @金瑞 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于 CC0 协议
可以详细介绍下如果确认最小可行的mvp么。具体删繁就简该如何做呢?
感谢分享~
运营有策略,产品懂业务,这事就成了
产品为啥懂业务呢,产品越懂业务,MVP的敏捷性就越高,不懂业务的产品10次迭代中间还有可能存在推翻重做才能实现目标,懂业务的产品3次迭代就搞定,当然,懂业务也存在对业务理解的深度,换个说法就是也要有很好的商业理解能力。
谢谢评论~
其实要懂业务的就是要求产品经理不能总是坐在办公司喝咖啡,而要深入业务现场,脚踏实地的做出符合实际使用场景,才能真正的解决用户痛点。