第四章：MVP（最小可行产品）规划

好，咱们进入第四章。这一章我特别想跟你聊聊，因为太多SaaS项目死在了“想太多”上。

MVP，最小可行产品。这词你肯定听过。但说实话，我见过90%的人理解错了。他们以为MVP就是“功能少一点的产品”。错。MVP的核心是——用最少的功能，验证最大的风险。

我自己踩过这个坑。2018年我带一个团队做企业协作工具，花了6个月做了30多个功能。上线后用户反馈：你们这玩意儿跟Slack有啥区别？后来我砍到只剩3个核心功能，两周上线，反而拿到了第一批付费用户。嗯，从那以后，我对MVP有了新的理解。

4.1 MVP核心原则

先记住三条铁律：

• 原则一：MVP不是最小功能集，是最小学习集。你做MVP不是为了交付功能，是为了验证假设。比如你假设“用户需要在线报销”，那MVP只需要验证“用户是否愿意在线上传发票”，而不是把审批流、预算控制全做了。
• 原则二：砍功能不砍价值。每个功能背后都有用户价值。砍功能时，要保留核心价值闭环。举个例子，打车软件的MVP可以没有支付功能（先叫车后付现金），但不能没有“叫到车”这个核心价值。
• 原则三：越快越好，但质量不能崩。我见过有人为了赶MVP上线，代码写得像屎山。结果用户一用就崩，直接劝退。MVP可以功能少，但核心流程必须稳。你想想看，用户第一次体验就卡死，他还会给你第二次机会吗？

4.2 功能优先级排序（MoSCoW方法）

功能那么多，先做哪个？我推荐MoSCoW方法。这名字有点怪，其实是四个优先级的首字母：

优先级	含义	我的理解
M - Must have	必须有	没有这个功能，产品就是个废物。比如电商的“加购物车”和“下单”。
S - Should have	应该有	很重要，但暂时没有也能活。比如“订单评论”功能。
C - Could have	可以有	锦上添花，有更好，没有也无所谓。比如“深色模式”。
W - Won't have	这次不做	明确告诉团队：这个版本不考虑。比如“多语言支持”。

具体怎么用？我一般这么操作：

1. 把所有功能列出来，写在卡片上。
2. 团队一起讨论，每个功能属于哪个优先级。
3. 关键一步：M类功能不能超过总数的20%。如果超过，说明你还没想清楚什么是真正的核心。
4. W类功能直接归档，别纠结。

4.3 MVP范围界定

范围界定，说白了就是画个圈。圈里的是MVP要做的，圈外的是以后再说。

怎么画这个圈？我有个“三问法”：

• 第一问：没有这个功能，用户的核心任务能完成吗？能→砍掉。不能→保留。
• 第二问：这个功能的风险高吗？比如涉及支付、数据安全、合规。风险高的功能，尽量在MVP里验证。
• 第三问：这个功能开发成本高吗？成本高且价值低的，直接砍。成本低且价值高的，优先做。

举个例子。我之前做SaaS CRM，MVP范围界定是这样的：

• 圈内：客户管理（增删改查）、跟进记录、简单报表。这些是核心。
• 圈外：邮件营销、自动化工作流、API接口。这些以后再说。
• 特别处理：数据导入功能。成本高但风险也高（用户数据丢了就完蛋）。我选择先做手动录入，导入功能放到V2。

4.4 用户故事地图

用户故事地图，这工具我强烈推荐。它帮你把MVP范围可视化，团队一看就懂。

怎么做？分四步：

1. 写用户故事：格式是“作为[角色]，我想要[功能]，以便[价值]”。比如“作为销售，我想要快速录入客户信息，以便节省时间”。
2. 按流程排列：把用户故事按使用流程从左到右排。比如“注册→登录→创建客户→录入跟进→查看报表”。
3. 分层：第一层是核心流程（必须有的），第二层是扩展功能（可以有的），第三层是未来功能（这次不做的）。
4. 画线：在核心流程和扩展功能之间画一条线。线以上的就是MVP范围。

我习惯用白板或者Miro来画。团队一起贴便签，边贴边讨论。你会发现，很多“重要”的功能，在用户故事地图上一摆，其实没那么重要。

好了，这一章的内容就这些。总结一下：MVP的核心是验证风险，MoSCoW帮你排优先级，范围界定画个圈，用户故事地图让团队对齐。下一章咱们聊聊技术选型，那也是个容易踩坑的地方。

记住：做SaaS，不是功能越多越好，而是验证越快越好。