需求缺口方法论

需求缺口和风向标、深度报告的出发点不同。它不是先看已有产品增长，而是先看 用户是否正在反复暴露同类痛点，并且已经用土办法自己扛着解决。

我们为什么把它单独成类

很多值得做的小软件，最早并不会先出现在收入榜、流量榜或产品榜里，而是先出现在这些信号里：

• 非技术用户持续求助
• 用户抱怨现有通用工具很难用
• 用户开始用表格、脚本、手工流程顶替软件
• 用户明确表达“我愿意花钱买一个更简单的解决方案”

这类线索的本质不是“已有赢家”，而是“需求已经存在，但供给还不够好”。

我们重点看什么

目标用户是否明确

不是“所有人都可能需要”，而是能说清楚是谁在这个流程里反复受苦，例如电商卖家、装修公司老板、自由设计师。

核心痛点是否具体

不是抽象地说“效率低”，而是能描述出具体任务，例如多平台库存手动同步、报价单反复复制、客户跟进依赖表格。

是否存在土办法证据

这是最强信号之一。用户已经在用 Excel、Google Sheets、Zapier、手工复制粘贴、临时脚本等方式解决，说明痛点足够真，且已经有解决意愿。

是否存在付费意愿

我们优先看两类表达：

• 直接说愿意付费、愿意雇人、愿意买工具
• 虽然没直接说付费，但已经投入大量时间自己硬解决

后者不等于一定会买单，但至少说明问题不是“可有可无”。

一条需求缺口如何形成

1. 先在 Reddit 非技术用户社区里找重复出现的问题
2. 再把相同场景、相同用户、相同需求的帖子归成一个机会簇
3. 检查它是否有土办法、付费意愿和跨帖共鸣
4. 最后再判断供给状态、适合的交付形态和价格带

机会判断看哪些字段

供给状态

• 无明确供给：还没有专门解决方案
• 低效供给：已有通用工具，但体验差、配置重、学习成本高
• 红海成熟：已有成熟产品充分覆盖，这类通常不值得再包装成机会

机会类型

• 有市场但没供应
• 供给低效
• 代做先行

推荐交付形态

不一定都是 SaaS，也可能是：

• Chrome 插件
• 自动化工作流
• 轻量内部工具
• 先以代做服务验证，再产品化

会员应该怎么使用需求缺口

不要把需求缺口当成“立刻开做”的清单，而要把它当成 验证优先级列表：

1. 先看目标用户是不是你熟悉的人群
2. 再看痛点是不是高频、重复、带流程摩擦
3. 再看价格带和付费方，判断它是不是一个能成立的生意
4. 最后决定是继续调研、先做 MVP，还是直接放弃

什么时候要谨慎

• 只有抱怨，没有土办法，也没有付费意愿
• 全部讨论都来自开发者，而不是实际业务用户
• 现有成熟产品已经覆盖得很好，只是用户还没找到
• 痛点太低频，无法支撑稳定付费