史上最全产品经理工作概述！

|沙龙精选自公众号枯叶咖啡馆

导读：由于环境原因，我们接触到的产品经理似乎总是“特别的”，以至于这个问题困扰了许多人。

产品经理到底是什么，我现在做的事情，真的是产品经理要做的事情吗？

01.产品经理的工作

本文所提及的观念，为我个人的心得分享，不具备标准性质，但具备参考性质

谈到产品经理的工作，“杂，乱”，是最常听到的定义，包括我本人也在许多场合提到了产品经理的工作内容很杂。

这有两个原因:

其一，我们并没有掌握这些看上去杂乱任务背后的共性;

其二，我们懒惰，相比长篇大论的陈诉以及费尽心思的沉淀，回答杂只需要一个字（我便是后者，惭愧，嘿嘿）

用杂乱来定义产品经理的工作内容，就如同用写代码来定义开发，用画图来定义设计师一样，只是一种自嘲的回应，并不是真正的定义

我简单的将我个人对这个角色的定义分享一下，并不代表所有的产品经理，但也代表我所认识，所接触过的大部分产品经理，分析样本在100人以上。

这是一个工作的循环，一共是7个环节，分别是接受任务，分析，设计产品，交付产物，跟进进度，验收发布，结果分析。

我们来简单讲讲每个阶段的工作性质。

02.接受任务

这里提到的接受任务，原则上是产品经理一系列工作的起点，这些任务便是我们的需求。

正式工作环境里，我们的需求大部分通过任务性质被下发给我们的，这一点即便是产品负责人，产品总监也不例外，区别只是我们的任务不一样而已。

以产品总监为例，我们会接受到要启动某个新产品的任务，而这个任务或者是由企业上层决定，或者是由战略决定，或者是由市场决定。

其本质上更多的是任务，而不是想做什么就做什么

我们来看看几种典型的任务:

我们增加一个打赏功能吧
我们增加一种消息样式
我们做个转发，怎么样
现在直播很适合我们公司的方向，你来操刀，设计一个直播系统吧
积分等级体系能有效的增加用户的活性，来一发
我们有教育资源，想找一位产品经理来做一款教育类app

当然，除了上级的直接要求以外，我们通过对市场，对用户的了解，也能发现一些问题，发现一些机会，而这部分内容，也同样是任务性质的，只是我们自己扮演者任务分配的角色。

冬日的某天，小雪，A和B两人相约去某地开会，准备打个出租车前往，两人在雪地等了许久，都没有出租车经过。

此时，A抱怨道，要是有一款APP ，能让我点一下就能叫到车就太好了（任务下发）

B思考了一下，觉得这是一个很好的想法，于是回应道，咱们自己做一个（任务接受）

于是，有了 UBER

于我个人而言，我其实很排斥“想法”，更多的是喜欢以“任务”的概念来驱动项目，想法过于偶然了，具备十足的不确定性，同时又过于廉价，谁没有几个想法呢？而任务却不一样，具备一定要达成的潜意识，我们接受任务或者下发任务时，都持有必须完成的心理

03.分析

分析是一个大类的环节，这样的称呼大概会让你感到迷惑，我们先来看看那，分析阶段都包含了那些事情。

市场调研，用户调研，需求调研，技术调研，数据分析，kano模型，马斯洛需求层次，用户画像等等

在分析阶段，我们运用各种各样的方法来完成对任务的分析，是的，我们所知道的许多看似很高端的名词，大概都是在分析阶段的某种方法论。

产品经理是个强思考的角色，这里的强思考主要就体现在分析阶段。

分析阶段在任务接受之后，我们分析的目的是如何去达成任务。

分析的目的在于寻找达成目的的方法，而不是去寻找拒绝任务的理由

很多时候，我们在分析时会有错误的思路，我们会下意识的去寻找能够帮我们拒绝执行任务的理由，这是一种潜意识，是我们需要克服的困难。

我深刻的知晓许多任务，在我们接受时，就已经存在不可执行性，从一开始就注定了失败的，但很遗憾，我们对此无能为力。

就像是士兵一样，服从是军人的天职，达成任务便是我们产品经理的天职，尽管他多么的离谱。

要知道，许多伟大的事情，都是在不可能完成的情况下被完成了。

产品经理接受的任务，极具挑战性质，80%以上的任务都是属于不可能完成的任务

我们的角色，本就是将不可能变为可能，将可能变为现实

