最近在开需求评审会的时候，发现自己又犯了一个很初级的错误，又对着解决方案和需求方PK起来，PK了几个回合之后，才回过神来问清楚为啥希望产品这么做。需求方解释是因为要解决一个业务上的问题，所以需要产品实现一个怎样的效果。
注意这个场景，想要实现的效果不是需求，是需求方以为的解决方案，而这个解决方案只是众多解决方案中的一个，未必是最好的。
所以出现了需求评审会上的一幕，各方对着需求方以为的“需求”，实际是解决方案进行PK。
当真正的问题被定位之后，有另外一种更合理、成本更低的方案可以解决问题，所以愉快的结束了。
之所以想起来说道这个事情，发现这个坑真的很容易踩，特别是企业服务领域，客户首先遇到了一个问题，对着问题天然地就会想解决方案，然后就会给对接的销售、CSM 提需求，需要一个XXX的功能。
经验不深的对接人员，很可能就照搬一个需求过来提到评审部门，多数情况下这个需求是有问题的，然后各方对着一个不合理的需求开始battle，然后越讨论越远，各方都留下了不好的印象，“产品经理没有同理心”，“销售接的都啥是需求”等等。
要区分什么是需求，什么是方案。需求是面对问题，方案是解决问题的一种方式。
从抽象意义上说，准确定位问题比解决问题重要100倍。
我们遇到问题，下意识地就会去想解决方案，但此时想到的解决方案，往往是“现象解”，只能解决面上的问题，如果问题定位不准确，得出的方案自然就是治标不治本。
更加值得警惕的，其实是我们很多预设的解决方案是不是真的是最优解，例如开车被加塞就路怒、想要多赚钱就加班996，评审会有有不同意见就怼回去，工作压力大下班就熬夜玩手机释放自己等等，这些下意识的解决方案都是应激型的，都不是最合理的方案，真正有价值的是背后的问题，但是多数时候我们不加思考的就沿着预设的解决方案往前走。
最有价值的应该是思考真正的问题是什么，有哪些解决方案，分别有哪些优缺点，应该选择什么方案。
而不是下意识就选择了一个方案，然后在一个局限的方案里辗转腾挪，怎么解决这个方案中遇到的问题。
永远记得，面对问题思考方案，而不是面对方案思考问题。