虽然角度不同，但是试着回答一下。
记得当时刚做产品经理的时候，去给一个大神级的人物汇报产品方案，该神人动辄提到：抽象化，不要听太具象的，就是让我讲一些抽象的概念。
当时不理解，你们扯来扯去不就是最终要看产品原型吗？现在原型都有了，还要抽象干嘛？
在后续的工作中，即使没有人再耳提面命，自身也体悟到抽象思维的重要性。难怪有人常说：把事情想复杂了，很容易，但是把复杂的事情想简单了，是个更需要功力的活。
把事情想太简单或者太复杂，可能都不够有功力，真正的高手就是要把简单的事情先复杂化（全面、周全、系统），然后——抽丝剥茧，再把复杂回归到简单。
从简单到复杂，体现的是系统化，全面性。
从复杂到简单，则更多要进行抽象化思考。
抽象就是从表面看到本质，从片面看到整体，然后抽出那些稳定的、共同的特征。
平时我们会考虑代码的复用性，组件的复用性，同一个功能对不同场景的复用性，有了复用的能力，就能够用更少的开发去满足更多场景的同类需求问题。考虑复用性或者便捷的拓展性，是产品经理必须要考虑的。
其一，我们的产品要满足的是一个需求类别而不是具体的某个需求。从而能够从一个具体的需求，看到一类的需求，看到衍生的相关的需求，甚至再对需求进行分类，看到更高层面的需求。进而才能够系统性解决同类的需求而不是就事论事点对点解决问题。
其二，产品经理要考虑投入产出比，让最小的投入取得最大的效益，所以每次的投入都要试图解决一类问题，或者多个类的相关问题，不能够处理具体案例就了事了。
有开发背景的产品经理对比设计出身的产品经理而言，抽象能力普遍要好一些，因为开发的一些专业课已经对此进行过系统训练，比如UML,比如系统架构。
而设计出身的产品经理，原本的优势恰恰在于将抽象的思维具体化，让更多人明白到底是讲的什么，毕竟面向用户，是无法抽象化的。而恰恰是这个优势，凸显出了一个思维上的不足，那么就是抽象化能力上的略微欠缺。当然，我们可以能够更加擅长使用概念图（concept map）,以及讲故事（story talking）将思维具体表达出来。在讲故事或者图像化的时候，也是一种对具体案例进行抽象归类的提炼。
我对于想要提升抽象能力的人，经常建议：画图吧，讲不清楚画图吧。但是，我强调的画图，万万不是线框图，ps视觉图。这种图反而顿时从抽象到具象了，这图一定是架构图或概念图。
前天，还和一个开发讨论某个产品的架构，我对着密密麻麻的文字说：你画个架构图出来看看吧。该同学说：有图确实会直观些，但是画图会比写这些文字多好几倍的精力。
我说，图不是单纯为了直观，画图本身是一种理解、提炼、加工、组织的非常好的思维过程。图本身可体现：次序、轻重、层次、关系……这些多维的信息，单纯通过语言的描述，很容易避重就轻，讲到云里雾里，讲的人和听的人都不自知，其实通过图则直接了当地可表达出来这些多维信息。画图过程本身就是一个抽象思考的过程。
大道至简，只所以到最后简了，正是因为抽象。
