产品经理的工作流程

第一篇：产品经理的工作流程

一线产品经理的工作感想

只是个人的工作心得和所思所想，信马由缰一通，做产品的人能大致看得懂就行了。 没啥铺垫的，直入正题，一块块来：先上一张图

需求文档看不看

当你辛辛苦苦写出来一堆需求文档，跟UED的同学定好交互、视觉、重构;满以为技术会认真对待，但是你会发现，技术同学基本不会看你准备的一堆东西，基本是按照自己的理解来开发，当开发不下去，第一时间也不是看文档，而是看测试用例，或者直接跟产品沟通;基本文档只是QA同学对着写用例。

刚刚开始工作的时候，对于技术不按照文档开发，是比较着急上火的，经历一段时间后，发现重点就好了。产品的本质是保证产品核心功能的质量，保障用户体验，用户端和商户端的功能不能含糊;运营后台、客服后台之类的，保障功能完整和业务流畅的基础上，可以给技术适当的自由发挥;就算是前台页面，多听听技术的意见，让技术同学参与进来;开发过程中，保持沟通，对于技术提出的问题，最快速度的响应。

什么样的需求要写文档?对于功能性、涉及业务流转，状态切换，边界条件灰常多的需求，流程图、交互、PRD一个都不能少;对于非功能性的需求，提升用户体验的部分，文档可以不准备，准备好原型图，然后在上面标注出重点，交付的时候讲清楚。

todolist与优先级

产品在迭代过程中，不断有新的需求，不断有需求被完成，通过list来管理这些需求，整理的过程也是对产品思考的过程，不停问自己，这个需求用户是谁，解决什么问题，是否必要，以及是否必要现在就做?

list的好处就是，可以尽量多的记录所有需求，虽然有些天生就是被砍的命，但是list一堆需要完成的事情，对整个项目组都会有紧迫感;一句话讲清楚每个需求，标明优先级，负责人，对应的开发，开始时间，完成时间，完成状态，让项目组所有人(包括老板)，都知道我们现在有多少事情在做，已完成来多少，接下来做什么。

需求永远做不完，对于优先级安排，平时工作中最常用的就是四象限法，重要又紧急，重要不紧急，紧急不重要，不紧急也不重要，根据项目实际来做判断。

需求会议

2014年都是一周一次迭代，每周都会有下次迭代的需求会议，并不是真正意义上的需求评审，产品驱动的公司，基本就是需求讲解，交付，以及相关时间点确认

需求准备要充分

在需求会议上，面对技术和QA，甚至老大们的挑战，这是正常的，他们会问为啥要这么做，为啥不那么做，甚至直接对你的需求提出挑战：这个东西不靠谱，不可能;拍桌子打板凳的事情也时有发生;唯一避免发生的情况，就是对于需求的准备要充分;不管面对何种挑战，讲清楚数据、用户需要、和竞争对手怎么做的，基本就能说服;一般只要保持平和的心态，不会有大问题。

真有自己无法立即解答的，快速承认错误：不好意思，这个是我没有准备好，会后我再去做详细调研和准备，快速跳过这个问题，继续下面有把握的内容;会后再去完整论证，并把问题描述清楚，邮件给大家;既可以避免冲突，会后大家平和心态来对待，也便于解决。

讲好我的故事

这里应该是讲好用户的故事，为啥叫讲好我的故事，因为产品需要把自己代入到各个角色中;做过几次用户访谈，很多用户描述这样一个场景，我快下班了，拿出点评App搜索附近找吃的;运营说这个这个很烦，我需要这么这么做，其实可以这样就解决了;

客服说，这个信息在这里查，那个信息在另外一个页面，每条记录处理的时间增加多少分钟;

最有意思的是商户端，商户那边有签合同的、店长、负责人、前台、收银，会计，每个人都有可能来用我们的后台，去商户端做访谈的时候，观察他们如何使用点评的产品;

讲需求的时候，先描述用户遇到的困境，绘声绘色，动人心弦;如何做到，代入自己的角色，不要假装用过，而是自己真正使用过程中的痛点，放大再放大，感情方式来打动技术。

描述痛点只是第一步，可以清楚描述，如果这个需求做来，运营效率可以提升多少，节约多少成本，最终转化率预计提高多少，以及ROI(投入产出比)，所有功能点的改进，最后都可以结算为Money，因为钱，会让所有人兴奋，并集中精力来解决问题。

让更多的人参与需求讨论

需求被挑战，会有点不舒服;但是若所有人都表现出对你的需求漠不关心，那才是最难受的。如何让技术更多的参与需求讨论：首先可以挖掘对业务有兴趣的人，多跟他们聊，他们会主动告知他们的想法。一般工作几年的技术比刚刚工作的童鞋更关心;其次让技术有存在感，定时告知他们相关的产品数据，月用户数，月增长量，收入等，根据技术所开发的功能点，细化到此功能带来的数据，以及同比环比数据;最后在Scrum中，计划扑克能够让所有人都参与到需求当中，因为每个人都要评估task的工作量，目前来看，效果还不错。

确定好时间点和相关责任人

Scrum确实是一个好的方式，能够估算出工作量，并且技术自发领取任务，直至每个人工作内容都填充满整个sprint。

在未开始Scrum之前，每周一次需求会议，只是交付好相关需求，由开发主管来指派任务，并定好工作计划表，然后QA同学补充相关测试安排，最后敲定上线时间。

其实不管何种方式，最终的结果导向就是，产品尽快上线，且以最有效、风险最小的方式。

适当地砍需求

产品是不需要懂技术，但是如果能根据需求大致预估工作量，排期更简单;每次我都会提前多准备一些，连交互和重构都准备好，摆出一副不做此需求是誓不罢休的架势;资源充分时，技术童鞋会主动领取需求的，但是当工作都排的比较满的时候，就很难了;所以需求评审时，每个需求的优先级都排的高高的，将用户痛点描述的栩栩如生，如果技术实在抱怨太多，或是总拿51230.com那样的婚恋网站来举例，那就象征性地砍掉一部分，前提是保证核心必须完成，其实当时砍掉一部分，不会一直砍下去，而且心里也会有满足感;其次给技术紧迫感，赶紧完成，后面还有一堆事情呢，即使这次迭代不做，下次迭代也需要完成。

产品开发过程中

保持沟通

