互联网产品经理-入门容易做好难(210111)

最近几年时间，虽然我博客上也经常会谈到产品规划和总体架构设计，但是很少谈互联网产品经理方面的文章。苏杰在10年前有本书《人人都是产品经理》，当时还找我写过推荐语，而产品经理这个概念确实也活了很长一段时间。

如果从简单的入门来说，确实可以是人人都是产品经理，但是要从全面的产品经理技术能力和软技能层面，那么真是千里挑一或万里挑一。

好好的一个词却烂大街

最近和合作伙伴交流，谈到中台的概念，朋友反应很强烈，说是阿里搞出的忽悠人的一个东西，现在阿里自己都在拆中台。我说你了解中台核心思想是什么了吗？

中台思想实际我们我们经常说的SOA思想，共性业务能力下沉，服务分层组装思想是一致的。中台这个词可以过时，但是核心思想从来没有变过。你现在否定中台，实际上你可能从来就没有接触到SOA思想，你本身就在不断地追逐和炒作新名称，新概念。

回到产品经理这个词来说。

一个人不是说你能够有产品构思，能够画点原型，能够做团队和项目管理就是产品经理。苏杰的人人都是产品经理这本书，看了后大家可能会觉得做一个产品经理是挺容易的一件事情，但是自互联网提供和设置了大量的产品经理岗位后，产品经理这个词基本就烂大街了。

那么应该如何来界定产品经理？

如果简单点来讲可以理解为根 据自己长期的项目和运营实践，通过自己的敏捷洞悉能力和分析能力，能够将当前的市场需求或潜在的市场需求转化为具体的产品需求，并能够核心的定义产品功能模型和价值输出，同时能够通过项目和 团队管理的能力，凝聚一个小组形成一个真正的团队，将自己的产品构思付诸于最终产品实现的人。

在这里我们还没有讲到运营，如果再讲到运营的话可以理解为通过他人或运营团队的运营，能够进一步的收集和分析用户需求和行为特征，同时对产品进行持续改进，这个要求可能就更高，但是最基本的是你首先要做到第一点。

一个产品经理如果最终不能主导团队完成一个产品的交付不能算产品经理，其次如果一个产品经理最终交付的产品没有得到市场的认可或实现最终的价值也不能算一 个产品经理。

就现在大部分互联网产品经理来说，实际上主要就是写需求文档和画原型，和开发沟通清楚，再加上项目和团队管理。

有些公司的设置是纵向产品线和明确，那么产品经理总负责，既管需求又管团队。而对于另外一些企业可能则是产品经理仅仅需求和原型开发人员，产品团队和研发团队完全独立管理，产品总监下面挂几个产品经理，负责需求，同时也负责和外部用户对接。

不论哪种设置方式都可以看到产品经理的核心能力是需求分析和开发能力。

但是很多产品经理是从原来的UI或交互设计人员转过来的，原型设计能力不错，但是需求理解和开发能力很弱。而产品设计不是简单的原型设计，更加重要的是对需求的抽象和转化。

一个公司做一个产品最终无法做好，也没有市场和客户，不是简单的产品经理问题，这是当前整体对产品经理的定位不清导致的。简单来说如果产品经理仅仅是需求实现和原型设计，那么在产品经理之上就真正还有一个人在构思产品。

产品构思和核心价值

产品经理的核心价值就在于搞清楚市场究竟需要什么，根据市场的需求如何构建一个产品并完成价值交付？产品经理我们一直强调要做正确的事，这个就是正确的事。如果产品经理和项目经理有独立的职位的话，那么产品经理要保证的是最终的产品能够实现客户价值，项目经理要保证的是按照项目或版本计划完成项目目标。

如果从这个层面来说的话，产品经理需要具备两方面的核心能力。

其一就是根据市场规划出有价值和意义的产品的能力 ，产品本身的功能架构究竟如何，产品能够完 成哪些客户需求和价值交付，产品如何分版本迭代的推出和上线。

其二就是能够真正指导和跟踪管控产品孵化和落地的能力 ，产品如何研发，产品本身的技术架构或 非功能性需求如何满足，这些虽然可以借助核心架构师的能力，但是产品经理必须有相应的技术背景和管控和指导产品落地而不是中途夭折。

很可惜的是，互联网产品经理逐渐成为一个伪命题，不管是做需求，做UI或是说做架构，做项目管理的都可以称为产品经理。导致我们对产品经理这个概念的认知 越来越模糊，但是哪里清楚一个真正合格的产品经理需要包括技术背景，实践经验积累，市场和运营，项目管理，软技能，软件工程等多方面的知识融合。

