# 第四步：通过5个步骤设计产品的MVP

> 讲解 MVP（最小化可行产品）的定义、形态与判断标准，用「在线定制球鞋 App」演示构建 MVP 的五个步骤，并以大众点评、PP 租车、在行三个案例总结 MVP 的五大优势。

---

LLMS 索引： [llms.txt](/llms.txt)

---

## 什么是 MVP

验证产品能否达到 **PMF 阶段**的第四个要点，是使用一种工具——**最小化可行产品（Minimum Viable Product，简称 MVP）**。

>最小化可行产品，指把产品原型用最简洁的实现方式开发出来，过滤掉产品中原本不需要的冗余杂音和高级特性，快速投放市场让目标用户上手使用；再通过不断听取用户反馈、掌握有价值的信息，在此基础上对原型迭代优化，帮助产品尽早达到 PMF。

这个最简洁的产品原型可以是：

- 产品界面的设计图
- 带有简单交互的、很胚胎级的原型
- 一段视频、一个公众号或一篇文章
- 餐巾纸上手绘的几根线条

以上形态在实践里都出现过。它的要求只有一个：最快、最简单地传达「产品到底是什么」并去验证。目的就是尽快接触消费者、验证需求，从而通往 PMF。

## 合理的 MVP 长什么样：Uber 的例子

仍以 Uber 为例。这家如今风光无限的硅谷独角兽，当年的 MVP 非常简陋：

> 最早的 Uber 叫 **UberCab**，App 只支持 iOS 系统，只有两个基础功能：就近叫车和付钱。界面里没有任何设计感可言，用户体验也不算优秀，CEO 卡兰尼克还要亲自开车接单。但恰恰是这个简陋的产品解决了一个核心问题——验证出了市场需求：让人们用最快的速度、最低的价格找到出租车。

回头看今天的 Uber，不仅界面更美观、体验更好，还加入了一系列贴心功能——行程规划、司机追踪、时间预估、AA 付款等，甚至用游戏化的奖励系统帮助产品实现增长、提高司机和用户的留存。

## 构建 MVP 的五个步骤：以「在线定制球鞋 App」为例

构建 MVP 是有方法、有流程、有逻辑的。一个通用的流程共分五步：

1. 定义产品的首要目标
2. 定义产品的用户流
3. 根据用户流的每个阶段罗列产品功能
4. 对功能进行优先级排序
5. 构建最终功能集合

画成流程图就是：

```mermaid
flowchart LR
    A["① 定义产品的首要目标"] --> B["② 定义产品的用户流"]
    B --> C["③ 按用户流每个阶段<br/>罗列产品功能"]
    C --> D["④ 对功能进行<br/>优先级排序"]
    D --> E["⑤ 构建最终功能集合"]
```

以下用一个虚拟项目来讲解：假设要开发一款**在线定制球鞋 App**——用户在线选择配色、款式、装饰物，然后下单购买。

**第一步：定义产品的首要目标。** 即思考产品是用来干什么的、能解决用户哪些问题、最首要的目标是什么、怎么满足客户需求。这个案例的产品让用户在线定制球鞋，首要目标显然是「让用户收到一双独特的、经过定制的鞋子」，拆解下来有两层含义：

- 用户可以在线自由定制——App 需要有展示功能
- 用户可以在线下单买到——App 需要有电商功能

**第二步：定义用户流。** 很多人对用户流（User Flow / Behavior Flow）并不陌生：它指用户在使用整个产品中经过的路径，即完成一个任务的必经路线。本案例的用户流，就是用户「收到一款独特的定制球鞋」需要在产品中经历的所有步骤。定义用户流时要牢记：不要过多思考产品的具体特征，而要把注意力集中在用户完成首要目标上，拆解产品使用步骤——假想自己就是一个正在使用这款 App 的用户：先在线定制，再在线购买一双，接着查看订单进程，最后等待鞋子送到家。整个流程就是：**定制（Custom-made shoe）→ 购买（Buy shoe）→ 订单管理（Manage order）→ 配送（Deliver order）**。可以类比平时使用电商网站的一般流程，只是前面多了一步定制。

**第三步：根据用户流的每个阶段罗列产品功能。** 使用步骤确定后，针对每个步骤设计相应的功能特征。这是发挥创造力和想象力的时候——不要带着顾虑，也不要考虑优先级、可实现性，尽可能多地列举，再把功能点贴到对应的用户行为流下面，便于展示和团队内部沟通。罗列功能可以用**穷举法**：

