SaaS 问题备忘录：每个产品想法都要先写成一页问题说明

开场：不要让产品想法只停留在一句灵感里

SaaS 创业者每天都会冒出很多想法：做一个自动报表工具，做一个审批 SaaS，做一个 AI 客服质检，做一个门店巡检系统，做一个给中小团队用的 CRM。这些想法听起来都有机会，但一句想法离可执行项目很远。

早期团队最需要的不是更多想法，而是把想法写清楚的能力。问题备忘录就是一页纸，用来回答：这个想法到底解决谁的什么问题，问题有多频繁，当前怎么解决，为什么现在值得做，我们有什么证据，最大的风险是什么。

如果一个想法写不成问题备忘录，大概率还不适合进入产品开发。

问题备忘录不是 PRD

PRD 通常描述要做什么功能、页面和交互。问题备忘录更早，它描述为什么值得做。

很多团队跳过问题备忘录，直接写 PRD。结果 PRD 写得很细，但根本问题不成立。

一页问题备忘录模板

可以直接用这个结构：

问题名称：

目标客户：

具体场景：

最近一次问题：

当前替代方案：

成本和后果：

已有证据：

为什么现在：

我们可能的切入：

最大风险：

下一步验证：

每个字段都要写事实，不要写口号。

目标客户要具体

不要写“中小企业”。要写：

30 到 150 人、每周需要人工整理客服会话质检结果、但没有专门数据团队的电商客服团队。

目标客户越具体，后面越容易访谈和验证。

目标客户至少包含：

• 行业。
• 团队规模。
• 关键角色。
• 当前工作方式。
• 购买或推动可能。

如果目标客户写不清，就先不要做产品。

具体场景要能复现

问题必须发生在具体工作流里。

差的写法：

客户管理效率低。

好的写法：

销售主管每周五要从 4 个销售的表格里整理本周跟进状态，手工判断哪些客户超过 7 天没有联系，并在周会上逐个追问。

具体场景能让你判断频率、角色、数据和结果。

最近一次问题很关键

如果客户说“我们经常这样”，你要追最近一次。

问题备忘录里要写：

• 什么时候发生。
• 谁发现。
• 怎么处理。
• 花了多久。
• 造成什么后果。
• 是否留下记录。

说不出最近一次的问题，通常不够高频，或者客户只是泛泛抱怨。

当前替代方案决定需求强度

客户现在一定有办法，哪怕很烂。

替代方案包括：

• Excel。
• 微信群。
• 人工会议。
• 旧系统。
• 外包人员。
• 内部脚本。
• 竞品工具。

替代方案越重，说明问题越真实。如果客户没有任何替代方案，也没有人负责，说明问题可能不够痛。

成本和后果要量化

成本不一定都能换算成钱，但要具体。

“麻烦”不是成本，“每周主管花 6 小时汇总，并且经常因为数据口径不一致重开会议”才是成本。

已有证据不能只写感觉

证据可以来自：

• 客户访谈。
• 样本数据。
• 手工交付。
• 原型测试。
• 竞品评价。
• 客户愿意付费试点。
• 行业公开资料。

问题备忘录里要写证据来源。比如“访谈 12 位客服主管，其中 8 位提到周报汇总耗时，3 位愿意提供样本数据”。这比“很多客户都需要”可靠得多。

为什么现在

很多问题长期存在，但不一定现在会买。

触发点可能是：

• 团队扩张。
• 新负责人上任。
• 旧系统续费。
• 监管要求变化。
• 人工成本上升。
• 竞品涨价。
• 事故暴露风险。

没有触发点，客户很容易说“以后再看”。

最大风险必须写

每个想法都有风险。

可能是：

• 客户没有预算。
• 数据拿不到。
• 流程差异太大。
• 技术实现太复杂。
• 客户不愿改变习惯。
• 结果无法量化。
• 销售周期太长。

写风险不是否定想法，而是让下一步验证更清楚。

下一步验证要具体

不要写“继续调研”。

要写：

• 访谈 10 个目标客户，确认最近一次问题。
• 收集 3 份样本数据，检查字段差异。
• 做一个无代码交付，验证结果是否有用。
• 向 5 个客户提出付费试点，看是否愿意。
• 做一个原型 Demo，测试客户能否理解流程。

