为什么这两年最火的 MVP，远不如设计冲刺法好用？

2017-01-19 09:46:00

编者按：这两年很多设计团队都喜欢用MVP（最小可行性产品）快速开发试错，但今天要告诉大家的是，最好的方式可能是谷歌的设计冲刺法。原因见下文。

越来越多的团队开发最小可行性产品（Minimum Viable Product，简写MVP），快速推向市场试错。不过在快速的同时，忽略了试错的本质，最后沦为了快速开发的代名词：

缺乏试错目标，MVP的没有上线标准，更有甚者推出MVP1.0，MVP2.0…
我们容易把MVP等同于粗糙的版本，有些重要的细节被忽略了；
把MVP推向市场后效果不佳，把问题归结到这个“产品”做的不够好。

在精益思潮的影响下，越来越多的人抛弃早期调研，把产品盲目投放到市场中，期待理想中的答案。但是“期待”和“验证”区别在于，验证需要建立在明确的假设之上。期待则意味着你对结果是没有预期的，投放到市场后，有可能意外的成功，但大多数情况下都会死的不明不白。

定义问题比解决问题更重要

不要用战术的勤奋去掩盖战略的懒惰，是什么造成了我们战略上的懒惰？主要的因素是“抽象性”。通常在团队协作中，我们习惯把抽象的东西放到一边，埋身于具体的战术。“定义问题”就属于战略层面，也是比较抽象的过程。不同背景的人看待问题的角度也不尽相同，更加深了定义问题的难度。

还有一种将虚荣指标作为团队目标，例如“半年内实现盈利”，“日活200万”这类KPI，把真正的问题掩盖在了结果驱动的假相下。基于这类虚荣指标，不同职能部门往往专注于不同的战术，战术与战术之间缺乏协同，有的时候还会出现前后矛盾的情况。那么“问题”和“指标”之间的区别在那里？什么样的目标更具协同性？

指标是主观视角，问题是客观视角，对于产品或服务来说，客观视角就是客户视角。
战略层的用户问题并不是易用性一类问题，通常是指我们需要解决什么样的用户，什么情况下的痛点。
多花点时间去认识和定义问题，问题之间的差异甚至体现在用词上。例如解决用户“闲聊”和“商务咨询”需求，都可以归纳为解决“沟通”需求。但如果把问题定义为“解决用户的沟通需求”，意味着产品的边界和微信一样。
基于用户问题去拆分职能KPI，例如目标要解决的问题是“提升协作效率”，那么市场部门的KPI就不是简单的“XXX万新增用户”，而是“XX万有效协作项目”。

来自DesignThinking的原型启发

MVP的概念来自原型（Prototype），《精益创业》的作者EricRies有提到来自于设计思维（DesignThinking）的影响。1999年IDEO创始人大卫凯利接受ABC专访，拍摄了的一期名为《the Deep Dive》的纪录短片，短片中他和团队一起花一周的时间创建了一个手推车原型，通过一周建造的原型，在基本能够反映主要功能和创新之处的情况下，放置到真实的环境中测试真实的使用体验，这也是另一种形式的MVP。

对于互联网产品，我们验证一个问题，并不意味着非要开发一款App或网站。把MVP锁定为launch的第一个版本，是另一个常见的认知误区。试想Dropbox通过演示视频获得了种子用户的经典案例，如果创始人在一开始将App直接呈现给用户，除了需要花费更长的开发周期之外，恐怕得到的结果也是失真的。因为对于没有文件同步这个概念的用户来说，仅仅看到一个带有同步标示的文件夹很难感知到最终的使用价值。

所以，我们要跳出软件工程的视角，根据验证的目标去选择合适的MVP形态：

有价值的MVP直指运营层面的假设，例如“前100个种子用户可以在CBD周边获取“？
有效的MVP是对使用价值的模拟，将使用者置身于足够真实的环境，才能触及用户足够真实的选择；
MVP的形态并不是单一的，有很多现成的工具和方法可以使用。Uxpin创始人ChristopherBank归纳了15种常见的MVP形态（参考《mvp（最小化可行产品）验证的15种方法》from 36氪），例如众筹，演示视频，预售页等，这些形式的特征是运营前置，触及客户的真实需求。

勘测和修建合二为一

Google Venture下的设计团队是代表投资者利益的设计批判者，他们并不会为初创公司提供设计服务，而是通过一套名为《设计冲刺》的设计迭代，去检验初创项目的商业模式。在进入迭代前，他们会事先预约好真实的用户，并承诺在5天内打造一款产品原型给他们进行测试。在高强度的压力下，GV的设计师会从理解用户开始到定义问题，通过低保真的原型传达核心的产品形态。5天后向用户展示可感知的“外观”，检验真实的用户需求。这个过程并没有设计一款产品，而是通过设计的方式做了一次早期的用户调研。

还有一个将调研和创建过程融合的案例是近年来风靡硅谷的黑客增长（Growth Hacking），原本隶属于不同职能体系的市场人员，运营人员，工程师，设计师被融合到了一个增长团队中。通过这样跨职能的融合，打破了以往调研部门和研发部门之间的，可以让团队具备更多元化的视角和可能性，而任何的可能性都可以被”灰度”发布给用户，进行反复的调研和优化。

10年前，我们寄望于调研来消除商业中的不确定性，就像修建高速公路，在真正动工之前需要做大量的勘测工作。而今天，唯有将勘测能力与修建能力合二为一，才能应对更为复杂多变的商业环境。何为合二为一，简单来说就是颠倒勘测和修建的顺序，以往勘测是为了修建，而如今修建是为了勘测。