在产品开发过程中，技术都是非常有责任心的，会帮你考虑边界条件，作为产品积极响应技术提出来的各种疑问，是维系技术与产品之间很有效的方式。虽然有一些问题，可能是技术对需求的理解并没有产品那么深刻，讲清楚就好了，没有必要上纲上线，因为最终大家的目的都是为了产品，另外公司开始实践的Scrum也对整个团队保持沟通，既是要求，更要成为一种习惯。

认真对待测试用例

测试用例，又是一个保证产品质量的利器;刚开始工作的时候，认为测试用例只是QA同学的工作，第一版本App上线做UAT的时候，发现对着需求文档并不能完整验证完所有需求，但是对着测试用例，所有的主流程，辅助流程，边界条件，非功能性需求，清晰明了，感觉太有用了。所以每次都提前完成需求文档交付QA，QA在技术正式进入研发完成用例文档;在过测试用例时，产品同时参与，避免一些需求理解上的偏差，此外技术同学对着case开发，比需求文档描述更清晰，另外技术同学可以参与部分自测;UAT的时候，也是产品的参考。

需求变更与delay

需求变更是永恒的话题，Scrum中一般是不接受需求变更，其实不允许变更的本质不是需求定板不动，而是对产品提出了更好的要求，从需求调研、准备、设计、交付每一步都需要考虑周全和清楚;即使在要求严格的Scrum中，需求真的不能变更么?如果临时线上bug造成用户无法访问，技术同学是不是要停下手中工作，来排查线上故障呢。作为一个产品，不是神，尽量保证所有的需求都是合理且必要，并且将所有的需求准备工作做到位;如果还不能避免，就要影响甚至说服整个团队来拥抱变化。

正确处理需求变更

需求变更已经发生，那就赶紧处理吧。如果是产品没考虑清楚，用户调研或者数据支持出错，果断向团队承认自己的错误，没有人会责怪一个真心诚意道歉的人;并在第一时间交付变更后的需求文档、交互、视觉、重构等，并跟技术沟通如何以最小的代价，完成此次实现;若技术的工作在本次迭代已经安排很满，那考虑需求的紧急程度，适当情况下，可以放到下个迭代去完成。

若是因为行业或者市场变动，产品转型等原因，直接向团队传达变更的原因，以及接下来的产品规划，让所有人都看到一个清晰明确的目标，技术会有疑问和挑战，耐心解答，通过行业数据、竞品等角度去阐述;遇到老板变更需求，那比较简单，因为老板的需求优先级永远是最高的，但是作为跟技术直接沟通的产品，要认真对待老板变更的部分，若老板频繁变更需求，烦的是技术，会不会以后合作留下影响呢。

关于产品delay

不管产品还是技术，没有人愿意看到delay的;面对delay，怎么处理?换个思路：就算delay了，只要用户还能用，服务照样跑，地球还照样转。如果真的导致用户不能访问，整个技术团队肯定加班加点，不吃不喝也会搞好的。一旦出现delay，整个团队一起来排查delay原因，是需求变更，还是资源没到位，还是项目之间的耦合关系，前面小的改动，导致后面项目的延期，做好每次的总结会议，并在下一个迭代中避免此问题。

目前团队中正慢慢引入Scrum敏捷开发，而本篇总结，大部分是基于小瀑布模式的迭代;需要学习的还有很多，一转眼又过了两个月，正式工作已经八个月，需要走的路还有很多，跟随整个team一起成长。

算是工作总结吧，主要是自己梳理一下，路还长，继续跟着一班牛人加油呗!

第二篇：产品经理的工作内容和职责

1) 产品经理的工作内容和范围 2) 产品经理的工作方式和方法 3) 心得体会 4) 其他经验分享

第1、2节分享给对这个行业感兴趣的学弟学妹和刚入行的同学们，第

3、4节(也是本文的重点所在)整理分享了自己工作一年多来一些主要的心得体会和经验。 第1节产品经理的工作内容和范围

这一节主要解释了产品经理是做什么的，这是一个入门级问题，可能对学弟学妹比较有用吧。但是要注意的一点是，由于行业很大，随着细分领域的不同(桌面产品、web、游戏、移动终端等)、公司的不同、甚至部门的不同，不同的产品经理的职责也不尽相同，所以felix所写的只能代表在腾讯的产品项目制度下，移动客户端产品经理的工作内容。所以，当以下出现PM(产品经理)这个字母组合的时候，你要在大脑中的替换为：腾讯模式下移动互联网客户端项目的产品经理。 1)挖掘用户需求，撰写需求文档; 2)跟进产品开发过程，与项目组内各类角色成员合作以确保产品开发的顺利进行; 3)跟进发布过程，确保产品顺利发布;(包括发布策略的制定) 4)产品相关数据的监测和分析; 5)行业、市场及竞争对手的监测和分析; 6)聆听并回复用户的声音，发现产品问题和筛选有价值的需求; 7)与公司内外部的产品进行功能层面上的互利合作; 以上，1～7的部分是一名客户端产品经理必须处理好的基本工作内容，此外，还有一些事情PM也是要或多或少参与的，只是根据产品形态、公司/部门的大小，会有一些专人去做这些事情，因此PM在这些事情中的参与度会小很多： a)产品的市场宣传相关内容 重点在宣传：品牌的建立和推广、对企业等组织进行宣传合作、对终端消费者进行宣传合作、同时研究消费者心里 b)产品的市场拓展相关内容

重点在拓展市场：具体到移动互联网上的客户端产品，就是通过投入资源与手机厂商，或者产业链其他环节进行合作帮助产品通过厂商内置、后置等渠道拓张市场份额; c)产品的商务拓展相关内容

重点在商务：根据产品形态的不同，不一定会有这样的部门。作为接口，它连接产品项目组和外部的与我们有商务合作的组织或个人 d)产品的渠道推广相关内容

重点在推广：动用各种渠道类资源，帮助产品扩张市场份额;紧跟市场大盘，预测市场发展规模并制定相关策略 e)产品的内容运营相关内容

重点在运营：根据产品形态的不同，紧跟社会热点进行内容类的运营，一般意义上而言，对于大多数半年以上的产品，内容运营至关重要。(如何处理产品的可运营性和功能特性之间的关系也是PM要花时间细想的领域，这是后话) 以上，a～e的部分则一名PM或多或少要参与其中的工作。

所以小结一下，一个PM的工作范围是以上1～7和a～e的和，而主要的工作内容(也是花时间最多的部分)是1～7的部分。 第2节产品经理的工作方式和方法

