优界网

首页 > 产品经理 > 产品经理的取舍之道与抽象能力

产品经理的取舍之道与抽象能力

61

0

0

2016-09-24 00:09:18

破茧~~

分享一下,又不会怀孕!

本作品为转载作品,版权为作品原作者所有,感谢上传者的分享!

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

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

1. 取舍之道

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

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

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

要点:

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

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

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

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

屏幕快照 2014-06-13 下午8.55.51

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

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

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

2. 抽象能力

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

概念图1

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

  本文作者?heidixie

已有0人赞过

+1赞

认真评论的都成大咖了

还可输入1000个字

我要评论 我要评论
  • 刚刚
  • 登录优界网 ×