Skip to content
返回想法验证

问题陈述

写一个清晰可测的问题陈述，点明谁、什么痛、多频繁。

为什么

模糊的问题陈述（"开发者需要更好的工具"）产出模糊的产品。清晰的（"独立开发者每次发布浪费 2+ 小时从分散提交手写 changelog"）迫使每个功能决策回答：这减少那个具体浪费吗？问题陈述是防范围蔓延的锚——有人提功能时你对照陈述拒绝不服务它的。没有书面具体陈述，每个功能都同等有效，产品臃肿成什么都不是。陈述也使问题可测，之后你能证明解决了它。

何时使用

在任何验证测试之前，想法刚出时。1-2 小时。验证发现你问题错了时修订。

如何做

1. 点明具体的人
   - 不是"开发者"——"每周发到生产的独立开发者"
   - 越具体越可测

2. 点明具体的痛
   - 不是"浪费时间"——"每次发布花 2+ 小时手编 changelog"
   - 可观察可测，不是感觉

3. 点明频率和情境
   - 多频繁？（每次发布、每天、入门时）
   - 什么条件下？（单人、无 QA、用 GitHub）

4. 点明当前变通
   - 他们今天怎么做？（跳过 changelog、从 PR 复制、用模板）
   - 变通证明问题真实且显示你方案替代什么

5. 写一句话陈述
   - "[画像] [动词] [痛] [频率]，目前 [变通]"
   - 例："独立开发者每次发布花 2+ 小时从分散提交手编 changelog，目前跳过或从 PR 标题复制。"

6. 压力测试
   - 这问题值得解吗？（频率 × 痛 × 改变意愿）
   - 够具体到能拒绝不服务它的功能吗？
   - 你能测是否解决了吗？（定义前后指标）

示例

想法：从 git 历史自动生成 changelog 的工具。

坏陈述："开发者需要帮忙写 changelog。"
  → 模糊、不可测、不拒绝任何功能

好陈述："每周发布的独立开发者每次发布花 2+ 小时从分散提交和 PR 标题手编 changelog，目前要么完全跳过（用户抱怨）要么把 PR 标题复制进 markdown（不一致、漏修复）。"

测试：
  - 画像：每周发布的独立开发者 ✓（在 r/IndieHackers 可找）
  - 痛：每次发布 2+ 小时 ✓（可测——前后计时）
  - 频率：每周 ✓（够高）
  - 变通：跳过或复制 ✓（证明问题真实）
  - 指标："每次发布花在 changelog 的时间"→ 目标：< 5 分钟

这陈述拒绝："加 Jira 集成"（独立开发者不用 Jira）、"加 AI 语气调整"（与时间无关）。

常见问题

  • ⚠写你无法观察的问题——"开发者感到不堪重负"是感觉不是问题；改为可观察行为。
  • ⚠画像太宽——"开发者"包括企业架构师和爱好者学生，问题完全不同。
  • ⚠跳过当前变通——如果无变通，问题可能不够紧急；人能与非紧急问题共存。
  • ⚠陈述不能拒绝功能——如果每个功能"可能有帮助"，陈述太模糊；应使 50% 的想法明显超范围。

最佳实践

  • ✓在陈述中含当前变通——它证明问题真实且显示你方案必须胜过什么。
  • ✓在陈述中定义成功指标——"从 2 小时降到 < 5 分钟"使其可测且防移动球门。
  • ✓用陈述做功能过滤器——写在便利贴上；每个提议的功能必须服务它否则拒绝。
  • ✓用 5 个目标用户验证陈述——读给他们听问"这是你的问题吗？"；如果 < 3 说是，你问题错了。