第1节概要性的描述了PM要做什么，而这一节则主要描述PM会怎么做。与上面1～7相对应的顺序。

一、需求撰写 1)需求从哪里来? a. PM根据自己的专业素养(也就是感觉)体验自己产品和市场上其他产品时发现的问题或是灵感闪现出的关键点; b. 各级产品领导的直接反馈和建议

c. 用户使用中遇到的问题、困惑、以及反馈非常需要的功能点 d. 行业最新的动向

当然，以上仅仅说明了需求的来源，这大量的需求最终在前线PM这里汇总，PM根据自己的专业能力对需求进行筛选、优先级划分、推理权衡和细化，并时刻与产品核心路线进行对比校正，最终拿出产品下一步发展的方案; 2)怎么写? a. 主要工具

word、ecxel、ppt什么的、原型设计类的软件，这些都不重要。所以你可以自由的选择自己需要的工具、软件、甚至系统，自己顺手就好，所以建议时不时的换一换工具换一换心情。 b. 写作技巧

#1 开始写之前，一定要在自己的脑子里完美的想好这个功能点的方方面面(或者至少想个80%)，各种可能、各种异常处理都要想清楚; #2 写作的时候，要尽量清晰全面的把想好的东西写出来: #2.1 清晰是指逻辑清晰，一定要让交互、设计、开发、测试同学能很好的理解你想要传达的想法; #2.2 而全面是指详细，一定要详情，非常非常的详细，需求产生的背景、要怎么改善、为什么这么改善、这么改善后期望达到什么样的效果、触发条件呢(前置后置)、具体怎么改善呢(最大量的写作工作、事无巨细描述清楚你的逻辑、同时考虑所有的异常情况)、必要的流程图、适当的最终效果(这里后面还会有提及)等等等等

#2.1和2.2是一名PM专业程度的体现，一定要拿出逻辑清晰的文档，因为你是自己产品的上帝，你的每一处逻辑都会影响到千千万万在这种逻辑下生活着的终端用户，通过完美的逻辑，概念设计一个完美是世界是这个工作最有价值的部分之一，可是最快乐的部分，不要错过它。 #3 写作之前和写作之后 #3.1 真正动笔写作之前最好能先把你的想法和涉及的开发、交互沟通一下，初步判定一下可行性，否则天马星空的设计如果最终被开发判定实现不了，或者实现的成本高于你的预期，就要再斟酌斟酌了。 #3.2 写作之后的流程

自己写出来的东西还不能直接拿给项目组开始开发的流程，还要至少组织一次会议请同为策划的同事、需求相关的同事和各级领导进对你写的东西进行一次评审，这样做的目的主要有3个：

a. 帮助你检查需求的严谨性，找出错误和漏洞，讨论出更优的方案

b. 知会到需求相关方，也就是这个需求会涉及到的项目组以外的其他组织的相关同学，在正式开工前听到他们的意见，一方面可以根据他们的现实情况对需求做一些调整，另一方面可以与他们约定好后续的合作方式、需要的资源，对方准备也需要一个时间

c. 领导那里会有关于市场、产品今后发展方向的更多的信息，因此他们会帮助你评估这些需求是不是符合当前产品的发展方向、会不会/会如何影响到公司/部门在这一个点上的定位和布局、会不会比他们对这个产品的期望不符。

具体这一步的流程和在项目循环中的位置，在后面一节“项目相关的流程”那里会进一步说明。

二、开发过程

与上面1～7相对应相对应，现在我们开始讨论第2个部分：开发过程。开发过程是我们的产品从概念变成真正可贩卖的工业品中必不可少的神奇一步，是多种不同分工、不同专业背景的同学在一起协同工作的过程，很重要。后面会以如下的一个目录方式逐步讲解这里的细节： 1)项目的概念 2)项目组 #1 人(资源) #2 流程(人和人之间如何协同) 3)PM在开发过程各个阶段中的作用 #1 需求阶段(需求方全体确认需求) #2 开发阶段(开发团队集中开发阶段) #3 测试阶段(质量检查的阶段) #4 发布阶段(内测、灰度、正式发布等逐级发布阶段) #5 发布后的阶段(效果跟踪的阶段) 下面会根据这样一个目录进行说明： 1)项目的概念

项目的概念相对简单，可以理解为一个话题或者主题，很多人为了同一个目标、同一个主题、同样的利益和愿景聚拢在一起形成了项目组。这一点和公司等任何组织的形成类似。 2)项目组 #1 人(资源)

项目组里有不同的人，一般来说，一个处于开发循环中的核心项目组包括了这样的一些人：产品经理、视觉设计人员、交互设计人员、开发人员(前端开发、后台开发)、测试人员、项目经理等。

所谓的开发循环中的核心项目组是指一个形成一个产品所需要的最少(最标准)的人力配置结构，当然一个更宽泛意义上的项目组还包括了很多很多其他角色：运营、渠道、运维等等等等; 这些角色在开发循环中(显然，不在循环中的时候某些角色还有自己的独立于项目组之外的工作)的主要职责是：

a. 视觉设计人员(视觉设计，你看到的几乎每一个优美的图案) b. 交互设计人员(交互设计，你在使用产品过程中哪些举动可以获得反馈以及以什么形式获得什么样的反馈) c. 开发人员(前端开发同学的成果就是你拿到的最终安装包、后端开发同学的成果则是在服务器端的逻辑，离你看起来很远，但实际上息息相关) d. 测试人员(写过程序的同学都清楚，开发过程中难免会有各种各样的问题，有些很容易看出来，但有些要通过一定的测试手段和方式才能找出) e. 项目经理(成熟稳健的项目经理对一个团队来说非常重要，人力资源在项目中的保证和调配、确保项目中涉及的各流程的顺利运行，以及处理好项目组内成员及其分别的外部支援团队与项目组之间的关系，这些是项目经理工作的内容，所以你看到了与项目经理良好的互动和项目配合对PM的工作会有很大的帮助) ##题外话一下，项目经理的英文 Program Manager,产品经理的英文 Product Manager，所以你看到两者如果英文缩写的话会很像，因此不同的公司都会想办法在英文名上对这两者进行区分，在腾讯，公司制度上项目经理缩写为PM，而产品经理缩写为PDM，但实际上不论是在行业内还是在公司内，大家还是总是喜欢叫产品经理为PM。所以以下我会继续这样写。 #2 流程

