用途：帮助用户界定项目范围、削减功能，聚焦“最小可行”版本，源资料称其汇总了15位产品负责人的框架。
主要能力与核心原则：一是用“时间预算（appetite）”而非工作量估算来定范围，固定时间、变动范围；二是把MVP视为验证工具，用于以最高效方式验证某个假设，而非低质量产品；三是激进地砍功能，写出MVP必需功能后砍一半再砍一半；四是固定时间、小团队，如把单个功能的预算控制在六周、两人完成；五是“造滑板车而非车轴”，让MVP是更小价值主张的端到端可用版本；六是用“绿野仙踪”式人工模拟来先验证价值主张，再投入工程；七是超时未完成的项目应让其终止；八是把“可转向或砍掉路线图项”的机制写入产品流程。
使用方式：当用户请求范围相关帮助时，先了解其想验证的假设，确定可投入的时间与资源，找出首版必须具备的核心，并确保范围支持快速反馈。可用文中列出的提问引导，例如“这一版要验证的唯一假设是什么”“你愿意在交付前投入的最长时间是多少”“如果时间减半你会砍什么”“能否先手工验证再自动化”“最小但能完整交付价值的东西是什么”。
限制与常见误区：容易只做估算而非时间盒、只造“车轴”即交付大功能的不完整部分、从不终止项目而反复延期、把MVP过度工程化、忽视先手工验证。源资料未提供具体收费、平台或安装步骤。