AI有用之后，产品发现该怎么做

昨晚，我在特隆赫姆的 Bart.js 聚会上做了一场关于产品发现以及人工智能对其影响的演讲。时间只有一小时，所以我们快速梳理了理论、分享了三位客户的实践经验，最后还略带“吐槽”地总结了几点看法。

以下是主要内容。

先来个“自白”

我也曾做出过会崩溃的产品；更糟的是，我还开发过一些几乎没有实际价值的功能，以至于连一张能放进幻灯片的截图都找不到。产品开发中真正的风险，在于做错了产品——对用户毫无价值，对企业也毫无意义。

为什么找准正确的产品如此困难？

用户使用我们所构建产品的动机各不相同，而只有真正投入生产才能检验其是否奏效。解决方案的空间并非无限，只是极其庞大。很多时候，我们之所以去构建，往往只是因为“我们可以做到”。

而软件本身并不具备固有价值——孤立存在时，它对企业而言只是风险与成本；真正创造价值的是用户。

我们习惯关注交付期限、范围和利益相关方的满意度，但更应该把目光投向四大风险：价值、可用性、可行性和业务可持续性。再加上人类的一个小“怪癖”——我们热衷于添加功能，却不愿删减，于是产品便不断堆积。

破解之道在于并行运行两种模式：持续发现回答“值得构建什么”，持续交付则解决“如何构建”。如果一味偏向某一方，要么陷入分析陷阱——什么都无法上线；要么掉入构建陷阱——盲目交付无人需要的东西。

因此，应将工作拆解为一系列小规模的“试错赌注”：先假设某件事能带来价值，再通过数据衡量，并根据所学及时调整方向。每一次改变都是一次有待现实检验的假设。

三个行之有效的方法

机会—解决方案树

先明确目标，可视化现有认知，再围绕该目标梳理潜在机会与对应方案。

我画的第一棵树就像真实场景一样：杂乱、分支过宽，完全不像书中的示例。而这正是关键所在——混乱恰恰反映了团队当前的心智模型，从而为改进提供抓手。

措辞也很重要：“搭建一个仪表盘”这样的表述会固化思维，而“规划人员无法及时察觉早期风险信号”则能保留多种可能的解决方案。用这棵树设定 OKR，还能免费获得一层战略框架：目标指明方向，关键结果衡量进展，而树状结构则清晰呈现每项指标背后的假设与行动。

度量体系

洞察力就像吃蔬菜：道理谁都懂，有人觉得味道奇怪，必须新鲜，还得养成习惯才见成效。健康类指标应能在用户察觉之前就预警异常；产品类指标反映用户行为，业务类指标则评估这些行为是否产生实质价值。

同时结合用户访谈，让“做什么”与“为什么”相互印证。即便用户提出了某个需求且看似合理，也不要急于动手——也许还有更具价值的替代方案。

原型设计火力全开

先写下假设：我们相信针对用户群体 Y 的 X 将带来 Z，而一旦观察到 A，则说明我们的判断有误。

随后减少讨论、增加原型迭代，并与领域专家共同打磨。没人能凭需求文档想象出完整画面，但人人都能指着屏幕指出问题所在。

人工智能对此有何影响？

原型设计已“起死回生”。只要会说话，就能做出一个网页应用——连我的孩子都能上手。纸质原型实现了数字化，再加上设计系统加持，不再显得冰冷无趣。

你的核心优势依然属于你，而其余知识则由 AI 补齐。如今已鲜少有人单打独斗，一个小团队也能发挥出大团队的效能。

借助 AI 这位“最佳助教”，各类工作坊的组织与执行都更加轻松：会前、会中、会后，AI 都能高效整理与重组知识，面向不同受众进行精准输出。

而原本就至关重要的度量体系，如今不仅更重要，而且设置起来也更便捷。

只需构建到足以得到答案的程度：

• 他们能理解吗？一张纸上的草图即可。
• 他们会使用吗？一个可点击的原型就够了。
• 这是否可行？一段粗糙的脚本配合真实数据就足够了。

不过需要注意的是，“容易构建”并不等同于“正确地构建”。门槛低到一定程度，有些人甚至直接跳过“从小处着手”，从第一天起就过度设计、功能堆砌、复杂度飙升。

AI 在设计方面仍显不足，需要人为引导；架构、扩展性与安全性依然由开发者把控；决策判断也无法自动化。如果你自己都不知道想要什么，自然也得不到想要的结果。

速度为我们赢得了学习空间，而最大的收获是能让大家把更多时间留给专业技艺本身。

眼下构建门槛极低，很容易让人忍不住多做一点、分散精力。切勿如此。请始终以价值为导向，否则最终只会留下更多无人问津的功能，甚至连一张可用截图都找不到。