如何做一个新产品的第一个版本:关于MVP和上线时间的权衡

最新文章 6754℃

为什么第一个版本要是MVP?为啥要梳理MVP?书里(《精益创业》)告诉你,你需要用一个最小可行性的模型去验证需求。用最小的代价去验证用户是否买账,就算是验证出来是伪需求,也方便及时调整方向或止损。

但是在我的实际经验中,MVP,实际通常是为了保证上线时间,被砍的光秃秃只被保留最核心功能的产物,为什么?

 

因为人手永远不够,老板要求上线的时间永远都紧迫。

 

开始设计一款新产品的时候,作为一个逻辑完整思路清晰目光长远牛逼哄哄的PM,可能通常会把整个产品设计的大而全,脑中有宏图心中有草原,但是如果一股脑都开发了是不太好的,因为功能越多,涉及到的交互细节越多,你花时间去设计这些大大小小的逻辑的时间越多,越有可能在一些不重要的细节、交互上浪费时间来回纠结。如果不确定这个产品的技术成本,那还有可能需要花时间和开发人员扯皮,权衡开发时间和收益。碰到好脾气的开发,可能自己悄悄花很多时间做了,碰到脾气不好的,可能就会指着鼻子骂你,做的产品没有意义。

那么如何避免这种情况呢?

 

 一个字:砍

 

其实砍需求是不太容易的,这不是打脸吗?!那怎么办? emm,那就给自己一个台阶下吧:你需要列优先级,先列大的功能点,再列小的。优先级靠后的往后面的版本去排,具体到版本号,大概排期1-4个大版本,第一个小版本里可以放4-5个小版本。

这样列完MVP就差不多可以做到心中有数了。

举个栗子,我们来看下抖音的mvp。

第一个版本的抖音,做了3件事,看视频、简单的录视频和关注。没有现在的发现页卡,没有美颜、贴纸、也没有热门话题,精选视频的标记,也没有私信,简简单单,只有最最核心的录视频和看视频功能,这就是它的MVP。

因为功能足够少,产品在后续迭代就有无数种可能和方向,业务重点也可以灵活的调整。

你自己梳理完就结束了吗?并不是的,靠你自己,可能只能完成50~70%的样子。why?请接着往下看。

初步的mvp梳理完,接下去就交给交互设计了,完成后开评审会。

第一次评审会非常关键,它会让你对MVP有更清晰的认识。因为这个会上,一定会被开发质问和喷。这次会上需要尽可能讲的细,尤其是你感觉不太好做的功能(需要对开发有一定了解),会上沟通,确认好大概的开发时间,如果开发告诉你某个功能耗时非常长不想做的时候,你就需要注意了,先记录下来,然后思考这个功能能否再拆分的细一些,把一些功能往后面的版本放。会议结束后,及时整理笔记,拆分耗时长的功能,重新梳理优先级,把最重要的保留,其他的往后面的版本放。

做完这一步,MVP基本就90%成型了。

接下来就是开发阶段,开发阶段,依旧还是会和开发有沟通,协商和调优先级的情况(简称撕逼),和之前的套路一样,碰到开发耗时长的功能,重要功能的做拆分,选出高优先级的,不重要的功能,就往后放吧。

就这样,等开发全部提交测试的时候,MVP就定了(如果没有被硬插新需求)。

从上面的过程来看,MVP的梳理过程中,开发哥哥们帮了很大的忙, 有句话说的好,君子性非异也善假于物也。不要拍被喷,因为比起你的成长收获和产品推进来说不值得一提,只要最后的需求都是合理的,他们还是会按时去完成的,而且,他们不做也得做呀(滑稽˃ꌂ˂)

砍需求看上去是件不容易的事情,但是它的意义还是很大的,在这过程中,你会一遍遍反复的去思考一件事:

什么才是我这个产品最重要的功能,我们的思路和主线会一步步的清晰,也会更关注产品本身的核心功能和产品定位。