产品经理的核心价值

 

在足球场有那么一群人，他们凶狠的拼抢不断的传球、他们思维敏捷视野开阔、因为处于兵家必争之地所以往往血溅当场、他们是球场上的 发动机，控制着全场的节奏、他们调配团队的资源，把球精准的传送到最有机会的队友脚下，这群人就是中场核心，西班牙的中场核心，大师级人物—哈维。

在现今的互联网行业中也有这样一群人，他们被称为“产品经理”。

互联网并不像世界杯具有80年的历史，所以团队中的人员分工和定位相对模糊。特别是近几年才在互联网出现的产品经理这个工种，已经有越来越多的人参与到讨论产品经理的核心技能、核心职能、核心价值是什么的问题中来。

在此，仅和大家讨论一下产品经理的核心价值，我想，只要认清了自身的价值所在，其他的迎刃而解，或者根本无需解。不管黑猫白猫只要能抓到老鼠就是好猫，无论你用什么方法、无论你是否有职权。

用了大量的内容来把产品经理的核心价值一层一层的剥开。

首先，整理一下互联网中的产品生命周期都会经历哪几个阶段。

需求收集、设计规划、开发、上线、运营推广或者市场销售、在市场和运营过程中产生新的需求、新功能的设计规划、开发、上线…… 一直迭代下去。“产品经理往往需要贯穿在产品生命周期的这整个流程中。”这是现在很多产品经理的理想。

好的，我们继续往下剥。将产品的每个阶段逐个分解，看看产品经理在这个过程中所起的作用。这是很重要的一步，所以我会说的尽量详细。

一、需求分析

在这一步，很多的产品经理花大量的精力去承担文案撰写的角色，这是误区！因为还有更重要的事情需要产品经理在这个时候去做。

1、了解公司的战略目的

也许“战略”这个词有点冠冕堂皇，可是产品的未来与这一步息息相关，所以不妨提到这个高度来讲。以我的经验，互联网公司要推出一款产品的动机大致四种

A复制 ：看到市场上同类的产品比较成功，结合自身的资源觉得可以效仿。对于这类产品公司仅能看到眼前利益，远景不明朗，需要一边做一边调整，结果多数是大起大落。例如最近狂热的团购。

B干扰 ：商场如战场，很多企业会玩声东击西的策略，用一些无关痛痒的产品吸引竞争对手的注意，以欺骗或者干扰对手的注意力，掩护自己的核心业务平稳的发展。此类产品往往成为炮灰。

C打圆场 ：对于上市公司而言，为了给资本市场一个好看的答卷，经常会用一些莫名其妙的产品来滥竽充数，虽然对用 户和行业没有任何意义，但是可以让股东和股民看到企业的产业链条是圆满的。此类产品多数是企业的纯消耗品，因为没有实际的盈利模式，所以都是其他产品在养 着他，其结果是没有地位。

D战略性产品 ：很多互联网企业从大众市场纷纷开始进入细分市场，这就要求企业敢于创新，在创新的过程中往往伴随 着很多改革，企业会从新定义市场、制定新的目标，推出新的产品，希望改变现有的盈利模式和业务框架、市场格局。这便有了所谓的战略性产品，例如腾讯的拍 拍、百度的有啊、新浪的博客、阿里的支付宝，其中有的成功、有的还不明朗，这也正是此类产品的特性。创新和改革的路上异常艰难，很可能这个产品与现有的很 多业务冲突、与现有的部门利益不协调。而且企业不会像中央政府那样搞十一五计划给你5年时间，也许你只有半年，所以这要求产品经理要具有很强的把控能力和 坚强的毅力。

作为产品经理只有去了解这些才能预想到今后的工作中可能遇到的问题、可能争取到在资源、可能投入的精力、可能组建的团队规模、可能遇到的瓶颈和坎坷，未雨绸缪才成为可能。

所以，不建议一开始就埋头设计精美的PPT、华丽的demo，应该去了解公司做这个产品的目的和动机。

2、了解市场需求

这里也有个误区，很多产品经理通过所谓专业的分析方法例如swot和大量的百度搜出来的数据做出来一个东西，就算交差了。而很少去考虑为什么要去做市场分析，如果我们每天把很多时间花在应付那些不知道为什么做而做的事情上，将很容易被淘汰。

我认为的目的有三个

