这篇《什么是产品经理》，将会像一个App一样，不断迭代。不断拷问产品人将要面对的永恒问题，在每个版本中修改Bug，整理需求，增加新功能，测试……甚至重构数据结构。
今年是我个人十分动荡的一年。2月以来就再没专注地写过产品文章。刚工作的时候，许多人跟我讲，产品经理最重要的能力都要在工作实践中习得。后来工作了快两年，又有人跟我讲，产品经理最重要的能力都在工作之外，让我回归生活。
最后，所有跟“为什么”沾边的问题，都又要重新回到哲学的层面。至于“为什么做产品经理”的问题，只有每个人自己才能回答。这次，我们聊聊什么是产品经理。
这篇是曾经拖稿一个月的文章。源自八月我在团队内部做的一次破冰分享。我想，任何一份工作，我们真正去做之前，最重要的不是沟通，不是方法论，也不是快速适应工作环境，而是，我们如何定义自己的工作？
如果一个人不能清晰的定义自己的工作，唯一可以肯定的是，在具体执行的过程中会遇到相当多来源于自身的阻力。这一点，我相信大家不管曾经是否听过，都能认同其重要性。当然，在定义自己的工作之前，可能我们还要定义我们自己。所以这段时间也总在思考许多哲学上的问题，探寻许多事物的本质。
海德格尔曾说：
“哲学不能引起世界现状的任何直接变化。而且凡是人的思想和图谋都不能做到。”
而就是这些“思想和图谋”，最终左右了我们的行动，让这个世界变化的，也来自于我们的行动。
一年多前，我曾写过“你为什么做产品经理”。我说“人本身就是产品，身体是硬件，思想是软件。”如今再回头看，又发现每个人的“软件”中，也有前端和后端程序的不同。就像后端程序，早已在系统底层写好，无需用户的直接指令，自动执行。我们的许多行为，也受这些“后台程序”的影响，潜移默化的被每个人的自我所改变，迭代。
所以这篇《什么是产品经理》，将会像一个App（应用程序）一样，不断迭代。不断拷问产品人将要面对的永恒问题，在每个版本中修改Bug，整理需求，增加新功能，测试……甚至重构数据结构。
对于永远追求“实用价值”的人来说，可能这个系列的文章并不适合你。我可以肯定的说，这些文章并不能帮助人们找到一份PM的工作，也不能帮助已经工作的产品汪们解决某些实际问题。如果非要说价值的话，可能在我们理解“产品经理”的本质，我们从何处而来？又将走向哪儿去？这些类似的问题上，带来一些思路或启发。
“也只有产品经理会用韦恩图来定义他们自己了”
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
商业于产品经理而言，可能经常被放在“重要但不紧急”的象限中。在各大互联网公司的职级体系里，对商业的理解，也多被放在较高职业等级中。包括网络上关于产品经理的各种文章，商业相关的分享，一般描述的也更少，或定义不清晰。
为什么会这样？因为商业是个永远没有终极的东西。商业以资金的增长为目的，通过资本运作，以关系为依托，规避风险为准则。我相信能深刻理解这几点的人，大都在忙着做生意，也在用同样的规则来判断，是否要分享某些东西。
那么我们如何提升自己在这方面的认知和能力？最直接有效的方法很简单，就是自己去做生意，在实践中习得。如果你也同样在这方面有困惑，推荐你在得到App中订阅李笑来老师的《通往财富自由之路》，他的观点，让我在个人的财富积累以及对资本的认知上有了很多的新的理解。
除此之外，我能想到的方法就只有从自己身上出发，把自己变成一个具有商业价值的人，让同样在商业上寻找机会的人能更方便的找到你，大家各取所需，也是种不错的方式。
回到工作中，大家经常说的可能不是商业这个词，而是业务，或者业务逻辑。即学会定义你当前所做的事情，在公司整体的业务中处在哪个分支，具有怎样的战略意义，能给公司带来怎样的收入，或可能带来的潜在价值。如果自己想不明白，去问问团队的Leader，如果觉得Leader的见解有局限，去问问CEO也是不错的选择。相信我，你的老板会很喜欢这样的员工，只看你准备的够不够充分。
产品经理管理的到底是什么？
我想这个问题不单是产品新人，也是每个从业者，在公司和产品不同发展阶段中，要经常捶问自己的问题。
你管理的究竟是什么？
在管理外界事务之前，先要管理好的，是自己的能力。
Copyright from BLUES
上图是腾讯PM职级体系中P1—P3的雷达图。当我们定义自己的工作内容时，看看别人如何定义也具有相当的价值。
腾讯的职级是从P1到P7，其中的各项能力可以分为：通用能力、专业知识、专业技能、组织影响力。各个阶段的成长中，也按不同的侧重点发展，最终则达到全满的状态。
我们可以先参考上面的能力模型，试着定位自己的位置，找到缺乏的点，在长期的工作中有意识的积累对应的知识和技能。（关于各项能力的详细描述，大家可以看我之前的文章“从PM成长体系聊职业规划”）
自我管理之外，产品经理的工作至少涉及如下5个层面的管理：
需求
需求
需求
需求
重要的事情说三遍。没了需求二字，所有事情也没了意义。
我们要明确的第一项需求，是一家公司对产品经理的需求，和你对公司的需求。这看似是句正确的废话，却是我们进入任何一家公司前最Base的决策依据。因为产品经理的确是一个即使公司没有这个岗位也能良好运转（至少短期来看）的角色。
你永远无法叫醒一个正在沉睡中的人。所以在入职之前，朋友、HR、CEO，任何一个能帮你多了解公司业务的人都尽量多聊聊，如果都没有，可以试着作为一个用户，去体验某项业务的整个服务流程，来形成自己的判断。如果把公司招PM的需求比喻成坑，这坑大概分3种：
1.公司开辟新业务——挖坑
2.某块业务没人负责了——接着挖坑
3.业务做的不够好——换个人继续挖
既然到哪儿都有坑，先看看深浅，哪个适合自己的职业规划，再往里跳。
明确公司和PM的需求后，业务需求、产品需求、用户需求便接踵而至。
PM给企业带来的价值，直接体现在业务上。业务面向的主体很庞杂，可能是用户、客户、企业、合作伙伴，也可能是自己的团队。近几年吵得很热的 B2B , B2C , O2O 还有最近刚起来的 C2M 等模式，本质上描述的就是企业和其业务主体之间的关系，或不同业务主体之间的关系。如何满足你所负责业务上的多方需求，实现业务的增长，将成为你工作的核心。
业务、产品、用户三者的需求，是有机的整体，从来都不能割裂来看。满足产品和用户的需求，是业务增长的基础。从这个角度，我们给用户提供的不是产品，本质上是服务。我们常说的产品功能，本质上是服务具有的特性。
你的产品为用户提供了什么服务？
满足了用户的什么需求？
服务具有的特性是否能在特定的场景下满足特定用户的特定需求？
这三个问题就是我们做产品时要不断问自己的永恒问题。
限制
能从Leader角度思考问题的人，未来才有可能成为Leader。优秀PM身上最让人渴求的能力，就是“让事情发生”的能力，谜一样的能力。限制，孕育了这种能力。
不论工作还是生活，每个人无时无刻都活在各种限制之中。久而久之，多数人选择臣服于限制。而PM则是在限制里找突破口的角色。就像我们在画原型时，第一步，是在白纸上画一个框，接着是无尽的框。
对限制的管理，一定程度上也算是种融资。你的Leader，是你融资的对象。当你有了新的产品构想，想让它最后发生，必须要其他人的帮助。你需要什么帮助？如何获取这些帮助？获取后又怎样在限定的时间和资源下完成？
这三个问题是管理限制时，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
随着工作的开展，团队的信任，越来越多的责任会加在我们肩上，我们做事要考虑的层次，切入点，关系人等各个维度的问题将接踵而至，此时我们面临的决策问题，更像是下面这张图：
当我们讨论决策的问题时，本质上说的是价值取向问题。这个时候我们做什么？简单讲，就是基于自己能控制的资源，在相对正确的方向上，选价值最大的事情做。
每个人都知道该做最有价值的事，问题在于如何判断最大的价值。没谁敢说自己的决策一定是正确的，也没谁敢说自己选的的方向就一定能成事儿。这个很难，非一般的难。
在下面三点上，说一下自己的理解。
全局观
一叶障目，百叶障天
全局观这个概念很抽象，抽象到几乎每个老板给员工打鸡血的时候都会用到。他们总会跟员工讲，你们要站在老板的角度看问题，站在Leader的角度看问题，把自己看事情的角度提高一个层次，就能理解XXX。在我看来这个逻辑是站不住脚的，当一个老板说出这样的话时，本身就没有站在员工的层面思考，如果员工每天晚上都来不及回家和家人吃顿饭，周末加班都不能出去进行正常的社交活动，手头的事情都没搞完，哪有空站在老板的角度思考问题？
通俗讲，全局观就是站在所有人的角度思考问题。从这个角度理解，对全局观的思考，就不是自上而下，意味着作为一个Leader，要从团队中每个人具体所做的事开始，到每个人的工作内容，责任范围，团队发展的整体目标，自下而上的思考全局问题。
举个例子，从PM自身的角度思考，一定是想用最快的时间，把所有新的、有价值的、能解决用户需求的功能都加上，让产品正向的发展迭代。从开发的角度思考，人家做一个功能要考虑的，是技术上的价值，这功能在现有的架构上如何添加，与其它功能怎样结合，后台需要新增哪些字段，服务器端怎么做负载均衡，甚至数据库是否要重新分表等等。而从设计的角度，首先要考虑的是用怎样的设计理念和风格，才能满足对应的需求，在交互上如何设计用户的操作行为等等。
此时，站在全局观思考的Leader，要在每个人的手头忙活的事儿之上，权衡当前来说更重要的事情，做取舍、平衡，选择相对正确的方向，带着团队把事儿干成。
时机
做对的事，远比把事情做对更重要
在对的时机做对的事情。永远都要有个清单，把事情做优先级排序。有很多方法帮我们做这样的分类，比如按事情重要和紧急的程度画个坐标轴，在四个象限对应的做事务管理。不过问题的关键在于，看起来重要和真的重要有很大的区别。我们判断一件事重要或紧急的关键因素，时刻影响着我们对时机的判断。
就像我们在搜索引擎输入关键字时， 算法会将我们输入的关键字按语义、词性，在句中的结构等要素进行拆分，在数据库中匹配最可能与关键字相关的网站依次排序展现。同样的，一件事给到我们，我们也会按 5W1H ,SMART 等类似的原则去分析，做决策。但这远远不够。
保持自己独立的思考，先做，快速试错，多总结。实践多了，对时机的把握会逐渐提升。
积累
没有立竿见影的努力，也没有全然无用的经历。我们做事情是不是有积累，就显得尤为重要。
去年做产品的时候，经常做个迭代方案，团队集中精力做一阵就上线了，事后发现效果不错，这事儿就结束了，效果不好，也大都找不到原因。不论效果好不好，这个方案给整个团队带来的价值，其实都没有积累下来。
后来把自己做的每一版原型，测的每一个Bug，改的每一个需求，ASO的优化，数据分析，用户访谈等等涉及到我工作的每一件能记录下来的东西，都以不同形式存在了我的硬盘里，在之后遇到类似问题时，这些数据都着实帮了不少忙。
有效的总结归纳，对问题有清晰完整的认识，在未来的某一天一定会体现出意想不到的价值。我一直觉得人经历的每件事都是一笔财富，就连自己被骗的经历，我都有个文件夹专门存着，分析他们的角色关系、业务逻辑、骗术技巧，时间久了，也挺有意思。
其实这篇文章上述的每个观点，都需要积累，也来源于积累，也正在被积累。我反复写了许多次，中间也被各种事情打断了许多次，我也不知道这些是否正确，只不过是我工作快两年以来的积累而已。也或许像许多人总说的那句，我说的都是错的。但我想只要有人看到这篇，能从其中的某个句子中获得些许启发，明白些之前未曾懂得的道理，也就值得。
尾声
我们总以为会有一种可以套用在一切情况中的套路，足以让我们在任何实际的工作情况中游刃有余。
实际上人生永远不会如此。
在我们向前走的同时，别忘了还要向左看向右看向后看。我想因为我的存在，能让一些人看到身边左右不曾发现的风景，看到后面匆忙中定格的路，便有了些价值。人生无非是遇到些有趣的人，懂得些道理。如若只顾着自己向前，那再有趣的人也会错过，再多的道理，也不会懂得。
我们都在平坦的道路上，曲折前行。