互联网产品的一个典型的项目组内环形开发流程是这样的：

需求的撰写和定稿–》交互设计和视觉设计–》开发–》测试–》发布–》新的需求的撰写和定稿……

##所以你看到了，需求阶段是整个环形开发的起点，因此当你综合考虑PM的职责和他在开发流程中这样特殊的位置时，就会明白他是很不容易的，有很多事情需要他来处理和承担责任(背黑锅而受到指责什么的……所以新手特别是毕业生产品经理是很艰难的，类比导演专业一毕业就带摄制组出去拍摄，艰难程度可想而知，因此对于新手，在你从业的前半年到一年的时间是需要准备好随时接受来自项目组内外的压力，这里冷暖自知了，最后第3部分心得体会和大家分享一点点) 那个循环开发流程只是说项目组内需要一同经历的流程，也就是说为了协调大家各种角色的时间、更好的进行协同工作所需要的循环流程，但实际上项目组内的部分同学，除了这个流程以外，在这里的项目组里每天每周都还有无数其他的流程要走。与项目相关的，比如PM在自己的组内有需求评审的流程、比如交互设计师和视觉设计师分别在自己的视觉/交互组内都有各自的评审流程; 3)PM在开发过程中各个环节中的作用 #1 需求阶段

#1.1 加工从各个需求渠道过来的需求、撰写需求的部分就不说了，上面已经讲到了 #1.2 带着写好的需求文档经过需求评审的流程，并根据评审的建议或意见进行修改，直到达成一个绝大多数人都能够认可的需求; #1.3 和交互设计师深入交流，不要只说你要什么效果，而要全面的讲讲为什么要这样做，你达成一个什么样的目的，这样可以更好的借助交互设计师的专业知识，可以提供给你和他更开放的思路一起想出可能原先想都想不到的更好的实现方案。

## 题外话一下，如果你所在的公司和部门在你所在的项目中提供了专职的专业交互设计师，那么建议在写需求文档的时候可以使用一些低保真的原型工具(低保真!)，而不是Axure因为这样会限制你和交互设计师、以及在需求评审阶段的每一个人的思维，这绝对不是你想要的效果，所以，试试低保真的原型图吧 #1.4 和视觉设计师深入交流，不要说你想到哪里用什么颜色，同样，尽量说说你想到达到什么样的效果，至于配色什么的交给视觉设计师吧 以上1.1～1.4的部分才是一个完整的需求方确定需求的部分。 #2 开发阶段

#2.1在问题出现时权衡取舍、做出决策

开发过程中，随时会遇到概念设计阶段想不到的新状况，比如开发同学开发过程中发现有的地方不好处理、或者有的地方有两种以上的实现方案但是都有优缺点、或者某些地方要是真按照需求文档那样写会有一些潜在的风险，而以上的任何一种情况出现，都需要你，一个一线PM根据自己的经验和感觉、根据产品方向和核心价值进行权衡取舍后给出直接明确的答案：做或者不做、选A方案或是B方案、哪些损失是值得的。 #2.2 保证资源及时到位

#2.2.1 及时与某些项目资源输出方沟通

保证资源的到位是项目经理的职责，但实际上产品经理也要深入的参与其中。比如设计资源的到位情况，项目经理会保证在一个时间段内这个设计人力可以100%的属于这个项目组，但是在设计师动手之前你需要与之充分沟通，确保设计师与你向着相同的方向在努力;而当设计师输出设计资源以后，还要根据设计资源的质量(也就是能否满足需要、是否契合PM希望达到的视觉气质等等)反复与设计师沟通，这个过程可长可短，而项目组后续的很多工作都有可能卡在这里，所以PM在这里也有责任保证资源的保质保量及时的输出。(##题外话，所以如何保质保量及时也是一个问题，这里涉及到“信任”和“妥协”，在第3部分心得分享的模块，会做进一步说明) #2.2.2在项目过程中随时与项目资源输出放沟通

既然如上所说，开发过程中随时都会有新的问题，都会有项目内外部各级的同事领导体验反馈出问题，那么相应到，很多资源上的新需求，也是在项目过程中随时产生的，当有此类场景出线时，及时与相应的资源输出方(一般是交互和设计)进行快速有效的沟通非常必要。 #2.2.3 及时审核确认

每天项目都会有新的进展，每天都会有一些功能点完成、一些修复优化的点开发好，因此及时的审核确认也是PM工作的一部分，否则等到了测试阶段或者上线前的阶段再发现一些重大问题(或是与需求文档不一致的地方，你会发现这种事情时有发生)就会造成很大的修复成本，时间、人力、项目组的信心、PM被信任的指数等等等等都有可能受到不同程度的伤害，因此这也是一个很重要的部分。 #2.3下一个循环也在同步的进行

移动互联网市场正在日新月异的迅猛变化，当前行业里最雄厚的资本、最杰出的人力资源都在以极快的速度向这个领域内聚集，因此腾讯MIG去年常说的一句话就是“快比什么都重要”，所以具体到腾讯的模式下你会发现以两周或者三周为周期的项目组开发周期非常的普遍(记得一年多以前还有2个月多一个周期，那个时候PM还有喘口气的时间，这是题外话了)，因此作为一个PM，在一个正在进行中的项目周期中，你除了要做到上面的#2.2.1~2.2.3之外，还在同时为下一个项目周期做好准备，开始进行需求的撰写、评审以及其他的需求方流程。 #3 测试阶段

一般来说，在前期开发过程中，PM会进行高频率的产品自测，也就是上面的#2.2.3所描述的部分，而到了真正的专业测试阶段，PM介入的就比较少了，专业的测试人员测试出问题后大部分情况会直接反馈给开发同学，只有当有很多很多问题开发同学做不完需要PM排优先级的时候、或者是有些优化点优先级低但是可能意义非凡时，需要PM来做一些时间和效率上的取舍。(关于质量与效率等问题，在第3部分心得体会那里也会有提及) #4 发布阶段

一般情况下，在经过了专业测试之后的产品差不多就可以发布了，以后的过程可能不同的公司/部门都会有所不同，但大致上还是比较相似的： #4.1找一小撮玩家进行测试 可以找公司内的同事，也可以招募一些公司外部的玩家用户测试，这一阶段的目的是找出专业测试也没有发现的重大问题(比如安卓平台上由于机型和系统的严重碎片化，很容易发生程序在某个特定机型上出一点小状况的事情)以及听听用户对某一个新feature是否会有比较大的正向或是负面的反应; #4.2 灰度发布

还是基于万一出现问题时控制受众范围的考虑，一般我们会采用灰度发布的策略(当然这个策略的制定也是PM工作的一部分)，灰度策略制订时一般考虑两部分受众：新增用户、老版本用户。新增用户如何处理、什么比例;老版本用户如何处理、什么比例，这些问题一般通过PM的经验结合这款产品的用户规模、所在生命周期的某一特定阶段而制定。 #4.3全量发布

灰度发到100%就是全量了，也有不经过灰度发布直接全量的情况。 #4.4其他

当然，以上#4.1～4.3才不会是我们工作的全部，还有很多很多的事情需要你来做，比如提前一周左右输出发布计划给所有相关部门和人员、发布前的各种各样的资料准备、发布前和各宣传相关的渠道的交流(微博、软文、、)、发布前准备好客服公告、新版本发布时安装包里帮助文件的更新、发布后信息知会给所有相关部门和人员等等等等。 #5 发布后的阶段 #5.1 效果跟踪

可以通过很多渠道直接或间接的获得用户反馈，比如论坛、微博、Q群、帮助社区、新闻(腾讯的产品不论好坏一般都会有或多或少的行业评论)、甚至家人、朋友、同事、领导等等等等。 #5.2 数据分析

毕竟只有血淋淋的数字才能直观的证明一项新功能/改动的正确性和效果，因此版本发布后的数据分析也是必不可少的工作。数据分析这里至少将包括规模数据的分析、和各主要特性的分析两大部分，当然用户及市场反馈的部分也是一个重要的可选项。

以上1)～3)整体上概要性的描述了开发环节中PM的主要作用，而实际工作中一般要处理的事情会更多一些。