所以，你还在排斥任务吗？或者你是否做好心理准备，迎接一个又一个的不可能完成的任务

再来说到具体的各种方法论，如同我们刚才列举的许多方法一样，其目的都是为了帮助我们分析。

我们已然清楚分析的目的是什么了，那如何分析便是这些方法论发挥作用的时候了。

这些方法论并不神秘，只是包装过于华丽了，我们简单列举几种分析方法吧。

市场调研

我们在获取需求时，最先做的就是市场调研，简单的来讲，就是去分析任务所对应的目标市场，具备什么样的特点，需要什么样的服务。

需要注意的是，此处调研对象是“市场”，比如出行市场，IT市场

用户调研

任何一个产品都是被某人所使用的，我们借助市场调研明确自己要做什么服务以后，就需要做用户调研了。

用户调研的落脚点在于某人，正确的讲，应该是某类性的群体

技术调研

技术调研是在有一定想法以后，我们找上开发人员，简单评估一下技术的实现成本，如果某个idea的实现成本过高，我们可能就要重新想想方案了，许多产品经理在设计产品时，会忽略技术实现难度及成本，这是不可取的.

在应用层面，大部分的需求都是不需要强行攻关的，比如我们要实现支付功能，但并不是一定要自己开发一套支付系统以及安全系统，直接接入第三方就好啦.

当然资金量很大时，我们的收益足够平衡我们的成本时，就很有必要自己开发了。

kano模型

kano模型是作为划分需求优先级的方法被创造出来的。

需求总是很多的，但前人经过研究，提取出了需求的共性，并总结成了需求的五个类型。

使用这个方法，我们可以很轻易的判断某个需求属于何种类型，再借助该类型需求的价值以及效应，最终来判断出某个需求的优先级和重要性。

04.设计产品

产品是被精心设计出来的，这是我所遵循的产品观念，在我体验一款新产品时，我会尝试站在对方的角色，来思考。

如果是我来做，我会如何设计呢？

当我们结束了分析阶段后，我们会根据自己掌握的信息，根据自己分析所总结出来的信息，来设计产品。

我们所使用的每一个参数，都是精心设计的，不仅仅是参数，一句提示文案，也是可以被精心设计的。

只是我发现许多产品落地很差，这点在设计上可以充分体现出来。

于分析阶段相同，设计产品也有诸多的方法，并且经常被我们使用到，只是很多时候，我们并不曾注意到。

设计产品的方法：结构设计，业务设计，流程设计，原型设计，情感设计，MVP设计原理等

产品经理行业，由于外界盛传的0门槛或者门槛低，导致许多朋友尚未准备好，就进入到这个行业，再加上目前尚未出现通用的技能体系，在实际工作中，许多leader ，许多产品老人，都尚未将自己的经验沉淀，最终的结果，是比兴奋更为巨大的迷茫.

迷茫：

从心底里想要学习，并认真的热爱这个行业，但却连自己应该学什么，都感到疑惑。

看不清当下，也看不清未来。

自己现在能力到底怎么样算好还是算差，又或者是一般.

下一步，我应该学些什么，如何才能变得更好.

其实没有那么复杂，这个行业远比我们想象的还要接近事物的本质，你所欠缺的只是应用的技能，以及对技能的熟练度。

在产品设计阶段，我们的差距更多的体现在思考面积的强弱上，我们掌握的设计方法越多，便越能设计出好的产品。

最合适的就是最好的。

在创业团队里，产品经理可能不会决定项目的成功，但却极大的决定了项目的死亡。

若产品经理没有掌握MVP设计原理，以及产品结构设计，极有可能在1.0版本花费太多的时间，并给未来的产品迭代遗留许多问题。

这将极大的增加创业团队的时间负担，创业而言，每一个小时都是极为珍贵的资源，可以想象，浪费一个月等同于将整个团队置于死亡边缘。

而一次版本迭代，若牵扯到了结构重构，几乎是必然超过一个月的时间耗损的。

在不同的时间，不同的阶段，不同的环境里，我们需要使用不同的设计方法，这就需要我们不断的充实自己，不断的学习。

设计方法之间是不存在正确或者错误的，这完全取决于我们是否在合适的地方，用了合适的方法。

因此，我们无需因为自己设计出来的产品被排斥，被冷淡，而动摇自身的信念，也无需为了失败而感到沮丧。

我们所欠缺的，其实只是方法，那便学习方法就好了，不需要漫无目的的学习。

