2022 年 12 月这一批文章有一个统一的开场句：「把创业起点放回客户现场」。这不是修辞，而是整月 20 篇的共同方法论：在写第一行代码之前，先把客户是谁、痛点在什么时刻出现、他们现在用什么方式凑合、愿意为什么结果付费这几件事弄清楚。与后来按主题横向组织的文章不同，这一批更像一组连续实验记录，从 ICP 收窄一路写到付费试点协议，每一步都给出具体可执行的动作。适合刚刚萌生 SaaS 想法、还没有任何客户的读者从头读起。
专题速览
| 维度 | 说明 |
|---|---|
| 文章规模 | 20 篇，全部位于本目录 |
| 时间跨度 | 2022-12-01 至 2022-12-30，一个自然月内完成 |
| 共同前提 | 用客户现场的真实证据替代内部想象 |
| 难度分布 | 全部为方法论，无技术门槛 |
| 组织方式 | 客户认知 → 验证交付 → 数据定价 → 运营复盘 |
| 核心价值 | 一套可在一周内跑起来的早期客户调研与验证流程 |
客户与市场认知
这一组解决「先找谁、怎么理解他们」的问题。ICP 收窄决定你不再服务所有人，痛点日记要求记录问题发生的瞬间而不是访谈里的总结，工作流触发访谈追问客户什么时候真的需要你，品类教育则处理一个常被忽略的事实：客户可能根本不知道该怎么称呼你的产品。
| 文章 | 核心内容 |
|---|---|
| SaaS ICP 收窄：从 0 开始不要服务所有人，要先锁定一种高频客户 | 从「中小企业都需要」收窄到一种高频客户，让访谈与文案有的放矢 |
| SaaS 痛点日记：从 0 开始不要等灵感，要连续记录客户问题出现的瞬间 | 记录问题发生的时间、处理人与后果，区分偶发抱怨与高频问题 |
| SaaS 工作流触发访谈：从 0 开始问清客户什么时候真的需要你 | 用触发事件定义产品入口、提醒时机与销售话术 |
| SaaS 品类教育：从 0 开始时，客户还不知道该用什么名字描述你的产品 | 帮客户把熟悉的问题、现有替代方案与新结果连接起来 |
| SaaS 市场进入论点：从 0 开始先写清为什么从这个小入口切入 | 用一页纸说明为什么先服务这类客户、后续如何扩展、何时停止 |
| SaaS 客户语言笔记本：从 0 开始把客户原话变成产品、销售和页面文案 | 保存客户真实原话，让定位、外呼与着陆页贴近工作现场 |
| SaaS 竞品拆解表：从 0 开始不要抄功能，要看清对方服务的是哪类客户 | 拆解竞品选择的客户、高频场景、收费方式与交付模式 |
验证与交付
这一组回答「怎么用最小成本验证」。微工具与模板产品是两种最轻的验证载体，先服务后软件则把人工交付当成学习手段。付费试点协议、无产品 onboarding 与人工运营看板共同构成「还没写代码也能开始交付」的组合。
| 文章 | 核心内容 |
|---|---|
| SaaS 微工具验证：从 0 开始先做一个能解决单点问题的小工具 | 用计算器、检查器、生成器验证关键动作是否值得持续使用 |
| SaaS 第一份模板产品：从 0 开始先做客户愿意复制使用的模板 | 模板是最轻的验证方式，能同时验证需求与收集客户语言 |
| SaaS 先服务后软件：从 0 开始用可控服务找出真正该自动化的部分 | 从服务交付过程里找出高频、稳定、可复制、值得自动化的部分 |
| SaaS 人工运营看板：从 0 开始先用内部看板管住交付质量 | 产品未自动化前，人工看板就是项目的控制台，防止试点失控 |
| SaaS 付费试点协议：从 0 开始用一页纸把验证、交付和转化说清楚 | 用周期、成功标准与下一步承诺避免试点拖成免费顾问 |
| SaaS 无产品 onboarding：从 0 开始先设计客户第一次成功体验 | onboarding 的核心不是界面步骤，而是客户第一次感到问题被解决 |
数据模型与定价
两篇偏「算清楚」的文章。数据模型沙盘主张先画对象关系再决定做什么功能，表格定价实验主张用一张表同时算清价格、成本与客户风险，避免被「怕贵」或「照搬竞品」两种情绪左右。
| 文章 | 核心内容 |
|---|---|
| SaaS 数据模型沙盘：从 0 开始先画清对象关系，再决定做什么功能 | 先想清业务对象、流转、修改权限与风险状态，再画页面 |
| SaaS 表格定价实验：从 0 开始用一张表算清价格、成本和客户风险 | 把价格视为价值、交付成本、购买风险与升级路径的组合 |
运营与复盘
这一组处理创始人的时间与信息沉淀。时间预算把每周注意力投向最能验证业务的动作，销售笔记与留存访谈分别覆盖「为什么买」与「为什么继续用」，小团队购买流程纠正「小客户没有采购逻辑」的误解，支持知识库则把重复问答沉淀成资产。
| 文章 | 核心内容 |
|---|---|
| SaaS 创始人时间预算：从 0 开始把每周时间投向最能验证业务的动作 | 避免把时间花在低风险、低反馈的内部优化上 |
| SaaS 创始人销售笔记：从 0 开始每次客户对话都要沉淀成资产 | 记录客户原话、反对意见、预算路径与下一步承诺 |
| SaaS 小团队购买流程：从 0 开始别以为小客户就没有采购逻辑 | 小团队决策快但不代表没有采购逻辑，要理解其风险判断方式 |
| SaaS 支持知识库：从 0 开始把客户问题沉淀成产品改进和销售素材 | 把散落在微信与会议里的知识沉淀为可复用资产 |
| SaaS 留存访谈：从 0 开始不要只问为什么买，更要问为什么继续用 | 围绕已试用、已付费、已流失客户追问产品是否进入日常工作 |
本月主题脉络
这个月的 20 篇其实是一条完整的时间线。月初（12 月 1 日至 8 日）集中在认知层：ICP 收窄、品类教育、痛点日记，解决「看什么、怎么记」；月中（9 日至 20 日）转入动作层：微工具、模板、先服务后软件、数据模型沙盘、付费试点协议，解决「先做什么」；月末（21 日至 30 日）落在运营与判断层：支持知识库、工作流触发访谈、市场进入论点，解决「怎么持续、何时停」。
如果只能读三篇，建议选 ICP 收窄、先服务后软件 与 市场进入论点——它们分别代表收窄、验证与退出条件这三件早期最容易被忽略的事。
推荐阅读路径
第一次做客户调研：
想在写代码前先验证：
把这一批方法用起来
这一批文章最容易被误读成「调研清单」，其实它们更接近一套可以按周执行的节奏。下面给出一个两周起步的可行安排。
第一周的前三天用于收窄与记录。用 ICP 收窄 把目标客户从「中小企业」缩到一类具体角色，然后用 痛点日记 开始记录，注意记录的是问题发生的瞬间，而不是访谈里客户对问题的总结。
第一周的后两天做访谈。用 工作流触发访谈 追问「什么事件发生后你必须处理这个问题」，同时用 客户语言笔记本 原样记下客户的说法。
第二周前三天做轻验证。从 微工具验证 或 第一份模板产品 里选一个成本最低的载体，观察客户是否愿意重复使用。
第二周后两天做承诺测试。用 付费试点协议 把口头兴趣换成有周期、有成功标准、有下一步的承诺，并用 人工运营看板 记录交付质量。
常见误区
第一个误区是把访谈做成产品推销。客户说了一个痛点，创始人就开始介绍自己的方案，结果得到的只是礼貌反馈。这一批文章反复强调，访谈的目标是收集事实，不是验证想法。
第二个误区是只记录结论不记录原话。客户语言笔记本之所以单独成篇，是因为原话与总结在后续写文案时的价值完全不同。
第三个误区是把「客户愿意试」当成验证通过。愿意试是低成本动作，真正有信息量的是客户愿意付出时间、数据或预算。付费试点协议的存在就是为了把这两者区分开。
第四个误区是同时验证多个方向。ICP 收窄的前提是一次只服务一类客户，同时铺开多个方向会让每一类的样本量都不足以判断。
本月可交付物清单
- 一份收窄后的 ICP 描述，明确到角色与工作场景
- 一本客户语言笔记本，保留至少二十条原话
- 一份痛点日记，记录问题发生的时间与后果
- 一个最小可用的微工具或模板产品
- 一份付费试点协议模板，含周期与成功标准
- 一张人工运营看板，覆盖线索到交付的关键节点
- 一份市场进入论点，写明进入理由与停止条件
- 一张竞品拆解表，按客户、场景与收费逻辑三个维度填写
- 一份数据模型沙盘草图，画出核心对象与它们的关系
相关专题
- SaaS Starter 专题导航：本目录的上级专题，含 45 篇分组方法论与全部月度归档。
- SaaS Starter 2023 年 1 月：紧接着的下一个月度归档，转入试用与埋点主题。
- SaaS 专题总入口：SaaS 大专题总入口。
- AI 开发者工具平台专题导航：把早期验证方法应用到具体产品方向的完整案例。