最小可行产品设计
# 最小可行产品设计
MVP vs MLP、验证假设、快速迭代——第一个版本只做一件事
# 一、MVP 到底在说什么：不是做半个产品
MVP（Minimum Viable Product）被误解最多的概念之一。
常见的错误理解：
❌ MVP = 功能砍一半，先上线再说
❌ MVP = 质量很差的版本（"反正以后会改"）
❌ MVP = 只是"Beta 版"——先让用户用着，收集反馈再迭代
2
3
真正的 MVP 含义：
✅ MVP = 用最小的成本，验证最核心的假设
↑ ↑
不是"功能少" 是你到底想证明什么
2
3
MVP 的输出不是"一个能用的产品"，而是"一次验证过的学习"。你上线的每一个功能，都应该对应一个你想验证的假设。如果你的 MVP 上线后什么都没学到——不管功能做得多好，这次迭代是失败的。
# MVP 的铁三角
假设（Hypothesis）
/ \
/ \
最小成本 可验证
（Minimum） （Validatable）
\ /
\ /
学到东西（Learn）
2
3
4
5
6
7
8
三个要素缺一不可：
- 有假设——不是"我想做个 XX 功能"，是"我相信做 XX 能让 YY 指标提升 ZZ%"
- 最小成本——能用一个按钮验证的，不要做一个页面
- 可验证——上线后能拿到数据，而不是上线后"感觉用户挺喜欢的"
# 二、从假说到实验：MVP 的正确起点
# 2.1 没有假设，就没有 MVP
大多数产品需求长这样：
"做一个用户积分系统，用户签到、消费都能获得积分，积分可以兑换优惠券。"
你如果直接开始设计数据库表、写接口——你跳过了 MVP 最核心的一步：你到底想验证什么？
先转换成假设：
假设 1：用户会因为积分激励而增加消费频率。
假设 2：积分兑换优惠券比直接发优惠券的用户留存更高。
假设 3：积分体系能降低用户流失率（因为有积分绑着，舍不得走）。
2
3
三个假设，哪一个是当前阶段最需要验证的？如果用户根本不在乎积分，假设 2 和 3 都不用做了。所以第一步只验证假设 1。
# 2.2 假设的写法——必须包含数字
模糊的假设没有验证价值。假设必须有量化的预期结果：
❌ 模糊假设：
"用户会喜欢一键下单功能。"
✅ 可验证假设：
"上线一键下单后，从商品详情页到下单成功的转化率将从 12% 提升到 18%，
且一键下单使用率超过 30% 视为验证成功。"
2
3
4
5
6
好的假设公式：
我们相信 [做什么] 会带来 [什么变化]。
当 [什么指标] 在 [什么时间内] 达到 [什么数值] 时，视为验证成功。
2
# 2.3 工程师写假设的天然优势
产品经理的假设往往是"用户想要 XX"——主观。但你可以把假设建立在你看到的系统数据上：
产品经理的假设：
"用户想要深色模式。"（来源：竞品都有）
工程师的假设：
"后端日志显示，晚上 10 点到凌晨 2 点的活跃用户占 35%，
而目前纯白界面在高亮度屏幕上刺眼程度可能影响使用时长。
如果能做深色模式，预期夜间用户平均时长可提升 10%。"（来源：Nginx 日志 + 设备亮度 API）
2
3
4
5
6
7
后者比前者可验证性强得多，也更难被质疑。
# 三、MVP 的成本控制：你能做到多小？
# 3.1 五级最小验证手段
不是所有验证都需要写代码。从低到高：
| 级别 | 手段 | 成本 | 验证强度 | 适合验证什么 |
|---|---|---|---|---|
| L1 | 纸上原型——画草图给用户看 | 1 小时 | ⭐ | 概念是否被理解 |
| L2 | 落地页测试——做一个介绍页，看有多少人点"感兴趣" | 半天 | ⭐⭐ | 需求是否真实存在 |
| L3 | 假门测试——按钮放上去但不实现，看点击量 | 半天 | ⭐⭐⭐ | 功能需求强度 |
| L4 | 手动后台——开发不做，你人肉代替 | 1 天 | ⭐⭐⭐⭐ | 复杂流程是否走得通 |
| L5 | 最小代码实现——只做核心路径 | 3-5 天 | ⭐⭐⭐⭐⭐ | 真实使用行为 |
原则：永远从最低级开始。L1 能验证的，绝不做 L2。
# 3.2 三个经典的"别写代码"案例
案例 1：Dropbox 的 3 分钟视频 MVP
Dropbox 在写一行代码之前，创始人 Drew Houston 做了一段 3 分钟的演示视频，展示"文件自动同步到所有设备"的概念。视频发布到 Hacker News 后，beta 注册用户从 5000 暴涨到 75000。
→ 验证的假设："人们需要跨设备文件同步。" 成本：3 分钟视频。如果做完整产品再做验证，成本可能是 6 个月。
案例 2：Zappos 的"手动 MVP"
Zappos 创始人想验证"人们愿意在网上买鞋"。他没建网站、没搞供应链、没写代码。他只是去本地鞋店拍了照片，放到一个简单的网页上。有人下单——他就去鞋店买那双鞋，自己寄出去。
→ 每双鞋亏一点钱，但验证了核心假设："网上买鞋的需求真实存在。" 之后才建了完整平台。
案例 3：假门测试——微信"摇一摇"的逻辑
如果你想验证"用户需要手机摇一摇来搜索附近的人"，不用先写陀螺仪监听 + 蓝牙 BLE + 地理围栏。先做一个按钮叫"摇一摇找人"，用户点了弹窗"功能开发中，感兴趣的留下手机号"——看有多少人点。
→ 如果没人点，省下了 2 周的开发成本。如果有人点，你还可以直接电话回访："你希望在什么场景下用这个功能？"
# 3.3 代码 MVP 的最小化技巧
当你确定必须写代码时，这三条规则能帮你砍掉 80% 的非必要工作：
规则 1：不做权限系统
❌ "先做一个 RBAC 权限模型，支持管理员、运营、普通用户三个角色……"
✅ "第一版只有管理员能用，硬编码判断登录邮箱是不是 @company.com。"
2
权限是 MVP 最大的成本黑洞——表设计、中间件、前端按钮显隐，一套下来 3 天没了。但你的 MVP 只有 5 个内测用户——你不需要权限系统。
规则 2：不做"通用方案"
❌ "支持导入 CSV、Excel、JSON 三种格式，支持自定义字段映射。"
✅ "只支持你给运营的那个 Excel 模板（固定的 3 列），列名写死。"
2
做通用方案意味着枚举所有可能情况——但你连用户到底用不用这个功能都不知道，枚举什么呢？
规则 3：不做"异常处理"——只做"已知异常"
❌ try-catch 包住整个方法，各种边界条件都处理。
✅ 只处理你在手动跑通主流程时实际遇到过的异常。其他异常让它 500——有日志就行。
2
MVP 阶段，用户量少，影响面小。一个没处理的异常造成的伤害远小于你花 3 天做防御性编程浪费的时间。
# 四、MVP vs MLP：什么时候够用，什么时候要惊艳
# 4.1 两者的定义
MVP（Minimum Viable Product） MLP（Minimum Lovable Product）
最小可行产品 最小可爱产品
↓ ↓
"能用就行，验证假设" "第一印象就要让人喜欢"
↓ ↓
B2B 内部工具 / 替代方案明确 C 端消费品 / 强竞争市场
2
3
4
5
6
MVP 和 MLP 不是互斥的——是同一个产品在不同市场阶段的策略。
# 4.2 什么时候必须 MLP
| 场景 | 为什么 MVP 不够 | 例子 |
|---|---|---|
| C 端社交产品 | 冷启动期用户没有容忍度——第一个体验不好就走了，没有"下次" | 微信朋友圈第一条评论就有动画 |
| 强竞争赛道 | 竞品功能完整——你的 MVP 对比起来就是残次品 | 打车软件：滴滴已经能实时看司机位置，你的 MVP 只显示"已派单"——用户不会等你迭代 |
| 品牌敏感型 | 用户对品质有预期——粗糙的第一印象会损害品牌 | 苹果做任何新功能都不能"凑合能跑" |
| 情绪价值为主 | 产品卖的不是功能，是体验 | 游戏、内容社区、设计工具 |
# 4.3 决策框架：MVP 还是 MLP？
用两个问题判断：
问题 1：用户有没有"替代方案"？
有 → MVP 即可（只要比替代方案好就行）
没有 → 考虑 MLP（用户对比的是"期待"，不是"竞品"）
问题 2：用户会不会给第二次机会？
会 → MVP 即可（B2B 工具、内部系统——不用也得用）
不会 → MLP（C 端一次性体验——卸载就是永别）
2
3
4
5
6
7
实操建议（对工程师）：即使是 MLP，也只"可爱"在最关键的一两个交互上。
做一个社交 App 的 MLP：
✅ 花精力打磨的：信息流滚动流畅度、发布动态的动画、点赞的触觉反馈
❌ 不用花精力的：设置页面、个人资料编辑、隐私协议弹窗
2
3
"可爱"不是所有地方都精致——是在用户情绪最高涨的那几个触点做到极致。
# 五、快速迭代：从 MVP 到 v2 的节奏
# 5.1 迭代的四个阶段
MVP 上线 → 收集数据 → 决定下一步 → 再次上线
↑ |
└──────────── 2 周一个循环 ─────────────┘
2
3
不要等"功能完整了再上线"。每一个迭代只做一件事：
迭代 1（MVP）：能登录、能发一条动态。→ 验证"用户愿意在这里发内容吗？"
迭代 2：能评论、能点赞。 → 验证"有互动后留存率提升吗？"
迭代 3：能关注用户、有信息流。 → 验证"用户会主动回访吗？"
迭代 4：能发图片。 → 验证"富媒体会让内容量提升吗？"
2
3
4
每个迭代只有一个核心假设。如果你一次迭代同时验证 3 个假设，上线后数据涨了——你不知道是哪个原因涨的。数据跌了——你也不知道是哪个原因跌的。等于白做。
# 5.2 "两周规则"——工程师的铁律
如果一个功能从设计到上线超过 2 周 → 说明它不是一个 MVP，你做出了一个"你以为用户需要"的东西。
2 周不是因为技术限制——是反馈周期的限制。超过 2 周，你上线时已经忘了当初的设计决策；用户需求可能已经变了；竞品可能已经做了类似的事。
如果估出来要 3 周——砍功能，不是延期。砍到 2 周以内。你能砍的永远比你想象的要多。
# 5.3 上了线不是结束——"空跑"的禁忌
MVP 上线后最常见的死亡方式：没人看数据。
❌ 迭代结束的标准：
"代码合并到 master，测试通过了，发版了。"
✅ 迭代结束的标准：
"代码上线 5 天后，拿到了足够的用户数据，
验证了（或否定了）迭代开始时的假设，
产出了下一步的行动建议。"
2
3
4
5
6
7
一个 MVP 上线后如果没拿到可用的数据——和没上线没有本质区别。你只是把代码部署到了一台服务器上，没有"学到任何东西"。
# 六、综合案例：一个积分系统的 MVP 设计
回到文章开头的例子："做一个用户积分系统，用户签到、消费都能获得积分，积分可以兑换优惠券。"
# Step 1：明确假设
核心假设：积分激励能让用户的月消费频次从 1.2 次提升到 2.0 次。
验证周期：上线后 4 周。
成功标准：实验组（有积分）vs 对照组（无积分），月消费频次提升 ≥ 50%。
2
3
# Step 2：砍到最小验证手段
完整的积分系统需要：签到、消费积分、积分商城、兑换、过期规则、积分明细、排行榜……
全部砍掉，只留一个东西验证假设：
MVP 方案：不做积分系统。直接推送消息：
"恭喜！本月消费满 3 笔赠送 10 元优惠券（限时 7 天使用）"
→ 不做积分累计，不做积分商城，不做兑换。
→ 直接"笔数换券"，后台手动发，前端只展示。
→ 成本的十分之一，但验证的是同一个假设：激励能提升复购率。
2
3
4
5
6
# Step 3：代码实现的最小化
后端：
- 查询本月订单数 ≥ 3 的用户 → 一个 SQL
- 给他们账户发一张固定面额优惠券 → 一个 UPDATE
- 定时任务每天跑一次 → 一个 cron
前端：
- 首页展示优惠券到账的横幅 → 一个已有的组件
- 不需要新页面
总工时：后端 1 天 + 前端 0.5 天 = 1.5 天
对比完整积分系统：至少 3 周
2
3
4
5
6
7
8
9
10
11
# Step 4：判断验证结果
4 周后看数据：
如果实验组复购率从 1.2 → 1.8（提升 50%）：
✅ 假设验证成功。下一步做积分系统有数据支撑了——可以投入 3 周去做。
如果实验组复购率从 1.2 → 1.3（几乎没变）：
❌ 假设被否定。积分激励不是用户复购的驱动力——省下了 3 周的开发成本。
下一步应该验证别的假设（比如：是不是商品品类太少导致的？配送太慢？）
2
3
4
5
6
7
8
无论验证成功还是失败——MVP 都完成了它的使命。你学到了东西。
# 七、工程师做 MVP 的常见坑
# 坑 1：为 MVP 写的代码"反正是临时的"就不管质量
❌ "这个查询循环里调第三方接口——先这样，以后改成异步的。"
→ 这个"以后"永远不会来。三周后线上因为这个超时报错，你忘了当初的"临时方案"。
✅ 同样是临时方案，但加一行注释：
// FIXME(MVP): 同步调用超时风险，迭代 2 改成消息队列异步
// 触发条件：日订单 > 100 时必须改，目前日订单 < 20 风险可控
2
3
4
5
6
原则：可以不做异常处理，但要知道什么情况下会出问题。把已知风险写在注释里，设定触发阈值。
# 坑 2：MVP 偷偷变成了"我想做的功能"
需求：做个商品收藏功能（MVP：一个收藏按钮 + 一个收藏列表）
→ 实际做出来的：收藏夹分类、批量管理、降价提醒、收藏商品分享……
→ 多了 4 个功能，没有一个是当初核心假设要验证的
2
3
每次写着写着想"再加一个"，问自己：这个额外功能是在验证假设，还是在满足我的工程师完美主义？
# 坑 3：MVP 做了，但没做数据埋点
"功能上线了，但是忘了埋点。不知道谁在用、怎么用、用了多少次。"
→ 这个 MVP 白做了——你什么都没学到。
2
MVP 的数据埋点比功能本身更重要。 功能可以糙，但数据必须全：
- 谁用了（用户 ID）
- 什么时间（时间戳）
- 做了什么（事件名）
- 达到结果了吗（转化事件）
# 八、小结
MVP 不是做一半产品——是用最小的成本，跑完一次"假设 → 验证 → 学习"的闭环。
MVP 的正确流程：
1. 写假设 → "我相信做 X 能让 Y 指标提升 Z%"（必须带数字）
2. 选手段 → L1 纸上原型 → L5 最小代码，从低到高
3. 砍功能 → 只做验证这一个假设所需的最少功能，多余的都砍
4. 做埋点 → 上线前先确认数据能不能拿到
5. 上线看数据 → 5 天后出结论：假设成立 / 不成立，下一步做什么
6. 再迭代 → 成立 → 继续做；不成立 → 换个假设
2
3
4
5
6
7
8
三条行动原则：
- 不写没有假设的代码——每个功能上线前，你都知道它在验证什么
- 两周上不了线的功能都不是 MVP——砍到两周以内
- MVP 的成功标准不是"用户说好"——是"你学到了新东西"
