从自己的痛点中找产品机会
「Scratch Your Own Itch」：一个经久不衰的起点
在创业和独立开发的世界里，有一句被反复提及的话：「Scratch your own itch」——抓你自己的痒处。Paul Graham 在经典文章《How to Get Startup Ideas》中写道：「The way to get startup ideas is not to try to think of startup ideas. It's to look for problems, preferably problems you have yourself.」翻译成中文就是：最好的创业点子不是凭空想出来的，而是从你自己遇到的问题中「看」到的。
这个思路之所以经典，是因为它解决了新手创业者最常犯的错误——凭空发明需求。很多人花几周时间头脑风暴，列出几十个「感觉不错」的点子，最后发现没有一个真正有人需要。而如果你从自己的痛点出发，至少能确保一个问题是真的：这个痛点确实存在，你自己就是第一个用户。
但「从痛点出发」只是起点，不是全部。A Smart Bear 的作者 Jason Cohen 专门写了一篇文章提醒：「"I scratched my own itch" isn't good enough」。你的痛点未必是别人的痛点，你愿意为之付费不代表别人也愿意。从个人痛点到成功产品之间，还有一段需要认真走过的验证之路。
本文将从实操角度出发，拆解整个过程：怎么识别自己的痛点、怎么判断它是否值得做成产品、怎么从痛点一步步推导出 MVP。
怎么识别自己的痛点
痛点不会以「产品灵感」的形式出现在你面前。它们藏在你每天的工作流程里，藏在你习以为常的抱怨中。你需要一套具体的「探测方法」来捕捉它们。
记录「重复操作」
拿出一张纸或打开一个文档，连续记录一周你在工作中反复做的事情。重点关注这些信号：
- 你每天手动做超过 3 次的操作。比如每天从某个网站复制数据到 Excel，再手动整理成报告。
- 你每次都要写「几乎一样」的代码或文档。比如每次起新项目中都要重复配置相同的环境、写相同的 boilerplate。
- 你经常为同一个问题搜索答案。比如每次部署都忘了某个步骤，每次都重新 Google。
独立开发者 Kyle Gawley 就是这么做的。他发现自己每次启动新的 SaaS 项目都要重新写登录、计费、基础页面等 boilerplate 代码，于是把这些代码打包成了一个可复用的模板产品 Gravity，卖给其他开发者，产生了可观的收入。
标记「手动步骤」
留意那些你不得不「手动」完成的环节，尤其是涉及在不同工具之间切换、复制粘贴、格式转换的场景。这些手动步骤往往意味着现有工具之间存在断层。
举个例子：如果你每周花 2 小时把设计稿里的标注手动整理成开发文档，这就是一个潜在的痛点。Figma 的早期用户就经常遇到类似问题——设计工具与开发交付之间存在巨大的信息鸿沟。
注意「找不到好工具」的时刻
当你为某个需求搜索了一圈，发现市面上的工具要么太贵、要么太重、要么已经停更、要么根本不存在，这个时刻值得记下来。
「找不到好工具」通常意味着以下几种情况之一：
- 市场存在需求但供给不足——有产品化机会
- 现有方案都太复杂，用户需要一个「轻量版」——有简化切入的机会
- 这个领域太新，还没有人像样的产品——有先发机会
- 这个问题太小众，没有商业公司愿意做——可能有独立开发者的 niche 机会
收集「情绪信号」
痛点往往伴随着情绪反应。留意让你感到烦躁、无奈、甚至愤怒的时刻。这些情绪是痛点的「信号放大器」。
具体来说，留意以下场景：
- 你不得不向别人解释为什么这件事这么麻烦——说明这个痛点已经影响到了协作效率
- 你因为某个工具的问题改变了工作习惯——说明你已经在「绕路」了
- 你向朋友吐槽「怎么没有人做一个 XXX」——说明你已经在想象解决方案了
怎么判断痛点是否值得做成产品
发现了痛点之后，不要急着写代码。先回答几个关键问题，判断这个痛点是否值得你投入时间和资源。
普遍性：你代表的是多大的群体？
你的痛点是你独有的，还是某个群体会共同遇到的？这一步的核心是「从个案到群体」的跳跃。
判断方法：
- 搜索同类抱怨：在 Reddit、V2EX、Twitter/X、Hacker News 搜索你遇到的问题关键词，看看有没有其他人在吐槽
- 加入相关社群：找到你所在领域的开发者社群、用户社群，观察大家讨论的高频问题
- 直接问身边的人：找 5-10 个与你角色相似的人（比如都是独立开发者、都是产品经理），问他们是否也遇到这个问题
Paul Graham 的建议是：你应该 targeting 一个「小而狂热」的群体，而不是一个大而冷漠的市场。10 个「非用不可」的用户，比 1000 个「还行吧」的用户更有价值。
付费意愿：人们愿意为解决这个痛点付钱吗？
痛点真实存在，不代表人们愿意掏钱。很多人已经习惯了「将就」——他们用 Excel 凑合、用脚本硬撑、或者干脆忍着。
判断付费意愿的方法：
- 观察现有解决方案的花费：人们现在为解决这个问题花了多少钱？请了助理？买了昂贵的企业软件？花了多少工时？
- 询问「替代成本」：如果不解决这个问题，他们会损失什么？损失的时间和金钱是否可以量化？
- 直接测试付费：做一个简单的 landing page，写上产品描述和价格，看有多少人在「购买」按钮上点击
一个实用的经验法则：如果你的产品能帮用户每周节省 5 小时以上，或者每月省下 500 元以上，他们大概率愿意为一个月费 20-50 美元的产品付费。
竞争情况：别人做得怎么样？
一个完全没有竞争者的市场，不一定是蓝海——很可能是一个根本没有商业价值的市场。适度的竞争反而验证了需求的存在。
你需要回答：
- 直接竞品有多少？ 如果已有 10 个成熟产品在做同样的事，你需要想清楚自己凭什么胜出
- 现有竞品的弱点是什么？ 读它们的差评、用户论坛里的吐槽——这些就是你的切入点
- 你的差异化是什么？ 更简单？更便宜？更专注某个细分人群？更好的体验？
一个判断矩阵
| 维度 | 值得做的信号 | 需要警惕的信号 |
|---|---|---|
| 普遍性 | 至少找到 3 个不同背景的人有相同痛点 | 只有你和极少数同行遇到 |
| 付费意愿 | 用户现在有花钱或花大量时间解决 | 大家觉得「忍忍就好」「免费凑合就行」 |
| 竞争情况 | 有竞品但用户不满意，或没有针对细分场景的方案 | 已有巨头做得很好，或完全没人做 |
| 频率 | 每周甚至每天都遇到的痛点 | 一年才遇到一两次 |
| 紧迫度 | 不解决会导致明确的损失（时间/钱/机会） | 只是「不太方便」但影响不大 |
| 你的优势 | 你有领域知识或技术能力做出差异化 | 你只是「觉得能做」但没有独特认知 |
从痛点到产品的推导过程
确认痛点值得做之后，下一步是把它转化为一个具体的产品方案。这个过程可以拆解为四个阶段：
第一阶段：痛点 → 需求定义
把模糊的痛点翻译成清晰的需求描述。一个好的需求描述应该包含三个要素：
- 谁（Who）：具体的用户画像，不是「所有人」，而是「像我这样的独立开发者」「我老婆那样的时尚二手卖家」
- 在什么场景下（When）：具体的使用场景，比如「每次部署新版本时」「每周整理数据时」
- 遇到了什么困难（What）：具体的问题描述，越具体越好
例如：「独立开发者（谁），在每次启动新的 SaaS 项目时（场景），都需要花 2-3 天重新配置登录、计费和基础页面（困难）」。这就是 Kyle Gawley 做 Gravity 时面对的需求。
第二阶段：需求 → 方案设计
有了清晰的需求定义后，开始考虑解决方案。这一步的关键是「先做减法」——不要试图一次解决所有问题。
问自己：
- 最小可行的解决方案是什么？ 如果只能做一个功能，做哪个？
- 现有工具的哪些部分可以去掉？ 很多工具过于复杂，你的优势可能是「做少」
- 技术上最简单的实现路径是什么？ 先验证需求，再追求完美
第三阶段：方案 → MVP
MVP（Minimum Viable Product）不是「简陋版产品」，而是「用最小代价验证核心假设的工具」。
一个好的 MVP 应该满足：
- 能在 1-4 周内完成：超过这个时间，说明你在做太多东西
- 能解决核心痛点：不需要完美，但要能用
- 能让第一批用户真正使用：不是 demo，是真实可用的产品
Jordan O'Connor 的故事是个好例子。他的妻子在时尚二手平台上手动推广商品，每天花大量时间重复点击「分享」按钮。Jordan 先写了一个浏览器 bookmarklet 帮妻子自动化这个操作——这就是 MVP。确认有效后才逐步做成完整的 SaaS 产品 Closet Tools。
第四阶段：MVP → 验证与迭代
产品上线后，核心任务是验证两件事：
- 需求验证：用户真的在用吗？使用频率如何？
- 价值验证：用户觉得有帮助吗？愿意付费吗？
收集反馈的渠道包括：
- 直接和用户对话（最好是视频或语音，文字容易遗漏情绪）
- 观察用户行为数据（活跃度、留存率、功能使用率）
- 关注用户在社交媒体上的自发分享或吐槽
从痛点到产品的完整路径
痛点类型与产品化潜力
不是所有痛点的「产品化潜力」都一样。有些痛点天然适合做成产品，有些则更适合写成脚本自用。下面是一个分类参考：
| 痛点类型 | 描述 | 产品化潜力 | 典型产品形态 |
|---|---|---|---|
| 重复操作型 | 每天手动做 N 次的机械性工作 | ⭐⭐⭐⭐⭐ | 自动化工具、SaaS |
| 信息断层型 | 在多个工具之间搬运信息 | ⭐⭐⭐⭐ | 集成工具、数据同步 |
| 能力缺失型 | 现有工具缺少某个关键功能 | ⭐⭐⭐⭐ | 插件、扩展、替代产品 |
| 知识门槛型 | 做某件事需要专业知识，太多人不会 | ⭐⭐⭐⭐⭐ | AI 辅助工具、模板、向导 |
| 协作摩擦型 | 多人协作时沟通或交接困难 | ⭐⭐⭐ | 协作工具、文档平台 |
| 体验糟糕型 | 现有工具能用但体验很差 | ⭐⭐⭐ | 替代产品（需要有明显体验优势） |
| 一次性困扰型 | 偶尔遇到，频率很低 | ⭐⭐ | 通常不值得做成产品 |
值得做 vs 不值得做的痛点
即使是一个真实的痛点，也未必值得你投入几个月甚至几年的时间。下面这个对比帮你快速筛选：
| 维度 | 值得投入的痛点 | 不值得投入的痛点 |
|---|---|---|
| 频率 | 每天或每周都会遇到 | 一年遇到几次 |
| 影响面 | 影响工作产出或收入 | 只是略微不便 |
| 解决成本 | 现在解决起来很贵或很费时间 | 已经有很便宜的替代方案 |
| 用户获取 | 用户集中在容易触达的社群 | 用户分散，找不到他们 |
| 技术壁垒 | 你有能力做出差异化方案 | 需要大量你不具备的技术能力 |
| 市场空间 | 目标用户有明确的预算和付费习惯 | 目标用户习惯「用爱发电」 |
| 成长潜力 | 可以从一个痛点扩展到更大的平台 | 天花板很低，做完就是做完 |
成功「从痛点出发」的产品案例
案例一：Dropbox —— 「我讨厌忘了带 U 盘」
Dropbox 的创始人 Drew Houston 经常忘记带闪存盘，不同电脑之间的文件同步是一件让人头疼的事情。当时的在线存储工具要么操作复杂、要么没有离线访问功能、要么同步速度极慢。
Houston 为自己写了一个简单的文件同步工具，发现身边的朋友也有同样的需求。他没有急着写代码，而是先做了一个 3 分钟的 demo 视频，展示文件在不同电脑之间自动同步的效果。视频发布后，等待测试版的用户一夜之间从 5000 人涨到 75000 人。
关键启示：Dropbox 的起点是一个极其具体的个人痛点，但 Houston 做对了几件关键的事——先验证需求再写完整产品、选择了「小而狂热」的早期用户群体、找到了一个足够简单的 demo 方式来展示价值。
案例二：Closet Tools —— 「我老婆每天花 3 小时手动分享商品」
Jordan O'Connor 的妻子在 Poshmark（一个时尚二手交易平台）上卖衣服，每天需要花大量时间手动点击「分享」按钮来推广自己的商品列表。这是一个极其重复、毫无创造性但又不得不做的操作。
O'Connor 先写了一个浏览器 bookmarklet 帮妻子自动化这个操作。妻子用了之后效率大幅提升。他意识到这可能不只是他妻子的需求——Poshmark 上有几十万卖家都在做同样的事。于是他把它做成了一个完整的 SaaS 产品 Closet Tools，按月收费，产生了可观的月收入。
关键启示：这个案例完美展示了「从身边人的痛点中发现产品机会」的路径。痛点非常具体、用户群体非常集中（Poshmark 卖家）、现有方案几乎不存在。O'Connor 从一个 bookmarklet 起步，逐步做成了真正的产品。
案例三：Zipic —— 「我需要一个快速压缩图片的工具」
独立开发者 FatBobMan 经常需要压缩图片，但 macOS 上的现有工具要么太大、要么需要联网、要么操作繁琐。他决定自己写一个轻量级的本地图片压缩工具，原生 Swift 开发，速度快且保护隐私。
他在开发过程中密切关注用户反馈，逐步加入了批量处理、并排对比、自动文件夹监控等功能。最终 Zipic 成为了一款受到创作者欢迎的 macOS 效率工具。
关键启示：独立开发者在 niche 市场有独特优势——大公司不愿意做「太小」的工具，但恰好有一群用户愿意为「小而美」的方案付费。
从痛点到产品的验证步骤
| 步骤 | 行动 | 目标 | 预计时间 |
|---|---|---|---|
| 1. 痛点记录 | 连续记录一周遇到的痛点，标注频率和情绪强度 | 产出 10-20 个候选痛点 | 1 周 |
| 2. 痛点筛选 | 按「频率 × 紧迫度 × 普遍性」排序，选出 Top 3 | 聚焦最有潜力的 3 个痛点 | 1 天 |
| 3. 外部验证 | 在社群搜索、发帖询问、找 5-10 人访谈 | 确认痛点是否普遍 | 1-2 周 |
| 4. 竞品调研 | 列出所有相关竞品，读差评、找弱点 | 确定差异化方向 | 3-5 天 |
| 5. Landing Page 测试 | 做一个简单的产品描述页面，放一个「加入等待列表」按钮 | 测试是否有陌生人感兴趣 | 3-7 天 |
| 6. MVP 开发 | 用 1-4 周做出最小可用产品 | 有一个能用的东西 | 1-4 周 |
| 7. 种子用户测试 | 找 10-20 个目标用户免费使用 | 收集真实使用反馈 | 1-2 周 |
| 8. 付费验证 | 上线付费计划或预售 | 有人愿意掏钱 | 1 周 |
评估个人痛点是否值得做成产品的检查清单
在你投入时间开发之前，逐项检查以下 12 个问题：
- 我能用一句话描述这个痛点吗？ 如果你无法简洁地说清楚，可能痛点还不够具体
- 这个痛点每周至少出现一次吗？ 低频痛点的商业化难度显著高于高频痛点
- 我找到了至少 3 个非利益相关者也有同样的痛点？ 「非利益相关者」是指不是你朋友或同事的陌生人
- 这些人在没有解决方案的情况下，已经在花金钱或大量时间应对？ 这证明痛点足够「痛」
- 我在 Reddit、V2EX、Twitter 等平台看到了类似的抱怨？ 这是痛点普遍性的间接证据
- 现有竞品的用户评分低于 4 星，或用户明确吐槽某些方面？ 说明你有差异化切入的机会
- 我的目标用户集中在我能触达的社群或渠道中？ 用户获取难度决定了产品能否活下去
- 我有能力在 4 周内做出一个可用的 MVP？ 如果你需要 3 个月，说明范围太大了
- 这个痛点的目标用户有付费习惯？ 开发者通常愿意为工具付费；学生群体可能不愿意
- 我能通过 SEO、社群或内容营销触达前 100 个用户？ 「做出来就会有人来」是最大的幻觉
- 这个痛点是否有可能扩展到更大的市场？ 从一个痛点出发，最终能否做成一个平台
- 我是否对这个领域有足够的认知优势？ 你在这个领域的工作经验、技术积累或人脉是否足以支撑你做出一款比别人更好的产品
如果 12 项中有 8 项以上的答案是肯定的，这个痛点值得认真考虑。如果低于 5 项，建议重新选择。
小结
「Scratch your own itch」是一个好的起点，但它不是终点。从个人痛点到成功产品，中间隔着「验证普遍性 → 确认付费意愿 → 分析竞争格局 → 构建 MVP → 获取种子用户 → 验证付费」这一整条路径。
最重要的三件事：
- 先验证，再开发。不要花 3 个月做一个没人要的东西。
- 先找 10 个用户，再做产品。如果你找不到 10 个愿意尝试的人，产品做出来也找不到 1000 个用户。
- 先做减法，再做加法。MVP 只需要解决最核心的那一个痛点，其他功能可以后加。
Paul Graham 说得对：最好的产品创意来自于你亲自遇到的问题。但 Jason Cohen 也说得对：你的痛点未必是别人的痛点。把这两句话结合起来，就是正确的行动路径——从自己的痛点出发，用系统的方法验证它是否属于所有人。
参考资料
- Paul Graham. How to Get Startup Ideas. 经典文章，提出「从自己的问题出发」的创业方法论。
- Jason Cohen. "I scratched my own itch" isn't good enough — A Smart Bear. 对「Scratch your own itch」的深度反思，提出 7 项关键假设检查。
- ListenUp IH. 3 Examples of Founders who scratched their own itch and succeeded. Product Hunt、Gravity、Closet Tools 三个从个人痛点出发的创业案例。
- OpinionX. 99 Problems That Inspired The World's Top Startups. 收录了 99 个知名创业公司的初始痛点，包括 Airbnb、Stripe、Dropbox 等。
- Indie Hackers. I Tested 100 Startup Ideas in 30 Days — Only 3 Were Worth Building. 快速验证创业点子的四步淘汰框架。
- FatBobMan. The Indie Developer's Trial — Zipic's Productization Journey from 0 to 1. 独立开发者从个人痛点到 macOS 工具产品的完整历程。
- DEV Community. Scratch your own itch: How to Build and Ship. 从个人痛点到公开构建、获取用户的六阶段实操指南。
- 人人都是产品经理. 场景四步法：从痛点到产品的需求实战. 梳理流程 → 遍历场景 → 发现需求 → 提炼功能的产品需求方法论。