什么是产品经理 1.0

24 评论 47738 浏览 450 收藏 31 分钟

这篇《什么是产品经理》,将会像一个App一样,不断迭代。不断拷问产品人将要面对的永恒问题,在每个版本中修改Bug,整理需求,增加新功能,测试……甚至重构数据结构。

今年是我个人十分动荡的一年。2月以来就再没专注地写过产品文章。刚工作的时候,许多人跟我讲,产品经理最重要的能力都要在工作实践中习得。后来工作了快两年,又有人跟我讲,产品经理最重要的能力都在工作之外,让我回归生活。

最后,所有跟“为什么”沾边的问题,都又要重新回到哲学的层面。至于“为什么做产品经理”的问题,只有每个人自己才能回答。这次,我们聊聊什么是产品经理。

这篇是曾经拖稿一个月的文章。源自八月我在团队内部做的一次破冰分享。我想,任何一份工作,我们真正去做之前,最重要的不是沟通,不是方法论,也不是快速适应工作环境,而是,我们如何定义自己的工作?

如果一个人不能清晰的定义自己的工作,唯一可以肯定的是,在具体执行的过程中会遇到相当多来源于自身的阻力。这一点,我相信大家不管曾经是否听过,都能认同其重要性。当然,在定义自己的工作之前,可能我们还要定义我们自己。所以这段时间也总在思考许多哲学上的问题,探寻许多事物的本质。

海德格尔曾说:

哲学不能引起世界现状的任何直接变化。而且凡是人的思想和图谋都不能做到。

而就是这些“思想和图谋”,最终左右了我们的行动,让这个世界变化的,也来自于我们的行动。

一年多前,我曾写过“你为什么做产品经理”。我说:

人本身就是产品,身体是硬件,思想是软件。

如今再回头看,又发现每个人的操作系统中,也有前端和后端程序的不同。就像后端程序,早已在系统底层写好,无需用户的直接指令,自动执行。我们的许多行为,也受这些“后台程序”的影响,潜移默化的被每个人的自我所改变,迭代。

所以,这篇《什么是产品经理》,将会像一个App一样,不断迭代。不断拷问产品人将要面对的永恒问题,在每个版本中修改Bug,整理需求,增加新功能,测试……甚至重构数据结构。

对于永远追求“实用价值”的人来说,可能这个系列的文章并不适合你。我可以肯定地说,这些文章并不能帮助人们找到一份PM的工作,也不能帮助已经工作的产品汪们解决某些实际问题。如果非要说价值的话,可能在我们理解“产品经理”的本质,我们从何处而来?又将走向哪儿去?这些类似的问题上,带来一些思路或启发。

what_is_a_product_manager

也只有产品经理会用韦恩图来定义他们自己了。

Martin Eriksson 用这张图很直观的向我们概括了产品经理在工作中的一种常态,即站在用户体验,技术,商业中间的那个角色。换句话说,我们是在三明治中间的那一块,需要面对向上和向下的细致沟通,同时又要在中间进行面向过程的管理和协调。

What is UX,Technology and Business?

如果从上图的角度出发,我们则需要先定义这三个概念以及三者之间的关系。

 User Experience

如今用户体验是许多人挂在嘴边的名词。却鲜有人知,这个词是人们对某项服务的一个相对的、主观的、片面的认知描述。我们首先需要重新认识的一件事是:用户体验面向的主体,不是某个产品、App、网站,或是设备等人们直接接触的实体,而是我们对用户提供的某项服务。

当我们着眼于服务的同时,意味着我们思考问题的目标和方向,将不仅限于某个App页面之间的跳转逻辑,界面的框架和布局,或是某道菜好不好吃,某个物件好不好用等等,更要从全局思考这项服务的整体流程。

