理解了MVP的含义，下一个问题是：具体怎么做减法？如何从20个功能砍到3个？
本节提供一套完整可操作的方法，包括功能筛选框架和「不做清单」的制作技巧。
面对每一个功能，问自己这三个关键问题：
这个问题帮你区分「核心功能」和「附加功能」。
判断标准：
待办清单的例子：
| 功能 | 没有它能用吗？ | 结论 |
|-----|--------------|------|
| 添加任务 | 不能 | 核心功能 |
| 完成任务 | 不能 | 核心功能 |
| 查看任务列表 | 不能 | 核心功能 |
| 任务分类 | 能（先不分类也行） | 非核心 |
| 暗黑模式 | 能（不影响使用） | 非核心 |
| 统计报表 | 能（知道完成了就行） | 非核心 |
这个问题帮你聚焦于验证假设的功能。
判断标准：
待办清单的例子：
假设核心假设是：「极简待办比便签纸更容易坚持」
| 功能 | 能验证假设吗？ | 理由 |
|---|---|---|
| 一键添加任务 | 能 | 测试「极简」是否真的更容易用 |
| 打卡日历 | 不确定 | 可能有用，但不是验证「极简」的关键 |
| 社交分享 | 不能 | 这是增长功能，不是验证功能 |
| 成就系统 | 不能 | 这是留存功能，先验证核心价值再说 |
这个问题帮你区分「获客功能」和「留存功能」。
判断标准：
关键洞见：
用三个问题筛选后，把功能分成三档：
| 优先级 | 定义 | 行动 | 示例 |
|---|---|---|---|
| P0 | 没有就无法验证核心价值 | 必须在MVP中包含 | 添加任务、完成任务 |
| P1 | 重要但可以后续迭代 | V2版本再做 | 任务分类、提醒功能 |
| P2 | 锦上添花 | 有时间再说 | 暗黑模式、统计报表 |
重要原则：
把上面的方法整理成一个决策流程：
大多数人只列「要做清单」，很少有人列「不做清单」。
但「不做清单」可能比「要做清单」更重要。
当你告诉AI「帮我做一个待办清单」，AI可能会问你：要不要加日历同步？要不要支持团队协作？
如果你没有明确的边界，很容易被这些问题带偏。
「不做清单」让你和AI都清楚：这些事情不在范围内。
做项目的过程中，你会不断产生新想法：
这些诱惑会不断膨胀你的项目范围。
「不做清单」是你的防线：这些功能我已经想过了，决定不做，理由在这里。
当别人问「为什么你没做XX功能」时，你可以清晰回答：
这个功能在我的「不做清单」里。原因是[理由]。我会在[条件满足时]重新考虑。
这比「还没来得及做」或「以后再说」专业得多。
一份完整的「不做清单」应该覆盖三个维度：
列出你明确决定不做的功能，以及理由。
你的产品不可能服务所有人。明确你不打算服务谁。
MVP阶段你应该聚焦于验证，而不是增长。明确你暂时不关心什么指标。
# 不做清单（V1版本明确不做的事情）
## 一、不做的功能
| 功能 | 不做的理由 | 何时重新考虑 |
|-----|----------|-------------|
| [功能名称] | [理由] | [条件] |
## 二、不考虑的用户群
| 用户群 | 不考虑的理由 |
|-------|-------------|
| [用户描述] | [理由] |
## 三、不追求的指标
| 指标 | 不追求的理由 | 替代关注点 |
|-----|-------------|----------|
| [指标名称] | [理由] | [替代指标] |# 不做清单（V1版本）
## 一、不做的功能
| 功能 | 不做的理由 | 何时重新考虑 |
|-----|----------|-------------|
| 多设备同步 | 需要后端开发，大大增加复杂度 | 核心功能验证成功后 |
| 团队协作 | 不是个人工具的核心价值 | 有明确的团队使用需求时 |
| 暗黑模式 | 纯美化功能，不影响核心验证 | 有用户强烈反馈时 |
| 日历视图 | 增加开发工作量，不是极简体验 | P0功能稳定后 |
| 统计报表 | 对于验证「极简好用」没有帮助 | 用户留存稳定后 |
| 小组件 | 平台特定功能，增加维护成本 | 主产品成熟后 |
## 二、不考虑的用户群
| 用户群 | 不考虑的理由 |
|-------|-------------|
| 大型企业团队 | 需求复杂，与个人工具定位不符 |
| 专业项目管理 | 有成熟的专用工具，竞争激烈 |
| 技术小白 | 学习成本高，早期用户应该是轻度用户 |
## 三、不追求的指标
| 指标 | 不追求的理由 | 替代关注点 |
|-----|-------------|----------|
| 日活跃用户数 | MVP阶段验证价值更重要 | 核心功能使用频率 |
| 用户增长速度 | 增长可能掩盖问题 | 用户留存率和反馈质量 |
| 功能完成度 | 功能多少不是重点 | 假设验证结果 |# 不做清单（销售数据分析V1版本）
## 一、不做的功能
| 功能 | 不做的理由 | 何时重新考虑 |
|-----|----------|-------------|
| 实时数据更新 | 增加技术复杂度，不是决策关键 | 有明确的实时决策需求时 |
| 多维度钻取 | 开发时间长，不如人工分析灵活 | 基础报表使用稳定后 |
| 自动报告生成 | 不是当前痛点 | 用户明确需要时 |
| 数据导出 | 不是核心验证目标 | 有二次分析需求时 |
## 二、不考虑的用户群
| 用户群 | 不考虑的理由 |
|-------|-------------|
| 财务部门 | 关注点不同，需要专门的财务报表 |
| 客服团队 | 使用场景差异大，需求不同 |
| 外部合作伙伴 | 数据安全考虑，权限管理复杂 |
## 三、不追求的指标
| 指标 | 不追求的理由 | 替代关注点 |
|-----|-------------|----------|
| 报告数量 | 数量不等于价值 | 决策效率提升 |
| 页面访问量 | 使用频率不是重点 | 实际采纳的决策建议数 |
| 数据准确性100% | 完美主义陷阱，99%足够用 | 关键结论的正确性 |对于每一个想做的功能，问自己：
诚实地评估你的限制：
对于每个「不做」的功能，明确什么时候会重新考虑：
「不做清单」不是一成不变的：
在项目启动阶段就制定「不做清单」，明确项目边界。
当发现功能越做越多时，用「不做清单」重新聚焦。
当用户要求新功能时，对照「不做清单」决定是否要考虑。
用「不做清单」统一团队认知，避免重复讨论已决定不做的事情。
在给AI提需求时，把「不做清单」作为边界条件明确告诉AI。
问题：把「不做清单」当成绝对的约束，失去了灵活性。
解决方法：
问题：「不做」的理由很模糊，比如「暂时不需要」。
解决方法：
问题：制定了「不做清单」但没有告诉相关方。
解决方法：
问题：项目环境变化了，但「不做清单」没有及时更新。
解决方法：
找一个你或别人做过的失败项目，分析：
给AI提一个需求，观察它是否会建议额外功能：
通过系统性的功能筛选和「不做清单」管理，你可以有效避免功能膨胀，聚焦核心价值，提高项目成功率。记住：决定不做什么，比决定做什么更重要。