SaaS 早期决策日志：为什么小团队也要记录关键取舍

开场：早期团队最容易忘记自己为什么这么做

SaaS 创业早期，每天都在做取舍：

• 这个客户需求做不做。
• 这个行业切不切。
• 价格要不要降。
• 功能先做配置还是定制。
• 技术架构先快还是先稳。
• 这个试点要不要继续。

当时大家觉得理由很清楚，但两周后就会忘。新人加入后更难理解，为什么产品有这些边界，为什么某些需求一直没做，为什么某个客户被拒绝。

决策日志不是官僚文档，而是团队记忆。

什么决策值得记录

不是所有事情都要写。只记录会影响方向、资源和客户承诺的决策。

如果一个决定未来可能被反复争论，就应该记录。

决策日志写什么

一条决策日志不需要很长。

日期：
决策：
背景：
备选方案：
选择理由：
放弃了什么：
触发复盘的条件：
负责人：

其中最重要的是“放弃了什么”。因为真正的决策一定包含取舍。

示例：拒绝一个定制需求

日期：2025-11-28
决策：暂不为 A 客户开发专属审批链。
背景：A 客户希望每个区域有不同审批层级，但当前目标客户大多只需要负责人确认。
备选方案：
1. 立即开发可配置审批链。
2. 用状态和负责人字段临时支持。
3. 拒绝该场景。
选择理由：立即开发会引入复杂权限和流程配置，影响当前 MVP 稳定性；该需求目前只有一个客户提出。
放弃了什么：短期可能影响 A 客户成交速度。
复盘条件：如果 3 个以上目标客户提出类似需求，重新评估标准化审批能力。
负责人：创始人和产品负责人。

这条记录能防止两周后再次从头争论。

决策日志能减少隐性反复

没有记录时，团队会不断重复讨论：

• “我们为什么不做这个功能？”
• “这个客户不是愿意付钱吗？”
• “当时为什么定这个价格？”
• “能不能先破例一次？”

记录不是为了阻止改变，而是让改变有依据。

如果新信息出现，可以更新决策：

更新：已有 4 个目标客户提出审批需求，且其中 2 个明确表示影响购买。
新决策：开发基础二级审批，不做完整流程引擎。

好的决策日志允许改变，但不允许失忆。

产品决策要连接客户证据

早期产品争论很容易变成个人偏好。决策日志要写客户证据。

没有证据的决策也可以做，但要明确写成假设。

销售决策也要记录

例如：

• 首年最低折扣是多少。
• 哪些功能不能在售前承诺。
• 试点期最长多久。
• 免费试用是否需要绑定目标。
• 哪类客户暂不跟进。

销售决策不记录，最容易出现口径不一致。今天为了成交答应一个特殊条件，明天客户成功和产品就要承担成本。

技术决策不要写成炫技文档

早期技术决策日志重点不是证明架构多先进，而是说明取舍。

例如：

决策：暂不做多地域部署。
理由：当前客户都在国内，SLA 承诺尚未进入企业级采购要求；先把备份、监控和恢复流程做好。
放弃：短期不服务对跨地域容灾有硬要求的客户。
复盘条件：出现 2 个以上年付 20 万以上客户明确要求。

这比写一堆架构术语更有用。

每月复盘决策日志

每月看一次：

• 哪些决策仍然成立。
• 哪些决策需要更新。
• 哪些假设被证明错误。
• 哪些破例正在变多。
• 哪些客户证据改变了优先级。

决策日志不是档案柜，而是复盘工具。

落地建议

从今天开始建立一个 decisions.md 或表格。每周只记录 3 到 5 条关键决策。

SaaS 从 0 开始，小团队看似沟通成本低，其实最容易靠记忆管理公司。把关键取舍写下来，团队才能在变化中保持清醒，也能更快知道什么时候应该坚持，什么时候应该改变。