做产品的时候，我记得很多书上都讲过一个典型的场景：用户描述需求时说：我要一匹更快的马。 不同的产品经理可能提炼出来的需求不一样，理解也有深浅，比如用户确实需要一匹更快的马，需求就是： “给用户弄一匹更快的马”。
深入一点思考，另一种理解就是“用户为什么需要一匹更快的马？是目前的马不能满足用户的需求了吗？用户时间紧宝贵？”，需求就是： 用户需要更快的交通工具，来达到节省时间的目的。 这里不是说「给用户弄一匹更快的马」是一个伪需求，而是这个需求并非用户核心需求的本质；用户只是在描述需求的时候，提出了他认为合适的解决方案。 而正是用户在「描述需求时提出了解决方案」，从而掩盖了真实的需求。
通常产品经理在为解决某个问题，提取需求时，首先要问几个问题：
（1）这个问题的本质是什么
（2）这个问题解决之后可以带来哪些价值
（3）最适合当前产品形态的产品设计是什么
（4）这个产品形态设计的解决方案会不会引入新的问题 很多程序员转产品经理之后会遇到的同一个问题： 当用户在描述问题或需求时，第一想的不是产品（这是什么、有何价值、怎么做），而是直接跨到“怎么做” 这个环节，也就是解决方案。
基本上想到解决方案这个层次的，会继续往下想很多，就差代码怎么实现了，比方说 “啊，内容太多了，就像订阅号一样，把内容分门别类折叠起来，用户自己去订阅，更新文章时增加小红点。” 这是很要命的产品思维模式，越俎代庖帮工程师想了他们应该想的问题不说，这样的思维模式会阻碍产品经理认真、全面思考产品功能的价值，和如何进行合理的产品设计。 产品经理应该关注的是产品的用户价值、设计合理性以及设计的可持续性，而不是把「解决方案」当「真实需求」。一旦无法判断用户需求的真伪时，多回到问题的场景中，多问用户开放性的问题，适当时可以利用「低成本试错」的方式来快速验证（比如常说的灰度测试，AB Test），从而达到「去伪求真」的目的。 当然，身为产品，别怕被别人笑你的需求是伪需求，错了就抬头接受批评。选择了产品经理这条路，谁没提过几次伪需求？
我记得上几周和技术经理讨论关于某一个产品的添加appname的场景时，技术经理反馈，客户需要一个域名下面支持多个appname，其实从客户的描述中我获取到这是一个解决方案，如果我们按照这样的解决方案做下去，发现这虽然可能解决他的问题，但是对产品的扩展性都是不利的。其实客户的需求应该是“我要在你们产品中使用多个appname”，至于是否放在一个域名下，其实客户是根本不关心，也就说客户根本不关心你后端程序是如何实现。
再举个例子，用户提一个需求：他想要一个馒头，其实他的需求本质是“他现在很饿”，我们可以提供馒头、面包、水等一系列的解决他饥饿的问题，发现问题往往比解决一个问题更加重要。抓到事情的本质，比低着头走更容易到达目标。
在2022年，记得在2018年的时候在奇虎工作时做直播时提到 客户需要appname 的需求；在昨天发生了一个类似的事情；
事情描述是这样的，某一家运维公司给我们的交付同学提了个“需求”，要对某个域名配置一个缓存周期，然后我们的交付同学按照正常去接收到了客户需求-配置某个目录缓存为“30天”，强制缓存，也很认真的做好了这件事情；
但后来触发了一些奇怪的问题，例如缓存降级被强制缓存，再后来客户要查看一下命中率…………等一系列反复的问题；
其实这个属于典型的把客户的解决方案当做诉求：
我们深入分析一下，做信息挖掘：
- 客户真的是要强制配置缓存30天这个“需求”吗？----在我看来这个动作更像是一个解决方案；
- 客户为什么要看一下命中率？ ---- 潜在的背后原因是什么？
经过我们分析发现：其实客观担心命中率比较低，所以提出来了要查看命中率数据、配置强制30天的缓存，
我们和客户沟通：
- 经过程序计算给予最大的缓存周期，尽可能大，最大是1年；
- 2.告知客户当前的命中率在 程序控制下是多少，让客户放心这样配置历史上是没问题的；
- 按照1的配置也可以解决缓存降级无法被联动的问题；
- 告知客户，我们计划将在什么时候上线自助查看命中率的问题，满足避免人性上的担忧；
- 告知客户，我们会帮忙验证一下统一告知客户 可以测试的是时间节点，而避免反复的重复沟通，让客户降低信任；
如上，通过我们分析，可以避免将客户的解决方案当做原始需求，而是挖掘客户想要解决的问题，进而演进通过客户配置是否真正解决了客户问题；
详细参考可以看我之前写的文档：
产品经理从诉求-到需求的思考过程；
文章评论