验证动作要能在一到两周内完成。

常见错误

问题备忘录要短，但要扎实。

落地建议

把你当前最想做的 3 个 SaaS 想法，各写成一页问题备忘录。不要比较哪个听起来更大，而是比较哪个客户更清楚、问题更高频、成本更具体、证据更强、下一步更可验证。

SaaS 从 0 开始，产品想法不值钱，写清楚的问题才值钱。问题备忘录能让你在写代码前先淘汰一批不成熟方向。

一个问题备忘录示例

问题名称：客服质检周报整理耗时
目标客户：30 到 150 人电商客服团队，已有主管每周抽查会话。
具体场景：主管每周从客服系统导出会话，抽样后用 Excel 记录问题，再在周会上和组长复盘。
最近一次问题：某主管上周五花 6 小时整理 300 条会话，会议前仍发现问题分类不一致。
当前替代方案：客服系统导出 + Excel 标注 + 群里催组长。
成本和后果：主管重复整理时间长，组长整改没有追踪，老板只能看到结果看不到过程。
已有证据：访谈 12 位客服主管，8 位提到周报整理耗时，3 位愿意提供样本数据。
为什么现在：客服团队扩张，新主管希望建立标准质检流程。
可能切入：先做抽样、标注和周报生成，不做完整客服系统。
最大风险：客户是否愿意为周报和整改追踪付费。
下一步验证：向 5 个客户提出两周付费试点。

这份备忘录不长，但足够指导下一步。它没有写“做 AI 平台”，而是把一个具体问题说清楚。

如何比较多个问题备忘录

如果你同时有 3 个想法，可以按五个维度打分：

得分最高的不一定市场最大，但可能最适合当前切入。

问题备忘录还要保存历史。被放弃的备忘录不要删除，记录为什么没做。未来你可能发现时机变化、能力变化或客户画像变化，旧问题又变得可行。

问题备忘录如何进入团队讨论

如果有合伙人，每个新方向都应该先过问题备忘录，而不是直接讨论功能。会议可以只问五件事：客户是谁，最近一次问题是什么，当前替代方案是什么，证据是什么，最大风险是什么。

如果这五件事说不清，就不要进入方案讨论。否则团队会陷入“这个页面怎么做”“这个功能酷不酷”的细节争论。

问题备忘录还可以帮助拒绝需求。客户提出一个需求时，你可以写一份迷你备忘录：这个需求背后是什么问题，是否多个客户出现，是否有成本，是否影响付费。如果没有，就先不做。

备忘录要有版本变化

一开始的问题备忘录可能很粗。随着访谈增加，它应该更新。比如目标客户从“客服团队”收窄到“有质检主管的电商客服团队”；问题从“质检效率低”收窄到“周报整理和整改追踪耗时”；最大风险从“能不能做”变成“客户是否愿意为整改追踪付费”。

这种变化说明你在学习。备忘录不是为了证明最初想法正确，而是为了记录问题如何变清楚。

问题备忘录的退出机制

每份备忘录都应该有退出条件。比如连续 15 次目标客户访谈都说不出最近一次问题，暂停；3 个客户都不愿提供样本数据，暂停；客户只愿意免费试但不愿定义成功标准，暂停；技术验证发现核心数据无法获取，暂停。

退出不是失败，而是节省资源。早期最昂贵的不是放弃一个想法，而是在证据不足时继续投入三个月。

退出后要写清原因：客户不痛，成本不足，预算不清，技术不可行，交付不可复制，或者时机不对。这些记录会帮助你未来判断相似想法。

问题备忘录最后还要写“下一步最小动作”。不是写一个宏大路线图，而是写接下来 7 天要验证什么：约 5 个同类客户、拿 2 份脱敏样本、做一次手工交付、测试一封冷启动邮件，或者请客户把当前流程现场演示一遍。

最小动作越具体，团队越不容易停留在概念层面。早期 SaaS 的推进节奏，应该是一页备忘录连接一组验证动作，再用验证结果更新备忘录。这样循环几轮后，产品机会会自然变清楚。