2.5 用最小化可行产品验证需求
什么是最小化可行产品
在市场不确定的情况下，贸然倾尽全公司之力，投入资源大规模进入是危险的。验证产品方向是否可行，可以通过“更聪明”的办法来完成。这就是硅谷作家埃里克·莱斯（Eric Ries）在其创业学著作《精益创业》中提出的“最小化可行产品（Minimum Viable Product，简称MVP）”概念。
《精益创业》作者埃里克·莱斯，图片来源：《连线》杂志
简单地说，精益创业是指开发团队通过提供最小化可行产品获取用户反馈，在此基础上持续快速迭代（或谋求转型），直至产品达到PMF阶段。它包含如下三个要素。
1．最小化可行产品：即所谓的MVP（Minimum Viable Product）是指将产品原型用最简洁的实现方式开发出来，过滤掉冗余杂音和高级特性，快速投放市场让目标用户上手使用，然后通过不断地听取反馈掌握有价值的信息，由此对产品原型迭代优化，尽早达到PMF状态。其中，“最简洁的产品原型”可以是产品界面的设计图，可以是带有简单交互功能的胚胎原型，甚至可以是一段视频、一个公众号。MVP的优势在于节约成本、调转灵活，能够直观地被目标用户感知到，有助于激发真实意见。它并不意味着“便宜”、“难看”或是“核心功能残破”，而应是能帮助用户完成任务的最小功能合集。除此以外对需要认知的内容没有直接帮助的一切功能或流程都应当暂时放弃。MVP的目的并不是为了回答产品设计是否优雅、技术实现是否高效这样具体的功能问题，或是过度许诺未来将承担的重任，而是用于解答商业产品开发中最重要的两个问题：一是价值假设，这款产品是否能够满足用户的需求？二是增长假设，用户是否愿意为产品买单？
2．用户反馈：指通过直接或间接方式，从产品的最终用户那里获得针对该产品的意见。反馈的内容包括用户对产品的整体感觉、是否喜欢/需要某项功能特性、想要添加哪些新功能、某些流程是否合理顺畅等。对精益创业者而言，用户的反馈应当作为产品开发中决策的根本依据。
3．快速迭代：“天下武功，唯快不破”。快速迭代就是要尽早发布，并针对用户提出的反馈以最快的速度进行调整，融合到新版本中。尽早发布，意味着产品获得更好的时间窗口和机会，能更快地验证想法并发现错误的部分，避免隔靴搔痒和战略偏差。不要等认为产品“完美”之后才发布。再完美的产品，如果没有人使用，那便无从称之为完美。快速迭代，则是鼓励开发者尽快将创意呈现在用户面前，而不是沉浸在闭门造车的节奏中。相比在实现产品前先口头向潜在用户宣讲你的创意，开发出的MVP能够用于实际演示和测试，有助于直观地被用户感知到，继而激发出真实的意见，帮助创业者尽早开启“开发—测量—认知”的反馈循环。
Facebook的马克·扎克伯格办公桌上放有“保持专注、持续交付”的座右铭
著名产品的MVP案例
说到这里，让我们来看一些公司开发最小化可行产品的独特方式。
1．Dropbox：同步云存储服务Dropbox的创意始于创始人德鲁·休斯顿（Drew Houston）自己上下班时的痛点：无法用移动设备获取电脑中的文件。为此他希望招募一群天才来共同实现这个有些前卫的想法。但他并没有急于马上动手开发，因为这需要克服重大的技术障碍，且投入成本暂时无法预估。取而代之的是，他选择在目标人群高度集中的新闻推荐平台Digg.com上发布了一则充满极客俚语的宣传视频，一本正经地向科技爱好者“虚构”了Dropbox的产品功能，以此判断是否有人为这个创意买账。结果这段3分钟的视频引发了网友的兴趣，经过投票很快便蹿升到当日热文榜单首位，吸引了几十万人访问视频中显示的着陆页。愿意排队等候产品问世的用户数量从5000人猛增至75000人。正是在这样积极的反馈下，德鲁·休斯顿才最终确定要让Dropbox诞生。
Dropbox的MVP演示视频
2．Groupon：团购服务鼻祖Groupon的创始人安德鲁·梅森（Andrew Mason）原本希望将公司做成一个“集体行动平台”，把用户聚在一起解决为公益事业筹款或是抵制侵权零售商的问题，但市场太过狭窄。于是他决定转型做团购。团购版的Groupon最初相当粗糙，使用的是开源的博客程序WordPress搭建，商品详情由运营人员一个字一个字手动输入连表单和在线咨询也没有。安德鲁·梅森又用现成的排版软件FileMaker制作PDF礼券，再通过AppleScript脚本发送电子邮件将礼券派送出去，一切都那么的“手工作坊”。验证成果表明，用户明显更喜欢这次转型，很快Groupon一天内就能卖出500份礼券商品。于是他才将部分环节纳入了自动化执行范畴。
3．Zappos：鞋类电商平台Zappos于1999年刚刚起步时，创始人尼克·斯威姆（Nick Swinmurn）并没有建立自己的仓储和物流基地，而是跑到隔壁鞋店拍摄了一批鞋子的照片挂到了网站上。当有人在网上下单时，他再去把鞋子买回来并寄出，通过这种方法来验证人们通过网上购买鞋子的需求。事实证明，他的确赶上了电子商务的早班车，业务也随着网民数量的增加和消费结构的升级而剧增。
鞋类电商平台Zappos
4．大众点评：大众点评的创始人张涛最早花了3天时间做出了一个简单的网站页面。当时他没有跟任何饭店签协议，而是直接将旅游手册里的1000多家饭店信息添加到了网站上，就为验证一件事：人们在饭店吃完饭，是否有足够的动力和意愿到网上点评？这次成功的验证成为大众点评日后商业模式的起点。此外，在验证是否有必要通过技术将声讯电话的语音内容转换成文本显示出来时，他们先选出了两位客服人员“假装”成声讯电话，实则在后台手动输入用户的语音内容。这避免了在效果未知的情况下耗费数月开发出一套失败系统的风险。
5．Hyperlapse：2014年，被Facebook收购的Instagram发布了一款名为Hyperlapse的延时摄影应用。当你打开这个应用，就会立刻开始录制视频，录制完成后可以设置2倍到12倍于原始视频的延时速率。成品视频会保存到相机胶卷中，你可以将它分享到Instagram或Facebook上。没错，拍摄、设置速度并分享，以上就是它的全部操作，最快只需要三次点击就能走完整个流程。它既没有高级编辑功能也无需申请账号登录，这省却了至少四倍的界面设计时间和六倍的代码开发时间，这还不包括平台适配和测试维护所耗费的精力。
6．微信游戏：为了快速验证游戏策划是否可行，曾负责腾讯微信国民级手游“天天系列”的天美艺游工作室美术负责人Vivi创造出了“暴力拼图法”，即在美术和动画定稿方案正式交付之前，就先用其他近似的图片依据策划“拼凑”出一幅要素视觉稿。具有良好美术素养的制作人和策划员工完全可以通过拼图，感受到最终的效果，一旦发现方案不可行便“尽快放弃，不再纠结”。
Instagram推出的Hyperlapse
从某种层面来说，开发最小化可行产品可能会增加一定的额外工作量（但这并不代表不必要），因此创业者在进行规划时，必须明确目标，坚定地砍掉与验证产品无关的任何附件模块。好的设计，更多源自于减法，而非加法。以小为始、保持迭代，才是创业团队保持生存活力与竞争优势的不二法门。
看Sendwithus如何用“钓鱼网站”验证市场
Sendwithus是美国的一家电子邮件营销公司，致力于为网络营销者提升事务性邮件（如重置密码、感谢注册、商品导购）的转化率。据公司的联合创始人马特·哈里斯（Matt Harris）透露，建立该公司的想法源于在小公司担任开发人员时，需要经常为不同的变量而改动邮件模板，缺少像大公司那样自动化的专业邮件管理系统。于是他开发出了Sendwithus，希望让不懂技术的用户也能轻松地完成邮件的优化。用户只需要登录网站，从现成的测试模板中选择一套或是自主上传，再进行简单的A/B测试配置，系统就会开始发送，事后根据收集到的反馈数据得出报表，告诉用户怎样写邮件更容易打动收件人。
其实在项目早期，哈里斯对自己即将着手建立的产品功能没有任何具体概念。为了研究潜在用户究竟需要哪些功能，并且收集到尽可能多的种子用户联系方式，他们想出了一个妙招——在尚未实际着手开发前，先虚拟了一个的“钓鱼网站”，作为验证市场需求的最小化可行产品。这个虚拟的网站叫“Sendwithus Zero”。登录该网站，用户将看到一个像模像样（但明显没有美化过）的网站管理后台，左边栏提供了“写邮件”、“优化”、“重定向”、“顾客管理”、“API配置”的一级入口，点击后还将展开对应的二级入口。右侧是页面的主体内容，包括功能介绍、邮件预览、导出设置和各种发送选项，整个布局井然有序。
Sendwithus Zero伪造网站
别看网站做得煞有介事，其实，页面中所有的按钮都仅仅是摆设，没有被赋予实际功能。当用户点击某一按钮试图使用该功能时，得到的唯一反馈就是蹦出一个消息框，告知用户：“您想要使用这个功能是吗？我们也觉得这是个不错的需求，并且正在努力实现它。请您留下电子邮箱，并告知您目前正在使用哪家竞品的服务。我们会在第一时间通知您产品上线了。”同时Sendwithus Zero会记录下用户的这一次点击，作为对功能需求的一次投票。结合Google Analytics的鼠标点击追踪功能，Sendwithus Zero能够定性与定量相结合地反映出用户的真实意图。
Sendwithus Zero的A/B测试按钮不提供实际功能，只用于吸引订阅
在完成Sendwithus Zero的搭建后，两位创始人将该网址尽可能地散播了出去。24小时内，为尝鲜而来的独立访问者数达到了803人，平均每人访问3.53个页面。在所有反馈中，呼声最高的功能分别是提供API和A/B测试模板，这两项的合计支持人数占到所有访客总量的一半。另外有92人留下了自己的联系邮箱，他们成为了日后Sendwithus正式上线时最早的一批种子用户。
Sendwithus为了开发这样一款最小化可行产品，投入的成本是怎样的呢？据官方博客介绍，所有的响应式邮件模板来自于设计公司ZURB的无偿提供，静态页面内的富文本编辑框使用开源的CKEditor和HTML ContentEditable搭建。至于页面设计是花费18美元购买的现成bootstrap主题，网站徽标则随意选了款字体。整个网站则架设在亚马逊的免费云服务套餐之上。满打满算下来只花费了28美元，用了一周时间——相比花费数月开发出功能齐全的完整网站，这实在是太值了。不久后，得到市场认可的Sendwithus获得了230万美元的天使投资。
基于微信的MVP开发策略
受开发环境、分发渠道、审核规则等因素影响，开发和验证一款移动应用往往比网站的成本更高，周期更久。一个新鲜出炉的产品构想，从着手开发到正式上线，短则只需几天，长则可达数月，过程中可能受到来自内外部的干扰因素，影响发布进度。有没有更巧妙的办法，快速地在移动平台上验证产品构想呢？其实，使用微信公众平台开发最小化可行产品就是一种不错的方式。
在此先简单介绍一下微信公众平台的交互原理。用户在自己的移动设备上安装了微信，关注公众号并发送某种类型的消息（图片、文字、地理位置等）请求后，这一请求经由微信服务器的处理，转换成特定格式的转发请求，传递到开发者自定义的后台处理服务器上（执行一个PHP脚本），开发者可在此阶段进行天马行空的发挥，如根据地理位置推送当地天气、根据文字推送固定客服回复；处理完毕的响应信息传回给微信服务器，再经由微信服务器处理成转发响应，最终传递回用户移动设备的微信界面上，以图片、文字或图文的形式显示出来。简单地说，微信公众账号承担了连接输入/输出方的“二传手”的作用，由它来统一获取用户的行为，并给出相应的服务器反应。
微信公众平台的开发基本交互原理，图片来源：停留的风
之所以推荐用微信公众平台开发移动端的最小化可行产品，原因如下。
1．开发成本低。微信公众平台的开发者模式，允许开发者通过开放的接口接入自己的服务器，响应公众号粉丝的输入。掌握PHP、HTML5等网站开发知识就能够实现各种媲美原生应用的酷炫交互功能。你也完全可以将设计精美应用界面的时间省下来，用微信聊天窗口里一来一回的简单问答作为基础互动。相比动辄数万元的应用开发，成本可压缩在十分之一到五分之一。
2．无须适配。移动平台的适配是开发过程中绕不开的恼人障碍，某些碎片化平台的适配工作甚至可能占到研发工作量的40％以上。而依托于微信，则可将这部分工作量完全省去（或者说由微信的研发工程师代劳了），无需在意某些特定机型的用户无法使用。
3．分发方便。引导用户去特定市场，下载动辄几MB的应用安装，并完成一长串的注册登录流程，这会让你的潜在用户望而生畏。在微信公众平台内建一个MVP，则几乎省去了这块成本，无安装门槛，推广成本也极低。此外，维护微信平台的功能如同维护网站，可以随时上线、下线，不需要让用户下载升级安装包。
4．便于收集反馈。微信本身就是个沟通工具，你可以明确地知道每个用户的身份，查询他们的互动记录。用户也习惯于直接以对话的方式提交意见，这比要求用户去应用内的反馈模块或是专门撰写一封电子邮件更加高效。
5．数据得以沉淀。通过微信公众平台开发MVP，获得的初期数据信息是可以提交到自己的服务器上的，不会随着MVP的废弃而不再具备效用。换句话说，微信内的数据与日后开发的应用数据是能够复用和互通的。这比一般的静态MVP更有长效价值。
下面我们来看一些用微信公众平台进行MVP验证的案例。
聚美优品的移动开发团队在探索如何实现“陪用户一起变美”的目标时，其中一个备选方案叫“女神进化史”，即鼓励用户分享自己变美前后的对比照片给大家看，并且这些上传的照片可以按照热度排序。这是一个听上去颇有噱头的想法，但实现该方案需要投入开发、推广、运营团队的人力，还得找到一批愿意晒照片的高质量女性来解决冷启动。经过讨论，团队决定先开发MVP验证创意是否可行。他们利用聚美优品的微信公众账号发布了一篇文章，内容是“女神”变美前后的照片和方法，文末鼓励广大粉丝参与分享自己的照片并附上活动详情链接。经过观测，事实很残酷，虽然有22.51％的人对这篇文章感兴趣，但没有人点击链接查看活动细则，更别提参与和传播了。这次失败的尝试让聚美优品团队认识到：女性用户对这类分享“女神”照片的活动兴趣不大，或许她们并不愿意晒出自己真正的丑照。最终这个方案作罢，团队并没有把宝贵的资源投入在一个不靠谱的方向上。
参与此类晒照活动意愿最强的用户通常都是真正意义上的“女神”
“悠泊”是一家致力于解决大街上停车难问题的代客泊车服务，在将产品构想落实成移动应用之前，他们花费了一周时间开发出了微信上的MVP，以此来验证一个基本假设：用户是否愿意把自己的车托付给别人？
悠泊VIP停车服务
悠泊在早期MVP版本中共提供了四个基本功能：“一键停车”、“我要取车”、“查看车辆状态”以及“绑定手机”号。开发完成后的第一周，他们没有向外推，而是邀请了公司内部和邻居公司的所有有车一族来体验。这个版本被他们自己戏称为“产检”版。通过一周时间收集和处理这批种子用户的反馈，产品得到了优化。第二周，他们决定举着印有微信公众号二维码的牌子到附近特别堵车的医院门口去招揽真实用户试用。结果，第一天就在朝阳医院门口接到了10个订单。在这场线下推广中，微信成功地扮演了简易入口的角色：几乎人人都安装，个个会扫码，关注一个服务号的操作成本近乎为零。
通过微信的快速验证，客户群体的特征渐渐显现：开30万以上车型的用户占比很高，约为70％。令悠泊团队喜出望外的是，这些早期用户们普遍反馈很好，都希望类似的服务能够常驻医院门口，以消除他们开车来医院的“停车恐惧症”。直到这一阶段，悠泊才正式将微信上的MVP开发成了原生的iPhone原生应用。
悠泊地推团队在医院附近举牌宣传微信公众号二维码
悠泊产品从微信“产检”版进化为iPhone原生应用的界面轨迹
回顾用微信做MVP的策略，悠泊团队事后也总结出一些值得关注的问题。
首先，当初为了追求实现速度，牺牲了产品的拓展性。如果当初多花一些时间设计通用的架构和API，那么到后面再做原生应用的时候能够减少很多返工时间。
其次，微信的地理定位准确度受到不同机型和网络的影响，一旦出现偏差会影响到服务品质。小团队没法像滴滴打车那样获得来自平台官方的应用级支持，这就需要在订单确认和服务沟通上下功夫。
最后，在项目运行期间出现了服务器突然宕机的紧急情况。由于悠泊使用的DNSPod有DNS轮查，于是他们迅速购入一台新服务器作为另一个节点，前端用DNS轮查将用户分配到不同的服务器上，实时监控不可用节点进行解析重定向和MySQL分布式处理，最终才有惊无险地维持住了服务的可用性。
悠泊的联合创始人赵珏映认为，如果当时没有把激烈的讨论付诸行动，通过微信开发的MVP来快速验证，那么悠泊今天不会健康地“顺产”出来。当你纠结一个产品是否能被市场接受的时候，可以尝试跳出“一定要做个应用”的思路，采用现在已经存在的轮子，为自己抢来一些时间和先机。
MVP的三大必备模块
如果问开发一个MVP必须具备哪些模块，那么我会不假思索地告诉你：除了待验证的基本功能外，反馈渠道、公告看板、自动升级和使用行为统计这四件事必须纳入考量。
1．反馈渠道：请尽可能为你的MVP用户提供产品内部的反馈机制（如网站顶部的留言板入口、移动应用中的提交反馈页面），而不仅是在产品体外设置独立的反馈渠道（如微博、微信、QQ）。用户希望在遇到问题的那一刻尽快将自己的疑惑、惊诧与愤懑传递给开发团队。这些最终采取了行动的少数派用户，极有可能出于两种初衷：第一，他们的确遇到了棘手的麻烦；第二，他们真的是你产品的忠实粉丝，以苛求的眼光审视任何一个不完美的细节，热忱地为团队带来改善意见。无论遇到哪一种，都决不能令其失望，倘若反馈渠道的门槛过高，会令他们望而生畏，提反馈的冲动也随之烟消云散。
2．官方公告：包括群体公告和针对单个用户的定向消息通道。公告看板的目的是向用户传递来自产品官方的声音，包括团队动态、运营公示、反馈回复，以及应对突发情况的紧急通知和危机公关等。对于网站而言，公告看板的具体实现形式可以是首页的一条醒目的横幅、个人中心的系统消息或是群发的邮件，而客户端及移动应用内的公告则可能更加醒目，如能够轻易占据用户注意力的推送通知（Push Notification）。并非每个用户都有看公告的习惯，然而对于试图主动了解官方信息的用户而言，找到入口的方式必须简单易行。
3．自动升级：网站的优势是随时部署，用户打开浏览器看到的永远是最新的内容。相比之下，客户端和移动应用的用户是经过漫长的链条转化而来的。如果用户每次获取新版本都要再一次经历手动搜索、下载和安装的过程，许多偷懒的用户宁愿选择继续维持在老版本，而最终看不到我们呕心沥血迭代出的升级版。这与我们快速迭代的开发策略背道而驰。最佳策略是在产品启动时提示用户有可用的新版本，当用户确认升级后，通过内置的下载模块在后台完成更新，整个过程无需用户介入，而是“傻瓜式”地完成。
笔者曾参与开发“云诺网盘”的iOS客户端任务。当时我们的团队过于专注于产品核心功能的实现，而忽略了加入用户反馈的收集模块、推送通知提醒和自动升级提示。这一疏漏对日后新版本的推广造成了麻烦：当iOS客户端配合网站改版完成一次重大迭代后，我们几乎无法告知这批iOS用户前去升级，只能眼巴巴地盼着他们上门来发现更新的消息。无奈之下，我们尝试向所有填写了联系邮箱的用户发送邮件，但到达率有限，后台数据显示的升级率依然非常低。这个前期隐患导致的后续影响是，在相当长的一段时间内，我们不得不维持旧版的应用接口，向下兼容用户的数据格式，并耗费大量额外经历保证新老用户体验的一致性。
之后在参与动漫阅读应用“高能贩”的开发中，我们吸取了教训，在最小化可用产品阶段就植入了这三大模块：在“关于”页面加入了“意见反馈”的入口；在代码里接入了友盟的推送通知和自动升级组件。于是在产品以周为单位快速迭代的早期阶段，新版本分发到大部分活跃用户手中通常只需要两到三天。这有助于让我们极早判断新版本是否稳定可靠，以及不同版本改动对用户行为数据的影响。
除了上述提到的模块之外，针对不同用户设置不同的后台功能开关，进行新功能的灰度发布，也是避免失败的一种方式。腾讯微信有一套动态运营的完整方法论，设计有大量的后台开关，每次完成新功能时，总是先让一小部分用户先使用，待效果好再放大受众范围，效果不好则折叠甚至删除。运行下来发现，大约有70％的想法最终未能通过市场的检验，真正让所有用户看到的功能可能不到30％。同样地，后台开关设计还能运用于提交市场审核时避免不必要的意外挫折，如暂时屏蔽掉可能带来审核麻烦的敏感版块。