A、试探 自己的思路与公司的思路是否有偏差，适当的在公司原有的想法上做扩展 ，加大公司对产品的兴趣 。

B、给相关部门吹风 ，特别是业务团队和运营团队，他们手上正在卖或者正在推的产品可能有很多，你的产品市场优势在哪里？也许不能让他们马上兴奋起来，但是至少应该让他们关注或者积极的反馈意见。

C、自我梳理 ，写的过程就是想的过程，想的过程就是辩证的过程，很多思路会在写的过程中迸发出来。

所以，市场分析可以包含以下内容：产品对于行业的价值、在市场发展的环境下产品可能的生存空间、产品在市场价值链中所处的环节、预期的市场回报。

关于用户需求这里就不多说了，有很多这方面的文章。

到这里，需求分析阶段算是尾声了，总的来说，产品经理在这个阶段最大的意义就是给产品建立意识形态，有点类似军队出征前的誓师大会，虽然很虚，但是对将来的工作很有帮助。

二、设计规划阶段

在这个阶段，开始有越来越多实在的交付物出来，例如：产品规划方案、产品demo、需求文档等等。

1、产品规划方案

无论这个方案是不是由产品经理本人来做，产品经理都应该要求这个规划方案中说明白几个问题：

（为什么做）产品背景和需求说明
（做成怎样）功能说明
（如何实施）里程碑和时间计划
（回报）投入和产出比
（如何经营）运营策略
这是产品从虚到实一个很重要的过渡，把之前天花乱坠的产品思路通过这个方案告诉大家如何实现，并且是有计划有里程碑式的实施。

如果把产品经理比喻为一枚陀螺，这个方案BOSS拍板的一刹那将成为陀螺的分水岭，在这之前鞭子缠绕着陀螺在蓄力，拍板声一响鞭子猛的抽开，产品经理就开始疯狂的忙开了。

2、产品demo

有了需求，自然就有了功能，各种功能组合生产了功能模块，功能模块就搭建起一个产品的框架，在这个产品框架下有哪些系统提供支持，最终画出产品大概的样子。于是功能模块、产品框架、系统架构、低保真原形打包起来就生成了一个产品demo。

产品经理可以拿着产品demo去评审验证了。听取交互设计师的意见、听取视觉设计师的意见、听取前端工程师的意见、听取开发工程师的意见、听取业务和市场的意见、听取用户的意见，陀螺陀螺疯狂转吧！

如果你发现这群鸟人，之前鸦雀无声，现在忽然噼里啪啦的开始拍砖，不要觉得奇怪。眼见为实，大家只有看到你产品的样子才能发表各种意见，而且这些意 见还多数是在抠细节。听取意见的过程中，产品经理不会忙于辩解，思维像陀螺似的转起来，意见是否采纳，更多的决定权还在于产品经理，所以你要能够识别各种 意见的出发点。有的人会从专业角度、有的人会用改变功能实现方法减少自己的工作量、有的人会站的自身利益的角度、有的人会站在伪用户的角度。如果你应付不 来，可以把大家的意见记下来，回去好好的考虑。如果一些问题非得会上就定结果，先明确轻重缓急，实在不行就中场休息借机场外求助。陀螺陀螺效率的转起来 吧！

关于需求文档，这个就不用说了吧！

在这个阶段，产品经理除了协调各方，还应该想办法建立一种沟通机制，让团队高效的工作。在很多互联网企业，产品是没有独立团队的，都是线条式的贯彻在各部门。

三、开发阶段

这里的开发是广义的，包括UI设计、前端制作、程序编写、运维支持

这阶段提几个建议：

做设计和开发的都不是好惹的鸟，要么极具个性、要么孤傲、要么执拗。其实这和他们的工作性质有关，创意是需要时间和空间的，建议产品经理们能尽量的 满足他们，也许时间是公司敲定的，但是一个良好的发挥空间还是可以提供的。在上面说的广义开发过程中，产品经理往往会遇到很多新的需求，要么是BOSS直 接发话、要么是市场部门临时兴起、要么是产品经理自己遗漏。怎么办？要不要加进去？衡量一下吧，如果是影响到核心功能的可以加，如果是边缘化的东西建议放 在第二版再加，否则有新的需求就加，这个产品很难在原定计划上线，而且干扰了开发人员的发挥空间，好不容易安下心来思考，又忽然来了新的需求要做，谁都不 乐意的，何必呢？相互多一点理解，就少很多抱怨的。

