原创 shaonan 2024-03-01 14:00 浙江
当我们被一个想法击中时，往往先看清楚的是解决方案，也是花费精力最多的地方；但多数产品都失败了，不是没有方案，而是没有定义好问题。
许多做产品的人都会忽略一个事实，许多时候自己设计产品功能的原因，不是为了解决某个问题，而是为了实现某个自己思考良久的解决方案。
比如有不少用户提到过想要语音输入，所以前些日子就在研究 Open AI 的 Whisper 语音转文字的模型，一直在思考如何才能找到体积和准确率的平衡点，让 flomo 的语音转文字功能更好用。
但沉迷了一阵之后跳出来看，到底这些用户遇到的问题是什么？为何非要用语音输入？一般语音输入时长是多少？是自己的感想，还是某些重要谈话的记录？是希望做汇总，还是希望原封不动记录？除此以外，他们的问题现有解决方案满足的如何？是大多数人都没有得到满足，还是少数高级用户无法得到满足？
想到这里就冷静了下来，因为在技术之外，还有太多问题没有回答。而虽然自己是「产品经理」，但也会陷入「产品爱好者」的思维方式 —— 沉迷于寻找或者设计新的解决方案，毕竟能用最新的技术武装自己的产品，EGO 必然会得到极大的满足。
问题是别人的，而方案是自己的。我们天然就会对自己创造的东西投入更多的注意力。
当然这么粗糙地归纳为人性是智力上的偷懒，受到 Leanstack 的创始人 Ash Maurya[1]文章的启发，想了想可能还有这些方面的原因：
•用户要求你增加更多功能，虽然他们未必用的到；•解决方案更具体可操（抄）作，产出明确；而问题往往模糊不清，想要得到明确结果很难；
用户反馈多是解决方案
前些日子 flomo 的客服同学感慨，为何无论是 flomo 还是幕布，大家的需求都是希望添加表格、Markdown、图文混排，而终极目标都是希望这两个产品变成一个 OneNote。
其实这不怪用户，因为他们并不擅长解决方案，所以就会复述自己曾经看到过的解决方案，希望能以此解决自己的问题。如果直接去思考和实现这些方案，那么最终产品将会变成一个臃肿的怪物。
所以核心不是探讨解决方案的优劣，而是思考他们的问题到底是什么。
比如许多用户会反馈，希望 flomo 左上角的热力图可以拖动，或者改成日历的形式，但实际上他们的问题是无法搜索某个过去记录的 MEMO。所以解决方案应该是优化搜索功能，使其可以根据日期搜索即可。
又比如许多用户会希望能够共享 flomo 的某个标签，这样能够相互订阅。但实际上他们的需求是寻找到某种优质的内容。所以解决方案不是改造 flomo，而是通过小报童来改变内容生产的激励模式，以此来创造出更多优质的内容。
但这不是说用户反馈都不要听，而是要通过解决方案挖掘他的问题和所处环境。比如一个用户反馈 flomo 对长文支持不友好，不如 OneNote 那样可以图文混排，希望能支持。
如果我们敏感一些，这个解决方案，其实给了许多问题的线索：
•用户没有理解 flomo 的定位，很可能在新人引导，功能介绍上出了问题；也可能是在某些推广渠道对外传达定位不清晰。•用户日常对 OneNote 并不满意，否则不会想迁移习惯到 flomo（后续调研对方是说同步慢，且移动端不方便）；
当往下挖一挖用户反馈的解决方案之后，就能看到更加明确且具体的问题。
方案产出明确，而问题很难定义
当我们被一个想法击中时，往往先看清楚的是解决方案，也是花费精力最多的地方；但多数产品都失败了，不是没有方案，而是没有定义好问题。
比如我曾经设计过一个电话急诊功能，其解决方案类似滴滴打车，即用户发起请求后，将会根据病情匹配科室，然后进行广播看哪位医生有空接诊。相较于传统的先选医生，然后进行图文咨询比，主打的就是一个快。
回头来看这个功能，当时算是对解决方案的迷恋，想试试滴滴打车的派单制模式，在互联网医疗中是否能行得通。但实际上这个解决方案非常鸡肋，让我们转换视角到患者的需求来看：
•大多数患者都会默认选择去医院看病，除了少数的诸如儿科（更多是咨询而非疾病）、皮肤科（看一眼就知道问题，误诊率低且影响小）、妇科、男科、精神心理科（隐私问题）。所以市场规模本身就不大。•而如果患者着急解决问题，那么肯定会打车去医院，而不会选择电话急诊；即使是选择电话急诊，也希望是结果可控，比如什么医院的什么医生，而不是撞大运。
所以不是这个功能设计的不好，而是根本没有定义清楚问题是什么，就盲目从别的产品/服务中照搬模式 —— 这其实在许多公司也存在，因为去「定义问题」很难且没有成果，倒不如从一个方案跳到另一个方案，至少能保证工作量和有开发成果证明。
如何定义问题，这个恐怕一本书都讲不完，但这里可以先给自己设下一个钩子：一旦觉得别的产品中有个某个功能/服务不错，那么一定要提醒自己，不要去分析他的实现方式，而是去思考他到底解决了用户什么问题。
开头能「跳出」迷恋语音输入的解决方案，就是多亏了这个钩子。
小结
如德鲁克所言，企业真正的工作是创造客户，而非完善某种解决方案。
客户本身是被服务/产品的产出或者结果所驱动。所以重要的是研究他们想要完成什么工作，以及现在是如何完成的，以及评估他们现在用这套解决方案，能否充分完成他们的工作。
Leanstack 的创始人 Ash Maurya 关于这个问题，做过一个很赞的比喻：
从解决方案开始，就像是先造一把钥匙，却不知道它能打开什么门。虽然可以在很多门上测试你的钥匙，但是那会消耗特别多的精力。如果你爱上问题而不是解决方案时，你就会为了某扇确定的门来打造钥匙。
爱上大多数人的问题，而非自己的解决方案。
References
[1] Ash Maurya：https://blog.leanstack.com/author/ashmaurya/
[2] Love the Problem, Not Your Solution：https://blog.leanstack.com/love-the-problem-not-your-solution/
