网络赚钱

用最小化可行产品验证需求

2021-06-02 08:58:30

    什么是最小化可行产品 

    在市场不确定的情况下,贸然倾尽全公司之力,投入资源大规模进入是危险的。验证 产品方向是否可行,可以通过“更聪明”的办法来完成。这就是硅谷作家埃里克·莱斯(Eric Ries) 在其创业学著作《精益创业》中提出的“最小化可行产品(Minimum Viable Product,简称 MVP)”概念。简单地说,精益创业是指开发团队通过提供最小化可行产品获取用户反馈,在此基础上 持续快速迭代(或谋求转型),直至产品达到 PMF 阶段。它包含如下三个要素。 

    1.最小化可行产品:即所谓的 MVP(Minimum Viable Product)是指将产品原型用 最简洁的实现方式开发出来,过滤掉冗余杂音和高级特性,快速投放市场让目标用户上手使 用,然后通过不断地听取反馈掌握有价值的信息,由此对产品原型迭代优化,尽早达到 PMF 状态。其中,“最简洁的产品原型”可以是产品界面的设计图,可以是带有简单交互功能的胚胎原型,甚至可以是一段视频、一个公众号。MVP 的优势在于节约成本、调转灵活,能够直 观地被目标用户感知到,有助于激发真实意见。它并不意味着“便宜”、“难看”或是“核心功能 残破”,而应是能帮助用户完成任务的最小功能合集。除此以外对需要认知的内容没有直接帮 助的一切功能或流程都应当暂时放弃。MVP 的目的并不是为了回答产品设计是否优雅、技术 实现是否高效这样具体的功能问题,或是过度许诺未来将承担的重任,而是用于解答商业产 品开发中最重要的两个问题:一是价值假设,这款产品是否能够满足用户的需求?二是增长 假设,用户是否愿意为产品买单? 

    2.用户反馈:指通过直接或间接方式,从产品的最终用户那里获得针对该产品的意见。 反馈的内容包括用户对产品的整体感觉、是否喜欢/需要某项功能特性、想要添加哪些新功能、 某些流程是否合理顺畅等。对精益创业者而言,用户的反馈应当作为产品开发中决策的根本 依据。 

    3.快速迭代:“天下武功,唯快不破”。快速迭代就是要尽早发布,并针对用户提出的反 馈以最快的速度进行调整,融合到新版本中。尽早发布,意味着产品获得更好的时间窗口和 机会,能更快地验证想法并发现错误的部分,避免隔靴搔痒和战略偏差。不要等认为产品“完 美”之后才发布。再完美的产品,如果没有人使用,那便无从称之为完美。快速迭代,则是鼓 励开发者尽快将创意呈现在用户面前,而不是沉浸在闭门造车的节奏中。相比在实现产品前 先口头向潜在用户宣讲你的创意,开发出的 MVP 能够用于实际演示和测试,有助于直观地 被用户感知到,继而激发出真实的意见,帮助创业者尽早开启“开发—测量—认知”的反馈循 环。

    著名产品的 MVP 案例 说到这里,让我们来看一些公司开发最小化可行产品的独特方式。 

    1.Dropbox:同步云存储服务 Dropbox 的创意始于创始人德鲁·休斯顿(Drew Houston)自己上下班时的痛点:无法用移动设备获取电脑中的文件。为此他希望招募一群 天才来共同实现这个有些前卫的想法。但他并没有急于马上动手开发,因为这需要克服重大 的技术障碍,且投入成本暂时无法预估。取而代之的是,他选择在目标人群高度集中的新闻 推荐平台 Digg.com 上发布了一则充满极客俚语的宣传视频,一本正经地向科技爱好者“虚构” 了 Dropbox 的产品功能,以此判断是否有人为这个创意买账。结果这段 3 分钟的视频引发 了网友的兴趣,经过投票很快便蹿升到当日热文榜单首位,吸引了几十万人访问视频中显示 的着陆页。愿意排队等候产品问世的用户数量从 5000 人猛增至 75000 人。正是在这样积极 的反馈下,德鲁·休斯顿才最终确定要让 Dropbox 诞生。 

    2.Groupon:团购服务鼻祖 Groupon 的创始人安德鲁·梅森(Andrew Mason)原 本希望将公司做成一个“集体行动平台”,把用户聚在一起解决为公益事业筹款或是抵制侵权 零售商的问题,但市场太过狭窄。于是他决定转型做团购。团购版的 Groupon 最初相当粗 糙,使用的是开源的博客程序 WordPress 搭建,商品详情由运营人员一个字一个字手动输 入连表单和在线咨询也没有。安德鲁·梅森又用现成的排版软件 FileMaker 制作 PDF 礼券, 再通过 AppleScript 脚本发送电子邮件将礼券派送出去,一切都那么的“手工作坊”。验证成 果表明,用户明显更喜欢这次转型,很快 Groupon 一天内就能卖出 500 份礼券商品。于是 他才将部分环节纳入了自动化执行范畴。 

    3.Zappos:鞋类电商平台 Zappos 于 1999 年刚刚起步时,创始人尼克·斯威姆(Nick Swinmurn)并没有建立自己的仓储和物流基地,而是跑到隔壁鞋店拍摄了一批鞋子的照片 挂到了网站上。当有人在网上下单时,他再去把鞋子买回来并寄出,通过这种方法来验证人 们通过网上购买鞋子的需求。事实证明,他的确赶上了电子商务的早班车,业务也随着网民 数量的增加和消费结构的升级而剧增。

    4.大众点评:大众点评的创始人张涛最早花了 3 天时间做出了一个简单的网站页面。 当时他没有跟任何饭店签协议,而是直接将旅游手册里的 1000 多家饭店信息添加到了网站 上,就为验证一件事:人们在饭店吃完饭,是否有足够的动力和意愿到网上点评?这次成功 的验证成为大众点评日后商业模式的起点。此外,在验证是否有必要通过技术将声讯电话的 语音内容转换成文本显示出来时,他们先选出了两位客服人员“假装”成声讯电话,实则在后 台手动输入用户的语音内容。这避免了在效果未知的情况下耗费数月开发出一套失败系统的 风险。 

    5.Hyperlapse:2014 年,被 Facebook 收购的 Instagram 发布了一款名为 Hyperlapse 的延时摄影应用。当你打开这个应用,就会立刻开始录制视频,录制完成后可以 设置 2 倍到 12 倍于原始视频的延时速率。成品视频会保存到相机胶卷中,你可以将它分享 到 Instagram 或 Facebook 上。没错,拍摄、设置速度并分享,以上就是它的全部操作,最 快只需要三次点击就能走完整个流程。它既没有高级编辑功能也无需申请账号登录,这省却 了至少四倍的界面设计时间和六倍的代码开发时间,这还不包括平台适配和测试维护所耗费 的精力。 

    6.微信游戏:为了快速验证游戏策划是否可行,曾负责腾讯微信国民级手游“天天系 列”的天美艺游工作室美术负责人 Vivi 创造出了“暴力拼图法”,即在美术和动画定稿方案正式 交付之前,就先用其他近似的图片依据策划“拼凑”出一幅要素视觉稿。具有良好美术素养的 制作人和策划员工完全可以通过拼图,感受到最终的效果,一旦发现方案不可行便“尽快放弃, 不再纠结”。从某种层面来说,开发最小化可行产品可能会增加一定的额外工作量(但这并不代表 不必要),因此创业者在进行规划时,必须明确目标,坚定地砍掉与验证产品无关的任何附 件模块。好的设计,更多源自于减法,而非加法。以小为始、保持迭代,才是创业团队保持 生存活力与竞争优势的不二法门。 

    看 Sendwithus 如何用“钓鱼网站”验证市场 Sendwithus 是美国的一家电子邮件营销公司,致力于为网络营销者提升事务性邮件 (如重置密码、感谢注册、商品导购)的转化率。据公司的联合创始人马特·哈里斯(Matt Harris) 透露,建立该公司的想法源于在小公司担任开发人员时,需要经常为不同的变量而改动邮件 模板,缺少像大公司那样自动化的专业邮件管理系统。于是他开发出了 Sendwithus,希望 让不懂技术的用户也能轻松地完成邮件的优化。用户只需要登录网站,从现成的测试模板中 选择一套或是自主上传,再进行简单的 A/B 测试配置,系统就会开始发送,事后根据收集到 的反馈数据得出报表,告诉用户怎样写邮件更容易打动收件人。 

    其实在项目早期,哈里斯对自己即将着手建立的产品功能没有任何具体概念。为了研 究潜在用户究竟需要哪些功能,并且收集到尽可能多的种子用户联系方式,他们想出了一个 妙招——在尚未实际着手开发前,先虚拟了一个的“钓鱼网站”,作为验证市场需求的最小化 可行产品。这个虚拟的网站叫“Sendwithus Zero”。登录该网站,用户将看到一个像模像样 (但明显没有美化过)的网站管理后台,左边栏提供了“写邮件”、“优化”、“重定向”、“顾客管 理”、“API 配置”的一级入口,点击后还将展开对应的二级入口。右侧是页面的主体内容,包 括功能介绍、邮件预览、导出设置和各种发送选项,整个布局井然有序。别看网站做得煞有介事,其实,页面中所有的按钮都仅仅是摆设,没有被赋予实际功 能。当用户点击某一按钮试图使用该功能时,得到的唯一反馈就是蹦出一个消息框,告知用 户:“您想要使用这个功能是吗?我们也觉得这是个不错的需求,并且正在努力实现它。请您 留下电子邮箱,并告知您目前正在使用哪家竞品的服务。我们会在第一时间通知您产品上线 了。”

    同时 Sendwithus Zero 会记录下用户的这一次点击,作为对功能需求的一次投票。结 合 Google Analytics 的鼠标点击追踪功能,Sendwithus Zero 能够定性与定量相结合地反 映出用户的真实意图。在完成 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,以此来验证一个基本假设:用户是否愿 意把自己的车托付给别人? 悠泊在早期 MVP 版本中共提供了四个基本功能:“一键停车”、“我要取车”、“查看车辆 状态”以及“绑定手机”号。开发完成后的第一周,他们没有向外推,而是邀请了公司内部和邻 居公司的所有有车一族来体验。这个版本被他们自己戏称为“产检”版。

    通过一周时间收集和 处理这批种子用户的反馈,产品得到了优化。第二周,他们决定举着印有微信公众号二维码 的牌子到附近特别堵车的医院门口去招揽真实用户试用。结果,第一天就在朝阳医院门口接 到了 10 个订单。在这场线下推广中,微信成功地扮演了简易入口的角色:几乎人人都安装, 个个会扫码,关注一个服务号的操作成本近乎为零。 通过微信的快速验证,客户群体的特征渐渐显现:开 30 万以上车型的用户占比很高, 约为 70%。令悠泊团队喜出望外的是,这些早期用户们普遍反馈很好,都希望类似的服务能 够常驻医院门口,以消除他们开车来医院的“停车恐惧症”。直到这一阶段,悠泊才正式将微 信上的 MVP 开发成了原生的 iPhone 原生应用。回顾用微信做 MVP 的策略,悠泊团队事后也总结出一些值得关注的问题。 首先,当初为了追求实现速度,牺牲了产品的拓展性。如果当初多花一些时间设计通 用的架构和 API,那么到后面再做原生应用的时候能够减少很多返工时间。 其次,微信的地理定位准确度受到不同机型和网络的影响,一旦出现偏差会影响到服务品质。 

    小团队没法像滴滴打车那样获得来自平台官方的应用级支持,这就需要在订单确认和服务沟 通上下功夫。 最后,在项目运行期间出现了服务器突然宕机的紧急情况。由于悠泊使用的 DNSPod 有 DNS 轮查,于是他们迅速购入一台新服务器作为另一个节点,前端用 DNS 轮查将用户分 配到不同的服务器上,实时监控不可用节点进行解析重定向和 MySQL 分布式处理,最终才 有惊无险地维持住了服务的可用性。 

    悠泊的联合创始人赵珏映认为,如果当时没有把激烈的讨论付诸行动,通过微信开发的 MVP 来快速验证,那么悠泊今天不会健康地“顺产”出来。当你纠结一个产品是否能被市场接受的 时候,可以尝试跳出“一定要做个应用”的思路,采用现在已经存在的轮子,为自己抢来一些 时间和先机。 MVP 的三大必备模块 如果问开发一个 MVP 必须具备哪些模块,那么我会不假思索地告诉你:除了待验证的基本 功能外,反馈渠道、公告看板、自动升级和使用行为统计这四件事必须纳入考量。 

    1.反馈渠道:请尽可能为你的 MVP 用户提供产品内部的反馈机制(如网站顶部的留言板入 口、移动应用中的提交反馈页面),而不仅是在产品体外设置独立的反馈渠道(如微博、微信、QQ)。用户希望在遇到问题的那一刻尽快将自己的疑惑、惊诧与愤懑传递给开发团队。 这些最终采取了行动的少数派用户,极有可能出于两种初衷:第一,他们的确遇到了棘手的 麻烦;第二,他们真的是你产品的忠实粉丝,以苛求的眼光审视任何一个不完美的细节,热 忱地为团队带来改善意见。无论遇到哪一种,都决不能令其失望,倘若反馈渠道的门槛过高, 会令他们望而生畏,提反馈的冲动也随之烟消云散。 

    2.官方公告:包括群体公告和针对单个用户的定向消息通道。公告看板的目的是向用户传递 来自产品官方的声音,包括团队动态、运营公示、反馈回复,以及应对突发情况的紧急通知 和危机公关等。对于网站而言,公告看板的具体实现形式可以是首页的一条醒目的横幅、个 人中心的系统消息或是群发的邮件,而客户端及移动应用内的公告则可能更加醒目,如能够 轻易占据用户注意力的推送通知(Push Notification)。并非每个用户都有看公告的习惯, 然而对于试图主动了解官方信息的用户而言,找到入口的方式必须简单易行。 

    3.自动升级:网站的优势是随时部署,用户打开浏览器看到的永远是最新的内容。相比之下, 客户端和移动应用的用户是经过漫长的链条转化而来的。如果用户每次获取新版本都要再一 次经历手动搜索、下载和安装的过程,许多偷懒的用户宁愿选择继续维持在老版本,而最终 看不到我们呕心沥血迭代出的升级版。这与我们快速迭代的开发策略背道而驰。最佳策略是 在产品启动时提示用户有可用的新版本,当用户确认升级后,通过内置的下载模块在后台完 成更新,整个过程无需用户介入,而是“傻瓜式”地完成。 笔者曾参与开发“云诺网盘”的 iOS 客户端任务。当时我们的团队过于专注于产品核心功能的 实现,而忽略了加入用户反馈的收集模块、推送通知提醒和自动升级提示。这一疏漏对日后 新版本的推广造成了麻烦:当 iOS 客户端配合网站改版完成一次重大迭代后,我们几乎无法 告知这批 iOS 用户前去升级,只能眼巴巴地盼着他们上门来发现更新的消息。

    无奈之下,我 们尝试向所有填写了联系邮箱的用户发送邮件,但到达率有限,后台数据显示的升级率依然 非常低。这个前期隐患导致的后续影响是,在相当长的一段时间内,我们不得不维持旧版的 应用接口,向下兼容用户的数据格式,并耗费大量额外经历保证新老用户体验的一致性。 之后在参与动漫阅读应用“高能贩”的开发中,我们吸取了教训,在最小化可用产品阶段就植 入了这三大模块:在“关于”页面加入了“意见反馈”的入口;在代码里接入了友盟的推送通知和 自动升级组件。于是在产品以周为单位快速迭代的早期阶段,新版本分发到大部分活跃用户 手中通常只需要两到三天。这有助于让我们极早判断新版本是否稳定可靠,以及不同版本改 动对用户行为数据的影响。 

    除了上述提到的模块之外,针对不同用户设置不同的后台功能开关,进行新功能的灰度发布, 也是避免失败的一种方式。腾讯微信有一套动态运营的完整方法论,设计有大量的后台开关, 每次完成新功能时,总是先让一小部分用户先使用,待效果好再放大受众范围,效果不好则 折叠甚至删除。运行下来发现,大约有 70%的想法最终未能通过市场的检验,真正让所有用 户看到的功能可能不到 30%。同样地,后台开关设计还能运用于提交市场审核时避免不必要 的意外挫折,如暂时屏蔽掉可能带来审核麻烦的敏感版块。