产品发现Product Discovery
你可能会说
先别让 AI 把整套功能写出来，我们先确认用户真的遇到这个问题，再用最小的测试决定继续、缩小还是停止。
在投入完整开发之前，通过收集用户与业务证据，验证问题是否真实存在、方案是否具备价值和可行性的探索过程。例如团队想做一个“提示词结果对比工具”。产品发现不会先把完整功能写出来，而是把“创作者经常需要对比结果”写成假设，通过最近一次真实操作的访谈记录和低保真原型观察来收集证据。结果可能支持继续，也可能要求缩小范围、改换问题或暂时停止；它降低早期押错方向的风险，不保证产品上线后一定成功。
也常被叫作产品探索需求探索Product Discovery Phase需求发现机会评估
产品发现在写代码前验证假设的闭环
现在只有想法，还没有用户证据
- 价值
- 创作者经常需要并愿意使用结果对比
- 可用性
- 新手能看懂双栏差异并完成选择
- 可行性
- 同一输入能稳定生成可比较的结果
“我觉得用户会喜欢”不能放进证据栏。
产品发现的产出是有证据的下一步，不是自动批准立项。
一个产品想法怎样变成可验证的决定
失败前：把团队猜测当成用户需求：团队想到“创作者需要对比提示词结果”，就直接让 AI 开始做账号、工作台和设置页。功能按计划交付，只能证明团队完成了开发，不能证明目标用户确实遇到这个问题，也不能证明现有方案值得替换。
把高风险判断写成假设，再收集行为证据：分别写清价值、可用性、可行性和业务约束。例如“创作者会手工并排比较结果，而且经常因此返工”。访谈时追问最近一次真实操作和临时办法，再用纸面或低保真原型观察选择任务。假设必须对应可观察行为，口头称赞不能单独作为立项依据。
结果是改变决定，不是凑齐一份报告：如果证据只支持“需要快速看差异”，就把方案收窄为两列对比，而不是继续扩展完整工作台；如果没人遇到这个问题，就暂停并重新判断。继续、收窄、转向或停止，只要理由和证据能对应，都是有效产出。
你可以这样告诉 AI Agent
我想为独立创作者做一个提示词结果对比工具。先不要写完整代码或高保真 UI：请列出最危险的价值、可用性、可行性和业务假设，先问我已有证据，再设计一轮基于最近真实经历的访谈和低保真任务测试。每项测试都写清要观察的行为、支持或推翻假设的信号，以及证据不足时是继续、缩小范围还是暂停。
接下来学什么
延伸阅读 · 权威出处
快速练习