之所以说 UE 是相对的、主观的、片面的描述,原因也在此。举个例子,当你去一家餐厅吃饭的时候,菜品能不能吃,好不好吃是餐厅所提供服务的核心,但当朋友们问起这次吃饭的体验如何时,你头脑中浮现的绝不仅是菜品的味道,可能包括的还有,这家餐厅的门面,店面内的布置,桌椅摆放,服务人员的态度、响应时间,菜单设计,看单点单流程,上菜的时间和顺序,其他客人的用餐状态,以及买单和离开时的服务等一系列的体验,构成了你对朋友的回答:好,或不好。

这一系列影响 UE 的因素,都存在于用户脑中,而不仅只在我们作为餐厅运营和管理者的脑中。作为一个产品经理,你如何定义这项服务中的每个关键因素,并围绕着关键点提升 UE ,就体现了你在这方面的专业素养。

Technology

产品经理用不用懂技术?真可以说是我在所有相关社区里遇到的最多的问题。直到现在都没想到过一个严谨的回答,只能分享一些我的个人经历。

There’s no point defining what to build if you don’t know how it will get built.

我大学的专业是“信息管理与信息系统”。这个专业早在上世纪90年代就被引进了中国高校的教育体系中,并作为管理科学与工程中的一个重要分支,为国内的信息产业发展打下了基础,给用友、金蝶、东软等国内一些老牌的企业服务公司输送了大量人才。

我们的课程都包括什么呢?除了正常的大学公共课程,在专业上包括计算机组成原理与体系结构、计算机网络、C++程序设计、软件工程、信息检索、信息安全、管理信息系统、企业信息资源管理、操作系统原理及应用、数据结构、以及数据库原理等等。

这些课程,在我高考结束后的几天中就已经搜到了,第一感觉就是,WTF这都是些什么东西?学完大部分课程之后,我的感觉还是,这都是些什么东西?然后决定大学先不念了,出来看看这些东西到底是干嘛的。

后来的工作中,这些知识的确没有过多的应用上,但着实给了我不少的帮助。

其中最重要的帮助就是信任。

产品经理的工作中,几乎要与所有项目关系人沟通。所有角色中,与开发人员沟通所消耗的时间,毋庸置疑要占到前三位。

而信任与沟通的关系,如同水和人的关系。PM对计算机知识的了解程度和迭代频率,就像“水”的质量和流动性,了解的越多,越能帮助彼此理解双方的需求,互相认同。

如果你真想做好一款产品,先去搞懂它是怎么被做出来的再做方案吧。

Business

商业于产品经理而言,可能经常被放在“重要但不紧急”的象限中。在各大互联网公司的职级体系里,对商业的理解,也多被放在较高职业等级中。包括网络上关于产品经理的各种文章,商业相关的分享,一般描述的也更少,或定义不清晰。

为什么会这样?因为商业是个永远没有终极的东西。商业以资金的增长为目的,通过资本运作,以关系为依托,规避风险为准则。我相信能深刻理解这几点的人,大都在忙着做生意,也在用同样的规则来判断,是否要分享某些东西。

那么,我们如何提升自己在这方面的认知和能力?最直接有效的方法很简单,就是自己去做生意,在实践中习得。如果你也同样在这方面有困惑,推荐你去看李笑来老师的《通往财富自由之路》,他的观点,让我在个人的财富积累以及对资本的认知上有了很多的新的理解。

除此之外,我能想到的方法就只有从自己身上出发,把自己变成一个具有商业价值的人,让同样在商业上寻找机会的人能更方便的找到你,大家各取所需,也是种不错的方式。

回到工作中,大家经常说的可能不是商业这个词,而是业务,或者业务逻辑。即学会定义你当前所做的事情,在公司整体的业务中处在哪个分支,具有怎样的战略意义,能给公司带来怎样的收入,或可能带来的潜在价值。如果自己想不明白,去问问团队的Leader,如果觉得Leader的见解有局限,去问问CEO也是不错的选择。相信我,你的老板会很喜欢这样的员工,只看你准备的够不够充分。

产品经理管理的到底是什么?

我想这个问题不单是产品新人,也是每个从业者,在公司和产品不同发展阶段中,要经常捶问自己的问题。

自我管理

你管理的究竟是什么?