这些方法并不在已有的产品相关书籍里，而是在于传统行业的金科定律里，相对历史悠久的传统行业，互联网作为一个行业而言，显得无比稚嫩。

现在大家所认识的kano模型，金字塔原理，马斯洛需求层次，没有任何一个方法论是属于这个行业原创的，均是来自于对前人知识的学习以及再应用.

要知道，早在互联网之前，人们就已经设计出了许多精美的”产品“，我们其实早已掌握了产品设计的”精髓“，我们也早已接触了数之不尽的”产品“。

一段文字，一本书，一部电影，一场真人游戏，乃至我们所使用的碗筷，衣物，都是被作为”产品“被设计出来的。

因此，你，无需感到畏惧，也无需感到迷茫。

05.交付产物

我一直信奉团队至上的观点，个人的力量无论多么强大，也需要团队的支撑。

我们在工作中，常常感叹，有一位助理多好，那就能帮我们分担许多工作了。

我们希望有位助理，或者有人协助，本质上是对个人能力的一种危险预警，潜意识在告诉我们，你不行了，你需要团队.

正确处理团队关系，高质量提供交付产物，是我们获得团队帮助所必须要付出的代价。

与不同角色合作，需要交付不同的产物，需要记住的是，没有谁是谁肚子里的蛔虫，也不要寄希望和谁心意相通，正如我们无法揣测BOSS的想法，放之他人，也是相同的。

在我们与团队合作的过程中，90%以上的分歧，不愉快都是因为产品经理没有严谨的对待自己交付的产物。

原型图和需求文档是我们最基础的两份输出产物，可直到现在，仍然有许多产品经理以思维，思考的名誉，剥削产物的意义。

产品经理确实是一个强思考的行业，但这不代表我们不需要执行，不需要输出。不需要将我们的思考过程交付给团队。

我把我应该做的做完，我就成功了，置于对方有没有做完，抱歉，这不是我的责任，可我们真的知道自己应该做哪些事情吗？

绝大部分的时候，我们是不知道自己要做哪些事情的，这是这类角色的一个特性，似乎没有人为我们安排明确的任务，于是，我们出现了各种问题，各种花式秀矛盾，如果我们是开发人员，我大概会这么说。

你不是来写代码的，你是来写bug的

我们来简单罗列一下要交付的产物:

原型图，原型全景图，需求文档，变更记录，业务流程图，数据流向图，迭代故事，材料准备，沟通，调整

并没有完全列举完，我并不想去堆砌交付产物，这似乎没有价值。

交付产物并不是越多越好，而是越有效越好

以需求文档举例，我们可以看看自己写的需求文档，是否方便研发阅读，是否有歧义，是否已经将功能大部分都覆盖了，一份好的需求文档可以极大的增加团队效率，减少低效时间的耗损。

我曾关注过一个现象，相同的团队，相同量级的需求，实际开发中所消耗时间的差异高达 60% 期间，发生变化的只是需求文档更为精致，交付产物质量更高。

仔细想想，平时耽误团队时间的，不恰恰是因为需求描述不清晰产生的沟通成本，调整成本，以及由于需求颗粒度不够导致的变更成本吗？

而这些问题，只是需要提高我们交付产物的质量，就能有效解决。

所谓的交付产物是指接力的介质，产品经理所需要做的事情做好了，然后慎重的将我们的努力交给我们的团队。

这是一个很庄重的仪式，很严肃，是对团队的尊重，也是对自己的尊重。

在野外，我们猎杀了一头野猪，大概有100kg，我们嫌弃搬运太重了，就只切了一条猪腿，带回部落，大概只有10kg。

当我们再回到狩猎地时，被猎杀的野猪已经被其他野兽吃完了。

野兽就是我们所接受的任务，由于嫌弃麻烦，我们很粗暴的对待自己的原型图，很粗暴的对待需求文档，对待我们的交付产物。

似乎是没有时间，实际上只是因为我们偷懒，而且还是很不聪明的一种偷懒。

如果用正确的方法画原型图，写需求文档，你会发现，这样才是最大限度的偷懒。

现在你知道如何面对交付产物了吗？他并不难，只是需要我们额外的细心，额外的认真，同时，也需要我们尊重团队，尊重自己。

切忌将产品经理等同于思考者，我们除了强思考以外，也是团队中的一份子，思维固然重要，团队力量却远胜于个人的思维

想的再多，做不出来，有什么作用呢？

06.跟进进度

