mvp-building

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数据不好时，知道何时转型