SaaS 创始人假设账本：从 0 开始先把你相信的事写下来

开场：创业不是从自信开始，而是从可检查的假设开始

从 0 开始做 SaaS，创始人通常会带着很强的直觉进入市场：某个行业效率低，某类团队缺工具，某个工作流很适合 AI，某个岗位每天都在重复劳动。这些直觉很重要，因为没有直觉就不会开始。但直觉如果不被拆开，就会变成一团无法讨论的信念。团队会说“客户肯定需要”“这个功能一定有价值”“价格不会是问题”，可到了真实销售时才发现客户不痛、预算不清、数据拿不到、交付太重。

创始人假设账本的作用，就是把这些看似确定的判断写成一条条可验证的假设。它不是商业计划书，也不是 PRD，而是一个持续更新的事实检查表。每当你和客户聊完、做完一次样本、跑完一次试点，都要回到账本里看：哪些假设更强了，哪些假设被削弱了，哪些假设根本没有证据。

早期 SaaS 最大的浪费，不是写错几行代码，而是在没有验证核心假设的情况下持续投入。假设账本能让团队更早发现自己到底在赌什么。

假设账本应该分成六类

第一类是客户假设。你相信谁会使用这个产品？不是“中小企业”，而是具体角色、公司规模、业务场景和工作责任。例如“20 到 80 人客服团队的客服主管，每周要整理质检和投诉复盘”。客户假设越具体，后续验证越清楚。

第二类是问题假设。你相信客户有什么高频、重要、愿意解决的问题。这里要写清最近一次场景、当前处理方式、造成的时间成本或业务风险。不要只写“效率低”，要写“每周质检复盘前要从三个表格手工合并，主管花 3 小时整理，还经常漏掉整改责任人”。

第三类是预算假设。你相信谁会付钱，用什么预算付，为什么现在愿意付。很多 SaaS 想法看起来有需求，但预算不存在。用户喜欢，不代表采购会批；执行者痛，不代表老板愿意买；部门有预算，不代表预算能用在软件订阅上。

第四类是替代方案假设。客户今天不是空白状态，他一定有办法处理：Excel、微信群、外包、旧系统、人工会议、主管经验。你要写清你认为当前替代方案哪里不好，以及客户是否已经为替代方案付出了时间或金钱。

第五类是交付假设。你相信团队能用多低成本交付结果。SaaS 不是只要客户愿意买就行，还要你能可复制地交付。如果每个客户都要大量定制、人工分析、现场实施，产品化难度就很高。

第六类是风险假设。你相信最大的失败点在哪里：客户不配合、数据拿不到、采购太慢、竞品太强、法规限制、技术效果不稳定、价值无法量化。风险写得越具体，验证动作越明确。

账本不是写结论，而是写可被推翻的句子

好的假设应该能被证据支持，也能被证据推翻。比如：

如果一句话无法被验证，就不适合放进账本。比如“未来企业都会智能化”太大；“客户希望更省心”太泛；“我们会做出体验最好的产品”太内部。账本关注的是近期能用行动验证的判断。

每条假设旁边要写验证方式。访谈、工作流观察、样本测试、着陆页注册、付费试点、冷启动触达、定价访谈，都可以是验证方式。不同假设需要不同证据。客户假设不能只靠竞品报告，预算假设不能只靠客户说“以后可以看看”，交付假设不能只靠产品 Demo。

给假设打状态，而不是打情绪

可以给每条假设设四种状态：

• 未验证：只是团队判断，还没有外部证据。
• 有弱证据：有客户口头支持，或少量访谈提到。
• 有强证据：客户提供样本、投入时间、拉同事参与、讨论预算。
• 被推翻：多次验证显示不成立，或成立条件与原假设不同。

状态要基于行为证据。客户说“有用”是弱证据；客户愿意提供样本是更强证据；客户愿意付试点费更强；客户连续使用并拉同事进来更强。

创始人最容易把积极反馈当强证据。尤其是熟人、朋友、同行，他们会鼓励你，但鼓励不等于市场。假设账本要尽量冷静：客户做了什么，而不是客户让你感觉如何。

每周做一次假设复盘

每周固定 60 分钟复盘账本。不要开成泛泛讨论会，只看三件事。

第一，本周新增了哪些证据。比如做了 8 次访谈、拿到 2 份样本、发出 40 条触达、完成 1 次手工交付。每条证据要连接到具体假设。

第二，哪些假设状态发生变化。比如“目标客户愿意提供样本”从未验证变成有强证据；“预算在运营部门”从未验证变成被推翻，因为客户说预算在老板或财务。

第三，下周最关键的验证动作是什么。不要同时验证十件事。早期每周最好选 2 到 3 个核心假设推进，比如预算路径、数据可得性、结果价值。

复盘时要允许坏消息。假设被推翻不是失败，而是节省资源。真正危险的是证据已经不支持，团队还继续说“再等等”。

用账本避免功能冲动

早期最常见的冲动是：一听客户提功能，就想做。客户说需要导出 PDF、需要移动端、需要审批、需要 API、需要更多图表，团队很容易把这些都放进路线图。假设账本能帮助你判断这些需求背后是否有已验证问题。

每个新功能都要问：

• 它服务哪条客户假设或问题假设。
• 是否有多个目标客户提出。
• 是否影响关键价值闭环。
• 是否能先用人工或模板验证。
• 如果做了，能提升哪个强证据。

如果一个功能只是让产品看起来完整，却不能验证核心假设，就应该延后。第一版 SaaS 不是功能越多越接近成功，而是越快证明核心假设越接近成功。

用账本管理合伙人分歧