虽然类似原来像中兴和华为的产品经理本身有更多和跟严格的岗位职责定义，我们也会感觉这些过程相对来说很重，不符合互联网团队的敏捷和快速迭代文化。但是为学日益，为道日损，没有真正经历过繁重过程的磨练，我们是很难真正清楚如何去繁从简。

你有一个产品构思或者说别人给了你一个产品构思，但是如果你能够将产品构思真正细化，理清楚产品核心模型和价值交付点，最终全程主导和跟踪将产品做出来并 推向市场实现价值，那么你可以算一个合格的产品经理。

有创意和想法的人太多，但是能够真正将想法喜欢为产品需求的人少，同时又能够将产品需求最终实现为产 品的人更少。网上说的就差程序员了为何经常被黑，很简单，这些人除了忽悠到的投资人的钱和一些烧钱的想法外啥都没有，他们根本就不清楚一个产品构思到真正 落地之间所需经历的复杂和历练。

传统B端企业的产品经理

在原来读《人人都是产品经理》的时候写到过，产品经理需要关注三方面内容，用户究竟要什么？我如何把用户要的东西做出来？做出来的产品如何好卖？

第一个内容关注到产品需求管理和产品设计，第二个内容关注到产品规划，产品研发和项目管理，第三个内容关注到产品运营和市场管理。从现在产品经理发展趋势来看，1和3的作用远远大于2。现在的产品经理在这三方面往往会有所侧重，当时必须有这三方面的意识。

产品经理的切入，从需求，项目管理，产品设计等都是可以的。不论是从哪个方面接入都要求对产品开发周期全流程相当熟悉，不能有明细的知识缺陷。从产品设计切入最怕的就是空中楼阁，不考虑可实现性，产品理念无法落地；从项目管理切入的又容易犯闭门造车的问题。

对于产品经理和项目经理关注点的不同，我原来已经做过比较，具体如下： 产品经理是做正确的事情。需要的是确定该做什么产品；而项目经理是正确的做事情，在已经确定了产品和项目的目标后，按目标把项目做成功。 产品经理关注的是产品生命周期，关注集成产品研发IPD等，关注组合项目管理和多项目管理；项目经理关注项目生命周期，关注软件工程和CMMI过程和改进等，关注PMBOK的单项目管理知识体系。

在这里谈下我原来在企业内做内部IT产品经理的一些总结。

首先是每年的10月就会启动下一年的产品规划工作，在这里涉及到大量用户的访谈，原始需求的收集和整理，优先级的排序，需求的条目化。其次是对业界同类产品发展趋势的分析和研究，业界关于该产品标准做法的一些研究以确保模型本身的标准和完整性。

整个产品规划里面涉及到很多内容，其中最重要的就是路标规划，年度规划，季度规划。 路标规划一般是3-5年中长期规划，年度规划一般是当年计划，季度规划则会细化到具体的子产品和产品版本。一个大产品会涉及到多个子产品，当时我负责的大产品下面涉及到10个左右的子产品，4个专职化的项目经理，因此产品规划需要确定去下一年每个子产品要做哪些产品版本，每个产品版本要实现哪些用户需求，具体的人力资源投入估算等。这里就涉及到比较多的组合规划，动态资源管理，组合项目管理，需求管理方面的内容了。

这个产品规划完成后，每个季度会对产品规划重新拿出来进行评审，对产品规划的内容进行调整。评审确认后产品版本对应到具体的项目版本，因此走产品计划审批到最终的项目立项。项目立项后一个新项目正式启动，所有的管理和跟踪工作基本就转移到了项目经理，后面产品经理的工作基本就是关键点的跟踪。而我们说的关键点主要是项目主计划评审，需求评审，关键技术评审，可用性测试和评估，产品版本发布评审。所以产品经理不仅仅关注产品生命周期，也关注项目生命周期，只是关注的点和粒度不同。

在这里对于一个60多个人的大团队，本身就是一个大产品，IT项目经理专职化是很多公司无法做到的，这块做到了感觉还是收益很大。四个子团队都有专职的IT项目经理，项目团队成员的资源动态调配就很关键的，而能够调配的关键又在于使用同一个业务架构和技术平台。公司本身有专门做技术平台的人，因此后面关键的一件事情就是业务和技术的横向贯通性。到后面把业务架构和技术架构从项目中抽离出来，形成了业务架构和技术架构的跨子产品，保证架构的完整性。