在管理外界事务之前,先要管理好的,是自己的能力。

p1

p2

p3

Copyright from BLUES

上图是腾讯PM职级体系中P1—P3的雷达图。当我们定义自己的工作内容时,看看别人如何定义也具有相当的价值。

腾讯的职级是从P1到P7,其中的各项能力可以分为:通用能力、专业知识、专业技能、组织影响力。各个阶段的成长中,也按不同的侧重点发展,最终则达到全满的状态。

我们可以先参考上面的能力模型,试着定位自己的位置,找到缺乏的点,在长期的工作中有意识的积累对应的知识和技能。

除自我管理之外,产品经理的工作至少涉及如下5个层面的管理:

需求

  • 需求
  • 需求
  • 需求

重要的事情说三遍。没了需求二字,所有事情也没了意义。

我们要明确的第一项需求,是一家公司对产品经理的需求,和你对公司的需求。这看似是句正确的废话,却是我们进入任何一家公司前最Base的决策依据。因为产品经理的确是一个即使公司没有这个岗位也能良好运转(至少短期来看)的角色。

你永远无法叫醒一个正在沉睡中的人。所以,在入职之前,朋友、HR、CEO,任何一个能帮你多了解公司业务的人都尽量多聊聊,如果都没有,可以试着作为一个用户,去体验某项业务的整个服务流程,来形成自己的判断。如果把公司招PM的需求比喻成坑,这坑大概分3种:

  1. 公司开辟新业务——挖坑
  2. 某块业务没人负责了——接着挖坑
  3. 业务做的不够好——换个人继续挖

既然到哪儿都有坑,先看看深浅,哪个适合自己的职业规划,再往里跳。

明确公司和PM的需求后,业务需求、产品需求、用户需求才接踵而至。

PM给企业带来的价值,直接体现在业务上。业务面向的主体很庞杂,可能是用户、客户、企业、合作伙伴,也可能是自己的团队。近几年吵得很热的 B2B , B2C , O2O 还有最近刚起来的 C2M 等模式,本质上描述的就是企业和其业务主体之间的关系,或不同业务主体之间的关系。如何满足你所负责业务上的多方需求,实现业务的增长,将成为你工作的核心。

业务、产品、用户三者的需求,是有机的整体,从来都不能割裂来看。满足产品和用户的需求,是业务增长的基础。从这个角度,我们给用户提供的不是产品,本质上还是服务。我们常说的产品功能,本质上是服务所具有的特性。

  1. 你的产品为用户提供了什么服务?
  2. 满足了用户的什么需求?
  3. 服务所具有的特性是否能在特定的场景下满足特定用户的特定需求?

这三个问题就是我们做产品时要不断问自己的永恒问题。

限制

能从Leader角度思考问题的人,未来才有可能成为Leader。优秀PM身上最让人渴求的能力,就是“MAKE THINGS RIGHT”的能力。一种谜一样的能力。

限制,孕育了这种能力。

不论工作还是生活,每个人无时无刻都活在各种限制之中。久而久之,多数人选择臣服于限制。而PM则是在限制里找突破口的角色。就像我们在画原型时,第一步,是在白纸上画一个框,接着是无尽的框。

对限制的管理,一定程度上也算是种融资。你的Leader,是你融资的对象。当你有了新的产品构想,想让它最后发生,必须要其他人的帮助。

  1. 你需要什么帮助?
  2. 如何获取这些帮助?
  3. 获取后又怎样在限定的时间和资源下完成?

这三个问题是管理限制时,PM要面对的永恒问题。

态度,勇敢,不怕冲突,是我觉得最能帮助我们解决这些问题的特质。

一个人的态度的确会影响别人,这跟职位是没有必然联系的。没有影响力的人,只能任由别人的态度影响自己。而在和 CEO 拍桌子,跟客户叫板上,我始终是不遗余力的。当然,没脑子的叫板不是勇敢,是鲁莽。世上没有两全其美的事,你要得到什么,就一定得放弃什么。要求别人也得放弃什么时,就会起冲突。