三、产品相关数据的监测和分析

这一部分讲到了数据，虽然在心里我倾向于认同PM(至少在需求的创造这一方面)实际上是一种(感性的)艺术，不应该以数据来作为唯一的判断标准进行衡量，但是醒醒吧阿宅，经济学常识告诉我们，在一个市场经济主导的经济社会里处于竞争环境中的企业内工作，这样的环境注定了用数字说话才更有力量，因为数据才代表了收入和金钱，所以艺术只能让位于商业，好吧，这么说有点冷酷，那么听听下面的说法：

另一方面，用户数据可以简单直观理性的证明给我们自己和各级相关同学：我们在做的事情是正确的!是有价值的!是想着光明的方向的!这些数据帮助你看到用户真实的想法，即使你在网上看到一堆人骂一个功能没用仅仅噱头，但看到数据显示92%的用户会频繁的使用该功能，你心里会不会踏实很多? 这里大概说一下吧，一般情况下我们更关注规模数据、操作数据和运营数据，其他的还好。

另一方面，以什么样的周期来关注数据也是一门学问了，根据公司/部分/产品/数据种类的不同而不同。

数据这里比较敏感就不细讲了，感兴趣的同学可以在网上找找书什么的，或者在工作中自行摸索。

四、行业、市场和竞争对手的监测和分析 #1 行业与市场

行业和市场信息的阅读和了解其实没有必要进行制度性的要求，只要平时多看看行业新闻就好，主要是培养自己的产品sense(这一点多用多想别人的产品也有很大帮助)和行业敏感度，这一点对热心于这个行业的新同学来说从来都不是问题吧。

值得提的两点是：

#1.1 兼容并蓄、海纳百川的心态

主观上不要轻视任何一种创意和市场行为，每一条科技新闻的形成背后都有一堆执着的人和一定的市场基础，多看多想，不要急于否定和排斥，可以多练习形成自己的观点和判断(这个阶段不一定要分享出来)。 #1.2 行业敏感度的培养与验证 当你对一个产品一个功能一种趋势有了自己的判断，即使身边的人、项目组暂时不能接受，但市场终究会给出一个答案。如果你的预见，总是能经过时间的证明(比如一段时间后在竞品的身上看到了自己原先的设计)，对自己自信心的形成会有很好的正向激励作用。 #1.3 工具、方式

一般来说，作为一个客户端PM白天你几乎是没有时间用来看网页看新闻的，所以你会比别人更需要一些移动智能终端设备比如iPhone、iPad什么的，便于你利用一些碎片时间update到最新的资讯，否则自己会很快过时，逐渐陷入到自己特定的领域内无法形成宏观的视野，也会容易缺乏自信，变得依赖于岗位。 #2 竞争对手的监测和分析

维护一张表格，周期性的检查竞品的动态，挑出一些你关注的点进行持续性的分析，知己知彼才能更好的打败对手。 第3节心得体会

现在回头看，在前面的章节中大量的许了愿要在第三节中进行心得体会的分享，千万不要有过高的期望啊，只是felix自己在工作中的一些不完全的感悟和总结(怎么可能期待我在这样的大半夜1点半回忆完整个这1年的经验呢～呵呵)，难免会有偏颇和不成熟的地方(毕竟才1年级嘛，不然以后靠什么吃饭)，仅供参考。 1)服务意识

第一点并没有提MIG内部常说的“产品经理是火车头”的概念，因为如果以那个观点作为出发点，操作层面其实比较走弯路，特别是毫无管理经验的毕业生同学。 所以根据自己长期的摸索，认为以“服务意识”作为一个PM心态的原点会比较好的应对面临的问题。这么想的原因是：

#1 首先重新审视一下我们的工作实际上是要求面面俱到，在开发循环中的任何一个环节全权代表产品团队和项目组在做一个一线的决策，因此可想而知每天可能每个环节的同学，包括各级领导都有可能来找你确认、查询、解决、反馈一些问题。确实会很忙很乱时间完全碎片化，有时也会因为总是被打断正在进行的事情，和接到很多临时性的任务而心烦意乱，所以这种时候如果认为别人的“打扰”干扰了你的“正常工作”，那你就输了，因为不断被“打扰”，不断被确认也是我们工作的一部分，因此这种时候如果能认识到“我的工作就是一种服务性的工作啊呵呵呵呵”基本上心理会比较容易摆正心态。 #2 服务的心态可以更顺利的作为一种内驱力，在项目组正常运行时提供助推剂;比如你不会独断的任务需求的产生是你一个人的事情(虽然你确实收到了比较专业的训练)，而是会用一种开放的心态与项目组内成员充分的交流;同理，很多事情，比如外部团队帮助下制定的产品宣传策略和品牌推广活动，作为一个接口人你也可以开放的分享的项目组的其他成员(当然虽然他们也许没有时间看，而你也不一定有时间这么做) #3醒醒吧啊宅，不要被“Manager”两字蒙蔽了双眼，IT业内(传统行业那个就不提了)最早提出PM概念的微软在设立“PM”这个职位之初的定位：为工程师端茶送水、预定会议室、与其他团队交流以及帮工程师团队承担来自外部的压力、并尽最大努力帮不善言辞的工程师们推销他们的想法。so ，看到了吗?其实这个职位从设立之初就是个服务性岗位，so，我把这一点作为“服务意识很重要”的最重要理论基础了。