产品管理不是产品经理一个人的事情，而应该形成产品管理团队。在这里我们的产品管理团队就包括产品经理，项目经理，业务架构和技术架构。 产品管理工作重点是产品经理+项目经理+开发经理；而产品设计的工作重点则在于产品经理+业务架构+技术架构。这也是我谈的产品管理铁三角和产品设计铁三角。

项目启动会议很重要，最好是能够要求高层领导参加，重点是确定资源，明确项目经理的职权。对于项目组织结构项目一般都采用强矩阵或者完全项目型，要弱化职能部门对人员的控制，体现项目经理的权力，特别是考核权和物质激励分配权。

项目经理要做到心中有树，项目经理最重要的意识仍然是目标意识，项目的本质就是在保证品质的前提下，在时间要求，人财物花费，项目范围三点上做平衡。WBS模板很重要，做的产品或项目越多，应该形成自己的产品或项目WBS模板。在CMMI下这些会提升到组织级过程资产，组织会根据项目类型的不同定义不同的项目生命周期，制定不同的WBS模板。

用户需求是从特定用户角度出发，而产品需求则是从推出通用化的产品出发，这是两者最重要的区别。不考虑产品需求，不从产品通用性出发会导致项目最终产品只能满足特定用户需求，完全是一单子买卖，首先是导致产品营销范围狭隘，同时也不利于推出通用化的产品，形成企业的核心竞争力。

用户需求需要向产品需求转换，转换的重点就是考虑用户需求的共性，考虑如何使产品每具备一个功能特性就能够满足更多的用户需求。用户需求收集->分析和归类->该需求的根源->抽取共性->形成产品需求，通过这种方式形成的产品需求有利于后期产品的通用化。我们在软件产品开发过程中使用一些框架，公用组件，分层等各种架构要素目的正是为了满足产品的可扩展性和配置性，而不是单单满足当前的用户需求，虽然这样在软件开发过程中可能会花更多的工作量，但投入的成本是完全值得的。

产品需求和软件需求可合并，也可以分开为两个文档。分开的时候产品需求关注产品化，关注业务模块和业务单元，只需要说明清楚业务单元的关键功能特点就可以了。同时要注意产品需求里面一定要包括非功能性需求的描述，产品需求是实现用户需求朝产品化转化的一个重点，产品需求往往应该由业务架构来完成，技术架构来落地，偏向于业务建模。到了软件需求重点则是用例分析和建模，在这里原来有一本书讲软件需求阶段也分了重要的三个层面，即需求的细化过程，首先是用例分析，然后是界面建模，然后是事件建模和交互细节补充。软件需求阶段一定要完成界面原型开发，这是这么多年来我们实践RUP方法的一个重点心得。

对于用例建模和软件需求文档，这是我们原来实践CMMI做的比较好的一个过程域。从产品经理到项目团队的每一个成员都足够重视需求。我们的敏捷是体现在了大的产品迭代开发，已经变成了3-5周的短周期版本。而在每一个项目版本里面我们的需求变更基本是完全可控的，投入在12-15个人左右4-6周的项目在整个项目生命周期需求变更很少。

对于用例文档我们后面也做了适当改进，因为发现了重要的问题即我们说的没有经过业务建模直接过渡到了单个用例实现的细节。所以后面改进的一个重点是增加了业务场景和业务背景的描述，增加了该业务场景下业务流程或活动的描述。在此种描述的情况下再展开到单个用例实现的描述，方面设计和开发人员理解业务。

那么对传统B端企业产品经理做哪些事情，具体如下：

//在战略层面需要考虑的内容
1. 产品的定位 ( 理解市场，细分市场，了解用户 )
2. 品牌的战略 ( 经营品牌就是经营产品，品牌的价值往往反映了产品的价值 )
3. 产品战略规划 ( 战略即方向，方向错误全盘皆输 )
4. 产品线规划和产品路标规划 ( 后续研发项目开发的重要指导 )
5. 项目组合管理 ( 产品组合分析和选择，组合决策，动态管道管理 )
6.CI 竞争情报和竞争战略 ( 充分了解对手才可能打败对手 )

