关于 idea-validation
一个用于按阶段验证创业想法的技能,面向创业者和产品团队。它结合需求信号、客户访谈、低成本假设测试与阶段性淘汰检查,帮助尽早判断继续、调整或停止。
主要功能
- 01四项问题定义检查
- 02多来源需求信号核验
- 03解决方案适配评估
- 04客户访谈与信号追踪
- 05限时低成本假设测试
- 06加权继续或停止评分表
适用场景
- 01评估问题是否具体且值得解决
- 02通过访谈确认客户痛点与付费意愿
- 03低成本测试关键商业假设
- 04比较多个想法并决定优先级
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ jk-0001/ skills --skill idea-validation安装后在 Claude Code 中输入/idea-validation确认已加载。
详细介绍
创意验证
概览
快速淘汰糟糕的创意,低成本验证好的创意。按顺序走完每个阶段。每个阶段都有一项淘汰检查——如果创意不通过,就记录原因并停止,避免继续浪费时间。
第 1 步:定义问题
一切都从这里开始。问题模糊,业务也会模糊。
准确回答以下四个问题:
- 谁——具体的人。不是“中小企业”,而是“同时处理 3-8 个客户项目的自由平面设计师”。
- 什么——具体的痛点时刻。“他们每周要花 4 小时以上,手动导出交付成果,并通过一连串邮件协调修改反馈。”
- 为何令人困扰——实际代价:浪费时间、收入损失、压力、错过截止日期、关系受损。尽可能量化。
- 他们现在怎么做——他们当前的权宜之计。这才是你真正的竞争对手——不只是竞品应用,还有现状本身。
**淘汰检查:**无法具体回答全部四个问题 → 问题定义不清晰。先进行更多探索。
第 2 步:收集需求信号
证明确实有人在意。不要依赖假设或朋友的客套话。
检查以下信号来源中的 3 个或更多:
| 信号 | 来源 | 积极信号 |
|---|---|---|
| 搜索量 | Google Trends、Ubersuggest free | 核心问题关键词的搜索量稳定或增长 |
| 论坛痛点 | Reddit、HN、Slack/Discord | 相关帖子有 10 条以上评论描述这一确切痛点 |
| 现有工具的缺口 | G2、App Store 评论 | 解决相邻问题的工具,其评论提到了你能填补的缺口 |
| 招聘信息 | LinkedIn、Indeed | 有些职位的存在,正是因为手动解决这个问题成本高昂 |
| 社交平台上的抱怨 | Twitter/X 搜索、LinkedIn | 人们未经提示就在公开抱怨 |
**淘汰检查:**积极信号少于 3 个 → 问题可能不够令人困扰。转向或淘汰。
第 3 步:检查解决方案是否契合
严格检验你提出的解决方案是否真的能把问题解决得足够好,值得围绕它建立一门生意。
- **10 倍规则:**你的解决方案是否在速度、成本、易用性或质量方面比当前权宜之计好 10 倍(而不是 10%)?只有微小改善,不足以让人们改用你的方案。
- **工作流变更审查:**准确梳理用户必须对当前流程做出的所有改变。摩擦越大,采用率越低。
- **单人开发可行性:**一个人能否在几周到几个月内构建出可用的 MVP?如果需要一个 10 人工程团队,那就是另一家公司。
- **不公平优势:**为什么偏偏是你?技能、行业资源、数据、人脉、信誉——总得有些竞争对手难以轻易复制的东西。
**淘汰检查:**不符合 10 倍规则,或完全没有不公平优势 → 继续寻找其他方向。
第 4 步:客户探索(与真实用户交流)
与 10-15 位真实潜在客户交流。这一点不可妥协。再多的案头研究也无法取代这一环节。
寻找交流对象:
- 在 2-3 个相关社群发帖,邀请大家进行 15 分钟的反馈交流。
- 在 LinkedIn 或 Twitter 上私信符合目标用户画像的人。
- 如有需要,提供小额奖励(礼品卡、未来免费使用权限)。
交流流程(15-20 分钟):
1. CONTEXT (2 min)
"Tell me about your work. Walk me through a typical week
around [problem area]."
→ Listen only. Do NOT pitch or explain your idea.
2. PAIN EXPLORATION (5 min)
"What's the most frustrating part of [workflow]?"
"How often does that come up?"
"What have you already tried to fix it?"
"What's still missing?"
→ Ask "why" and "what happens when" repeatedly. Dig.
3. OUTCOME PROBING (3 min)
"If a tool could [describe the outcome, not your feature set],
how would that change things?"
"What would that be worth — in time, money, stress?"
→ Let them quantify. Never suggest a number first.
4. WILLINGNESS TO PAY (2 min)
"Would you pay for something like that? What range feels fair?"
→ Discount stated numbers by ~50% when planning.
5. WARM REFERRAL (1 min)
"Know anyone else who hits this same wall? Mind if I reach out?"
在所有交流中跟踪以下指标:
- 未经提示就描述了问题的人所占比例(痛点信号)
- 目前确实花钱或花时间解决问题的人所占比例(收入信号)
- 明确愿意付费的人所占比例(需求信号)
- 多人独立提出的功能(产品信号)
- 交流证明你原先持有的假设有误的地方(尽早淘汰相关功能)
**淘汰检查:**确认存在痛点且愿意付费的人少于 60% → 返工或淘汰。
第 5 步:风险最高的假设测试(RAT)
如果有一个假设不成立,就会让一切功亏一篑。找出它,并在不到 2 周、花费不超过 $200 的时间和预算内进行测试。
常见的风险最高假设及低成本测试:
| 假设 | 最小测试 | 通过门槛 |
|---|---|---|
| 人们愿意付费 | 创建落地页并添加“预购”按钮。吸引 200 名目标访客。 | 3-5% 的访客完成付款或支付定金 |
| CAC 负担得起 | 投放 $100 的定向广告。衡量每条潜在客户线索的成本。 | CPL < 计划客户终身价值的 20% |
| 人们会改变工作流 | 为 5 人免费提供手动版服务。观察他们是否真的使用。 | 5 人中至少有 3 人持续使用 |
| 我能独自完成开发 | 先将难度最高的单项技术功能开发成原型。 | 在 ≤ 2 周内完成可运行的原型 |
流程:
- 陈述假设。
- 明确定义什么情况算“得到确认”(具体、可衡量的数字)。
- 设计成本尽可能低的测试。
- 设定严格的截止日期(最长 2 周)。
- 执行测试。客观记录结果,不加修饰。
终止检查: RAT 未通过 → 当前形式的想法不可行。调整解决方案、客户或模式,或彻底放弃。
第 6 步:继续/停止评分卡
| 维度 | 评分(1-5) | 权重 |
|---|---|---|
| 问题的严重程度与明确性 | __ | 20% |
| 收集到的需求证据 | __ | 15% |
| 客户探索的确认结果 | __ | 20% |
| 解决方案契合度(10 倍提升 + 可行性) | __ | 15% |
| RAT 结果 | __ | 20% |
| 你的不公平优势 | __ | 10% |
加权得分 = Σ(评分 × 权重)
- 4.0–5.0 → 继续。 开始规划 MVP + 商业模式画布。
- 3.0–3.9 → 有条件继续。 先通过一轮额外测试解决最薄弱的维度。
- < 3.0 → 停止。 放弃或从根本上调整方向。记录经验教训。
应避免的想法验证错误
- 未将发现记录在同一处——洞察散落在笔记、邮件和聊天记录中,就会失去价值。从第一天起就维护一份持续更新的“想法验证”文档。
- 让验证无限期拖延。将整个流程的时间限制在最多 2-3 周。验证瘫痪和完全跳过验证一样致命。
- 单独测试一个想法。条件允许时,并行测试 2-3 个想法——对比能让判断更准确,也能揭示你对这些想法共同做出的假设。
- 把礼貌性的兴趣误认为真实需求。朋友和同事会说好听的话。只有陌生人愿意付费或做出承诺,才算有效信号。
- 跳过终止检查。每个阶段都有终止检查,自有其原因。无视未通过的检查而继续推进,只会在走不通的想法上浪费数周或数月。
评论
支持 Markdown