产品经理的主要职责.doc

.在启示录中，主要对产品经理的主要职责进行了二项分类：1、评估产品机会产品的需求来源很多，可能是高层的意见，可能是市场用户的反馈，可能是产品团队的点子，也有可能是专业人士的分析，而这些点子总是会掺杂部分伪需求和不占大多数的个体需求，需要有人来进行统一的审核和取舍，也就是常说的对产品做减法。在初期只专注于产品的核心需求，产品经理就是负责这项工作的人，这项工作也是产品经理工作的重中之重，这项工作是在产品的概念化阶段完成的,交付产物为商业需求文档(BRD)、市场需求文档（MRD)。2、定义要开发的产品当评估产品机会结束以后，如果得出的结论是产品依旧可以开发，那么就要有人来将这个概念化阶段的需求功能点，转换成UI设计师、开发人员、高层能看懂的产品模型。主要工作是制作产品的线框图（axure即可完成）和主要复杂功能的流程图（例如：支付流程图-visio即可完成），在完成原型之后，邀请目标用户，对原型进行可用性测试，验证自己的想法能得到用户的积极反馈。在这一阶段，产品团队的交付产物应该是产品需求文档（PRD)(不一定是word格式，现在提倡的在axure中进行批注是一个不错的方法），这一阶段完成之后，产品就进入了开发阶段，产品团队要做的保证开发的顺利进行和开发出正确的产品。启示录这本书中对产品经理的主要职责，进行了以上两大类，并没有将产品经理的其他细化职责归并到大类中，如果就这样结束，估计很多人会吐槽，因为现实中对产品经理的工作定位，远远超过了以上2点，于是网上有一种从产品的生命管理周期来对产品经理职责进行划分定位的方法，如下图1-1：产品的生命管理周期分为：概念化阶段 -评估产品机会产品化阶段-定义要开发的产品开发阶段-协调资源、保证开发进度，确保开发出正确的产品商业化阶段-与运营和市场团队合作，制定推广策略和产品宣传方案市场化阶段-与客服部门沟通，了解用户反馈，升级产品，评估2.0产品机会，循环进入第一阶段图 1-1 产品经理职责从产品生命管理周期来定位产品经理职责的话，可以分为五个阶段的职责，如上图1-1所示，每个阶段产品经理的工作职责侧重点不同，在开发阶段确保开发进度和开发质量，商品化阶段和市场化阶段，产品经理主要的工作是协调公司资源，推进产品进度，了解产品反馈，制定产品推广策略，而这几点都建立在和其他部门的相互配合上，统一可以称之为推动产品目标的实现。个人总结：从产品生命管理周期来定义产品经理职责比较明确，如果将开发阶段、商品化阶段和市场化阶段的职责进行抽象化，产品经理的职责也可以在原有启示录作者观点上的基础上抽象为四大类：1、评估产品机会2、定义要开发的产品3、协调资源、推进确保开发出正确的产品4、协助各部门，推动产品目标的实现产品需求的4层关系互联网产品需求，其实跟以前我们做开发的软件需求基本是类似的，我也不知道是不是大家从那里搬过来的，暂且不考究这个。今天说下产品需求的4层关系； 首先先说是哪4层：1. 业务需求2. 用户需求3. 功能需求4. 系统需求看官别着急，单独拉出来一个系统需求是有原因的，如果你不是三五年内的小白产品应该能看懂。业务需求（business requirement）什么是业务需求？我觉得是Business Analysis， 就是所谓的 BA吧。不过现在大多数boss或者说创业者不懂这里面具体都是点什么，百度给的定义其实也不是特别的精准，倒是找到一个文库内容，关于业务分析师的定义 这里介绍的很精准。好吧，简单的说业务需求是方案范围，经营范围，或者项目范围。业务分析的东西其实就是一种需求的寻找。举着栗子说： 业务需求就是写出来，我们是做什么的，电商？还是社交？还是其他平台？我们是不是垂直的，线上的还是线下的？我们依赖什么盈利？我们的业务方向怎么发展？ 到这里都是业务需求。 业务的需求往往来自boss或者创业的小老板再或者是你们的某个高层领导。专业一些的会有一些大牛给出商业或者业务分析报告给你。更强有力一些。比自己觉 得做哪个好要靠谱很多 。当然我现在讲的是互联网，其实很多东西都是通用的。用户需求（user requirement）用户需求在互联网中的表现大多是在各种场景下，用户想做某件事情所遇到的问题，或所想满足的欲望。用户需求前期是对比，后期是体验。 在软件中的用户需求则不是，软件用的用户需求是在场景下用户的目标以及能完成的东西是什么。这里需要大量的用例，跟场景描述。 用户需求直白的说就是，你的业务规划，有没有人鸟你，大家对这个事儿咋看，你能帮他们解决啥问题等等。其实还是为了确认project scope 是不是正确的 ，有木有搞头。功能需求（functional requirement）功能需求是为了满足业务跟用户而制定的。也就是说，在你的业务需求出来之后，你要满足用户在你这个产品上怎么实现自己的任务。业务需求都包括什么呢？或者说细化到哪一步了呢？举个栗子：做电商要有购物车，要有商品发布。好的，那购物车里面的功能具体是什么，怎么展示？你可能要细节的写出来，购物车可以批量结账，要有一个单价叠 加的计算，如果有打折，可能还有其他的运算； 商品发布，参数都有哪些，发图片、名称、商品描述、颜色、类型等，如果你是一个很有经验的产品人，在这一步你能为前端跟猴子省下很多很多时间。系统需求（system requirement）为什么把这个单独拿出来了，是因为在每个需求下都会牵扯到这个系统需求。在软件中是架构师的责任，在互联网中可以是项目经理、产品经理、技术总监共同完成 的东西。因为它包含的东西太多了，而且过于繁琐与复杂。那什么是系统需求 ？ 系统需求是数字控制。还是举栗子说：在开发过程中，产品时要反复跟各个部门打交道跟交流的，前端、设计、猴子、项目经理、boss。但是有一点，你必须要出的东西其中有一项叫数据字典，这个 程序员帮不了你。 比如你的用户名长度，猴子的思维是，我的是string，长度你随意，前端的世界是，正则判断下不要乱七八糟的符号就好了，然后不要超过样式的宽度或者超 过了也没事儿我给隐藏了。 那请问，用户名到底要多长？ 区间是什么？ 这就是系统需求的一部分，因为你要合理的写出来账号，介绍，密码，描述，等等等等之类的一切能键入的规则，你以为这样就完了吗？ 再深化一些，你要跟运营部或者市场部，估算出用户成长，在什么时候达到一个什么活跃度等相关数据，以便猴子们可以分库分表或者早点做防备，可能会有人问， 为啥当初不分好呢？ 要是当初能分好，阿里巴巴就不用去请oracle的团队来架构自己的数据库了，当井喷的时候你根本想不到是什么时间，所以这些必要的措施跟部署也是需要产 品人来参与的，这会直接影响到产品跟用户的。 如果你做的不合理，你的规划不好，那用户的体验就没有了。 说案例： 你的社交功能需求跟业务需求写，客户浏览自己个人中心的时候会加载很多推送，这一页的数据加载量很多，有可能认识的，可能感兴趣的之类的，好的。没有什么 经验的猴子可能就直接捅给你数据了，功能实现了没错，首页加载慢的要死。如果你能写出来，这里会跨表，跨库，需要一个沉余或者缓存数据表，要不就用分布式