不怕冲突,是你对立场的坚定,而你的立场,体现了你的价值。所以,我们经常会在群里看到一些“老好人”抱怨:“做个XX怎么他妈这么难。”

沟通

沟通本身就是个永恒的话题。这里我们只谈工作中的沟通管理。

现在我问大家一个问题:

你现在的工作中需要沟通的对象有哪些?

先别急着回答,想三分钟再看。

看看我们的答案是否一致:

  • 与上级沟通;
  • 与用户沟通;
  • 与同事(开发、设计、运营等)沟通;
  • 与客户沟通;
  • 还有跨部门沟通。

这些分别对应着向上、向下、对内、对外、平行 5个维度的沟通。每一个展开说,都有许多技巧和例子。但今天想说的,不在这5个维度。

产品经理最重要的沟通,是和自己的沟通。先过自己这关。我的一位老师曾说,

一个人能拿出来的,就是他能做到最好的。

在沟通层面,也是如此,你说的每一句话都会定格在那一时刻。所以,永远不要说没经过准备的话

“准备”和“说”的过程,就是管理沟通的过程。包括至少三个要素:

  1. 明确沟通的目标
  2. 沟通所需的素材
  3. 就目标达成共识

沟通的目标,意味着一系列的行动,并最终达成一个明确的,双方可达成共识的结果。就像我们接到个新项目后,要将其复杂的需求分割成一个个小块,分发给每个能解决小块问题的人,在各个部分都解决后,再重新组合成一个复杂整体,以解决项目的需求。

在沟通中,所有的行动和结果都是双向的,简单讲就是:我知道你明确了XX,你也知道我明确了XX。XX就是你沟通的目标、行动和结果。

依然是,世界上没有两全其美的事。沟通时,对方的态度和意愿,对达成共识有着关键影响。虽然也有些事大家不得不做,但至少我们都占用了彼此的时间,就值得重视。对于任何你觉得沟通时可能会用到的素材,无一例外的都要准备,包括但不限于:历史典故,引用名言,过往的案例,共同的经历,合理的比喻、暗喻、演绎、推理等等。准备的越充分,沟通时越有自信,越容易让对方理解你的表达。

过去一年中,和我总监的撕逼是最让我挫败和成长的地方,我出的每一版产品构想,总能被合理地驳回返工,而且只要我说一句,总监那里至少十句话等着我辩论。这背后和年龄、工作年限并无必然联系,呈现的是一个人的知识积累,思维的深度和广度,逻辑的缜密程度以及对人心理的窥探。这种本事,读书做事都学不来,只能靠不断地沟通,思考,总结习得。

当然,很多时候沉默也是一种选择,但要适度。

我们所说的达成共识,就是消除类似的歧义,让双方在时间、地点、人物、事件上都互相明确。最直接有效的方法就是反馈。A表达完后需要B的反馈,B反馈后A也要给出回应,有疑问一定提出来,没有则要表达出“我知道你知道了”以示达成共识。

目标

起初构思整篇文章架构时,想把“目标”放在“沟通”前面来着,觉得不妥,又放在了后面。

不妥的原因是,当我们明确了需求和限制,争取到足够资源后,需要在沟通中做出妥协和平衡。因为这个目标不是你的,而是整个团队的。过程中一定是沟通确认,再沟通再确认,才能得出一个相对合理的,可行的,团队成员都认同的目标。

对目标的管理,就是对事件结果的管理。上面也提到,当我们接到新项目时,需要对其复杂的需求进行解构和重构,面向的是每一个执行中的细节,即每一件事,都要有结果。

  • 目标是结果而非过程
  • 目标是结果而非过程
  • 目标是结果而非过程

什么是结果?当一件事具有明确的开始和结束时间,以及是否合格的标准时,它最终才可能以结果的形式呈现。没有标准的事件始终只是过程,在工作中不具有现实意义。

(标准面向的是事件执行前、中、后的条件判定。其中有些是既定的规则或常识,无需过多强调,有的则是仍需要沟通确认,再沟通再确认的。)

