| name | mvp-building |
| description | 构建最小化可行产品来快速验证创业假设。当你有了一个创业想法、不确定顾客是否真的需要它、想在投入大量资源前先测试核心假设时，使用此Skill。 |
Skill: MVP构建法
Metadata
- ID: leanstartup-001
- 类型: framework
- 来源: 《精益创业》第五章
- 验证状态: ✅ 三重验证通过（V1: 5+章节佐证, V2: 实战高频, V3: 非常识）
R — Reading（原文引用）
"最小化可行产品是满足早期用户核心需求的最简单产品形态，用于启动学习反馈循环。"
"如果在没有真实数据证实顾客会改变行为之前就开发新产品，就像是在黑暗中去射击。"
I — Interpretation（方法论骨架）
MVP的核心逻辑是**"最快速最便宜地验证最危险的假设"**：
- 不是"做一个功能不全的产品凑合"，而是"为验证假设而精确设计"
- MVP的目的是学习，不是"发布产品"
- 判断标准不是"功能多少"，而是"能否在最短时间内、用最低成本获得关于核心假设的真实反馈"
A1 — Past Application（书中案例）
IMVU的第一个产品：作者团队花了6个月开发了一个"糟糕透顶"的产品，发布后几乎没人用。但通过快速迭代，最终获得6000万用户和5000万美元年收入。如果当初花2年做"完美产品"再发布，可能早就倒闭了。
Facebook的起步：第一个版本只有一个功能——投票选头像好不好看。根据用户反馈才逐步添加功能。
A2 — Future Trigger（何时调用）
当你听到以下问题时，就应该调用这个Skill：
- "我有一个产品想法，怎么验证它有没有市场需求？"
- "我要做一个App/平台/服务，应该从哪里开始？"
- "团队总说资源不够开发所有功能，先做什么？"
- "投资人要我做出完整产品才能给钱，但我只有有限的时间和预算"
- "我在犹豫要不要把所有功能都做完再发布"
E — Execution（可执行步骤）
步骤1：识别最危险的假设
列出你的商业计划中最可能在市场上站不住脚的假设：
- 顾客真的有这样的问题/需求吗？
- 顾客愿意为此付费吗？
- 你的解决方案是顾客会接受的吗？
原则：挑那个"如果错了整个业务就垮了"的假设优先验证。
步骤2：设计最小化实验
针对这个假设，设计一个能获得真实反馈的最简单产品：
- 能否做一个一页纸的展示页面，看顾客会不会点击"注册"？
- 能否做一个手动流程代替自动系统，先看顾客是否真的需要这个服务？
- 能否做一个视频/模型给目标顾客看，收集真实反应？
判断标准：这个MVP能否在2周内、用最小资源完成，且能回答"顾客是否真的需要这个？"
步骤3：发布并收集真实行为数据
- 关键是观察顾客的行为，而非问他们"你想要什么"
- 顾客说的可能是错的，但顾客做的基本是真的
- 如果顾客只是"感兴趣"但没有实际行动，说明假设未验证
步骤4：根据数据决定下一步
- 数据支持假设 → 继续投入，开发更完整的产品
- 数据不支持假设 → 立即调整/转型，不要把资源浪费在错误方向
- 数据不明确 → 设计新的实验继续验证
B — Boundary（何时不适用）
| 不适用场景 | 原因 |
|---|
| 硬件/制造业产品开发 | 物理产品无法像软件一样快速迭代，MVP成本太高 |
| 需要大量初始资本的餐饮/零售店 | 实体店开业前无法做真正的MVP测试 |
| 高度监管行业（医疗/金融） | 合规要求限制MVP的边界 |
| 已经是成熟市场的复制型业务 | 这种情况下"验证"的意义不同，更多是执行问题 |
作者盲点提醒：MVP方法最适合软件/SaaS/互联网产品。对于需要实体生产的产品，MVP的成本和周期都不可控，需要调整策略。
关联Skills
- Build-Measure-Learn循环 — MVP是BML循环的起点
- 对比测试 — MVP验证后，用A/B测试优化
- 转型决策树 — MVP数据不好时，知道何时转型