创始团队内部经常有分歧：一个人觉得应该做大客户，一个人觉得应该做中小客户；一个人想先做 AI 自动化，一个人想先做工作流；一个人认为价格可以高，一个人担心没人付。没有假设账本时，这些分歧容易变成观点对观点。

把分歧写成假设，就能变成实验对实验。比如：

• 假设 A：50 人以上客服团队更愿意付费。
• 假设 B：20 人以下团队反馈更快，更适合早期。
• 验证方式：两周内分别触达 30 个客户，比较回复率、样本提供率、试点意愿。

这样讨论就从“我觉得”变成“我们去看证据”。合伙人不必马上统一观点，但必须统一验证方式。

假设账本的最小模板

可以从一个简单表格开始：

模板不复杂，关键是持续更新。如果账本三周不变，说明团队没有真正学习，只是在执行旧判断。

什么时候可以进入开发

假设账本不是让你永远调研。它的目的，是告诉你什么时候可以进入更明确的开发。通常需要至少满足几类强证据：

• 目标客户清楚，且能稳定触达。
• 问题有最近案例，不只是抽象需求。
• 客户愿意提供样本、时间或同事参与。
• 当前替代方案有明显成本。
• 结果样例能引发下一步承诺。
• 交付路径有初步可复制性。

如果这些都没有，就先不要做复杂产品。可以继续访谈、跟访、人工交付、着陆页测试。开发不是开始创业的证明，开发应该是证据累积后的下一步。

一个假设账本的演化例子

假设团队最初想做“AI 客服质检 SaaS”。第一周的账本可能是：

• 客户假设：电商客服主管需要自动质检。
• 问题假设：质检太慢，AI 可以节省时间。
• 预算假设：客服部门愿意为效率付费。
• 交付假设：上传会话后自动分类即可产生价值。

做了 10 次访谈后，账本可能变化：

• 客户假设收窄为“30 人以上、有质检主管、每周开复盘会的团队”。
• 问题假设从“质检慢”变成“质检后整改没人追踪”。
• 预算假设从“客服部门预算”变成“需要运营负责人或老板认可，因为它影响管理复盘”。
• 交付假设从“自动分类即可”变成“分类只是开始，客户更需要责任人、截止时间和下周追踪”。

这个变化非常重要。它会改变产品方向：第一版不再只是做 AI 分析，而是做“问题分类加整改追踪”；改变销售话术：不再说节省质检时间，而是说让质检问题进入管理闭环；改变试点：不再只上传数据看准确率，而是要开一次周会复盘，看整改表是否被使用。

如果没有假设账本，团队可能会觉得自己只是“多听了一些客户反馈”。有了账本，你能看到认知如何具体变化。

假设要有优先级

不是所有假设都一样重要。早期要先验证“如果错了，项目就不成立”的假设。比如客户是否痛、是否能触达、是否有预算、数据是否可得、结果是否可交付。这些比按钮颜色、页面布局、技术框架更重要。

可以给假设打风险等级：

• 一级风险：错了就应该暂停方向。例如目标客户没有这个问题。
• 二级风险：错了需要调整方案。例如客户愿意付费，但预算路径不是原来想的。
• 三级风险：错了也能后面优化。例如某个报表样式客户不喜欢。

每周优先验证一级风险。很多团队反过来，花大量时间优化三级风险，却不敢验证一级风险。比如持续打磨产品界面，却不问客户是否愿意提供样本；持续研究技术方案，却不问客户是否愿意付试点费。

假设账本能提醒你：不要用忙碌逃避最关键的不确定性。

让假设连接数字

早期样本小，不要迷信数据，但可以给部分假设设置小数字。比如：

• 触达 50 个目标客户，至少 10 个愿意回复。
• 访谈 15 个客户，至少 8 个能讲出最近一次问题。
• 5 个客户中至少 3 个愿意提供脱敏样本。
• 3 个样本交付中至少 2 个客户愿意复盘下一步。
• 2 个试点客户中至少 1 个愿意付费继续。

这些数字不是行业基准，而是团队自己的阶段性门槛。它们能防止你把零散积极反馈放大。比如 20 个客户里只有 1 个愿意看样例，那就不能说“市场很热”；如果 5 个客户都愿意提供样本，那就是强信号。

数字要和行为绑定，而不是和情绪绑定。回复、会议、样本、试点费、同事参与，比“客户说不错”更值得记录。

假设账本也要记录反例

很多团队只收集支持自己想法的证据，忽略反例。反例非常重要。比如 5 个客服主管都说质检很烦，但其中 3 个不愿提供样本，因为数据权限在 IT；这说明问题存在，但数据可得性是假设风险。又比如客户认可报告，但没有人愿意为整改追踪付费，这说明价值表达和预算路径要重新看。

账本里可以专门设一列“反例”。每次出现不支持原假设的证据，都写进去。反例不是为了打击团队，而是防止团队只看自己想看的东西。早期创业需要信念，但更需要纠偏能力。

如果一条假设只有支持证据、从来没有反例，反而要警惕：是不是访谈样本太单一，是不是问题问得太引导，是不是只找了熟人，是不是没有触达真正会拒绝你的人。高质量验证一定会带来反例。

结尾：先管理自己的相信，再管理产品

从 0 开始做 SaaS，创始人最宝贵的是判断力。判断力不是天生准确，而是在证据中不断校准。假设账本就是校准工具。它把团队相信的事写下来，把证据贴上去，把下一步验证动作安排出去。

当你能清楚说出“我们现在最确定的三件事是什么，最不确定的三件事是什么，下周要验证什么”，团队就不会在混乱中前进。早期创业仍然有风险，但风险至少变得可见。可见的风险，才有机会被管理。