决策

A fork in the road.

每个刚入行的产品经理,在最初做决策时面临的选择都很简单:To be or not to be.

随着工作的开展,团队的信任,越来越多的责任会加在我们肩上,我们做事要考虑的层次,切入点,关系人等各个维度的问题将接踵而至,此时我们面临的决策问题,更像是下面这张图:

CBO-Health-Deficit-Reduction-Nov-12-300x206

当我们讨论决策的问题时,本质上说的是价值取向问题。这个时候我们做什么?简单讲,就是基于自己能控制的资源,在相对正确的方向上,选价值最大的事情做。

每个人都知道该做最有价值的事,问题在于如何判断最大的价值。没谁敢说自己的决策一定是正确的,也没谁敢说自己选的的方向就一定能成事儿。这个很难,非一般的难。

产品经理应该有的三种能力

在下面三点上,说一下自己的理解。

全局观

一叶障目,百叶障天。

全局观这个概念很抽象,抽象到几乎每个老板给员工打鸡血的时候都会用到。他们总会跟员工讲,你们要站在老板的角度看问题,站在Leader的角度看问题,把自己看事情的角度提高一个层次,就能理解XXX。

在我看来这个逻辑是站不住脚的,当一个老板说出这样的话时,本身就没有站在员工的层面思考。如果员工每天晚上都来不及回家和家人吃顿饭,周末加班都不能出去进行正常的社交活动,手头的事情都没搞完,哪有空站在老板的角度思考问题?

通俗讲,全局观就是站在所有人的角度思考问题。从这个角度理解,对全局观的思考,就不是自上而下,意味着作为一个Leader,要从团队中每个人具体所做的事开始,到每个人的工作内容,责任范围,团队发展的整体目标,自下而上的思考全局问题。

举个例子,从PM自身的角度思考,一定是想用最快的时间,把所有新的、有价值的、能解决用户需求的功能都加上,让产品正向的发展迭代;从开发的角度思考,人家做一个功能要考虑的,是技术上的价值,这功能在现有的架构上如何添加,与其它功能怎样结合,后台需要新增哪些字段,服务器端怎么做负载均衡,甚至数据库是否要重新分表等等;而从设计的角度,首先要考虑的是用怎样的设计理念和风格,才能满足对应的需求,在交互上如何设计用户的操作行为等等。

此时,站在全局观思考的Leader,要在每个人的手头忙活的事儿之上,权衡当前来说更重要的事情,做取舍、平衡,选择相对正确的方向,带着团队把事儿干成。

时机

做对的事,远比把事情做对更重要。

在对的时机做对的事情。永远都要有个清单,把事情做优先级排序。有很多方法帮我们做这样的分类。比如,按事情重要和紧急的程度画个坐标轴,在四个象限对应的做事务管理。不过问题的关键在于,看起来重要和真的重要有很大的区别。我们判断一件事重要或紧急的关键因素,时刻影响着我们对时机的判断。

就像我们在搜索引擎输入关键字时, 算法会将我们输入的关键字按语义、词性,在句中的结构等要素进行拆分,在数据库中匹配最可能与关键字相关的网站依次排序展现。同样的,一件事给到我们,我们也会按 5W1H ,SMART 等类似的原则去分析,做决策。但这远远不够。

保持自己独立的思考,先做,快速试错,多总结。实践多了,对时机的把握会逐渐提升。

积累

没有立竿见影的努力,也没有全然无用的经历。我们做事情是不是有积累,就显得尤为重要。

去年做产品的时候,经常做个迭代方案,团队集中精力做一阵就上线了,事后发现效果不错,这事儿就结束了,效果不好,也大都找不到原因。不论效果好不好,这个方案给整个团队带来的价值,其实都没有积累下来。

后来把自己做的每一版原型,测的每一个Bug,改的每一个需求,ASO的优化,数据分析,用户访谈等等涉及到我工作的每一件能记录下来的东西,都以不同形式存在了我的硬盘里,在之后遇到类似问题时,这些数据都着实帮了不少忙。

