产品经理的介绍及提高

产品经理的诞生背景

定义任何一个问题，不妨从它的背景开始讲起。

自1927年，美国P&G（宝洁）公司出现第一名产品经理以来，产品经理的价值逐渐被市场认可，但其实那个时候的产品经理更像今天传统行业的品牌经理，负责产品的品牌建设、市场销售等几乎所有的事情，偏重于市场、商业端。

随着互联网和移动互联网的普及发展，一波又一波的互联网、移动互联网、智能硬件、VR/AR等产品被推向了市场，还有很多生活里的传统行业，也被“互联网+”的力量跨界渗入，互联网公司的从业人员规模也极速膨胀起来。为了提升从业人员的职业能力和效率，很多互联网公司的岗位职责也越来越细化，将原来的策划一职，拆分为产品经理和产品运营。在之前，各家公司的招聘需求中，策划是同时担任网站的需求整理、沟通实现与推动上线，同时还要对上线后的运营结果负责的工作职责。慢慢地，就逐渐演化为了两个职业角色，其中一类能对产品需求把握比较准确，与开发沟通推动需求上线，并做产品规划与迭代的人，被称为了产品经理；而另一类，对用户欲望了解比较深入，比较擅长文案编辑、策划各类创意活动，用户互动等，则被称为了运营人员。

由此可见，产品经理的出现是为了适应行业、公司发展的需要，就好比在淘宝还没有出现之前，是没有淘宝客服这样一个角色的，但是随着电子商务，尤其是淘宝的普及率越来越高，淘宝客服这样一个职业的出现也是为了适应行业、公司的发展需要。如果再进一步想，随着人工智能的发展，以后可能有相当一部分的职业将会被机器人给替代掉，到了那个时候，是不是也会相应出现一些新的职业来让人们去从事和劳动呢。

大家是不是也可以想想，产品经理这份职业究竟可以走多远。

产品经理需要扮演的三种角色

了解了产品经理这个岗位的背景来源，我们是不是还需要了解产品经理平时都干些什么工作。很多还没有入行的新人，往往不太清楚产品经理的具体工作职责是什么，更没有办法详细地阐述产品经理可能涉及到的角色。

在我看来，产品经理至少是3种角色的混合体。

首先，产品经理应该是一个商业洞察者。

所谓商业洞察者，是指具备商业洞察能力的人，说到底，其实就是对人性和隐形规则的把握能力。产品经理必须要有洞察人性和商业的能力，这样你才能更好的发现市场痛点，了解用户需求，然后用商业来完善你的产品想法，而不是仅仅作为一名员工去实现公司给你指定的产品路线。很多产品经理工作多年无法进一步提升，其实相当一部分是卡在了商业洞察这一块。于是很多人在问是不是应该多读几本书就可以系统训练商业知识和商业嗅觉，从而来增强自己的商业洞察能力。结果未必如此，我们会发现一家公司的老板往往是商业洞察能力最好的那一个，他们有很系统的商业知识吗？他们有很高深的商业理论吗？他们有相应的专业知识吗？其实也不见得，他们中的一部分可能连报表都看不懂。但他们知道，什么生意赚钱，什么生意亏本。这就是商业的洞察力，就像长久在森林里打猎的猎人，他们知道猎物在哪里，这种本能几乎是天生的。

其次，产品经理会变为一个创作者。

这种创作，和其它所有的艺术家创作是一样的，就像画家画画，诗人写诗，作家写小说，人体艺术家创作人体艺术，而产品经理创作的则是一款互联网产品。产品经理需要去定义和规划这款产品，要为这款产品确定设计风格，要去梳理这款产品的架构设计，甚至还要去确定每一个页面里面的每一个按钮究竟该如何摆放，如何设计。当然，和所有的创作者一样，产品经理也会受到现实世界里的各种束缚，比如这个需求目前的技术实现不了，这个产品并没有太大的商业价值等等，和其它艺术创作者一样，产品经理也在追求一种创作的平衡，戴着镣铐进行舞蹈。对于产品经理来说，能够通过创作将自己的想法、价值观灌输到产品中去，已是一件非常令人振奋的事情了。

