SaaS 路线图取舍：需求很多时先做什么

开场：需求越多，越需要拒绝机制

SaaS 早期最开始怕没人提需求。等客户多起来，又会怕需求太多。销售说这个客户要集成，客服说那个客户不会用，老客户要报表，新客户要模板，开发还想重构，系统稳定性也需要补。

如果没有取舍机制，路线图会变成一张越来越长的愿望清单。团队每天都很忙，但产品方向越来越模糊。

路线图不是把所有需求排队，而是决定哪些事情最能提高产品的长期价值。

先把需求放进四个篮子

不要把所有需求混在一起。先分类：

同一个功能可能同时影响多个目标，但分类能帮助你看清当前阶段最缺什么。

例如，如果很多试用用户无法激活，继续做增长入口意义不大；如果付费客户频繁因为通知失败投诉，做新模板也不应优先。

用阶段目标决定优先级

路线图必须服务阶段目标。

不同阶段的优先级不同：

如果阶段目标不清，团队会在所有方向上平均用力。平均用力通常等于没有重点。

建立一个简单评分模型

早期不需要复杂产品管理工具，用 5 个问题就能评估需求：

每项 1 到 5 分，合计只是参考。评分的价值不是制造精确排名，而是逼团队把判断说清楚。

如果一个需求只服务单个客户、不能复用、维护成本高，即使对方催得很急，也不一定应该优先。

稳定性需求不能总被推迟

早期团队容易偏爱新功能，因为新功能更容易被客户看见。但 SaaS 是持续服务，稳定性本身就是产品。

这些需求经常被低估：

• 告警和监控。
• 备份和恢复。
• 错误日志。
• 权限边界。
• 数据导出。
• 账单准确性。
• 核心流程性能。
• 发布回滚。

它们不一定带来新客户，但会减少流失和信任损耗。客户不会因为你有监控而夸你，但会因为系统坏了没人知道而离开。

路线图里应该固定留出稳定性和维护时间。否则技术债会在客户增长后集中爆发。

客户承诺要进入路线图纪律

销售或创始人有时会为了成交承诺功能。这很常见，但必须管理。

每个客户承诺都要记录：

• 承诺了什么。
• 谁承诺的。
• 客户是否因此付费。
• 交付时间。
• 是否可复用。
• 如果延期如何沟通。

不要让承诺只存在聊天记录里。路线图最怕隐藏承诺，它们会突然在某个时间点变成紧急任务。

如果必须为成交承诺功能，最好承诺问题解决，而不是承诺具体实现方式。这样保留产品抽象空间。

拒绝需求也要专业

拒绝不是简单说“不做”。你可以用几种方式回应：

• 现在不做，因为当前阶段优先解决激活问题。
• 这个需求更适合通过配置处理，我们先提供替代方案。
• 这属于专属定制，可以单独评估报价。
• 我们记录了这个场景，但需要更多同类客户验证。
• 这个方向会增加所有客户复杂度，因此暂时不进入产品。

清楚解释原因，比模糊拖延更专业。客户不一定喜欢被拒绝，但会更信任有边界的团队。

路线图要对内清楚，对外谨慎

内部路线图可以具体，外部路线图要谨慎。

对内需要明确：

• 当前季度目标。
• 本月重点。
• 本周交付。
• 哪些需求明确不做。
• 哪些客户承诺需要跟进。

对外可以表达方向，但不要轻易承诺日期。早期变化快，过度公开路线图会制造压力和失信风险。

如果客户问某功能什么时候有，可以回答：

这个需求我们已经记录，正在和类似客户确认。当前优先级排在数据导出和通知稳定性之后，暂时不承诺具体日期。如果它进入开发，我们会第一时间同步。

这样的表达比“快了快了”更可靠。

常见误区

第一个误区，是谁声音大就做谁的需求。声音大不代表价值大，可能只是客户更会表达。

第二个误区，是只做新功能不还债。短期演示很好看，长期稳定性会被拖垮。

第三个误区，是把路线图当承诺墙。路线图应该允许根据证据调整，而不是为了面子坚持错误方向。

第四个误区，是没有非目标清单。明确不做什么，和明确做什么一样重要。

一个路线图会议模板

每两周可以开一次短会：

1. 当前阶段目标是什么？
2. 上周期哪些需求真正影响了客户？
3. 哪些问题重复出现三次以上？
4. 哪些客户承诺即将到期？
5. 哪个稳定性问题不能再拖？
6. 下周期只做哪 1 到 3 件最重要的事？
7. 哪些需求明确拒绝或暂缓？

会议结束后，把结论写下来。路线图管理最重要的不是工具，而是让取舍有记录、有理由、有复盘。

SaaS 创业的需求永远做不完。真正的能力，是在做不完的情况下，持续选择最能提高产品价值、客户信任和商业质量的事情。