人无完人，没有哪个产品经理能把产品的方方面面想到100%的程度，所以开发过程中，开发人员会有很多问题需要确认，这些问题需求文档里面被遗漏了，所以产品经理需要留有足够的时间给开发人员，如果自己很忙也需要安排一个专人负责协调。

此时沟通的事情占用产品经理的时间不多，所以可以开始花时间考虑产品相关的文案了，这部分我在之前的文章《构建完善的互联网产品文案体系》 中有讲到。这个体系的内容如下：

产品上线之后再做就耽误了，也许这些文案不用产品经理本人来做，但是需要把你的想法和对产品的理解灌输给做事的人。不是所有产品都需要这些文案，相信大家能区分。

四、测试阶段

相信有很多互联网公司没有专门的测试团队（QA），甚至忽略了测试这个环节，所以更多是要求产品经理在短时间内协调分工来完成。问题就产生了，没有 专业的团队所以测试的结果可能会有遗漏、测试的周期很短所以有的问题即使发现了也需要放到产品上线后解决，这些仍然需要产品经理来协调和分工。

不要抱怨了，把精力放在解决问题上。这里有几点建议：

A、让自己专业起来：在没有专业的测试队伍之前，产品经理就是最专业的测试人员，只有这样要求自己，上线的产品才能做到尽量完善。

产品的测试包含三个重要的环节—功能测试、性能测试、用户测试

功能测试的内容有很多，曾经在某集团任职的时候，公司推出一个SNS社区，其中测试用例一共7130个，QA部门至少需要测试7130个功能点。朋 友们可能很疑惑，觉得怎么会有怎么多的功能点需要测试呢？这里截个图了解一下专业测试团队是怎样测试的，特别是对每个测试用例的描述。

虽然专业，但是仍然无法避免问题的出现，所以微软的团队也在不断的在给产品打补丁。提这个的用意在于，不要因为测试的问题成为产品发展的牵绊。作为产品经理仅需要在五个方面做功能测试就差不多了：

A功能流程： 根据之前定义的功能模块，以模块为单位分担出去，分担给谁？部门总会有些机动的人，如果没有可以找前端或者UI，引导他们在测试样式和界面展现的时候以功能操作为前提。系统的流程就不多说了，一个功能从头到位走一遍。
B前端与数据库响应： 在我们的影响中，一定能够找出数据存储量最大最频繁的功能点，例如个人空间的日志、相册、视频、签名、好友动态等等。测试的时候需要做的仅是操作界面发布看看前端页面是否及时响应，如果之前要求的是同步，测试的时候发现延迟5分钟，说明前端提出数据的时候出现问题。
C浏览器兼容： 万恶的浏览器，没有更好的办法，一个一个测吧，可以交给前端开发去测，谁希望自己辛苦做出来的页面用户看到是变形的呢？
D系统规则和机制： 在产品设计的过程中，会有很多的规则和机制穿插其中，例如排序规则、录入和显示的字段最大长度、用户的积分经验值等等。注册几个账号开始模拟用户的角色测试吧。
E模拟用户角色： 这里的用户是虚拟的，我们只需要关注其是否能达到目的，暂不去考虑过程的体验。

性能的测试，需要产品经理预估一个用户的峰值，然后可以让开发人员去做评估，看看在这个可能的峰值下系统是否还能正常稳定的运行。

用户测试不细讲，网上有很多相关文章。

在一个月黑风高的深夜，产品上线了！有的人告一段落、有的人兜里揣着项目奖血拼去了、有的人休假旅游，唯独有一个人，产品上线对他来说仅仅只是开始，他需要从一个战场转移到另一个战场，这个人就是产品经理。

这里出现了第二个分水岭，有的产品经理会在这里停下，回头负责另一个新的产品。而对于另一部分产品经理来说，公司给他制定的KPI不仅仅只是产品上 线，还可能是诸如用户量、活跃度、信息量、转化率、购买率、续费率等等被量化的数据。所以这也成为产品经理积极讨论的问题。因为产品经理被细分了

A、规划型产品经理： 只负责产品前期的规划，然后把规划交给需求部门梳理，完事！这类产品经理表达能力很强，无论是语言还是文字图表。但是因为无法参与产品核心的设计，所以往往成为BOSS的代言人。

