1. 一个具体问题
团队想验证用户是否愿意为每周整理好的行业资料付费，却先花三个月开发登录、积分、推荐和社交功能。上线后无人续费，很难知道是需求不存在，还是复杂体验掩盖了真正价值。验证最危险的假设，未必需要完整产品。
2. 一句话解释
最小可行产品是为获得有效学习而设计的最小必要产品或交付方式，其范围由待验证假设决定。
3. 出处与原意
MVP 一词常追溯到 Frank Robinson 的相关实践，并由 Eric Ries 的精益创业方法广泛传播。精益创业语境强调用最少必要投入获得经验证的学习，不是把低质量、缺少基本保障的产品交给用户后再称之为试验。
4. 原理与机制
“最小”针对验证成本，“可行”针对用户能否真实体验核心价值以及团队能否解释结果。若假设是愿意付费，需要真实交易或足够接近交易的行为证据；若假设是技术可实现，原型实验可能比售卖页面更适合。手工交付也可以验证需求，但不能据此证明自动化后的成本可行。每个 MVP 都应包含目标群体、核心承诺、测量指标和决定规则，避免把“有人点过”误当作整套商业模式成立。
应区分试验成功与规模化成功。人工服务能发现用户是否需要结果，却可能依赖创始人的特殊能力；演示视频能检验兴趣，却不能证明用户能顺利完成任务。每次结果只支持被实际测试的部分，应清楚说明下一项尚未验证的风险。这样的阶段边界能防止团队因为一次正向反馈，就直接投入完整平台和大规模市场预算。
5. 一个完整案例
假设案例：团队要提供收费的行业资料周报，先招募二十位符合目标需求的读者，用人工筛选和邮件发送四期内容，明确试运行安排。每期追问哪些内容被用于实际工作，并观察续费与退订原因。若读者只在免费时打开，团队就重新检查价值；若持续付费但人工整理成本过高，下一步验证编辑流程与自动化，而不是直接扩张。这个试验可以检验核心交付价值，却尚未证明大规模获客和自动生产可持续。
6. 适用条件与反例
适合不确定需求下的早期产品探索。高风险领域不能通过省略必要保护来缩小产品；内部技术依赖也可能让最小范围仍然不小。一次失败不一定证明所有需求不存在，应检查样本、价值表达与执行质量是否足以检验原假设。
7. 今天可以尝试的行动
写出一个最可能让项目不成立的假设，然后设计能让真实目标用户表现出行动的最小交付。限定投入与期限，提前定义继续、修改和停止的条件。删除与验证无关的功能，但保留履行承诺所需的基本质量。