2)“产品经理是火车头”的理解

这一句话基本上在腾讯MIG内部经常被提及，你的各级leader、项目经理，甚至开发团队潜意识里都会反复提到这个词，所以作为这句话所涉及的主体行为人，PM会怎么理解这句话呢?我的理解是： #1 执行力

输出需求的效力、保证需求尽快通过各种各样评审的效力、保证需求所涉及的各类资源的正常按时输出、保证对开发过程中出现的问题的及时解决、保证发布正常进行的效力、以及各种各样你主要处理的事情的执行力，因为一般情况下，对方的单线程和线性的，而PM会同时面对很多人很多件并发的事情需要解决，因此如果在某一个方面某一批人那里出现延误和没有处理好的情况，PM很容易被认为执行力差……所以执行力是一个很重要的要求。 #2 积极的感染力

就是怎么看怎么觉得有精神，类比各类动漫中的热血小强型角色; #3 责任感

主人公的意识，积极的涉足、主导和解决不期而遇的问题，时刻从产品大局出发权衡取舍;这里大家已经很熟了就不说了。 #4 当然，还有黑锅

如上所述，既然很多很多人的很多事情都与你有关，那么进度卡在你这里、或者你没有说清楚、或者你没有提任务、或者你没有早说……就都是你的责任了，这种情况下一方面参考一下#1的解释调节调节，认真你就输了;另一方面，可以通过一些制度性的行为为自己提供支持，比如及时邮件什么的。 3)信任、妥协、营造气氛

这条几乎上升到了方法论的层面，这两条其实说大很大说小很小，灵活应用的话效果会比较好。 #1 信任与妥协

上面第二部分说了，PM所在的项目组中有各种各样的角色(项目组外也是)，每个人都有自己的专业分工，所谓“术业有专攻”，其他角色顶着自己的帽子、带着自己的头衔，一定是在自己的专业领域内受到多年理论和实践打磨的，为什么你不相信别人的专业素养却要求别人相信你的眼光?所以信任很重要。

所以毕业生PM来公司如果立马就开始背诵“产品经理是火车头”，并且希望自己在任何一个领域内的看法都被严格执行的话，基本上立马会躺枪，因为你的看法在某一个特定的领域内是不成熟考虑不全面的，所以在有些时候当你意识到在这个领域内有更专业的人可以贡献力量的时候，“妥协”吧!因为大家的目标是一致的(妥协的理论基础) #2 营造氛围

如果能在一定时期里项目组内，特别是需求方内部(产品、交互、设计)大家都能比较好的做到信任和妥协，就有可能形成一个良性的循环，其结果是PM的工作会轻松一些，而项目组的效率会更高一些。(眼熟么，有点像微观经济学博弈论里囚徒困境中双方互信时的情况，各方的利益都能最大化并且组织的利益也得到了最大化) 4)承受压力

当然，你要做很多的事情，你要接触不同的人，会会有很大很大的压力，在上面的第2节、第3节的2)#3里也略微讲到了如何面对压力。这里再稍微说一下 #1 正向操作

#1.1 尽量让各级领导和你项目组中的同伴了解到你工作的内容(虽然很难，因为在项目跟进时PM的工作量很大但很琐碎，每一个点要花的时候都是不定且很难预估的) #1.2 多和前辈沟通或者买些书来看，积累理论工具和有效的方法论。压力不会凭空产生的，压力一定是依托于某件或者某一些你可能面对不了的事情而发生的，因为你需要经验的积累(理论工具!)和处理这些问题时可行的方法，这会更治本一些，从根本上减轻压力。

#1.3 同理，为了直击压力本源，你需要更好的解决问题，那么可以尝试借助更好的工具(新电脑、新键盘、iPad、Mac、)或者其他人的力量帮你提高效率、分散压力

#2 中庸缓和型操作

如果压力太大，可以看看电影逃避一下什么的，或者洗个澡按个摩什么的，或者找个哥们喝一杯什么的、或者冲动性消费一下什么的，或者暴饮暴食什么的(虽然不建议) 5)平衡效率和质量、工作和生活的关系 #1 效率和质量

工作中的事情很多?而且总是在限定的时间内要求有结果，那么其实对于PM来说随时都在面临一个效率和质量的问题，要效率高，必须赶在时间点到来之前完成手上的所有的事情，那么每件事情的完成质量可能就会有偏差，难免有些情况会不符合别人的预期;而如果重视质量，有绝无可能在限定的时间内完成我们在上面提到的海量的工作，效率必然有损。所以如何平衡效率和工作是一个很重要的问题。如果达到这里的平衡就要看自己了，如果处理不好很容易自己累死累活但吃力不讨好。 #2 工作和生活

工作很重要，那生活呢?显然，作为一名PM你也许会很少会有休息的时候，周一到周五累死累活工作到很晚，周末两天光是补觉洗衣服基本上就没有时间了，这样当然不好!时间长了，随随便便一个契机一个场景坐在那里喝着咖啡就该开始走神感慨，我的生活为什么会是这样?这是我要的生活吗?如果不是，那这样生活的意义何在? 所以为了避免这种困惑的发生，为了缓解孤独寂寞冷，尽量调节自己的生活吧，给生活更多的时间。如果你没有妹子的话，去找个妹子吧。如果你异地的话，找一种爱好吧，比如电影、运动、看书、桌游或者单纯一点：吃! 6)被信任