产品经理需要跟进版本进度，毫无疑问，我需要再强调一下，只有思想，只有想法，是无法做好产品经理的，我们不缺少想法，每一天我们都有许多想法，成出不穷。

2011年，在我第一次创业时，认识了一位灰色产业的朋友，他告诉了我一个很棒的想法，他想要消灭钱包，消灭现金。

人们每天买东西要带钱包，多么麻烦，还要找零，现在手机那么方便，做个软件出来，直接扫一下就能付钱，多方便。

光是手机付费还不够，金额太高，用手机也不方便，我们还得带个手机，最好还是刷身份证，刷脸，这样什么都不用带，要付钱的时候，扫一下脸就好了。

很遗憾，他不是马云，也不是马化腾，他只是一位不那么普通的普通人，现在，人们手机支付已经非常方便了，平时的生活中，我也很少再用现金了。

移动支付产品经理的想法与我这位朋友的想法并没有什么不同，但将想法实现出来却是截然不同的两个概念。

想法固然重要，但也只是重要，真正起到决定因素的，还看我们的做法。

当我们把产物交付给团队以后，我们的事情并没有结束，你需要留意一下，此时你的身份已经变化了。

你的产品从交付的时候开始，出现了变化，此时，团队就是你的产品，团队效率就是你的产品质量。

如果一个团队中没有更高的角色，那产品经理就是这个团队的leader，产品负责人就要对这个产品负起责任，还要对这个团队负起责任。

早会，需求卡片，周会，进度跟踪，风险报警，日报，周报，需求调整，需求管理，资源协调

这些是我们最常看见的在交付后的任务，尽管我们在交付产物之前，有做技术调研和需求评审，但这并不能保证在开发过程中出现需求障碍。

实际上，无论我们的技术调研和需求评审做的多么细致，总会出现意料之外的问题，这是因为我们的开发同学，在技术调研和评审时，只能根据大概情况进行预测，而在执行时，却会考虑的更深更全面。

在研发阶段，开发会遇到一些较为复杂的需求，会消耗较多的时间，此时，我们就需要根据开发的反馈进行再评估。

慎用技术强攻关，大部分的产品并不是以技术决定胜负的，超过80%的团队，并不需要过于强硬的技术，尤其是小团队，初创团队。（技术性项目例外）

在我接触的许多项目中，再也没有任何一个方法比修改产品方案更快捷了，当出现研发障碍时，修改需求方案，能够节省1天至1个月以上的时间，这需要我们每天跟进跟进研发进度

仔细想想，我们真的有必要花费这么大的成本去实现某个功能吗？

当我们参与到进度跟进时，会收获许多的调整，为了避免出现需求不统一，也是为了提高交付给测试同学的产物，我们还需要对需求进行有效管理。

需求管理：

目的：统一需求，提高需求溯源性，也是为了测试时能依据最新的，正确的需求进行测试，减少我们的沟通成本，也减少需求的不确定性

需求本身首先要能被管理，我并不提倡word版本的需求，也不提倡原型图上写需求，两者皆因为需求无法被管理

其次，当需求评审以后，不再对已评审的需求进行编辑和删除操作，原则上，我们将以取消和新增的状态进行标示。

同时，我们还要维护变更记录，让变更原因，变更内容清晰可见。

这并不是一件简单的事情，需要我们掌握一些方法，比如尝试用excel来编写需求文档，并且在需求文档的撰写过程中，遵守一些规范。

资源协调：

产品开发过程中，其实需要用到很多资源，包括内部的和外部的。

当我们需要使用第三方系统时，需要为开发同学准备好第三方系统的账号，key或者其他什么，比如第三方统计，第三方图片处理，第三方登录，第三方地图

而内部的资源集中体现在接口API 和设计图输出上，许多时候，我们都是由前端驱动的，我们设计的多数是前端的产品，比如APP， H5 ，WEB， PC ，但前端的功能需要依赖后端的接口，以及UI的效果图。

等接口，等设计图，这两种时间的耗损虽然很可惜，但却是我们经常遇见的问题，如何妥善的安排资源，如何取舍，便是我们要做的资源协调，尽量的减少等待，这需要我们知晓各个功能的优先级，复杂度，尽快进入并行轨道，避免等待。

07.验收发布

我带产品团队时，会经历两次验收，这里提到的验收是整体验收，我并不是很提倡在开发过程中频繁打包，但我也很理解许多团队，都会频繁的打包验收。

