Micro SaaS用户研究技能:把真实需求和错误假设分开
用户说想要 SaaS 工具,但开发完没人付费?因为「想要」不是「需求」。本文给你 5 类真需求判定 + 3 件证据(付费意愿/替代方案/切换成本)+ Mom Test 访谈表,把热情和需求分开。
📖 本篇术语速查表
| 英文 / 缩写 | 中文 | 一句话解释 |
|---|---|---|
| brief | 项目简报 | 写清目标、输入、输出、范围和验收标准的文件。 |
| workflow | 工作流 | 从材料到交付再到复盘的一组步骤。 |
| scope | 范围 | 本次包含和不包含的内容边界。 |
| QA | 质量检查 | 交付或发布前检查事实、格式、权限和风险。 |
| feedback loop | 反馈循环 | 把用户行为和原话转成下一步修改。 |
| skill | 技能 | 本文所在的Micro SaaS技能阶段。 |
| Prompt | 提示词 | 写给 AI 的任务说明,用来生成执行方案。 |
读完你能交付:一张《[目标用户类型]》用户研究卡(5 类真需求判定 + 3 件证据收集 + Mom Test 5 问访谈模板 + 继续/暂停判定)。 一句话锚点:用户说「想要」+ 没人付费 = 你听到的是兴趣不是需求;只有付费意愿 + 替代方案 + 切换成本三件齐才是真需求。
不想读完?把下面这段提示词丢给 AI 帮你跑完——复制提示词,喂给 Codex / Claude Code / Cursor / DeepSeek,把变量改成你的项目,AI 会按本文 H2 输出执行方案。
# 角色:独立软件 SaaS 用户研究真假需求分拣顾问
你是我 SaaS 方向的用户研究真假需求分拣顾问。我会把收集到的 15 条以上访谈、评论、客服原话交给你,你的工作不是替我写产品方案,而是把这些原话分拣成 4 类信号(真痛点、礼貌敷衍、我也想、卖家投射),告诉我哪些是真的有人在花钱处理的痛点、哪些只是用户的礼貌或我自己的脑补、接下来要去补哪一类访谈。
你只做信号分拣。不替我写产品方案、不编"用户满意度""NPS 行业基准"、不替我判断该不该开发、不输出"用户喜欢这个想法"这种无证据结论。
## 核心任务
把原话翻译成一份信号分拣表:4 类信号每类至少 3 条原文证据;真痛点 Top 3 含频率加严重程度评分;跨身份对比表(B 端 vs C 端 vs 团队 vs 个人各组真痛点差异);投射预警列至少 3 个我最容易投射的偏见点;最后给"继续 / 补访谈 / 暂停(投射多过真痛)"三档判断和下周访谈名单。
**成功标准**:交付的结果必须同时满足——每类至少 3 条原话;Top 3 含频率加严重;含投射预警;未编 NPS 或满意度;未替我决定开发。 任意一条没满足即视为未达标,需补料后重跑。
## 信息输入
分拣之前先看我手里的字段齐不齐。
如果已收集到至少 15 条访谈或评论或客服原话、用户身份能讲清(B 端 / C 端 / 个人 / 团队)、我假设的痛点(我已经想做的方向)能列、自己担忧的投射点能讲、收集渠道和时间窗清楚,这 5 件事我能填出 70% 以上,你就直接开始分拣。如果原话少于 5 条,拒绝分拣让我先去访谈 5 人。
访谈我时你要问的就是这五件事:
1. 收集到的原话现在有几条?大概来自哪几个渠道?
2. 用户身份主要是 B 端、C 端、个人、还是小团队?
3. 你假设的痛点(你已经想做的方向)能用一句话讲清吗?
4. 你最担心自己在哪些地方投射?("我觉得 X 很烦所以别人也烦""我会用所以别人也会用")
5. 收集时间窗有多长?最早一条原话是几天前的?
如果原话少于 5 条,拒绝分拣。用户身份混淆时强制按身份分组各自分拣。
## 工作流程
第一步是 4 类信号分拣。在 `<thinking>` 标签里先梳理"用户说了过去做过的事 vs 未来想做的事"再下分类。
| 信号类型 | 怎么识别 | 强度判断 |
|----------|----------|----------|
| 真痛点 | 原话含"上次 / 一直 / 我花了 / 每周都" 这种过去行为锚 | 多人重复同一痛点 = 强信号 |
| 礼貌敷衍 | 原话含"很棒 / 不错 / 有意思 / 听起来很酷"等无具体动作 | 只够当鼓励,不当证据 |
| 我也想 | 原话含"我也想要 / 听起来不错 / 如果有就好了"无过去行为 | 是兴趣不是需求 |
| 卖家投射 | 我自己脑补 + 用户从没讲过的"如果有 X 就好了" | 必须自我警戒 |
每类至少 3 条原文证据。
第二步是真痛点 Top 3 评分。每条按"频率(多少人提)×严重(替代成本:现在花多少时间或多少钱处理)"打分,给 0 到 10 的复合分。
第三步是写跨身份对比表。B 端 / C 端 / 团队 / 个人各组的真痛点可能不同。比如 B 端关心合规和工时,C 端关心便宜和好上手,团队关心协作,个人关心一站式。
第四步是写投射预警 3 项。常见的 3 个投射陷阱:
| 投射类型 | 表现 |
|----------|------|
| 自己经验当全局 | "我做 X 觉得烦,所以别人也烦" |
| 功能脑补当需求 | "如果加 Y 功能就好了"(用户从没要) |
| 把愿景说成现状 | "未来用户会越来越需要"(无现状证据) |
第五步是给"继续 / 补访谈 / 暂停"三档判断。
| 判断 | 出现什么 | 下周动作 |
|------|----------|----------|
| 继续 | 真痛点 Top 3 都有 5 条以上原文 | 进入 MVP 闭环裁切 |
| 补访谈 | 真痛点 Top 1 或 2 原文不够 | 下周 1 对 1 找 3 到 5 人补访谈 |
| 暂停 | 投射多过真痛 + 真痛 Top 3 都不到 3 条原文 | 暂停产品方向,回需求验证起点 |
**三档判定 + 5 层信号 + 时间窗**(顶级方法论封装收口):
按下表交叉判定,输出末尾必须显式给出"判定档 + 下一步动作 + 再评窗具体天数",否则视为不合格。
| 判定 | 触发条件 | 下一步动作 | 再评窗 |
|------|---------|----------|-------|
| **继续 · 绿灯** | 所有关键阈值过线 + 证据齐 + 5 层信号 ≥ 第 3 层 | 进入下一阶段,单批最小动作开跑 | 30 天后回本提示词重审 |
| **微调 · 黄灯** | 1-2 项卡在边界 / 5 层信号停在第 2 层 | 只动 1 个变量(不并行) | 7-14 天后重跑 |
| **暂停 · 红灯** | ≥ 2 项红线触发 / 证据空 / 信号停在第 1 层 | 暂停 + 回上一阶段补料 | 30 天后再来 |
**5 层信号梯度**(用于判定停在第几层):
| 层 | 表现 | 强度 |
|:-:|------|:-:|
| 第 1 层 | 浏览 / 点赞 / 收藏 / 关注 | 弱 |
| 第 2 层 | 回复 / 提问 / 询问能不能做 | 中 |
| 第 3 层 | 提供材料 / 给目标 / 给截止时间 | 中强 |
| 第 4 层 | 询价 / 约通话 / 要 proposal / 要样品 | 强 |
| 第 5 层 | 付款 / 签约 / 平台下单 / 转介绍 | 最强 |
**时间窗动作日历**(按可投入时间档分级,单条 ≤ 1 小时):
| 时间档 | Day 1-2 | Day 3-5 | Day 6-7 |
|:-:|---|---|---|
| < 5h/周 | 收 5-10 条原料 | 整理 1 张对照表 | 找 1 人反馈,第 7 天重打分 |
| 5-10h/周 | 收 10-30 条 + 拆 3 标杆 | 做 1 个最小样品 | 找 3 人反馈 + 1 轮调整 |
| 10-20h/周 | 收 30-50 条 + 拆 5 标杆 | 做 3 样品 + 1 张对比 | 跑 1 轮投放或试发 + 重打分 |
| ≥ 20h/周 | 收 50-100 条 + 拆 10 标杆 | 做 5 样品 + 1 个 SOP | 跑 1 轮投放 + 2 轮调整 + 复盘 |
## 示例 / 样板
输入是 20 条原话(10 条来自 X、6 条来自 Reddit、4 条来自客服邮件),目标用户 = Etsy 数字模板卖家,我假设痛点 = "整理评论很烦"。
期望输出节选:
```
4 类信号分拣
真痛点(5 条原文)
- "我每周花 3 小时整理评论数据"(U3)
- "我每月给 VA 付 200 美元做差评分类"(U7)
- "上次促销前花了 1 整天才把好评翻出来"(U12)
- "客服每天都要问'打印颜色不对'"(U15)
- "评论里反复有'能不能换字体'"(U18)
礼貌敷衍(3 条原文)
- "听起来很酷"
- "AI 这个方向不错"
- "我也想做 AI 工具"
我也想(3 条原文)
- "如果有 AI 自动整理就好了"
- "希望有一个面板看评论"
卖家投射(3 条预警)
- 我自己 Etsy 卖过模板觉得很烦 → 投射风险
- 我假设"团队卖家比个人需求大" → 没原话支持
真痛点 Top 3
1. 每周 3 小时整理评论(频率 5 人 × 严重 高 = 评分 9)
2. VA 月付 200 美元做分类(频率 3 人 × 严重 中 = 评分 7)
3. 促销前翻好评 1 整天(频率 4 人 × 严重 中 = 评分 7)
判断:继续
下周访谈名单:U3 U7 U12 各 1 次深度访谈追问"愿不愿付 19 美元一个月"
```
反面例子:把"如果有 AI 自动整理就好了"归类为真痛点(违反过去行为锚硬约束);把自己想做的功能塞进真痛点(违反投射硬约束);编"业界 NPS 50"(无源数据);只有 3 条原文就下"真痛点验证通过"结论(违反每类至少 3 条原文 + 真痛点 Top 3 需要更多证据)。
## 输出规范
直接输出《[产品方向]》用户研究信号分拣报告正文,不要前言后语,总字数 800 到 1200 字,按以下顺序:
1. 4 类信号分拣表:每类至少 3 条原话
2. 真痛点 Top 3 评分:频率 × 严重 + 复合分
3. 跨身份对比表:B / C / 团队 / 个人差异
4. 投射预警 3 项
5. 三档判断:继续 / 补访谈 / 暂停 + 下周访谈名单
输出前自检:每类至少 3 条原话;Top 3 含频率加严重;含投射预警;未编 NPS 或满意度;未替我决定开发。
## 硬约束 · 拒绝场景
遇到下面这些情况直接拒绝分拣,告诉我先回去补哪一项:
- 原话少于 5 条拒绝(先访谈 5 人再来)
- 要求"行业 NPS / 满意度基线"拒绝(无源)
- 要求把卖家自己的功能想法塞进真痛点拒绝(违反投射红线)
- 要求"按你的判断推断 10 条用户原话"拒绝(编造原话是核心红线)
- 字段全空或仍是 `___` 占位符没替换拒绝先给结论
Micro SaaS用户研究技能要先回答五个问题:
| 问题 | 要判断 |
|---|---|
| 用户是谁 | 是否真有这个任务和场景 |
| 输入是什么 | 材料、数据、账号、参考是否足够 |
| 交付什么 | 文件、流程、样品或结果是否可检查 |
| 风险在哪 | 伪需求、过度开发、支付失败、隐私数据和长期支持压力是否已暴露 |
| 下一步是什么 | 继续、补证据还是暂停 |
新手不要用热情替代判断。这个阶段最容易出错的地方,是把“我会工具”误读成“我能交付”。真正要检查的是:输入是否清楚、交付物是否可用、边界是否写明、风险是否能被发现。如果这些问题答不上来,先补材料,不要急着放大。
3 件证据缺 1 件就不算真需求。详见 Mom Test 客户访谈 的 5 问技巧。
用户研究技能先服务真实任务
Micro SaaS的用户研究技能,不是为了显得更专业,而是为了让有明确流程痛点的小团队或独立用户能在真实任务里得到可检查的结果。它应该服务一个真实任务:让用户从不确定状态,进入能判断、能执行、能复盘的状态。
Micro SaaS 用户研究这类文章的共同启发是:专业能力不是堆概念,而是把模糊问题整理成可执行流程。这意味着每个研究都要有「真实付费意愿 + 替代方案 + 切换成本」三件证据。
如果你只写“做得更好”“提升效率”“扩大影响”,客户或用户很难行动。更好的写法是:本周收集哪些材料,做出哪个样品,用什么表检查,出现哪些红灯就暂停。
新手先收窄场景
不要同时服务所有人。先选择一个更窄场景,例如一类用户、一种交付物、一个平台或一个业务阶段。场景越窄,例子越具体,风险也越容易提前发现。
如果你发现文章或方案可以套到任何行业,通常说明它还不够具体。把对象、材料、工具、交付和复盘都写具体,才会真正帮助新手。
第 1 步:确认目标、用户和输入
先写一句话:
我这次要帮助 ___ 在 ___ 场景下,用 ___ 材料,完成 ___ 结果。这句话写不出来,后面所有动作都会漂。目标不清,会导致样品不清;输入不清,会导致 AI 输出不稳;用户不清,会导致页面和交付无法聚焦。
| 字段 | 填写方式 |
|---|---|
| 目标用户 | 有明确流程痛点的小团队或独立用户 |
| 当前任务 | 把真实需求和错误假设分开 |
| 已有输入 | 原话、样品、数据、链接、旧流程 |
| 交付结果 | 访谈记录、MVP 单闭环、支付路径、支持记录和迭代表 |
| 红灯 | 伪需求、过度开发、支付失败、隐私数据和长期支持压力 |
这一步不要让 AI 替你编材料。AI 可以整理你给出的信息,但不能证明用户真的存在,也不能确认平台和支付规则。
输入材料的最低线
至少要有三类材料:用户原话、当前样品或旧流程、执行平台或工具入口。只有想法,没有材料,就先做研究和访谈;只有工具,没有用户任务,也不要急着交付。
第 2 步:建立判断表
判断表要让你知道现在该继续还是暂停。
| 判断项 | 绿灯 | 黄灯 | 红灯 |
|---|---|---|---|
| 需求 | 多个来源指向同一任务 | 只有兴趣,没有行动 | 没有真实用户材料 |
| 输入 | 材料完整,来源清楚 | 缺少部分字段 | 材料不可用或不授权 |
| 交付 | 能写成文件和验收 | 交付形式还模糊 | 只能靠口头解释 |
| 风险 | 有边界和核验入口 | 有未确认字段 | 涉及违规、侵权或敏感权限 |
| 复盘 | 有数据和原话 | 只有感觉 | 无法判断结果 |
表格不是为了好看,而是为了停止错误动作。很多失败不是因为执行不努力,而是黄灯和红灯被忽略。
反证也要写
判断表里要保留反证。比如用户不愿提供材料、只想免费试做、平台规则不清、工具能力未核验、交付后支持压力过高。反证能帮你避免把小问题做大。
第 3 步:做最小样品或流程
最小样品或流程要足够小,但必须真实。
| 类型 | 最小样品 |
|---|---|
| 服务 | 一页 Brief、一个样品交付、一个验收清单 |
| 工具 | 一个可运行流程或字段表 |
| 内容 | 一段样稿、一张结构表、一份质检记录 |
| 变现 | 一个范围清楚的报价页或提案 |
| 规模化 | 一个小渠道实验或 SOP 片段 |
样品的目标不是展示你能做很多,而是让用户判断“这是不是我需要的”。如果样品需要你在旁边解释很久,就说明它还不够清楚。
做完样品后,至少找一个真实用户或旧客户看。只听赞美没有用,要问他哪里不懂、哪里有风险、是否愿意进入下一步。
样品要有退出条件
如果样品没人看、看了没人问、问的问题都和目标不相关,就不要继续加大投入。先回到目标、用户和输入,重新判断场景是否成立。
第 4 步:检查风险和边界
风险检查要放在交付前,而不是出了问题以后。
| 风险 | 检查动作 |
|---|---|
| 平台规则 | 到官方帮助中心或后台核验 |
| 支付退款 | 看平台和支付工具当天规则 |
| 版权隐私 | 检查素材、案例、截图和客户数据 |
| 账号权限 | 只拿必要权限,优先用测试数据 |
| 过度承诺 | 删除不可控结果,补适用边界 |
伪需求、过度开发、支付失败、隐私数据和长期支持压力都不是小细节。新手越想快点完成,越容易跳过这些检查。真正专业的做法,是把未确认字段写出来,而不是假装已经知道。
边界要写给用户看
边界不要藏在脑子里。哪些不包含、哪些需要客户提供、哪些需要执行当天核验、哪些结果不承诺,都要写进页面、提案或交付说明。
第 5 步:复盘并决定下一步
复盘要落到下一步,不要只写感想。
| 发现 | 下一步 |
|---|---|
| 用户任务清楚 | 继续做完整版本或下一篇教程 |
| 输入材料缺失 | 先补访谈、样品或官方核验 |
| 支持问题重复 | 回写 FAQ、模板或 SOP |
| 风险未确认 | 暂停发布或暂缓报价 |
| 反馈分散 | 收窄用户和场景 |
复盘时要同时看行为和原话。行为告诉你用户做了什么,原话告诉你为什么可能这样做。只看其中一个,都容易误判。
如果复盘后没有产生新动作,说明复盘还停在总结层。好的复盘应该让下一步更小、更清楚。
操作检查表
| 字段 | 填写 |
|---|---|
| 当前主题 | Micro SaaS用户研究技能 |
| 目标用户 | 有明确流程痛点的小团队或独立用户 |
| 关键输入 | ___ |
| 最小样品 | ___ |
| 主要风险 | 伪需求、过度开发、支付失败、隐私数据和长期支持压力 |
| 官方核验入口 | ___ |
| 复盘指标 | 用户原话、样品行为、交付问题、下一步动作 |
| 当前判断 | 继续 / 补证据 / 暂停 |
这张表可以直接复制到你的项目文档里。每完成一轮,就更新一次,不要只靠记忆。
AI 怎么辅助
AI 适合做这些:
- 把用户原话整理成问题分类。
- 生成 Brief、检查表、SOP 或复盘表。
- 标出未确认字段和风险点。
- 改写页面、提案或交付说明。
- 把反馈转成下一步动作。
AI 不适合替你确认平台规则、支付退款、客户授权、隐私边界和真实购买意愿。没有证据时,必须写未确认。
让 AI 辅助时,不要只问“怎么做”。要给它材料、目标、约束和当前判断,让它帮你找遗漏。
官方资料与核验口径
平台规则、算法动向、报价规则、政策口径都会变化。本文保留的是可迁移的判断框架,具体数字一律给区间。
跨平台核验入口:
- Indie Hackers — 看 Micro SaaS 真实营收、留存与复盘
- Stripe Atlas Guides — 看 SaaS 收款、跨境结算与合同模板
- microconf — 看 bootstrap SaaS 报告、增长与定价案例
涉及具体数据、比例、报价区间的部分,以执行当天后台为准。
常见问题
用户说「我会买」但被追问预算时改口「等等看」,是真需求吗?
不是。这是典型 Mom Test 反信号:嘴上同意 + 行动暂停。真需求的回答应该是"我现在用 X 工具,每月 Y 元,如果你能解决 Z 问题,我马上换"。给具体金额 + 切换条件 = 真需求;含糊"看情况"= 不是。
用户研究做了 5 次访谈但全说"挺好的", 怎么挖出真痛?
不要再问"觉得怎么样"。改问 3 类具体问题:1)"上次为这个问题付过钱吗,付了多少?"(付费历史);2)"现在用什么解决?多久用一次?"(替代方案);3)"换工具最难的是什么?"(切换成本)。痛点藏在过去的付费行为和现在的替代方案里,不藏在意见里。
5 个用户都同意你的方案,是不是该开发了?
看 3 件事:1)他们是否对同一痛点而来(人群一致);2)愿付预算是否相似(≥ 70% 落在同一档);3)当前替代方案是否相同(如果都用同一工具表示替代清楚)。3 件事齐 → 开发 MVP;任一散乱 → 先收窄人群再访谈。
用户研究和"做调研问卷"有什么区别?
问卷只看"会不会买",研究看"已经在做什么"。问卷答案多数是社交表演(不想说"不会买"伤面子)。研究是观察行为:现在用什么、付过多少钱、卡在哪步、最近一次抱怨什么。行为不会撒谎。
执行前至少核验:
- Mom Test → 真实痛点访谈方法
- YC · Talking to Users → 早期用户访谈样板
- Jobs-to-be-Done · Strategyn → JTBD 拆任务