第3)点提到了信任，那里的信任其实更多的是指PM对其他成员和角色的信任，那么反过来呢?如何被信任? 凡是讲PM工作的书基本上都会提到PM个人影响力的构建，主要讲得就是如何被信任这一永恒的话题。每个人都会有自己的方法，但基本上都是要不断的通过自己的努力累计被信任的成功案例来逐步达到这一点的。有点类似恋爱中的男方操作技巧不是吗? 第4节其他经验

这里就很松散了，不能也不可能总结完所有的经验，在操作层面出现的问题、总结的经验还是要自己亲身体会会来的直接一些。所以像什么会议之前xx、会议之后xxx，充分沟通，邮件电话之类的工作技巧就没什么可分享的了，而且隐隐觉得此类办公技巧真的写出来会被大牛嘲讽什么的…… 所以谈谈其他一个更重要的话题吧，那就是健康!!! # 健康

一定要保护好自己的身体，时常锻炼一下什么的(虽然这一点我做的也不是很好，现在我坐到下午5点多的时候差不多就要开始腰背酸疼了…然后要挺到

8、9点…)

结合上面提到的“效率与质量、工作与生活”的章节，尽量给自己的生活留下充分的时间。培养至少一种自己愿意坚持的运动类型，这样不仅可以强身健体，更可以换换心情。

没想到一直连载了两天，长达4次更新才写完这篇文章，这一次总结的有点多了，下次吸取教训框架可以搭的小一点就不用这么面面俱到了。

第三篇：互联网产品经理的工作职责.

三、开发及项目管理 3.1、需求确认: 组织协调市场、研发等部门,对需求进行评估及确认开发周期; 3.

2、项目跟踪: 跟踪项目进度,协调项目各方,推动项目进度,确保完成项目按计划完成;向领导及相关部门沟通项目进度; 3.3、产品测试: 配合测试部门完成产品的测试工作;BUG管理;

四、产品运营 4.1、流程制定:

组织客服、运维部门,建立用户问题投诉、意见反馈及其他产品相关的工作流程、分工、响应时间要求; 4.2、协调沟通: 与公司领导、相关部门协调资源、沟通产品发展规划、产品发展现状及问题; 4.

3、对外合作: 与合作方商讨合作可行性、方案,参与商业合同的编写,跟踪项合作项目的进度、完成; 4.4、问题处理: 跟踪产品运营过程中出现的故障、问题,并进行总结、分析,制定解决方法或纳入到产品改进计划;协助市场、客服、运维部门,解答或协调解决用户提出的产品问题; 4.

5、数据分析: 组织建立并逐步完善业务数据分析系统,确定数据报表样式,建立日/周/月报制度,整理并定期向相关部门提供产品运营数据;对产品数据进行监控,分析产品运营效果、用户使用行为及需求,以便对产品进行持续性优化和改进; 4.6、文档编写:

人人都是产品经理(woshipm.com中国最大最活跃的产品经理学习、交流、分享平台

第四篇：产品经理跟产品市场经理的区别

MartyCagan是享有世界声誉的产品管理专家，曾经担任网景副总裁、eBay产品管理及设计高级副总裁。本文是他回顾自己二十多年来从事软件产品管理工作的总结和经验分享，谈到了产品管理与产品营销的区别与合作关系，最后总结了导致产品失败的常见原因。

产品管理与产品营销的区别

业界权威指出市场上多达九成的产品未能实现既定目标，因而是失败的。即使你的产品不在此列，我依然觉得大多数产品构思拙劣、尚不成熟，可用性差、毫无价值的产品随处可见。

导致产品失败的因素很多，我会尝试从不同角度分析其原因。但我一直认为，最根本的原因是公司对产品经理的职责界定不清，担任这项工作的人缺乏专业训练。我一直在思考这个问题，因为它触及了产品经理的核心工作职责。

产品经理的工作是从细节上定义开发团队开发什么产品。市场营销的职责是对外宣传产品。两项工作天差地别。

为理清职责，我坚持为每款产品指派一名专职的产品经理，负责定义产品(将产品需求和用户体验设计相结合)。然而我发现企业常常会陷入以下三种误区。

1. 由市场营销人员定义产品：由产品营销经理或所谓的“产品经理”负责收集高层产品需求，然后直接交给开发团队开发。这种方式忽略收集详细产品需求的步骤，回避探索(定义)产品的艰难决策过程，也绕开了用户体验设计。

2. 两人分担定义产品的工作：定义产品的工作分给两人完成，产品营销人员负责高层商业需求，“产品经理”负责低层产品需求。

3. 一人兼任两项工作：产品营销人员兼任产品经理的工作(有些公司称这类人为产品经理，有些公司还是叫营销人员)。

下面分别讨论这三种情况及其引发的问题。

由市场营销人员定义产品

这种情况很容易辨认。这类“产品经理”可以为产品团队提供市场营销资源、制作数据表格、培训销售队伍、为产品命名和定价，但是一旦涉及定义产品的具体工作，他们就无能为力，只能袖手旁观。我推荐大家工作之余看看呆伯特(Dilbert)系列漫画，作者用了大量笔墨描绘这类“产品经理”。

这类“产品经理”或许擅长市场营销，但是对详细定义有价值的、可用的、可行的产品往往束手无策。除非他们不但具备营销技能，还掌握管理产品的方法，那么产品还有成功的机会，否则只能寄希望于其他人(比如主程序员、交互设计师、公司高管)挺身而出，担起真正意义上的产品管理工作。然而，更常见的情况是产品从一开始就因此陷入了麻烦。

我第一次接触产品管理工作时，遇到的就是这种棘手的情况，从而导致我以前对产品经理没什么好感。幸亏后来遇到一位贵人，他让我明白了产品经理的真正职责。从那时起，我就开始强调产品经理的作用，并致力于重新定义产品经理的工作职责。

两人分担定义产品的工作

没人单独负责管理产品，这种情况也很常见。产品营销人员(有时被称为“业务责任人”或“商务产品经理”)负责收集高层业务需求;产品经理(在敏捷开发团队中也被称为“技术产品经理”或“产品责任人”)负责收集低层产品需求。

问题在于两个人都不是真正的产品责任人，没人对最终的产品负责。而且这种模式是基于错误的观点，即认为可以脱离具体需求(尤其是脱离用户体验)定义高层需求。

这种模式让产品经理的工作蜕变成制作各类文档，不但令人沮丧，而且限制创新思维，很难做出成功的产品。

大公司由于业务部门较多，很容易陷入这种管理产品的模式，它们常常为此苦恼，却找不到原因。

一人兼任两项工作

很难找到同时具备产品管理能力与产品营销能力的人。管理产品与推广产品都对产品的成功至关重要，都需要专业的技能，但两者的要求大相径庭。虽然我认识一些能够从容驾驭两项工作的天才，但这样的人少之又少，而且这种团队模式的扩展性很差。即便是最简单的产品，也应该由专职产品经理投入全身心进行管理。让产品营销人员兼任产品管理的工作，即便他具备两种技能，也没有精力把两边的工作都打理好。

开发企业级应用软件的公司，由于非常倚重销售，最容易出现这种问题。销售代表原封不动地把大客户的需求传达给产品经理，再到开发人员。不用说，这样做很难开发出有价值的、可用的产品。

上述三种模式背后都有其原因，认识这一点很重要。很多公司没有意识到错误的模式给它们带来了多大的损失。它们浪费时间，开发出的产品却不是客户想要的，或者只能勉强使用。

解决方法

要解决这些问题，必须清晰界定产品经理和产品营销人员的职责。产品经理负责详细定义待开发的产品，让真实的用户验证产品。产品营销人员负责向外界宣传和推广产品，包括产品定位、产品动态、产品价格，负责产品发布，为拓展市场销售渠道、组织重点营销活动(如在线营销)、促进产品销售提供支持。

请注意，我这里强调产品管理重要性，并不代表产品营销不重要。恰恰相反，我认为产品营销很重要，好的产品营销可以创造巨大的价值。只是这与讨论产品经理职责关系不大。

产品经理和产品营销人员应该经常沟通、展开合作。一方面，营销人员是产品经理获取产品需求的重要来源;另一方面，产品经理是营销人员获取市场营销信息的重要来源。

最后，无论头衔或者组织形态怎么变化，我相信所有成功产品的背后都有一个 全权负责定义产品的人。

请记住：如果产品经理定义的产品没有价值，不具备可用性和可行性，无论开 发团队多么出色也无济于事。

第五篇：产品设计体会产品经理与项目经理的区别

有一句话说的很精辟：

产品经理——靠想。产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润的。

项目经理——靠做。项目经理是把事情做正确，把事情作得完美，在时间，成本和资源约束的条件下完成目标。

从管理的角度讲,项目经理是纵向的,而产品经理是横向的。

产品经理关注的是做正确的事，关注的是产品生命周期，关注的是产品是否能够赚钱，能否持续的赚钱。因此产品经理必须要能够规划整个产品的架构和发展路线，能够确定产品的定位和受众，能够预计产品真正的价值和效益。

项目经理是需要正确的做事情，即按照产品规划制定的项目目标正确的做事情。项目能够按照目标完成则项目就是成功的，如果项目的产品不能真正盈利往往则是产品规划出现了失误。

例如我们姑且理解项目经理是一个开发部门的项目经理，那么他一定是对某个产品进行开发的管理，负责开发的进度，开发过程中的协调，供应链等有关开发方面的问题，他最大的目标是时间第一，立项目标达成第一。并不会很尊重产品本身的市场需求以及业务逻辑的问题。

在一个公司中类似这样纵向管理的部门都是一个个职能部门，例如市场部，主要负责推广，销售部主要负责销售等，而产品经理是横向管理的，也就是说他将负责某个产品或者某个产品线从商业计划市场竞争开发需求推广方案渠道策略物流等各个方面。当然产品经理不一定是决策人，每个公司对产品经理的权限限制也不同，但是产品经理一个产品线从头到尾的重要参与人。想做好产品经理需要很多方面的才华和技能，他也是一个公司中最适合培养复合型人才潜力的职位。

一个产品经理可能没有权利，但是一个产品经理要善于运用同事关系，客户关系去协调去促进事情的发展，一个项目是属于项目经理开发的，他有开发目标达成的责任。而这个项目也是属

于产品经理的，他有对商业计划负责的责任。因此作为产品经理就意味着的和本产品有关的事，不论是开发生产推广销售成本物流渠道都是你的问题!

如果希望做一个复合人才就选择产品经理，如果希望做一个专注人才就选择项目经理。(iamsujie补：对这句话持保留态度，做不同的事情而已，没法用通才、专才概括)

产品生命周期和项目生命周期

产品生命周期关注的是整个产品从规划到制造，再到最终维护和消亡的整个过程。一个产品往往会由多个项目来实现，也可能分多个迭代周期来实现。由于项目有特定的目标，一般产品制造出来通过验收则项目生命周期就算完成。而产品生命周期则不同，既包括了项目开始前的预研，评估和可行性研究，也包括了项目完成后产品的维护和废弃。

产品管理和项目管理

产品管理的目标是产品，是产品生命周期;而项目管理的是项目生命周期和项目目标的实现。产品管理关心的是产品能够真正的赚钱和创造效益，因此前期的项目分析决策，后期推广都很重要，跟产品管理相对应的是组合项目管理。IPD集成产品开发是产品管理常用的方法论，其中两个重点就是组合项目管理和研发流程管理。

项目管理关注的是项目能够按照既定的目标顺利完成。产品究竟应该规划哪些Feature不是项目管理的事情，而是项目管理的范围输入。项目管理始终关注的是进度，质量，成本和范围四个要素，要把项目做好则首先需要保证过程的稳定性。在软件项目管理中需要综合考虑工程，项目管理和支持过程三个方面的内容，因此实施CMMI或其它一些敏捷的项目管理方法论是可以保证项目管理成果的重要方法

项目经理与产品经理另一个重要区别是授权的范围不同

项目经理一般是被授权的合同履约的负责人：

项目合同是规定承、发包双方责、权、利具有法律约束力的契约文件，是处理双方关系的主要依据，也是市场经济条件下规范双方行为的准则。

项目经理是公司在合同项目上的全权委托代理人，代表公司处理执行合同中的一切重大事宜，包括合同的实施、变更调整、违约处罚等，对执行合同负主要责任。

当然，根据企业的不同，老板能否给予项目经理相应的授权是另一回事。

产品经理的授权是保证流通链的畅通：

产品经理保证其所负责的产品，从上游创意、研发开始，至采购、生产，到下游渠道、通路，直至终端用户的整个流通链的畅通，因此要求产品经理既要有产品知识，也要有市场意识，还要具备协调能力，例如：财务、售后、物流……

但是，产品经理并无对外签订合同的授权。