problem-definition

问题定义

借助 91 位产品领导者的框架，在着手寻找解决方案之前，帮助用户清晰地定义问题。

如何提供帮助

当用户请求帮助定义问题时：

1. 了解当前的问题表述——询问他们目前如何看待这个问题
2. 深入了解受阻时刻——帮助他们描述用户感到无从下手的具体情境
3. 区分问题与解决方案——确认他们没有把想要的功能与根本需求混为一谈
4. 验证问题是否重要——帮助他们确认这个问题是否足够紧迫、普遍，值得解决

核心原则

将线下事物数字化还不够

Bret Taylor：“为什么要用这个，而不用《黄页》？它只是把已有的东西变成了数字版。”单纯将线下事物数字化往往会失败，因为它没有体现出在新平台上存在的内在理由。可以问：“客户为什么要花时间关注这个产品？”

通过原型明确问题

Jake Knapp + John Zeratsky：“摆脱困境，把你们一直在讨论的一些抽象想法或概念转化为一个具体的原型，让人可以查看并试着操作。”从抽象概念转向具体原型，是定义并解决问题的最快方式。

避免追逐新奇事物的陷阱

Marily Nika：“有一种陷阱叫追逐新奇事物的陷阱，我总是告诉大家：‘嘿，不要为了做 AI 而做 AI。确保确实存在一个问题。’”确保 AI（或任何新技术）是用于解决具体且经过验证的用户痛点，而不是为了使用技术而使用。

需求源自受阻时刻

Bob Moesta：“受阻时刻会催生需求。你会发现，在某些情况下，这种受阻时刻确实存在，而且可能长期存在，却始终没人解决。”需求源自用户生活中的某个具体“受阻时刻”，而不是产品本身。研究让用户的行为显得合理的情境。

从一开始就看清终点

Ryan Singer：“如果我们无法从一开始就看清终点，就不会启动任何项目。我们不会先提出一个宏大的概念，然后再问‘这个东西的工作量估计是多少？’”在投入资源之前，确保团队能够想象功能完成后的样子。不要从模糊的概念开始。

客户购买的是解决方案

Marty Cagan：“人们不会购买问题，他们购买的是你的解决方案。显然，如果解决方案无法解决他们关心的问题，他们就不会购买，但有许多产品确实解决了他们关心的问题。”理解问题是必要的，但竞争优势取决于解决方案的质量。如果问题已经明确，就不要过度纠结于验证问题。

在问题上花更多时间

Christopher Lochhead：“花在问题上的时间要多于花在解决方案上的时间。”深入理解客户视角下的问题，比内部进行产品构思更有价值。倾听他们的看法，而不只是推销你的解决方案。

明确问题的类型

Christopher Miller：“我不确定我们是否会在没有限定词的情况下讨论问题。我们谈的是业务问题，还是客户问题？”有效定义问题需要区分业务需求和客户痛点，以避免制定出“对客户不友好”的解决方案。

帮助用户思考的问题

• “用户遇到这个问题之前在做什么？他们想要完成什么？”
• “为什么这个问题至今还没有解决？难点在哪里？”
• “这是业务问题还是客户问题？两者是一回事吗？”
• “如果你能完美地解决这个问题，用户的生活会有什么不同？”
• “你能描述一个具体的人在某个具体时刻遇到这个问题的情形吗？”
• “如今人们会采取什么方法来绕过这个问题？”

需要指出的常见错误

• 解决方案优先思维——先提出功能创意，再反向寻找理由为其辩护
• 技术优先思维——想使用 AI、区块链等技术，再寻找可应用这些技术的问题
• 抽象的问题陈述——将问题定义得过于宽泛，以至于无法指向任何具体的解决方案
• 混淆业务问题和客户问题——只关注内部指标，却没有解决用户需求
• 跳过困难时刻——不了解痛点出现时的具体情境

深入了解

要查看 91 位嘉宾分享的全部 123 条见解，请参阅 references/guest-insights.md

相关技能

• 定位与信息传达
• 路线图优先级排序
• 界定范围与删减
• 产品品味与直觉