- 定制阶段：用户希望流畅自由地定制产品，比如选颜色、选形状、生成 3D 预览图；用户第一次可能没找到理想方案、或希望下次继续——需要收藏功能；从社交角度看，个性化商品是很好的社交货币——可以加分享功能，允许用户分享给朋友
- 购买阶段：功能需求更直接——让用户最方便地「剁手」。要接入多种支付通道，尽可能覆盖所有用户群体；还可以允许支付时使用优惠券，配合后续的推广活动

## 功能排序与最终功能集合

**第四步：对功能进行优先级排序。** 不同功能的设计难度差别很大，带来的收益未必与劳动量成正比，因此要优先做那些执行简单、对产品提升最大的功能。此时需要问五个问题：

1. 它对完成这个步骤有多重要？
2. 多少用户会使用它？
3. 它的使用频率高吗？
4. 它能给用户带来多大价值？
5. 它存在风险吗？

对这五个因素在头脑中打分（比如 1–10 分），将前四项相加、减去第五项风险的评分，总分越高的功能，优先级就越高，可以考虑优先做。排好序后重新规划任务：优先级高的先做，次要的放一放。如果团队习惯用自动化任务看板，或喜欢在墙上、玻璃上贴便签条，就重新组织便签条的位置——把重要的提上来、次要的降下去。在定制球鞋案例里：

- 高优先级：选择颜色、尺码，生成 3D 效果图
- 中优先级：收藏
- 低优先级：分享给朋友

**第五步：构建最终功能集合。** MVP 优先考虑的，就是上一步中优先级最高的那些功能，应当优先设计。如果用看板或便签条，可以在下面加一条线，把优先级最高的划分出来——这条 **MVP 线**之上的就是应该优先设计的功能，第一排一定是最重要的骨架，是构成 MVP 的必要但不充分条件。在定制球鞋 App 的例子中，MVP 需要的重要功能是：选择尺码颜色、微信付款、查看订单、物流追踪。

以上就是构建 MVP 的通用步骤，可结合具体情况灵活运用，找到最合适、成本最低的方式。

两点补充建议：其一，MVP 非常适合创业产品很早期的阶段，越早尝试效果越好；

其二，有些人觉得要等融资拿到钱、筹集到创业基金之后再开始做产品——没有必要。完全可以在动身创业、冒风险之前，就用很简单很聪明的方式把 MVP 做出来，投放到市场做小规模测试。

如果说 MVP 几经打磨，最终证明根本不适合市场，那就赶紧打消创业念头，留在原来的岗位上安稳做事，而不是冒着大风险出来折腾大半年一整年，最后发现产品从根上就是一个「看起来很牛、其实没什么用」的东西。MVP 在早期不需要做得很华丽，也不必追求它本身带来增长——它的作用是一旦验证产品在某个时间点达到 PMF，再把它开发出来，让正式产品快速增长。

## 三个 MVP 实战案例

### 大众点评：三天做出的网页

> 创始人张涛当年只花三天时间就做出了大众点评最早的网页。他以前很羞于给别人看这张页面，因为太丑了——但后来他意识到，这个最简陋的网页就是一个 MVP。当时他没有跟任何饭馆签协议，而是把旅游手册里的一千多家饭馆直接录入网站系统，只想验证一件事：网民在一家饭馆吃完饭，是否愿意进行点评。这个认知是大众点评商业模式最重要的起点。那时他们是无意识地做 MVP，如今已经会主动选择这种产品策略。

后来大众点评想切入餐馆订位服务。市场上的解决方案很多，比如电话预定；经过一番研究，点评想采用**声讯电话**模式：用户在手机上提交预定请求，用技术把文本转为语音，通过声讯电话服务商把要求发送给相应餐馆；餐馆按 1 或 2 选择是否接受预定，大众点评再把结果短信通知用户。这套方案听起来很漂亮，但开发至少需要三个月，而且他们并不确定用户是否愿意通过电话预定餐位。MVP 的思路再次帮了张涛——他做了一个很「性感」的实验：一开始完全不用语音转化技术和声讯电话业务，而是直接在后台找两位客服人员人工接受电话信息、致电餐馆、回复用户。换句话说，派人工假装成声讯电话，用这种方式验证需求和解决方案是否可行。验证发现大家真的愿意通过声讯电话订餐之后，他们才投入大量资源开发这套自动化系统。最终这套系统帮助大众点评逐渐从上海扩展到北京等区域。

