为什么不能直接给方案？
你有病啊？你有药啊？
现状挑战
思考日常工作场景，产品经理负责承接不同来源的需求，进行需求分析并产出方案，传递给研发团队并跟进实现。上线后可能收到来自客户的各种反馈：
“做的完全不是我想要的！”
“嗯……也行吧，感觉不是很理想。”
“先这样用，后面肯定得再改进。”
“……”面对不同用户不同程度的不满意，产品经理挠头，问题到底出在哪儿了呢？
问题分析
当用户描述对产品的反馈，它可能长成下面的样子：
“APP不好用，再也不用了。”
“为什么下载销售报表这么慢，看报表的人时间很宝贵啊！”
“商品添加后无法删除，需要加一个删除商品的判断逻辑，A类品可删，B类品不可删。”
“用户不知道我们的产品，得想办法让用户知道并愿意下载，需要设计一些市场活动来获客。”这些反馈或直接或间接的表达了用户对产品的诉求，可能是表达情绪，或描述现状问题，或直接给了方案建议，也可能同时包含了这几种。
针对这几种不同的需求表达，我们需要进行不同的处理：
当收到的是情绪或现状问题的描述时，我们需要分析情绪产生的根源，挖掘现状问题背后的真正原因。在这个阶段多维度的倾听是很重要的，不仅倾听内容，也要倾听情绪，同时分析对方急需响应的是情绪还是问题。当用户向你抱怨“APP不好用，再也不用了”，这是一个非常强烈的情绪表达，如果在当时的场景中，可能抱持对方的情绪第一重要，需要先“懂我”，然后才能解决“我”的问题和困惑。
分析和挖掘用户的痛点之所以艰难，在于缺乏足够的信息和同理心。当信息不足时，无法判断痛点和问题的真正原因，如果有较强的同理心，可能基于对用户的同理进行合理的推断。而当信息和同理心均匮乏时，就容易沉溺于假想的“自嗨”中，做出用户不想要的产品。
当我们收到的是解决方案时，同样需要回到方案背后的痛点和现状中去，在真实的用户场景中去思考如何提供价值。当用户或客户直接让我们增加或修改业务功能，如“下载报表太慢，需要改善生成报表的性能”，先不忙做下载报表的性能调优，可以深挖一下用户下载报表的使用场景：
- 哪些角色会下载报表？
- 这样的角色现有多少人？
- 在什么情况下会查看和下载报表，时间规律是什么？
- 用户查看报表的目的是什么？后续动作是什么？
- 一定要查看实时报表吗？能否在指定时间发送报表给用户？
- 用户最关心报表中的什么内容？
- 哪些数据用户不关心？
- ……
在挖掘用户的使用场景后，我们找到了更多提供价值的可能性。需牢记用户要的是价值不是方案，只要价值不发生偏离，方案大概率是没问题的。而实现价值的方案不止一种，抽离出既有方案的视角才有可能找到用户最满意的方案。
为什么不能直接给方案？
基于我们对产品需求工作现状的理解和在大量客户现场的观察，发现直接给方案可能产生以下问题：
- 缺乏对用户的深入理解，问题定义错了，进而找错了需求的价值点（不正确）
- 缺乏对需求场景的分析，虽然价值点找对了，但提供的方案不是最优方案（不经济）
- 缺乏在全流程中的多次验证，价值点发生了变化却无从得知和响应（返工，不高效）
- 缺乏深入交流和思考，错失了进一步的机会或其他更多的可能性（不持续）
为了避免浪费产品精力、错失良好的时机，我们推荐的核心思路如下：
- 获取上下文：行业背景、既有方案、组织内部上下等
- 清晰定义问题：定义正确的问题是提供正确方案的基础
- 提炼价值点并验证：从问题触发思考价值点，并进行验证
- 设计方案并验证：从价值出发，以经济高效的思路提供方案，并进行验证
- 进入交付后：时刻保持对价值变更的敏感度
一句话总结：为什么不能直接给方案？因为我们追求做正确的事和正确地做事，必须在做事之前、做事过程中时刻确保价值方向是正确的，时刻确保我们在高效地进行价值交付。