B、需求型产品经理： 更多的负责收集和处理各方面的需求，并且从设计和开发角将讲需求转化为需求文档，完事！这类产品经理协调能力很强，往往能成为产品对外沟通的枢纽。但是因为没有深入到产品的业务和市场方面，所以在需求的权重排列上会很踌躇和痛苦，往往成为背黑锅的人。

C、设计型产品经理： 更多的负责产品的可视化设计，例如产品demo、交互设计甚至是UI设计等等，完事！这类产品经理善于把握细节，而且思维活跃。但是往往因为太注重细节和完美，导致很多想法被强势的业务和市场团队压制，很多想法无法实现，非常痛苦和挫败。

D、市场型产品经理： 主要负责产品在市场环境下的运作，承担了大量的市场指标。这类产品经理拥有很强的市场嗅 觉，而且市场资源丰富，产品上线之后交付给他们打理。但是因为此类产品经理在前期很少参与产品的设计和规划，所以其对产品的理念以及卖点与产品初衷会有偏 差，而且会出现利益为先的情况，影响到产品长远的发展。如果此类产品经理把控能力不强，很容易出现产品频繁的调整方向，最终被其他业务合并或者被公司搁 置。

从产品经理的分类来看，要找到产品经理准确的定位和定义，并赋予其核心价值真的不是容易的事情，何况每个企业都有自身的特点和组织架构。

我们把思路拉回来。产品上线以后就到了第五个阶段

五：运营和市场销售

我经常把运营分为四大块内容：

A、产品包装 ：产品要面向市场，就需要做包装，例如建一个网上展台（产品专题）阿里的诚信通 263的企业邮箱 腾讯儿童频道 。除了这些还有宣传材料（宣传彩页、海报、易拉宝）和公关软文。

B、对外合作： 包括推广合作、数据对接、功能整合、利益分配

C、公关推广： 媒体互换、寻找G点（市场的兴奋点）

D、策划活动： 会议营销、网民线下活动

以上这些工作，也许不需要产品经理本人去实施，但是必须产品经理提出来，并辅助具体实施的人完成。

不是所有产品都有市场销售行为，因为有的产品更多的是支持核心的业务发展，例如论坛、公司内部OA、统计系统、CMS系统等等，但是对于业务要往外出售的产品来说，市场销售这个环节产品经理至关重要，有很多事情值得做。

A、植入业务体系： 很多企业的业务体系并非只销售你这一个产品，所以如果利益关系不处理好，很容易出现好产品没 人卖的现象。例如：公司给销售员的考核时每月30万，也许你的产品定价5000而且属于年费，而销售员卖一个广告售价10万，那么对于他们来说要完成本月 业绩是去强攻3个广告还是卖60个你的产品呢？答案很显然。所以产品经理必须努力的推动产品最终深入到业务体系中去，调整产品的提成也好，捆绑打包也罢， 总之好产品是卖出来的，而绝非设计出来的。

B、协同作战： 与业务体系一起，找出产品的卖点，包括产品销售过程中的一些话术、容易遇到的问题、客户对产品的兴奋点，都需要产品经理去发现，并且努力做到可复制性。

C、参与制定产品定价： 产品的价格能不能根据不同的客户类型进行分档，分档的依据是什么？功能如何区别？

D、建立市场需求反馈通道： 市场需求的反馈有通道么？畅通么？如何应对这些需求？是定期和销售员沟通还是参与市场行为？如何识别哪些是客户的需求、哪些是销售员从自身利益出发的需求？

陀螺陀螺转啊转！

对于产品经理的核心价值，在这个层面我们剥了很多内容，朋友们是否隐约感觉到了产品经理核心价值所在？如果还不能确定咱们继续剥。

说完了产品生命周期中的几个阶段，现在提一下产品经理在这个周期中所要沟通的对象，关于这方面我在《产品经理的前世今生》 一文中有较详细的说明。这里仅用一个图来说明

蓝色的线条代表了产品经理需要沟通的对象。这也是产品经理核心价值的一部分。

现在咱们回顾一下，产品经理在产品的整个生命周期中其实就做两件事情。

第一件事情是“合”： 表现为收集各方面的想法、需求、资源、工作内容和节点

第二件事情是“分”： 产品可能涉及到的部门和角落通过产品经理这根导管精准顺畅的传输出去，传输的对象可以是各部门、市场、用户、合作伙伴等等

不要再纠结下面这张图了