产品发现
Product Discovery
中级通用产品发现（Product Discovery）是在投入开发前，通过了解用户、观察实际行为和验证假设，弄清值得解决的问题及可行方向的过程。它帮你避免把未经验证的想法直接做成产品；比如先确认用户为何放弃上传，再决定改不改上传界面。
你可能会说：「我想先弄清用户到底卡在哪里，再决定让 AI 帮我做什么功能。」
读之前建议先了解
动手看看用户放弃上传，要改界面吗
1
假设我们在做简历上传功能，发现有人选好文件却退出了。先记下这个现象，别急着认定是上传界面难用。
要点产品发现要弄清哪些事？
- 1
先找问题而不是先定功能
你看到用户反复导出报表，可能会想到做自动邮件。但他们真正的麻烦也许是数据口径不一致。先问清使用场景和现有做法，后面才不会把功能做在错误的位置。
- 2
用行为和反馈检验猜测
我们可以访谈用户、看操作记录，或拿可点击原型请人完成任务。重点不是收集一句“这个功能不错”，而是看看问题是否真的存在，以及提出的办法能不能帮他们完成任务。
- 3
带着证据决定下一步
发现不一定以开发新功能结束。如果用户只是找不到现有入口，调整导航可能就够了；如果证据还不足，就继续验证。把已知事实、未证实的假设和决定依据分开，团队更容易判断下一步。
容易混淆的地方
产品发现关注“解决谁的什么问题、哪种办法值得试”，产品交付关注“怎样把选定的办法做出来并上线”。它也不等于写 PRD：PRD 可以记录已经明确的需求，但写得详细不能证明需求有价值。发现过程中同样可以做原型或写少量代码，只是为了验证，而不是先承诺完整交付。
什么时候用
适合用
- 你准备给记账 App 加 AI 分类，但还不确定用户是分类费时，还是根本不信任分类结果。
- 后台团队收到多个客户的导出需求，想先找出共同的工作障碍，再决定排哪些功能。
- 新网站注册完成率低，你想弄清用户在哪一步退出、为什么退出，再讨论改版方案。
不适合用
- 线上支付流程已确认有阻断交易的故障时，先按故障排查和修复流程处理，不必把修复当成产品发现。
- 需求和方案都已确认，只是把现有页面按设计稿实现时，直接拆开发任务并核对验收标准。
- 只是想比较两个已实现的按钮文案对转化的影响时，用 A/B 测试更直接，不必重启完整的产品发现。
练一练选一个答案，看看解释
你在做一款会议纪要工具，用户说“加个自动生成待办的按钮”。团队还不知道他们怎样处理会后任务。下一步怎么做更合适？
让 AI 帮你做复制给 AI Agent 直接用
请和我一起做产品发现，暂时不要写正式功能代码。针对会议纪要工具的“自动生成待办”想法，先列出待验证的用户问题和关键假设，再给我访谈问题、可观察的行为证据，以及一个低成本验证方案；请区分事实与猜测。