对MVP(最小化可行性产品)的一点反思

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

fansi

一两年前接触了Lean UX的概念,也在实际参与过的项目里体会到一些MVP(最小化可行性产品)与敏捷迭代的实际应用。除了创业公司,一些大公司内部团队也在尝试推行这种快速验证迭代的策略,但这真的是最合适的解决方案吗?于我个人而言,在大公司里对其缺点感受反而更多,感觉MVP被当成了定位不清晰、用户特征模糊、业务逻辑不周的借口,也在无形中拉低了设计师思考与输出的质量标准,结果第一个版本上线后才发现错漏百出,设计师们忙着缝缝补补疲于奔命,久而久之就有些磨灭热情,而这种局部弥补也难以从整体上带动产品设计再上一个台阶。

拒绝借口,设计不该为产品买单

很多设计师都喜欢做To C的产品,觉得更有个人成就感,但现在的我却更喜欢To B,因为大多数To B的产品定位、用户群都非常清晰而有针对性,设计师可以一开始就往正确的方向上使力。而有一些To C的产品呢,产品经理根本就没想清楚产品定位与用户定位(也不能全怪他们,影响因素很多),直接搞个Design for all的口号,就让设计师辛辛苦苦画线框图画高保真出MVP,好不容易搞出来了,一句轻描淡写的战略方向调整,设计师们的辛劳成果一夜之间化为乌有。

敏捷迭代不是修修补补》这篇文章里有一段说得很好:“敏捷迭代在很多大公司其实是个口号,更多是漏洞百出、战略不清晰的借口。”,而奋战在一线的设计与开发,则是最直接的买单人。对那些打着MVP幌子来回避对产品定位、目标人群、业务逻辑进行清晰系统描述的借口,我们不应该纵容;设计师应该具备产品思维,并不是说一定要在未来转型为产品经理,而是可以更好地帮设计师从源头上减少不必要的时间精力浪费,毕竟你不能指望永远遇上足够靠谱的产品经理。

流失的种子用户

这一点Medium上有篇文章《So long MVP,Hello Minimum Loveable Product》已经说得非常好了,文中打了一个比方:“The MVP might validate that people like cake, but it won’t get people talking. The MLP should validate that people love your cake, will come back for more and tell their friends.”

432464-ebc8b8555826dbc9

简而言之,MVP一开始就将全量用户当做测试对象,用户也许会觉得不错,也会提一些建议,但也就是普通感受上的“不错”罢了,并不会觉得它多令人眼前一亮或觉得不可替代。但缺少针对性定位将导致产品很难有明确的忠诚种子用户群体,也失去了这些用户能带来的一传十、十传百的强大辐射,表面上只是流失了一两个种子用户,但算上用户口碑的影响力后呢?

《About Face 4》对用户目标的最高层面——Life Goals的描述是:“Life goals describe a persona’s long-term desires, motivations, and self-image attributes, which cause the persona to connect with a product. These goals are the focus of a product’s overall design, strategy, and branding.Addressing users’ life goals makes the difference (assuming that other goals are also met) between a satisfied user and a fanatically loyal user.”,如果希望产品能获得持久的用户黏性/活跃度,只让用户满意其实是不够的,APP相比实体产品几乎没有转移成本,哪天市场上冒出个多几个亮点的竞品也许用户就迅速转移流失了,这一点在工具类APP中体现尤为明显。产品设计在Life Goals这一层面上的表现将决定用户从满意到忠诚甚至自发传播之间的鸿沟究竟有多大,而MLP在这方面将可以比MVP带来更大的帮助。

亡羊补牢,无底之洞?

当一个定位不够清晰、逻辑不够严谨、设计不够精致的MVP上线后,如果可以继续推进下去,大量的迭代修改也是不可避免的。设计师和开发将不断地被各种用户吐槽转化而来的小需求狂轰滥炸,修修补补疲于奔命,看不到尽头,而这种修补也多是不痛不痒或顾此失彼,设计师则更容易被并不那么重要的细节困住,改动形不成一个整体,无法真正将MVP再提升一个档次。

在我最近参与的一个项目里,也出现了这样的苗头,源头是前期对一条核心的业务逻辑梳理不够清晰全面,中途又不断有从属该业务逻辑的需求加入,每次都是接一个需求加一个设计,局面慢慢有些失控;当我自己意识到这一点后,立刻提出应该用更体系化的方法来重新梳理流程,从整体角度来改进而非盲目纠结细节,和产品经理交流后发现双方想法不谋而合,于是立刻敲定接下来的方向,并寻求了Researcher的介入,把产品设计拉回到正确的轨迹上。

MVP因为在初期的低成本、快速而受到一些人的追捧,但他们却忽视了潜在的成本:对低质量的MVP,耗在迭代改进上的时间精力也可能要恐怖得多。而这个过程对于一个内心不够强大、热爱行业的设计师来说,很可能就慢慢磨灭了他对设计的热情,我曾经就陷入过这种迷惘、恐惧的无边黑暗无法自拔,认真思考过是否转行,虽然今年已经基本从中走出并渴望成为国内UED行业专家级的人物,但仍然心有余悸,这或许也是我不打算转产品经理却开始花很多时间去思考产品、思考业务的重要原因吧。

 

作者:鸿影Akiko授权转载

原文链接:http://www.jianshu.com/p/2e1ca1c22b65

您的赞赏,是对我创作的最大鼓励。

评论( 3

登录后参与评论
  1. 文章写的好好,说的很到位,都提出小步快跑的理念,但有时候真的未必是正确的

    回复
  2. 最小可行性产品是一种以验证性学习为基础来开发产品的一套方法,不要忽视“可行性”,片面的强调迭代速度牺牲质量和创新的行为都是在给自己刨坑。

    回复
    1. 回复

      评论的好好啊

加载中