想做的事情很多，但是要结合现实(资源和能力)，但是这可能还不够，还要考虑竞争者，是不是你要做的事情别人更有优势，是不是他们很容易超越你，这些因素都要考虑进去，最终得到能做且能做好的事情，目标明确。但是这取舍还不够，接下来进行时间的取舍，也即所谓的轻重缓急，什么事情是现在不做不行的，什么事情是可以放放的。

按照半年一个周期的话，会把前面几个月作为重点突破，先交付出可供试点或内测的版本，此时注重的是商业模式的清晰，定位的清晰，之后稳打基础，做一些重的事情，第三个阶段加强运营和体验优化。

最近看到另外一句话，分享给大家：think big, start small, do smart.

2. 抽象能力

记得当时刚转岗做产品经理的时候，去给一个大神级的人物汇报产品方案，该神人动辄提到：抽象化，不要听太具象的，就是让我讲一些抽象的概念。

当时不理解，你们扯来扯去不就是最终要看产品原型吗?现在原型都有了，还要抽象干嘛?

在后续的工作中，即使没有人再耳提面命，自身也体悟到抽象思维的重要性。难怪有人常说：把事情想复杂了，很容易，但是把复杂的事情想简单了，是个更需要功力的活。

把事情想太简单或者太复杂，可能都不够有功力，真正的高手就是要把简单的事情先复杂化(全面、周全、系统)，然后——抽丝剥茧，再把复杂回归到简单。

从简单到复杂，体现的是系统化，全面性。

从复杂到简单，则更多要进行抽象化思考。

抽象就是从表面看到本质，从片面看到整体，然后抽出那些稳定的、共同的特征。

平时我们会考虑代码的复用性，组件的复用性，同一个功能对不同场景的复用性，有了复用的能力，就能够用更少的开发去满足更多场景的同类需求问题。考虑复用性或者便捷的拓展性，是产品经理必须要考虑的。

其一，我们的产品要满足的是一个需求类别而不是具体的某个需求。从而能够从一个具体的需求，看到一类的需求，看到衍生的相关的需求，甚至再对需求进行分类，看到更高层面的需求。进而才能够系统性解决同类的需求而不是就事论事点对点解决问题。

其二，产品经理要考虑投入产出比，让最小的投入取得最大的效益，所以每次的投入都要试图解决一类问题，或者多个类的相关问题，不能够处理具体案例就了事了。

有开发背景的产品经理对比设计出身的产品经理而言，抽象能力普遍要好一些，因为开发的一些专业课已经对此进行过系统训练，比如UML,比如系统架构。

而设计出身的产品经理，原本的优势恰恰在于将抽象的思维具体化，让更多人明白到底是讲的什么，毕竟面向用户，是无法抽象化的。而恰恰是这个优势，凸显出了一个思维上的不足，那么就是抽象化能力上的略微欠缺。当然，我们可以能够更加擅长使用概念图(concept map),以及讲故事(story talking)将思维具体表达出来。在讲故事或者图像化的时候，也是一种对具体案例进行抽象归类的提炼。

我对于想要提升抽象能力的人，经常建议：画图吧，讲不清楚画图吧。但是，我强调的画图，万万不是线框图，ps视觉图。这种图反而顿时从抽象到具象了，这图一定是架构图或概念图。

前天，还和一个开发讨论某个产品的架构，我对着密密麻麻的文字说：你画个架构图出来看看吧。该同学说：有图确实会直观些，但是画图会比写这些文字多好几倍的精力。

我说，图不是单纯为了直观，画图本身是一种理解、提炼、加工、组织的非常好的思维过程。图本身可体现：次序、轻重、层次、关系……这些多维的信息，单纯通过语言的描述，很容易避重就轻，讲到云里雾里，讲的人和听的人都不自知，其实通过图则直接了当地可表达出来这些多维信息。画图过程本身就是一个抽象思考的过程。

大道至简，只所以到最后简了，正是因为抽象。

PS: 平时多看看一些concept map 图，有助于提升抽象能力，最近google不好用，换bing来学习学习

注：概念图(concept map)是一种用节点代表概念，连线表示概念间关系的图示法。概念图的理论基础是Ausubel的学习理论。知识的构建是通过已有的概念对事物的观察和认识开始的。学习就是建立一个概念网络，不断地向网络增添新内容。为了使学习有意义，学习者个体必须把新知识和学过的概念联系起来。Ausubel的先行组织者主张用一幅大的图画，首先呈现最笼统的概念，然后逐渐展现细节和具体的东西——百度百科

　　关于这块，本人还需长远修炼。

　　本文作者 heidixie