//在产品规划和执行层面
1. 产品规划和技术平台规划 , 产品项目的版本规划。
2. 管道管理和资源管理 ( 资源需求计划，资源分配和交易，多项目间资源平衡 )
3. 多项目和项目群管理 ( 产品级项目管理 )
4. 市场需求分析。
5. 产品级风险和问题管理。
6. 产品需求全生命周期管理 ( 需求管理，需求收集， $APPEALS ，需求验证和跟踪 )
7. 结构化产品开发方法论 ( 并行工程，产品开发团队，决策机制 )

//产品开发团队管理
1. 产品开发团队的组织结构和角色分工。
2. 团队激励机制和绩效管理机制。
3. 矩阵管理沟通汇报机制。
4. 团队沟通平台建设。
5. 产品层面的培训计划和资产库。

//产品实施和推广
1. 产品推广和实施计划，推广策略。产品营销管理。
2. 产品的宣传手册。
3. 定制化的产品项目建议书和产品解决方案 PPT 。
4. 产品定价和定位策略。

理解市场和理解产品

如何做好一个产品？

简单来讲就是要理解市场和理解产品，市场驱动产品研发，如果连市场真实需求都不清楚如何能够做好一个好的产品。在互联网时代，如果单独拿SaaS类产品来说，很多产品当前还收费，实际上可以看到即使这些产品免费估计也没有什么人会真正长期使用。即：

一个好的产品不怕收费，但是一个垃圾产品免费也无法获取流量

因此理解市场，理解用户对于产品经理来说始终都是首位的。传统的STP营销方法论仍然适用，即理解市场，细分市场，然后找到细分市场和自己的差异化定位。

做传统产品你可能还可以面对真正的用户展开需求调研和分析，但是对于互联网产品很多传统需求调研方法论行不通，因此需要转换思路。

其一是对已有竞争类产品的分析 ，微创新这个概念很好，现在多大部分产品都很难算得上完全从0到1的创新，而是微创新，因此更需要站在巨人的肩膀上去思考。把所有同行产品全部分析清楚，并真正注册使用和体验一定时间，那么你对自己的产品架构也就清楚了。

其二是短周期迭代 ，短周期迭代不是简单地缩短上线时间，更加重要的是要通过上线最小化版本来快速地获取用户需求，从用户使用过程中反馈的问题才是真实的需求。

其三是数据驱动思维， 一个全新的产品上线后进入运营和不断迭代优化阶段，而这个时候产品转运营，运营最重要的又是数据驱动。一说到运营很容易想到独立的运营团队，但是这种运营团队更多是偏于产品内容的运营，而产品经理要关注的是产品功能使用过程中采集的日志数据分析。哪些功能被高频使用，哪些功能上线无效果都应该被记录和分析。

一个好的产品经理一定是一个深度用户，懂得换位思考。

赋予产品灵魂

一个好的产品往往也会打上产品创始人或产品经理的烙印， 产品经理是能够真正赋予产品灵魂的人 ，是能够真正将一群人构建为一个核心产品团队的人，是一个能够真正实现产品价值的人。

只有产品经理的高度领袖能力和全身心的投入才可能真正将产品从0到1孵化出来，他可能没有做太多具体事务性的工作，但是却会出现在产品打造全过程中的任何关键 点。他们会参加需求调研和分析，总体产品设计，架构方案，产品测试和验证，市场推广和运营等任何关键点和关键环节。他们做的所有活动和跟踪唯一目标就是让 产品能够真正根据自己的构思和想法孵化出来，而不是在这个过程中不断地偏离轨道而没有修正。

一个好的产品往往是产品经理大量实践，深思熟虑产生的构思，不断地沉淀和细化并融入的。试想一下，如果一个产品经理本身都做事懒散，粗枝大叶不关注细节，无法做到自律和严格要求，那么又如何确保产品经理设计的产品本身具备足够的易用性和气质。

产品经理是光彩夺目的，他们得到团队的拥护，客户的认可和产品带来的价值回报，能够通过自己和整个团队的努力打造一款真正创造价值的产品所带来的成就感和 自我实现无任何其它可以替代。但是产品经理本身又是孤独的，产品经理是真正负责产品成败的唯一责任人，你的任何一个不够慎重的决策都可能将产品引入歧途或 最终夭折，资源的投入，产品的延期，客户的不买账，大量的深夜对产品的思索和煎熬，对工作和家庭的无法平衡，这些都需要你一个人去默默承受，伟大是熬出来的。

对于软件产品来说，产品最终交付给用户的不应该仅仅是功能可用，更加重要的是软件产品使用过程中带来的美感，使用时心情的愉悦，而这些往往都需要持续的积累和打磨。而你的每一点心血都最终融入到产品气质中。