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