SaaS 创始人领域地图：从 0 做产品前，先把业务世界画清楚

开场：不要一上来就把客户业务翻译成页面

很多 SaaS 创始人第一次进入一个行业，会很快开始想页面：要有客户列表、任务列表、数据看板、设置中心、权限管理。页面当然重要，但如果你还没有理解客户业务里的角色、对象、规则和例外，页面很容易只是把表格搬到了浏览器里。

从 0 做 SaaS，真正要先画的是领域地图。领域地图不是技术架构图，也不是商业计划书，而是对客户业务世界的结构化理解：谁在里面工作，他们处理什么对象，按什么顺序流转，哪些规则不能破，哪些例外最常发生，哪些指标决定负责人是否愿意付钱。

如果领域地图不清楚，后面的 MVP、数据模型、权限、定价和销售话术都会摇晃。你可能会做出一个能演示的产品，却无法进入客户真实工作流。

领域地图要解决什么问题

领域地图回答六个问题：

这六个问题比“客户想要什么功能”更底层。客户提功能时，往往已经把自己的解决方案说出来了；领域地图能帮你回到问题结构本身。

第一步：画角色，不要只写用户

“用户”这个词太粗。B2B SaaS 里，真正影响产品的不是一个抽象用户，而是一组角色。

以门店巡检场景为例，至少有这些角色：

如果你只把这些人都叫“用户”，产品就会混乱。店员要简单，区域经理要全局，总部要口径，IT 要安全，采购要预算依据。一个页面不可能同时满足所有角色。

领域地图里要明确：谁是日常使用者，谁是管理者，谁是决策人，谁是阻碍者，谁会在出问题时承担责任。

第二步：列业务对象，而不是先列功能

业务对象是客户每天处理的东西。它可能叫订单、工单、线索、门店、合同、会话、设备、项目、审批单、质检记录。SaaS 产品的核心通常围绕这些对象展开。

列业务对象时，不要只写名称，要写状态和生命周期。

例如“工单”不是一个静态表格，它可能经历：

新建 -> 已分派 -> 处理中 -> 待复核 -> 已完成 -> 重新打开 -> 归档

每个状态背后都有问题：

• 谁能创建。
• 谁能分派。
• 什么条件进入下一步。
• 超时怎么办。
• 能不能撤回。
• 谁能重新打开。
• 归档后还能不能改。

这些问题不清楚，产品上线后会不断出现“能不能加一个状态”“能不能特殊处理这个客户”“能不能管理员强制关闭”。

第三步：画流程，但要画真实流程

客户口头描述的流程经常很理想：

提交申请 -> 主管审批 -> 财务确认 -> 完成

真实流程可能是：

员工先在群里问主管 -> 主管口头同意 -> 员工补系统申请 -> 财务发现字段缺失 -> 退回修改 -> 主管忘记再批 -> 员工催促 -> 财务月底统一处理

SaaS 的机会常常藏在真实流程和理想流程的差距里。你要画的不只是正式流程，还要画绕行流程。

访谈时可以问：

• 标准流程是什么。
• 实际上大家怎么做。
• 哪一步最容易跳过。
• 哪一步最容易返工。
• 谁经常需要催别人。
• 如果系统不可用，大家怎么处理。

绕行流程不是客户不专业，而是现有系统无法适配真实约束。理解这些绕行，才知道产品从哪里切入。

第四步：记录业务规则

规则决定产品边界。常见规则包括：

很多早期 SaaS 失败，不是因为功能少，而是因为规则没想清楚。客户一用真实数据，马上发现统计不对、权限不对、状态不对。

规则不一定第一版全部实现，但必须知道哪些是硬规则，哪些是可暂时人工处理的软规则。

第五步：找例外，因为例外决定交付成本

业务总有例外。早期创始人容易只看标准路径，因为标准路径更容易做产品。但客户每天最痛的往往是例外。

例外包括：

• 数据缺失。
• 重复记录。
• 审批人离职。
• 客户临时改需求。
• 上级越权干预。
• 系统导入失败。
• 规则冲突。
• 任务超期。
• 责任人不认账。

每一种例外都要问：现在怎么处理，谁处理，花多久，是否有记录，出错后谁负责。

如果例外高频且处理方式一致，它可能就是产品机会。如果例外低频且高度个性化，可以先人工处理，不要把第一版产品拖复杂。

第六步：把指标接到业务结果

领域地图最后要落到指标。客户愿意付钱，不是因为你把流程画得漂亮，而是因为你影响了他关心的结果。

指标可以分层：

很多 SaaS 只停在操作指标。客户真正付费，通常要看到流程指标和管理指标改善。

例如“生成报表次数”不是结果，“主管每周少花 4 小时汇总、超期问题从 18 个降到 6 个”才更接近购买理由。

一份领域地图的最小模板

你可以用下面这张表开始：

这张表不需要一次写完。每次客户访谈后补充，三周后你会看到行业图谱逐渐清晰。

不要把领域地图做成一次性文档

领域地图应该持续更新。

当你发现一个新角色，要更新角色地图；当客户反复提同一个异常，要更新例外清单；当销售因为同一个问题卡住，要更新规则和指标；当产品上线后真实使用和访谈不一致，要更新流程图。

它应该成为产品、销售、客服和实施共用的底层文档。否则每个人会用自己的理解对客户讲话。

常见错误

领域地图越早建立，后面越少靠猜。

落地建议

接下来两周，不要急着画新页面。先找 8 到 12 个目标客户访谈，每次只围绕角色、对象、流程、规则、例外和指标提问。访谈后把内容补进同一份领域地图。

SaaS 从 0 开始，代码不是最早的资产。你对客户业务世界的结构化理解，才是后续产品、销售、定价和交付能否跑通的基础。

补充：用领域地图反推第一版产品

领域地图画完后，不要马上把所有内容变成功能。更好的做法是选出最短的一条价值路径：一个角色、一个对象、一个流程、一个结果。比如不是做“完整门店运营平台”，而是先做“区域经理追踪巡检整改超期问题”。这条路径越短，越容易验证。

判断第一版范围时，可以问四个问题：哪个角色最痛，哪个对象最稳定，哪个流程最重复，哪个结果最容易被负责人认可。四个答案交集处，通常就是 MVP 切口。这样选出来的范围，比从功能灵感出发更可靠。

领域地图还可以反推销售话术。你不再说“我们提供任务管理和报表”，而是说“我们帮助区域经理把巡检后的整改问题从群聊催办变成可追踪闭环，让总部每周看到哪些门店超期、谁负责、是否复发”。这句话里有角色、对象、流程、结果，比抽象价值主张更容易被客户听懂。

它也能反推数据模型。对象状态、规则、例外和指标，会告诉你哪些字段不能省，哪些状态不能乱加，哪些统计口径必须提前确认。早期数据模型不是为了追求完美，而是避免第一批客户一接入就发现核心对象无法表达。

所以领域地图不是调研附属品，而是产品入口。每次你想加功能，都应该回到地图上问：这个功能服务哪个角色，处理哪个对象，改善哪段流程，解决哪个例外，影响哪个指标。如果答不出来，就先不要做。