当开发阶段结束后，测试介入前，产品经理有义务进行一次验收，目的是确保主要功能逻辑与需求符合，没有遗漏需求功能，可以称之为需求验收。

当测试结束后，产品经理还需要再进行一次验收，目的是确保产品无明显Bug，能够正常使用，此时，才是真的产品验收。

需求验收：

有时，我们需要做好心理准备，也许开发实现的功能与我们的想象的有所区别，甚至南辕北辙。

我们首先需要确认一下，有没有需求遗漏的，通常情况下，会有开发漏做了部分功能，此时，我们就要判断这部分功能是否可放到下个版本迭代，还是当前版本非常重要的功能。

面对一些实现效果与预期效果不一致的功能，我们还要冷静的分析判断，开发这样的调整，能否接受，如果能接受，那就要根据调整结果，来修订我们的交付产物

原则上，我们希望尽快的切换轨道，需求验收是一个阶段，更多的却是一个节点，我们要把关，但也要灵活，尽量避免过多时间的反复调整。

如何判断哪些需求调整是可被允许的，哪些需求遗漏是可悲允许的，便是我们在这个阶段所需要锻炼提升的技能，MVP原则在这个环节也是适用的。

产品验收：

确保产品上线没有明显BUG，不只是测试同学的职责，也是产品经理的职责，当然，我们无法像测试同学一样细致，成体系，成规范的进行模拟操作。

但我们却可以从自己的角色出发，确保主要路径不出明显bug，我们需要保证业务是正常的，核心功能是能被使用的，大部分使用场景是没有明显Bug的。

同时，产品验收阶段也是我们对需求逻辑的最后审核阶段，我们的业务逻辑，功能逻辑这样做是否正确。

这需要我们站在用户的角色，真实的进行体验，可以说产品验收时，我们便是这个新功能的第一位真实用户。

当我们已经完成产品验收了，此时，我们就会通知开发同学。

没有问题，可以打包了

打包的意思是将已经验收的程序独立生成安装包，在android平台，我们往往需要打多个渠道包，每个渠道一个唯一的标示，这样我们就能知道我们的用户都是从哪里下载的。

当然，发布一个版本可不是这么简单的。

产品发布：

从硬性角度来讲，我们要为产品发布准备一些材料，比如更新文案，上传安装包以供审核，特别是IOS平台，要预算3-7天的时间进行审核，且可能审核被拒绝。

从软性角度来讲，当我们发布一些特殊的版本时，还需要配合运营的规划拟定发布策略，必要时，可以封包待发布。

即，我们将可发布的版本准备好，但却不真的发布，等待机会成熟，再进行发布。

为什么在一些重要节庆日，成熟的产品都能准时准点的上线特殊版本呢？比如圣诞节版本，如果延期一两天，是否表示这个版本的时间完全浪费了，毕竟圣诞节可不会等你两天。

特殊的版本，我们往往会提前将安装包准备好，进入封包待发布的状态，只要等待某个特定的时间，便可以直接发布版本。

08.结果分析

这是最后一个环节了，也是最容易被大家忽视的环节，我们习惯性的将希望寄托在下个版本，寄托在下个功能，却很少对结果进行分析。

当我们产品已经发布了，此时要注意观察相应，观察数据，通过实际市场结果，我们再来思考和评估。

这个功能是否被用户所喜欢，用户使用情况怎么样？有没有提高的方法？

我们知道一个页面，不同的位置，人们的点击欲望是不一样的，相同的发布功能，以点击次数来判断，右上角的发布只占底部菜单的发布的1/10。

我们需要通过产品发布后的结果来持续的去改进，去分析，为下一个版本提供总结性材料。

作为产品经理而言，我们所设计的功能，应该是越来越有效的，而不是越来越多的，我至今仍然记得一个案例。

某网站，进行了一次改版，改动内容是将注册的按钮做的比以前更突出了一些，新版本的网站，注册率比老版本的提高了30%

这里提升的是注册率而不是绝对值，因此我们可以忽略运营或者市场情况带来的影响。

如果我们每次发布后，不对结果进行分析，我想一年经验和两年经验，区别真的不大，甚至再做到第三年，第四年也是相同的。

我们在入门的时候，是以能做出产品为目的的，但当我们能做出来以后，就要学会去分析，去改进，而不是一成不变。

去年今日运营文章

原创文章，作者：爱运营，如若转载，请注明出处：https://www.iyunying.org/pm/97909.html