MoSCoW优先级排序：80个点子只做5个

你有80个功能点子——50个是你自己的，另外30个是用户建议的。MoSCoW优先级排序——必须有（Must have）、应该有（Should have）、可以有（Could have）、不会有（Won't have）——能把这80个点子砍到5个或更少、真正用来检验你假设的功能。其余的都是干扰，而且大部分都该归入“不会有”。

除了你那80个，竞争对手还有另外20个你没有的功能。你不可能全做，也不该全做。下面是无情砍需求的框架：每个类别的检验问题、在真实时间线上好的与坏的优先级排序是什么样子，以及防止你去做那些本可以直接手工完成的东西的规则。

MVP的MoSCoW优先级排序是什么？

MoSCoW把每个功能归入四个桶之一，每个桶只有一个检验问题。诚实作答，那份80项的清单会自己塌缩：

注意这个例子里哪些没通过“必须有”的检验。优先级？用户可以手动重新排序列表。分类和标签？不错，但不是核心。重复任务？可以手工创建。一个功能成为“必须有”，不是因为它有用——而是因为没有它，你的假设就无法检验。

你做的不是最小可行产品

你做的是最小可检验产品。这个重新定义改变了一切，因为它把每一个优先级决策都锚定在你的假设上，而不是你的愿景上。愿景是留给第10版的。如果你无法用一句话说清楚你的假设，先停下来把它搞定——它直接来自你在决定做任何东西之前所做的验证工作。

而“不会有”正是纪律所在。它不是待办列表——它是一份你主动决定不做的功能清单，每一项都附有重新考虑的书面触发条件：有了100个用户之后、V1被证明之后，或者用户提出五次或更多次要求时。把触发条件写下来，才能防止这个功能在第二周悄悄溜回范围。

12 周企业职业生涯从来都不是计划申请加入 Solopreneur Accelerator。立即申请 →

第二轮：影响与投入

MoSCoW把你从80个带到一份候选清单。影响-投入矩阵把你带到五个。给每个留下来的功能在两个维度上打分——对用户有多大帮助（1–10）、老老实实要做多少天——四个象限就出现了：

• 速赢项（高影响、低投入）：这些就是你的MVP。
• 大项目（高影响、高投入）：验证之后再做，绝不在之前。
• 补位项（低影响、低投入）：打磨细节，有时间才做。
• 浪费时间项（低影响、高投入）：永远不要做——可能只有两个用户想要的定制报表引擎、没人要求的AI功能、为边缘情况设计的复杂权限。

对你自己的数字保持怀疑。创始人系统性地低估投入、高估影响——所以给每个估算加50%的缓冲，质疑每一个9分（满分10）的影响评分，并把总构建时间控制在四周以内。

先手工做，再去构建

对每个留下来的功能，再问一个问题：头10个用户，我能手工完成吗？如果能，就先别做。自己发邮件通知。用电子表格做每周报告。通过一对一通话带每个用户上手。手工开发票。替他们导入CSV。

先手工，上线更快，让你了解用户真正需要什么而不是他们嘴上说需要什么，还能与最重要的早期用户建立关系。它同时也是一次伪装起来的需求检验：如果你连为10个用户手工做一件事都懒得做，为什么要为1000个用户去构建它？只有当你已经手工做了10次以上、每次耗时超过30分钟、模式稳定一致，并且用户明确提出要求时，才去自动化。

好的与坏的优先级排序是什么样子

同一个任务管理器点子，两种范围决策。坏的版本：重复任务、子任务、标签和分类、时间追踪、团队共享、移动应用、日历视图、甘特图——要做90天。好的版本：创建任务、设置截止日期、标记完成、简单的列表视图，以及手工发给前10个用户的每日邮件摘要——14天。两周上线，而不是三个月。

被砍掉的功能本来也不是真正的成本——错失的学习才是。一个面向自由职业者的CRM，从八个功能、120天的计划砍到五个功能（添加联系人、添加备注、标记状态、简单搜索、手动导出CSV），21天就上线了，而用户揭示了任何路线图都预测不到的事：他们根本不想要项目管理，他们要的是跟进提醒。一个落地页构建器，从60天的计划砍到五个模板、可编辑文本和一个基础表单，结果发现用户想要的是更多模板，而不是自定义。多花的90天构建，只会是90天都在做错误的东西。

让范围重新膨胀的五个陷阱

1. “但这是我们愿景的核心。”愿景是留给V10的。检验假设的核心是什么？
2. “用户提到过这个。”哪些用户？有多痛？他们会付费吗？一个准备付费的人，比十个“要是能……不是很酷吗”的建议更有分量。
3. “只多两天而已。”两天加上调试会变成两周。砍掉它；证明确实需要之后再加。
4. “竞争对手都有。”他们为此花了好几年。你是在检验，不是在竞争。
5. “没有这个我们没法上线。”不，你可以。绝对最小的版本是什么？

如果你最终的清单超过五个功能，说明你还没砍完。最好的功能，是你不去做的那一个：每砍一个，都能更快上线、更快学习、成本更低、维护更轻松。你的目标不是做出一个产品，而是检验一个假设。

本书The Solopreneur RevolutionLuis Gonçalves 讲述如何在不辞职的情况下用 AI 打造独立创业者事业。获取本书 →

常见问题

MoSCoW是什么的缩写？

必须有（Must have）、应该有（Should have）、可以有（Could have）、不会有（Won't have）。每个类别都有一个检验：必须有，意味着没有它假设就无法检验；应该有，意味着没有它早期用户仍会使用产品；可以有，意味着缺了它没人会不再使用产品；不会有，意味着它分散核心价值，被明确砍掉。

一个MVP应该有多少个功能？

五个或更少。如果你的清单更长，说明你还没砍完。总构建时间控制在四周以内，给每个投入估算加50%的缓冲，并质疑每一个“必须有”——大多数功能都属于“不会有”。

必须有和应该有有什么区别？

“必须有”是没有它你就无法检验核心假设的功能——拿掉它，实验就死了。“应该有”能显著改善体验，但没有它早期用户仍会使用产品，所以要等到V1验证之后再做。

什么时候应该把手工流程自动化？

只有当你已手工做了10次以上、每次耗时超过30分钟、模式清晰一致，并且用户明确要求自动化时。在那之前，手工比代码便宜——而且它会教你用户真正需要什么。