有效的总结归纳,对问题有清晰完整的认识,在未来的某一天一定会体现出意想不到的价值。我一直觉得人经历的每件事都是一笔财富,就连自己被骗的经历,我都有个文件夹专门存着,分析他们的角色关系、业务逻辑、骗术技巧,时间久了,也挺有意思。

其实,这篇文章上述的每个观点,都需要积累,也来源于积累,也正在被积累。我反复写了许多次,中间也被各种事情打断了许多次,我也不知道这些是否正确,只不过是我工作快两年以来的积累而已。也或许像许多人总说的那句,我说的都是错的。但我想只要有人看到这篇,能从其中的某个句子中获得些许启发,明白些之前未曾懂得的道理,也就值得。

尾声

我们总以为会有一种可以套用在一切情况中的套路,足以让我们在任何实际的工作情况中游刃有余。

实际上人生永远不会如此。

在我们向前走的同时,别忘了还要向左看向右看向后看。我想因为我的存在,能让一些人看到身边左右不曾发现的风景,看到后面匆忙中定格的路,便有了些价值。人生无非是遇到些有趣的人,懂得些道理。如若只顾着自己向前,那再有趣的人也会错过,再多的道理,也不会懂得。

我是杨柳,I am back.

#专栏作家#

杨柳,微信号:PMYANGLIU。人人都是产品经理专栏作家。一个自由职业的产品经理,正在平坦的道路上曲折前行。专注企业服务领域的产品规划、UX、用户研究及数据分析。坐标帝都,欢迎交流。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 每看一遍都会有不一样的感受,感谢作者的分享

    来自北京 回复
  2. 作者说的情况我也遇到了,经常是忙完一阵上线后就不管了。自我分析了原因:1、没有意识2、做之前本来就没有目标,很多东西不会自己想做要做的,而是被告知要做什么,也就没有那么上心。反思:这两种情况都是不职业的表现,要改

    来自北京 回复
  3. 喜欢尾声中的观点,没有万能的套路能应对所有的场景。

    来自北京 回复
  4. 同信息管理与信息系统,我们班做什么岗位的都有,感觉我们什么都学了,但是什么都不会,哈哈

    来自广东 回复
  5. 时常回顾本质问题,才不至于迷失前进的方向

    来自广东 回复
  6. 受益良多!

    来自北京 回复
    1. 能帮助到就好

      来自辽宁 回复
  7. 对于一毕业即将从事产品经理的毕业生来说受益匪浅,一篇很值得回味的文章

    回复
    1. 能帮到就好

      回复
  8. 积累总结这个确实很有必要!

    来自广东 回复
    1. 却是常常被我们忽略的一点。

      回复
  9. 感谢分享!

    来自广东 回复
  10. 我之前是草根创业的,失败后就开始应聘产品经理相关岗位,因为没有系统的了解过该岗位所以频频受挫!今日拜读此文受益匪浅,感谢!希望接下来的面试能够顺利

    回复
    1. 祝一切顺利!

      来自黑龙江 回复
  11. 管理科学与工程,同学你好我也是这行的。我们学的东西和产品简直是完美对接啊。 😉 至于我们的定位就是组织,协调,管理,策划帮助整个团队协同目标,努力前进。哪里有坑,我们想办法填

    来自上海 回复
    1. 沟通是永远无法逾越的坑呢 😥

      来自黑龙江 回复
    2. 这个深有体会 每天都互相撕逼 😥

      来自广东 回复
    3. Everything that kill‘s me make me feel alive

      回复
  12. :mrgreen:

    来自安徽 回复
  13. 《通往财富的自由之路》是南希言的吧

    来自北京 回复
    1. 那不是一本书,是李笑来在得到App上开设的专栏

      来自黑龙江 回复
    2. 哦哦 是我寡闻了 能给个链接么 去学习学习 😉

      来自北京 回复
    3. 可以在AppStore里下载得到App,在里面订阅就OK了

      回复
  14. 写的很好,值得思考。

    来自北京 回复