最后，产品经理又会变身成为一名导演。

之所为会说比较像导演，是因为导演在挑好拍摄的剧本后，需要组织安排一伙人（制片、摄影、灯光、道具、演员等）将剧本给拍摄出来，其中穿插着大量的沟通、管理工作，拍摄完成后，还要带着一票人马跑到全国各地的院线去做路演宣传，不得不说，这是非常辛苦也非常有成就感的一份工作。产品经理也是这样，在产品设计完成之后，产品经理需要协调一大帮人，其中包括设计师、程序员、测试工程师、运营推广、销售等等，将产品通过代码给实现出来，发布上线并进行推广，让产品被更多的用户了解和使用。

当然，这里所阐述的三种角色，是一种相当理想的情况下，产品经理可以从事的三种角色状态的切换。但一般来说，要做到这种理想状态，往往需要产品经理具有丰富的产品实战经验和产品阅历，能够自己从0到1去创造一个新的产品，不然的话，可能只会涉及到这里面的某一个角色，或是某一个角色里面的一小部分。

通过这样一种通俗易懂的描述方式，让那些没有从事过互联网工作的人也对产品经理有了一定的了解，接下来你还可以对他们讲讲产品经理的几个特征。

产品经理的几个特征

没有实际的领导权

很多外行的人，听到产品经理这个职位名称的时候，都以为产品经理是什么公司领导，管理着一票人马来实现和推广产品。殊不知在国内，产品经理虽以“经理”为头衔，但是在大多数情况却并没有实际的行政领导权。由于没有实际的行政领导权，所以产品经理要想做好产品的确不是一件简单的事情，因为你需要去驱动和说服一批不是下属的同事去实现公司老板或者自己的想法。这时候对产品经理本身的人格魅力，就是一大考验，在成为产品经理的道路上，你会碰到一系列的困难和挑战，比如如何去推动团队成员完成项目，如何让团队成员觉得你是一个靠谱的产品经理，如何让大家对你产生信服等等。

事多而杂

在很多人的眼里，产品经理是一个非常高大上的职位，逼格满满。近年来，也有越来越多的人毅然投身到了产品经理这一行。产品经理这个职位就像忽如一夜春风来，在各大互联网公司花开千树万树。事实上，产品经理每天需要处理非常多的杂事，加班更是成为了一种现象。

相信很多从事产品经理年限比较久远的人，对此深有感悟。为什么说产品经理做的事情多又很杂呢，我们先来大致梳理下产品经理都有哪些可能要做的事情：

a.跟进类：项目进度跟进、BUG修复跟进、发版跟进、UI跟进、客服跟进、测试跟进等；

b.设计类：市场调研、竞品分析、功能点设计、原型设计等；

c.沟通类：和老板沟通、和开发沟通、和运营沟通、和设计师沟通、各种相关资源协调等；

d.组织类：组织项目会议、组织需求评审会议、组织开发会议、组织测试会议等；

e.文档类：需求文档、原型文档、流程图、会议PPT、产品PPT等；

f.分析类：数据分析、投入产出分析等；

g.打杂类：产品专利申请、产品培训、搜集资料、产品帮助手册撰写等；

以上大家不难发现，产品经理的工作不但多，而且杂，就像互联网上流行的那首《产品经理是条狗》里面唱的那样“我睡得比猫晚起得比鸡还早，工作在拼体力武器得用大脑，左手的P R D 右手的产品稿，什么才是你想要我每天在烦恼，邮件又来催催催 产品开发累累累”。

协调和驱动

产品经理有很大一部分工作是在做协调和驱动相关的工作，虽然产品经理不能直接领导其它部门，但是可以对其它部门的人员进行协调和驱动，统筹所有团队人员来更好的完善产品。所以，产品经理平常要经常去协调很多部门，比如要和设计师打交道，要和程序员好好沟通交流，要和测试人员沟通工作，要给客服销售培训产品，要跟运营人员沟通推广的事情，要跟市场人员谈支持，有时候还要说服老板给资源，去给陌生用户做用户访谈。

