1704227047
作为项目经理的产品经理
1704227048
1704227049
在他们合作发表在《哈佛商业评论》的文章“产品完整性的力量”中，金·克拉克（Kim Clark）和藤本隆宏（Takahiro Fujimoto）对“重量级”产品经理与其“轻量级对手”进行了区分。根据他们在汽车行业所做的研究，[1] 有不少产品经理只属于某一个部门，因此不能承担跨部门的领导职责。他们缺乏在自己部门之外的影响能力，很少甚至从来不和处于实际工作层面的工程师或营销人员接触，并且主要作为辅助人员和协调人员开展工作。因此，他们会花很多时间参加各种会议、阅读各种报告，并撰写各种备忘录。
1704227050
1704227051
与此相反，重量级产品经理是作为产品的总经理发挥其作用的。克拉克和藤本隆宏解释说：
1704227052
1704227053
除了各种与概念（创意）有关的工作之外，他们的工作职责还包括：协调生产与销售以及工程设计之间的工作；协调从概念到市场的整个项目运作活动；终结有关规格、成本目标、产品设计以及主要部件选择等方面的争论；保持与现有和潜在客户的直接接触。重量级产品经理应该知识面广泛，充分了解整车开发所需要的所有产品以及流程设计方面的知识。在公司工作多年，增加了他们的说话分量，也增加了对他们没有正式控制权限的人员的影响能力。[2]
1704227054
1704227055
本田公司的“大产品领导”就属于这么一个职位。它负责制定出强大的产品概念，而且要有能力将最终产品开发出来，并提供给终端客户使用。本田雅阁的产品经理在开始第三代产品设计的时候，他所面对的挑战是在整个产品开发的过程中保持“人为本，车为末”的概念，但仍要坚持把雅阁汽车重新定位成符合未来顾客预期的产品。为此，在先期开展的一系列小组头脑风暴会议中，产品领导及其团队决定将其轿车的信息人性化，以便给顾客造成一种“穿西服的英式橄榄球运动员”的形象。接下来的工作是将这个形象相应地体现到轿车的品质上去。为此，他们选择了五组关键词汇：开放心态、友好沟通、坚韧精神、没有压力以及永恒的爱。坚韧精神是指在困难环境中的操控性；永恒的爱是长久的客户满意；没有压力则体现在降低噪声和减震方面的努力。
1704227056
1704227057
要全部实现所有这些目标的要求，对于雅阁的设计团队来说一个挑战。为了实现最大的乘用空间和驾乘人员的可视性，他们放低了发动机舱盖，从而使得设计中的前挡风玻璃比以往的更大。可问题是，巨大的窗户意味着夏天车内温度会高得让人难受，因此需要加装更大动力的空调，这就要求轿车装备更多马力的发动机，而大型发动机与低发动机舱盖设计则是相互矛盾的。
1704227058
1704227059
它的产品负责人没有让这种情形转变成非此即彼的选择，他提醒设计团队，要以未来用户的眼光来看待自己的工作，从而完整地保持了最初的概念。他们因此开发出一款既紧凑动力又强的新型发动机。
1704227060
1704227061
本田公司的这个例子表明，以市场为导向是有才能的产品经理工作的重要内容。但克拉克和藤本隆宏俩人同时指出，要求远不止这些：
1704227062
1704227063
确实，设计源于客户的需求，因为最好概念的提出者总是需要对各种信息进行加工整理和补充，而这些信息主要来自营销专家，他们能亲手获得各种原始数据。不过，强大的产品概念还包括对我们成为“市场想象”的合理测量：这包括客户声称他们想要的，以及概念提出者想象的、客户三四年后将会想要的东西。产品经理始终要牢记，客户所知道的只是现有产品和现有技术，这样他们才能避免过于接近顾客和设计出的产品在投入生产之前就已过时的陷阱。[3]
1704227064
1704227065
产品经理必须对大量细节进行处理，以确保产品概念各细微之处在开发与营销的过程中不会丢失。尽管制订产品和营销计划是这种工作的一部分，但其中最重要的是，就难以触及的理念与他人进行沟通。在设计阶段与专业工程设计团队之间的日常沟通，以及在开发阶段与工厂人员之间的日常沟通，是产品经理的重要职责。同样，产品经理在一定意义上还必须对轿车进行试驾，并持续努力实现更加强大的产品完整性：
1704227066
1704227067
产品经理的工作触及新产品开发过程的每个步骤。事实上，重量级产品经理必须能运用多种语言进行沟通：对于顾客、营销人员、工程师以及设计师的沟通语言都必须流畅。这一方面意味着能把像“口袋火箭”这样的煽动性概念转化成“最高时速250公里”以及“风阻系数低于0.3”这样注重细节的工程师容易理解的具体目标值。另一方面，这也意味着能够评估并解释，对于客户来说，“0.3的风阻系数”是什么意思。[4]
1704227068
1704227069
组织出色的产品管理需要依靠正式和非正式组织架构协同工作。本田公司的例子以非常重要的方式展示了这种协调性。沟通渠道都是开放式的，且直接沟通多于间接沟通。各部门专家都获得了相应的尊重，但却不必对其有过分崇拜的心理。产品理念也被整个产品团队人员充分吸收理解。
1704227070
1704227071
其他产品的重量级产品经理也都拥有汽车行业产品经理一样的特征。正如让·勒格朗（Jean LeGrand）在《银行家》杂志上发表的文章“需要管理的产品”[5] 中所指出的那样，“在银行业，成功的产品经理必须是优秀的专业人员，并在本行业内广受尊敬”。他必须能够理解“复杂的组合管理项目，以及用于成本核算和计算资产回报率（ROE）的计量模型”。并且，与汽车行业一样，这个职位还需要丰富的市场知识，拥有能把技术概念转变成消费者能够理解的语言的能力。
1704227072
1704227073
在快速消费品公司，产品经理（通常称“品牌经理”）不太可能有产业方面的经验，而是拥有相当多的管理和营销技能，这通常属于MBA毕业生应具备的能力。他们需要为自己的产品创造强大的品牌识别度，通过自身努力赢得尊敬，在整个产品设计项目中保持冲劲，并为实现共同的目标去激励每一个成员。与其他行业的产品经理一样，快速消费品的品牌经理也必须努力实现并支持其产品的完整性。
1704227074
1704227075
团队架构、组成以及项目流程
1704227076
1704227077
新产品项目的重要资源是让合适的人做合适的事。具体的工程师、设计师、营销人员以及其他人员要体现某个特定项目最为需要的品质，但他们需要从相关部门“借用”这些品质特征。产品经理必须与不同职能部门的经理协商，有时候还必须与具体个人协商，以便为自己的任务配备合适的人选。
1704227078
1704227079
团队架构要与项目的种类相适应
1704227080
1704227081
团队可以小到几个人，大到数百人。美国的公司大多数运用跨部门团队，让每个成员在项目中代表最大的利益相关方。不同的团队架构（见图8-2）适用于不同的项目。直线延伸或简单产品可以运用直接透明的矩阵结构，其中，产品经理通过不同职能部门引领项目开发。在这类架构中，职能部门团队成员可能在特定的项目中花费的时间不到25%。产品经理很可能地位较低或处于中层。随着复杂性的增加，组织架构的重量级也会增加，产品/项目经理会与把全部时间（临时）投入新产品工作中的职能部门专家合作共事。对于某些突破性产品，自发团队（偶尔会在同一地点办公）比较合适。在这种架构中，报告关系从单独的职能部门转向项目单元。最后这种架构是最不常见的。（小公司也许无法奢望用不同的矩阵架构，因为每个人可能都会参与到所有项目之中。）不管组织架构如何，产品经理必须构建一个尽可能完善的最佳团队。
1704227082
1704227083
1704227084
1704227085
1704227086
图8-2 新产品矩阵结构
1704227087
1704227088
不同部门的视角至关重要，但你可能还需要考虑组织期限、文化层次、人员性别与个性的多样性。这可能导致协调起来更加困难，但也可能因为不同视角的互动而产生新的想法和解决问题的思路。更高程度共享心智模式的团队，可能容易受团体迷失的影响。因此，让团队成员在不同项目之间进行轮换很有价值，但这可能导致低效。为了降低这种风险，产品经理应该尽量掌握跨团队的知识体系。有几种工具可以帮助他实现这个目标：（1）在新组建的团队中安排过去在成功团队里工作过的成员；（2）在参与新项目团队工作之前，让新团队成员参加成功团队的会议，向他们学习；（3）指派成功团队的成员作为导师；（4）确保整个团队的所有成员不会同时被更换。[6]
1704227089
1704227090
建立团队基本准则
1704227091
1704227092
产品经理作为产品开发团队的主管，负责指导团队的活动，保持团队的目标协调一致，并且与高级管理团队保持有效沟通。首先就要确立团队的宗旨。尽管团队明显是为开发新产品而存在的，但也必须明确每个人对其职能、时间安排以及产品开发的目标都要有一致的认识。团队宗旨应该高于团队的一切会议日程和会议记录。确立了团队宗旨的承诺之后，为团队会议制定共同接受的基本原则，可包括的条款有“参加会议前必须做好充分的准备”“所有会议都必须按时召开或结束”“开会时不得使用手机或其他干扰会议进程的设备”“团队成员轮流承担做会议记录的责任”。确保所有团队成员认识到自己对每次阶段性检查工作的贡献。
1704227093
1704227094
运用工作分解结构和活动图表
1704227095
1704227096
项目团队组建的同时，项目的进程也要同步制定。首先搞清楚完成特定新产品项目所需要的主要活动。每项主要活动都应进一步细分成具体的任务和分任务，创建工作分解结构（WBS）。用WBS中的信息来预估项目开展的时间和各种资源要求。工作任务必须细分到足以允许各种可接受的预估为止。如果没有WBS，任何对时间和资源的估计都只能是个大概，可能会与真实要求产生巨大出入。下面是一次产品召回的WBS范例。尽管不是新产品开发项目，但它仍然给我们呈现了一个完整流程的简单案例。