前几天在产品大群里发起讨论，如果只说一个能力，对于产品经理来说，什么能力最重要?
大家讨论得很激烈，有说学习力，有说需求分析能力，有说自我驱动，但提到的最多的是，解决问题的能力。
我也比较赞同这个答案。
一、敢于拿结果
好的产品经理，应该具备拿到好结果的能力，通过解决一个又一个的问题，攻克一个个难关，带领团队取得不错的成绩。
而要拿到好的结果，还有几个过程指标非常重要。
第一是业务洞察能力，第二是系统设计能力。
如果把拿结果当做建高楼，那业务洞察就是建高楼前的方案调研，只有通过详细的调研，才知道将来高楼要建成什么样，高楼的主人的喜好是什么，未来的用途是什么，周边的环境未来的开发节奏是什么。
调研得差不多了之后，才是进行系统设计。这个高楼要建多高，那地基就要考虑相应打多深。
附近会不会有地震，是否需要提前预埋防震装置...
业务洞察能力和系统设计能力缺一不可，而且顺序不能颠倒。
有些人非常迷信业务洞察能力，挖掘了非常多的需求，来一个做一个，需求堆积如山，但是产品经理没有减负，开发也没有减负，因为产品方案的复用性不强，和业务耦合的很深入，每次业务变动就摇摇欲坠。
所以，经常有一个口号，业务需求要尽可能具象化，但是产品方案要尽可能抽象化，做到举一反三，以不变应万变。
还有人非常迷信产品架构的设计能力，反正业务就得听我们的，产品架构就是这样，听我们准没错。
系统的核心使命是要带来业务价值，而且产品架构也是基于一定范围的业务诉求而设定的。
看看写字楼的地基和普通住宅的地基，一定不一样，但我们不能直接把写字楼的地基直接搬到建住宅上，因为地基上面建高楼的很多方式不一样，直接套用可能还会使得楼房产生危险。
二、怎么做好业务洞察?
产品经理业务的敏感度太重要了，都说产品经理是系统的父母，如果对自己的孩子不够了解，那做出来的产品就容易营养不良。
那怎么做好业务洞察?
换位思考，把自己变成业务，从第三方视角是去看问题。
洞察业务痛点，业务的过程中到底遇到了什么问题，这个问题的本质是什么，为什么会导致这个问题，是业务流程有问题，规章制度有问题，还是组织架构问题...
业务洞察不是业务说什么就是什么，而是深入到场景当中去，洞察问题的本质。
这个过程一般会输出用户调研报告，作用到的方式有访谈、问卷、观察。
三、怎么做好产品设计?
在业务调研清楚之后，接着就需要输出产品设计方案。
一般我们会把业务流程图，转化为系统流程图，从业务角色视角转化为系统模块视角，各个业务流转如何转化为系统模块之间的流转。
模块与模块之间的边界是什么，如何保证系统之间的架构清晰，不过多的耦合。
最核心的目的，就是要使得后续随着业务的发展，多个单一模块可以快速拼接起来，其他系统模块的改动，不会过多影响到其他系统，或者不会带来大的改动。
这一方面，往往还和系统架构强相关。
这个过程，一般会输出系统流程图，产品架构图，系统架构图。
