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范例。尽管不是新产品开发项目，但它仍然给我们呈现了一个完整流程的简单案例。
1704227097
1704227098
1000开展全面的安全分析
1704227099
1704227100
1001根据产业/政府标准进行风险分类
1704227101
1704227102
1002参观工厂
1704227103
1704227104
1003员工访谈
1704227105
1704227106
1004产品与设备测试
1704227107
1704227108
1005确定召回的速度
1704227109
1704227110
2000通知员工