### PP 租车：一百单人工实验

> PP 租车最早下单后的支付转化率很低，只有 20%。团队分析发现，新用户面对新业务很难建立信任：当时的产品流程是先在 App 下单、先支付——要交几千块押金，交完押金还要再交几千块租车金，全部手续做完，车主才能看到订单、决定是否接受申请。一个新用户面对一家自己不信任的小公司，没见过实车、只在网上看过图片，就要先充几千块钱，很难接受，很多用户的转化流程就卡在了这里。团队通过电话、调研等方式也确认：大额支付确实是卡点——用户没见到实物就要交这么多钱，构成了障碍。

于是团队提出核心假设：把租车押金降到足够低，或者先让用户看到车再交钱，理论上就能提高下单到成单的转化率。这个假设看起来很正确，但事先并不知道它的收益有多大、能提高多少转化率——不知道收益就很难贸然让公司投入大把时间和资源，说到底创业公司最要命的就是时间。于是他们围绕假设做了一个测试一百单的实验：从系统里筛选出一百个订单，用户一下单，PP 租车团队立刻让车主与用户沟通；产品经理亲自拿着 POS 机跟着车主找到叫车用户，当面交钱、当面交车。北京的大冬天，他们就用这种人工方式测试了一百单，结果这一百单用户最终全部成交，转化率 100%，而且用户很开心，再也没有那么大的心理压力。这证明了核心假设：用户愿意在看到车、且车主接单之后主动付钱。这个实验很简陋，没有任何产品上的改变，体验也说不上好，但用户还是接受了——这就是一个 MVP。实验之后，PP 租车迅速扩大方案、调整产品结构，整个研发组辛苦两周彻底改变了支付流程。功能上线后，整体订单成单转化率翻了一倍。

### 在行：先验证再开发 App

> 世界上有两类知识。一类是公共性知识，在 Google、百度百科里都能查到，解决方案是普世答案，对大多数人都有效——也正因对大多数人都有效，贡献答案的人会很多。另一类是个性化的经验性知识：比如做产品、做运营、做市场，甚至未来想做增长黑客，成长路上有很多艰难险阻，需要一对一的精细化指导，这对个人的价值更高，却很难在网上找到普世化答案。脱胎于果壳网的在行团队，最早要解决的问题就是：为每个人的个性化问题匹配行家，进行一对一指导。这件事的难点在于如何平衡双方的价值对标——A 为什么愿意帮 B？B 能从中获得什么？B 怎么衡量 A 的价值？A 怎么判断 B 的需求？

为了研究产品怎么启动，在行团队做了两件事：其一，假设产品已经做出来，模拟记者的身份在科技媒体上写一篇报道，大家看了报道会觉得很有感觉——这本身就是最小化可行产品的一种体现；其二，用果壳网的微信账号推送产品预告，并在 2014 年 11 月做了一个非常粗糙的 Web 页面，用各种曲折的方式测试用户的交易模式，花三个月积累了几十单真实交易案例。在这个过程中，他们理顺、搞清了产品逻辑——产品应该怎么运作，双边市场里双方各自怎么思考、心里大概怎么想。把一切想清楚之后，他们才去开发移动 App。

## MVP 的五大优势

1. **节约开发成本**：不需要烧几百万、上千万，最后才发现商业模式从根上就站不住。
2. **测试商业模式**：MVP 的存在价值就是验证市场、测试商业模式，这是创业早期最重要的一件事。
3. **获得第一批用户（甚至付费用户）**：种子用户很重要，在产品后续成长中可以作为冷启动的用户池、病毒传播的种子源头；如果 MVP 能吸引一些人付费，说不定还能解决项目早期的运营成本，甚至早早实现盈亏平衡，这对融资也非常有价值。
4. **获得更多反馈**：创业想法停留在纸面或口头时，出去交流很难获得直观、清晰的反馈；一旦通过 MVP 实现出来，别人就能直观地使用它，给出更客观的意见。
5. **吸引投资人**：只有一份商业计划书、空口说白话，有些投资人可能被打动，但更多只是看中创业者本人及其背景而不是项目；如果能拿出 MVP，说服力就不在一个层面上了。
