1. MVP 定义与核心概念

本章是整套取舍方法的认知地基。如果不先把 MVP 本质、MVP 目标 和 “最小可行 vs 最小可爱” 这三个概念界定清楚，后续所有功能边界判定都会失去准星。以下按 SOP 流程展开。

1.1 适用场景

凡涉及以下任意一条的项目或产品阶段，必须首先对齐本章定义：

• 新产品从 0 到 1，资源有限，需要快速验证市场假设。
• 已有产品计划添加新模块，不确定用户是否真正需要。
• 团队内部对“MVP 该做多少功能”存在分歧，导致开发范围反复摇摆。
• 投资人/高层要求“尽快上线”，但业务方坚持“体验完整再发布”。

1.2 前置条件

开始本章学习或团队对齐前，需准备好以下条件：

1. 产品经理、技术负责人、业务方代表至少各 1 名在场。
2. 已梳理出初步的用户故事（User Story）或功能列表。
3. 明确本次要验证的核心商业/用户假设（例如：用户愿意为 30 分钟送达支付 5 元配送费）。
4. 准备一块白板或协作文档用于实时记录概念差异。

1.3 操作步骤

以下三步构成“MVP 概念校准流程”，每一步都必须输出可存档的结论。

1.4 输入输出物

1.5 责任边界

• 产品经理（PM）： 负责主持概念校准会议，确保假设陈述精确、不模糊。
• 技术负责人： 对每个 [可爱] 功能评估实现成本（人/天），给出“是否可砍”的建议。
• 业务方/运营： 提供用户场景细节，协助判断某项功能对验证假设是否必要。
• 团队全员： 在步骤 3 投票标记时，每人拥有相同权重的一票；争议时由 PM 做最终裁决。

1.6 记录材料

以下表格是会议中必须实时填写的记录，完成后归档至项目知识库：

1.7 异常处理

1.8 验收标准

完成本章内容学习或团队对齐后，必须达到以下状态：

1. 每位成员能用自己的话说出“我们这次 MVP 要验证的单一假设是什么”。
2. 功能清单上每个条目都有明确的 [可行] 或 [可爱] 标记，且标记理由可回溯。
3. 团队对“如果资源只够做 3 个功能，选哪 3 个”能达成一致（或有记录的裁决）。
4. 产出物归档至项目知识库指定位置。