产品经理就是产品的负责人，也是互联网公司里面唯一一个枢纽型的岗位，理所应当为了让产品活得更好而去驱动更多的人为产品服务。

1. 维护一份竞品跟踪文档

竞品分析是一个长期、繁重、琐碎的工作，而不是在刚接触产品时，写一份文档就丢在一边。维持一份长期的竞品分析文档，保持对竞品的关注，不仅可以从中分析竞品的策略。竞品跟踪主要从以下三个方面来看：交互变化、功能迭代、战略变化。

2. 维护一份产品全局文档

年初我刚接手现在在做的产品时，踩了很多坑，当然现在也还在持续踩。当时几乎没有文档，而仅存的文档不仅数量稀少，而且过时（跟实际情况有较大的出入）。当时想要知道一个功能的实现逻辑，只能靠自己手工测试，或者让程序员去查看代码，效率十分低下。

除了被别人挖的坑埋了之外，我也做过自己挖坑埋自己这样的蠢事···在做版本迭代的需求的时候，自己是非常清楚上下文和用户场景，以及在细节处的实现逻辑（要知道在实现过程中，总是会临时做出一些不在文档范围内的小调整），由于调整比较小，所以也没有体现在文档中。于是出现了在几个月后，想不起来当时的实现逻辑的情况···

鉴于以上的惨痛经历，我开始维护一份产品的全局说明文档。在这个文档中说明版本的大致迭代情况、各个模块的现状和调整。

在实际情况中，我建议你的产品全局文档不用写的特别长，妄想把所有文档都集中到一个文档中，我建议你只在这个文档中说明『变化』和相关文件的地址。

另外，在云笔记中保存文档也是一个不错的主意，这非常利于及时修改和查看。但是切记要备份。

3. 横向记录版本：版本的需求文档

请注意自己的需求文档的阅读体验。

好好写需求文档。

好好写需求文档。

好好写需求文档。

重要的事情要说三遍。如果你觉得这个不够重要，请你去翻一下产品的历史产品需求文档再来说话···

结构不清晰的产品需求文档，不仅会虐死你的继任产品经理，还有可能虐死自己。请在写文档的时候，务必注意格式，注意错别字，注意结构。确保文档语句通顺，且能够完美的表达你的想法。

4. 纵向记录版本

从时间轴上，记录每个版本的基本信息和概况与上下文

之前已经说了，对竞品的迭代要保持关注。但同时也要对自己的产品的迭代进行记录。这个记录包括了每次版本迭代的内容和相关信息，以便于以后查询。

5. 需求池

维护需求池，而非收集所有需求。

在平常工作里，你一定都会收到来自很多同事或用户的改进建议，千万不要弃置一旁，也不要立马将需求加入需求池。多和提需求的同学沟通一下，了解一下需求的上下文、场景等，从多个维度对产品进行评估，如果需求足够重要就将它加入需求池。

注意要用多个维度对需求进行衡量，建立上下游都认可的衡量体系。譬如隶属的功能模块（不同模块有不同的重要性和优先级）、紧急性（影响程度）、重要性（覆盖面）等等。

6. 记录需求的场景与上下文

这个本来是要归到『好好写需求文档』那里，但我觉得很重要就另外抽出来了。

我知道需求文档是给技术部的程序员看的，而大多数情况下他们并不 care 你需求的上下文、场景和合理性，但是，不管他们是不是 care，你都要记录下需求对应的场景，好记性不如烂笔头，千万不要过度信任自己的记忆力。

7. 良好的文件管理习惯

所有的文件，一定要好好管理，分文件夹摆放，定期备份，及时清理。

不经历一次找不到重要文件的事情，你就不知道好的文件管理习惯有多重要。

8. 指导全局的文案风格文档

一个产品的文案会出现在产品的各个角落，一个统一一致的口吻，有助于塑造一个优质的品牌形象。而前后不一致、不礼貌、不细心、冷冰冰的文案风格，将会极大的影响用户体验。

而最简单的解决方案是，将文案风格用文档的方式确定下来。哪怕团队只有你一个人在负责产品，也一定要写下来。写下来，那就是准则。被遵守的机会也更大一些。