第2章 适用场景判断：哪些项目适合MVP、哪些不适合、决策检查表

2.1 适用场景

MVP（最小可行产品）并非万能工具，错误地在不适合的项目上启动MVP，会浪费团队时间和资源，甚至错过市场窗口。本章提供一套结构化判断框架，帮助你在项目启动前快速甄别“是否适合用MVP来验证”。

适合MVP的项目特征

• 核心假设不明确：团队对用户痛点、解决方案或价值主张存在多个待验证的猜想。
• 构建周期短：能在2–4周内交付一个具备核心功能的最小版本。
• 依赖真实用户反馈：无法通过内部推演或二手数据验证假设，必须由目标用户实际使用后提供反馈。
• 失败成本可控：最坏情况下的资源损失（时间、资金、人力）在可接受范围内。
• 快速迭代文化：团队和组织具备“试错—学习—调整”的敏捷协作机制。

不适合MVP的项目特征

• 强合规与安全约束：涉及医疗、金融、航空等必须通过完整认证才能接触用户的领域。
• 高度依赖基础设施：需要先建设底层平台、数据管道或硬件设备才能交付任何可用功能。
• 市场确定性高：已有充分的数据或竞品分析表明需求存在，直接进入完整开发更高效。
• 单次构建成本极高：即使“最小”版本也需要大量资源投入，失败风险不可承受。
• 无法隔离核心变量：产品功能高度耦合，无法单独抽取一个可独立验证的单元。