前言：打算写一些不成体系的小文章，因为即使不写在这里，也会写在我的evernote里，写在这里的好处更多，比如让一些鄙视我更新太慢的同学住嘴。还有，开放地进行讨论。不过要声明的一点是，过去我习惯写长篇大论，也由于追求完美，犯了拖延症（《拖延心理学》一书中，剖析拖延原因之一就是追求完美所以迟迟不做）。我的evernote里写了一半的文章，估计有20多篇了吧，有的仅仅是缺几张图而已，就一直拖。

所以，特地开辟了一个分类《杂思录》，专门放点这种偶尔的思考，不苛求完美，也期望在大家的交流中谋求进步。本来这个分类想命名为非请勿转的，可是觉得不妥，转与不转是人家的事，写与不写是自己的事，就还是关心自己的事吧。

1. 取舍之道

很多道理已经被古人讲完了，比如大道至简的一句话：好钢一定要用到刀刃上。

你可以说，那是因为钢不够多，如果够多，就不用这样了。这恰恰就是我们生存的环境——资源永远是有限的，时间、人、精力都是有限的。

把事情从简单想复杂——体现你的系统性，全局观，长远规划，但是要落地了就要把复杂再回归到简单，让开发、需求方很明确地知道如何开始“咬下第一口”。

要点：

1. 取舍之道，一定要建立再系统、全局之上。

2. 取舍之道，可按照用户群、功能、内容、体验多维展开，每个维度都可以取舍。

3. 舍是多样的：并不是绝对不做，而是分阶段去做，明确现在做什么，将来做什么，以及为什么这么划分。

下图是我喜欢用的取舍之道模型：

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

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

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

2. 抽象能力

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

建议继续学习：

1. 为什么现在那么多人应聘产品经理岗位？    (阅读：6932)
2. 给想转行做产品经理的同学    (阅读：5865)
3. 互联网产品经理必读书目    (阅读：4743)
4. 产品经理与研发经理的分工    (阅读：4274)
5. 行进在产品经理的路上    (阅读：4048)
6. 互联网产品经理，全方位入门，图书推荐    (阅读：3886)
7. 成长的财富，我做产品经理社区组织的这3年。    (阅读：3994)
8. 产品经理怎么和程序员打交道    (阅读：3818)
9. 产品经理3年沉淀和总结    (阅读：3645)
10. 如何做一个干货且装逼的产品经理演讲？    (阅读：3578)