Day 4：构建原型
AI 时代，PM 自己做原型。
从 Day 3 开始
昨天你做了三层判断——值不值得做、什么形式做、能不能持续。答案是：做。现在问题变了：怎么用最低成本做出来？
大多数人的第一反应是"写代码"或"找工程师"。但你马上会发现：在验证阶段，代码往往是最贵的选择。
Zappos 的创始人没写一行代码就验证了"人们愿意在网上买鞋"。Dropbox 的创始人录了一段三分钟视频就拿到了 75,000 人的等候名单。Airbnb 的第一版"产品"是三张气垫床。
他们做的事情本质上一样：用最低成本做出一个可以让用户体验的东西。
MVP：不是简陋产品，是最小实验
先纠正一个根深蒂固的误解。
MVP（Minimum Viable Product，最小可行产品）是 Eric Ries 在 2011 年提出的概念。原始定义是：
"MVP 是一个新产品的那个版本——让团队用最小的努力，收集到关于用户的最多的验证性学习。"
注意关键词：验证性学习，不是"最小功能集"。
大多数人把 MVP 理解成"砍功能砍到最少"。但 Ries 的本意是：MVP 是一个实验载体，它存在的目的不是"上线"，而是"学到东西"。
这意味着 MVP 不一定是产品。它可以是一段视频、一个 Landing Page、一次手动服务、甚至一个假按钮。形态取决于你要验证什么假设。
Ash Maurya 把这个思路推到了极致——他发明了 RAT（Riskiest Assumption Test，最危险假设测试）：不是"构建最小产品"，而是"构建最小测试"。当你这样想，构建物可以比你想象的小得多。很多时候一个 Google Form 就够了。
练习 1
选形态：用什么方式最便宜地让用户体验？
MVP 的形态选择是 Day 4 最关键的判断。选错形态，要么花了三周做了只需要一天的东西，要么做了精致的草图却测不出付费意愿。
我们分析了 12 位顶级产品人的构建方法。他们的形态选择各不相同，但背后的逻辑一模一样：形态由你要回答的问题决定。
| 你要验证什么 | 最佳形态 | 经典案例 |
|---|---|---|
| 有没有人想要这个东西？ | 视频 / Landing Page / 假门测试 | Dropbox：3 分钟视频，一夜 7.5 万人注册等候 |
| 有没有人愿意付钱？ | 绿野仙踪 / 预售页 | Zappos：网站看起来像电商，背后是创始人跑鞋店 |
| 用户能不能顺利使用？ | 高保真可交互原型 | Knapp 的 Design Sprint：一天做出逼真外壳 |
| 技术上做不做得出来？ | 代码原型（只验证关键路径） | Cagan 的可行性原型：写够回答技术问题的代码就停 |
| 服务流程对不对？ | Concierge（手动服务） | Graham：手动服务就是最小原型，不需要写代码 |
| 什么都不确定？ | 纸质草图 / 角色扮演 | IDEO：纸板、泡沫、乐高——能让想法不再抽象就行 |
Cagan 把原型分成四种形态，每种对应不同的构建目的：可行性原型（验证技术）、低保真用户原型（验证流程）、高保真用户原型（验证体验）、实时数据原型（需要真实数据才能引发真实反应）。
关键是：先确定你要回答什么问题，再选形态。 不是"我们做个 App 吧"，是"我们要验证什么，什么形态最便宜"。
练习 2
选保真度：做到什么程度够用？
形态选好了，下一个问题：做到多精致？
这不是越精致越好。IDEO 的创始人 David Kelley 有一条反直觉的原则：越粗糙越好。 因为精致的原型让人不敢提意见——谁好意思对一个花了一周做的精美界面说"我觉得方向不对"？
但 Jake Knapp（Design Sprint 发明者）持相反观点：原型必须逼真到让用户以为是真产品，否则用户在"测原型"而不是"用产品"，反应不真实。
谁对？都对。取决于你处在什么阶段：
| 阶段 | 保真度 | 为什么 |
|---|---|---|
| 方向还没定 | 低保真（草图、故事板） | 你需要用户说"方向不对"，粗糙才敢说 |
| 方向定了，测流程 | 中保真（线框图、可点击原型） | 需要用户走完流程，但不需要逼真 |
| 流程定了，测体验 | 高保真（逼真外壳） | 需要用户产生真实的情绪反应和使用行为 |
| 测付费意愿 | 高保真或真实服务 | 用户不会为草图付钱 |
Nielsen Norman Group 的研究结论：低保真和高保真原型在发现可用性问题方面同样有效。区别在于：低保真能让用户更自由地反馈方向性问题，高保真能引发更真实的情绪和行为反应。
练习 3
BML 循环：先想 Learn，再想 Build
到这里你已经知道选什么形态、做到什么程度。但还有一个问题：你怎么确定自己没有在盲目构建？
Eric Ries 的 Build-Measure-Learn（构建-测量-学习）循环是构建阶段的顶层逻辑。但它有一个违反直觉的用法：反向规划。
名字叫 Build-Measure-Learn，但执行顺序是反过来的：
1. 先想 Learn：我需要学到什么？（"用户愿不愿意在网上买鞋"）
2. 再想 Measure：怎么测量？（"有多少人真的下单了"）
3. 最后想 Build：做什么最小的东西能拿到这个测量？（"拍鞋店照片放网上"）这就是 Zappos 的故事。Swinmurn 不是先想"我要做一个电商网站"，而是先想"我要验证人们会不会在网上买鞋"——然后倒推出最小的构建物。
反向规划解决了一个致命问题：大多数人是从 Build 开始想的。 "我们做个 App 吧""先把数据库搭好""UI 设计先走起来"——这些都是在没想清楚"要学什么"之前就开始构建。
练习 4
真实案例：他们为什么选那个形态？
理论讲完了，来看三个经典案例。每个案例都是一道选择题——先想想你会怎么选，再看他们实际怎么做的。
练习 5
练习 6
练习 7
回头看
你在 Day 1 发现了痛，Day 2 把痛定义成可验证的假设，Day 3 决定做。今天你学了怎么用最低成本把假设变成用户可以体验的东西：
| 问题 | 做了什么 | 你刚才体验了什么 |
|---|---|---|
| 做什么形态？ | 根据要验证的假设类型选形态 | Zappos 选绿野仙踪测付费，Dropbox 选视频测需求，Airbnb 用三张气垫床测接受度——形态由问题决定 |
| 做到什么程度？ | 根据需要用户产生什么反应选保真度 | 方向不定时越粗糙越好（让人敢说不好），测体验时必须逼真（让人以为是真的） |
| 怎么避免盲目构建？ | BML 反向规划：先想 Learn → 再想 Measure → 最后想 Build | 大多数人从 Build 开始想——"做个 App 吧"。反向规划逼你从"要学什么"开始想 |
MVP 不是简陋产品，是最小实验。形态选择比构建质量更重要。Alberto Savoia 说得最直接：先确保你在做对的东西，再去把它做好。
有了原型，下一步是把它放到用户面前——怎么测、怎么判对错、什么时候该坚持、什么时候该转向。