启示录:打造用户喜爱的产品

    [美]Marty Cagan著

    七印部落 译

    无论是产品经理，还是产品设计师；无论是蓄势待发的创业

    型公司.还是一筹莫展的大企业，大家都在思考这个问题。

    Marty无疑是eBay最出色的产品经理，他对eBay的影响至今

    仍在。

    —————————————Frerk-Malte Fellef

    eBay德国区常务董事

    Marty是产品管理的行家里手。这本书如醍醐灌顶，让我茅

    塞顿开。

    ————————————————Judy Gibbons

    AcceI Parfnels公司风险投资人

    Marty在工作上自有一套，他总能打造出流的产品。

    ————————————————Pete Deemer

    Yahoo ! 前任首席产品经理、Good Agile公司CEO读完这本书，我不得不重新审视产品管理的原则和方法。

    ————————————————Jim Denney

    TiVo产品副总裁

    图书在版编目(CIP)数据

    启示录打造用户喜爱的产品[美]Marty cagan著;七印部落译.-

    武汉: 华中科技大学出版社，2011.5

    ISBN 978-7-5609-7018-9

    Ⅰ.启…Ⅱ.①M…②七…Ⅲ.电子商务-商业经营Ⅳ.F713.36

    中国版本图书馆CIP数据核字(2011)第051014号

    Original English language edition copyright ? 2008 by Marty

    Cagan.

    The Chinese translation edition copyright ? 2011 by

    HUAZHONG UNIVERSITY OF SCIENCE AND TECHNOLOGY

    PRESS in arrangement with SVPG PRESS.

    湖北省版权局著作权合同登记号 图字：17-2011-079号

    [美]Marty Cagan 著 七印部落译

    策划编辑：徐定翔

    责任编辑：徐定翔

    责任校对：祝 菲

    责任监印：张正林出版发行：华中科技大学出版社(中国?武汉)

    武昌喻家山 邮编：430074 电话：(027)87557437

    录 排：华中科技大学惠友文印中心

    印 刷：湖北新华印务有限公司

    开 本：880mm×1230mm 132

    印 张：8

    字 数：156千字

    版 次：2011年6月第1版第2次印刷

    定 价：36. 00元

    本书若有印装质量问题，请向出版社营销中心调换

    全国免费服务热线：400-6679-118竭诚为您服务

    版权所有 侵权必究

    前 言

    二十世纪八十年代中期我还年轻，在惠普担任程序员，参与开发一款各受瞩目的产品。当时人工智能风靡一时，能进入

    业内最优秀的公司，加入一支出类拔萃的团队(许多同事后来成为

    业界的中流砥柱)，我感到非常荣幸。我们的任务是为低成本的通

    用工作站开发软件，难度不小。当时市场上都是软硬件结合的专

    用产品，每个用户的花费超过十万美金——鲜有人负担得起。

    我们辛勤工作了一年多，牺牲了无数个夜晚和周末。一

    路走来，我们为惠普增添了不少专利，开发出符合惠普严格品质

    要求的产品。我们把产品翻译成多种语言，实现国际化。我们还

    培训销售团队，向媒体进行展示，收到了良好的反馈。我们发布

    产品后，以为万事俱备，开始庆赞。

    但问题出现了：没人购买我们的产品。

    这款产品彻底失败了。是的，它的技术让人耳目一新，媒体反馈也不错，可足人们并不需要它。面对这个结果，团队成

    员很沮丧。我们很快开始反省：谁有权决定开发什么产品?他们

    是怎么决定的?他们怎么知道产品有没有用?

    我们汲取了深刻教训：如果开发的产品没有市场价值，那么无论开发团队多么优秀也无济于事。不仅如此，我们认识到

    仅仅做出产品并不够，还要确认产品是有价值的、可用的、可行

    的。

    追溯产品失败的根源，我发现决定开发什么产品的人

    是“产品经理”，他们通常隶属于市场部门，负责定义我们开发的

    产品。同时，我还发现当时惠普并不擅长产品管理。不仅是惠

    普，人多数公司不谙此道，即便是今天，有些公司依然如此。

    我暗下决心：除非知道产品是用户需要的，否则我再也

    不会盲目投入精力。此后二十年，我有幸参与开发多款高科技产

    品。个人计算机兴起时在惠普工作；互联网技术爆发时，在网景

    公司平台及工具部门任副总裁；电子商务风靡时，在eBay担任产

    品管理及设计高级副总裁。当然，并非所有产品都十分成功，但

    我可以自豪地说，没有一款是失败的。有几款产品广受欢迎，在

    全球拥有上千万的用户。

    离开eBay不久，我接到一些产品公司的电话，对方希望

    改善开发产品的方式。与这些公司合作后，我发现他们的工作方

    式与优秀公司的差异很大。我意识到普及一流产品管理理念的工

    作任重而道远。大多数公司都在使用过时且低效的方式定义和开

    发产品。同时我发现无论是学术机构(包括最好的商学院)，还是那些因循守旧而无法自拔的公司(像我工作过的惠普)，都对此无

    能为力。

    我能积累宝贵的经验，得益于与行业精英共事的经历，书中很多想法是受他们启发形成的。我从他们身上获益良多，无

    以为谢，书后致谢中记有他们的名字。

    我选择这份职业是想开发客户喜爱的、体现真正价值的

    产品。我发现产品经理都想打造让人眼睛一亮的成功产品，可惜

    多数产品都缺乏创意、寿命短暂。

    我希望通过本书分享优秀企业的成功经验，让更多的产品赢

    得客户的厚爱。

    谁应该读这本书

    本书是写给软件产品(包括企业级产品和大众产品)开发

    团队(特别是互联网软件产品团队)中负责定义产品的成员看的，他们通常被称为产品经理。这个职位实际上常常由公司的创始

    人、高层主管、主程序员、设计师兼任。除了产品经理，本书还适合用户体验设计师、软件架构师、软件程序员、项目经理、市

    场经理及其他管理人员阅读。以我的经验来看，本书的内容广泛

    适用于各种产品开发团队和开发场合。

    无论是刚刚起步的小公司，还是产品多样化的大公司，或者规模介于二者之间的公司；无论是开发1 0版的新产品，还是

    改进现有产品；无论是使用敏捷方法(如scrum)，还是使用传统的

    瀑布式开发方法，这本书都适用。

    无论产品是互联网服务、零售软件，还是设备、平台；

    无论产品针对的是个人消费者，还是企事业单位：无论产品是电

    子商务网站、虚拟竞技或游戏网站，还是消费类电子产品、企业

    托管服务，或是特定类型的网络应用(如社交和视频网站)，这本

    书都适用。

    但我必须声明，本书不是针对非软件产品(如药品)所作，也

    不是针对非产品化的软件(如定制软件项目)所作。这并不是说书

    中的方法一定不适用于其他行业，只是这些想法和经验源自软件

    产品行业，我不能保证应用于其他行业一样有效。

    本书的结构

    从担任网景高级产品经理开始，我的日常工作明确分为三

    块：人员、流程、产品。

    人员是指负责定义和开发产品的团队成员的角色和职

    责。

    流程是指探索、开发富有创意的产品时，反复应用的步

    骤和成功的实践经验。

    产品是指富有创意的产品具有的鲜明特性。

    这三个部分是探索和开发用户喜爱的产品必不可少的。

    项目都是由人完成的，流程则保证大家持续开发出用户喜爱的产

    品。

    本书也相应地分成三个部分，每个部分包含若干个主

    题。这些主题独立成篇，读者可以根据兴趣选择阅读。我总结了

    二十条个人认为最重要的经验和技巧，放在书后。

    书中内容多数来自一流公司的实践经验，有些得益于与

    业内精英交流的结果，剩下的则是我本人的工作经验。

    本书旨在帮助读者打造更好的产品，书中主题均遵循三

    条标准：鼓励思考、与实际工作密切相关、切实可行。同时我也

    非常希望听到读者分享自己的经验。欢迎访问硅谷产品集团的网

    站(www.svpg.com)，分享您的想法。

    预祝大家开发出用户喜爱的、富有创意的产品!

    好产品靠设计

    我从不认为富有创意的产品来自偶然。成功的产品都遵

    循一定的规律。以下是我总结的十条规律。

    1产品经理的任务是探索产品的价值、可用性、可行

    性。

    2.探索(定义)产品需要产品经理、交互设计师、软件架

    构师通力合作。

    3.开发人员不擅长用户体验设计，因为开发人员脑子

    里想的是实现模型，而用户看重的是产品的概念模型。

    4用户体验设计就是交互设计、视觉设计(对硬件设备来

    说，则是工业设计)。

    5.功能(产品需求)和用户体验设计密不可分。

    6.产品创意必须尽旱地、反复地接受目标用户的试

    用，以便获取有效的用户体验。

    7为了验证产品的价值和可用性，必须尽旱地、反复地

    请目标用户测试产品创意。

    8.采用高保真的产品原型是全体团队成员了解用户需求和

    用户体验最有效的途径。

    9产品经理的目标是在最短的时间内把握复杂的市场

    用户需求，确定产品的基本要求——价值、可用性、可行性。

    10一旦认定产品符合以上基本要求，它就是一个完整的

    概念，去掉任何因素，都不可能达到预期的结果。

    容我再啰唆一句，有太多产品团队身陷错误的产品研发

    模式，帮助读者走出困境，是本书的宗旨!

    第一部分 人员

    People

    产品团队

    产品是由团队成员设计开发的。选择团队成员、界定工

    作责任是产品成败的决定因素。

    本书第一部分探讨现代软件、互联网产品团队成员的关

    键角色及其职责。

    许多产品团队在这方面显得因循守旧，捉襟见肘。他们

    会发现，我即将讨论的角色选择和职责界定与他们的做法大相径

    庭。

    第1章 关键角色及其职责

    Key Roles and Responsibilities

    现代软件产品团队

    团队角色的概念贯穿全书的内容，因此在第1章我会给出这

    些角色的明确定义。我知道并非所有公司都严格按照这种方式设

    置职位、分配任务，但是大部分成功的公司是这样做的。这些角

    色都是打造成功的软件产品不可或缺的。请注意，我所说的“软

    件产品”不仅包括提供给企业或消费者使用的软件，也包括互联

    网服务、电子消费产品，以及所有以软件为核心的设备。

    产品经理

    产品经理的主要职责分为两项：评估产品机会(product

    opportunity)；定义要开发的产品。产品创意的来源很多，比如，公司高管的意见、用户的反馈、可用性测试的结果、产品团队和

    营销团队的点子、业内人士的分析等。应该有人严格审核这些创

    意，判断是否值得采纳。产品经理就是负责这项评估的人。许多

    公司借助市场需求文档(market requirements document，MRD)来完成这项工作。我更愿意使用一种简化的方法，我称之为机会评

    估(opportunity assessment)。

    确定有价值且符合公司发展要求的产品机会后，还需要探索

    产品的解决方案.包括基本的产品特征和功能、产品的用户体

    验、产品的发布标准。这些也属于产品经理的工作范畴，而且是

    产品经理的核心职责。有些公司借助产品需求文档(product

    requirements document，PRD)来完成这项工作，也有人称其为产

    品说明文档或功能说明文档。同样，我主张采用简化的文档，围

    绕产品原型来展开这项工作。注意，文档应该清晰地描述产品的

    功能和属性，避免讨论产品的实现方法。

    用户体验设计师

    用户体验设计团队由多种角色组成，稍后我会详细说明。这

    里只谈谈最关键的角色——交互设计师(也称为信息架构师、用户

    界面设计师、用户体验架构师)。交互设计师负责深入理解目标用

    户，设计有价值的、可用的功能，以及用户导航和产品使用流

    程。交互设计师与产品经理密切合作，将功能与设计相结合，满

    足用户需求。目标是确保产品同时具有可用性和价值(可用性指的

    是用户明白如何使用产品，价值指的是用户对产品的渴求程度)。

    项目管理人员

    产品经理完成产品定义后，开发团队承接项目，开始开发产

    品。项目管理的核心任务足制订计划和跟踪进度。项目管理工作

    常常由不同的角色承担，可能由专职的项目经理操刀，也可能由

    开发经理兼任(因为开发团队占有大部分项目资源)，还可能由产

    品经理披挂上阵。这通常取决于公司文化和项目规模。规模较大

    的项目最好安排经验丰富的专职项目经理管理。

    开发团队

    软件工程师也称为产品开发人员或软件开发人员，负责开发

    产品。开发团队在有些公司被称为IT(信息技术)团队。注意不要

    混淆这两个概念，区分的关键是看他们是为顾客开发软件，还是

    为公司内部(如人力资源部门)开发软件。1T团队通常指的是为内

    部员工提供技术支持的团队，而开发团队指的是为外部客户开发

    和维护产品的团队。

    运维团队

    互联网服务产品通常运行在服务器上，用户通过web访问服

    务。运维团队负责保证服务正常运行。虽然有些公司将这项任务

    交给开发团队负责，但是运维工作需要一系列专业技能，很难由

    开发团队单独承担。

    产品营销人员

    产品营销团队负责对外发布信息、宣传产品，为拓展市

    场销售渠道、组织重点营销活动(如在线营销)、促进产品销售提

    供支持。有些公司让一个人同时负责产品管理(产品定义)和产品

    营销。这两项工作内容相差很大，这样做实在不明智。

    顺便提一下，微软把负责制定产品说明文档和管理项目

    进度的人称为项目经理(program manager)。由于这些“可怜”的人

    要同时应付多个项目，因此业界现在已经习惯用这个头衔称呼同

    时管理多个项目的管理人员。在微软，产品经理指的是那些负责

    产品营销的人。虽然我不喜欢微软对这两个头衔的用法，但我认

    为他们定义产品的工作做得非常棒。团队成员的构成比例

    在产品团队里，产品经理、设计师和开发人员的人数存

    在一定的比例关系。为使开发人员集中精力开发产品，必须有相应人数的产品经理和用户体验设计师协助他们。

    影响成员比例的因素包括待开发软件的类型、员工的工

    作经验和技能水平等。下面阐述的比例可供参考。

    问：需要多少产品经理?

    答：通常，每五到十位开发人员配备一位产品经理。

    问：需要多少用户体验设计师?

    答：一位交互设计师大约可以支持两位产品经理的工

    作，一位视觉设计师可以支持四位交互设计师的工作。

    问：应该聘请专职的项目经理吗?

    答：凡超过十名开发人员参与的重大项目，就应该配备

    专职的项目经理，此外，如果采用火车模型发布模式(以固定的周

    期持续发布产品，如果某项既定功能未完成，就挪到下个周期发布的开发方法)，必须为每次产品发布(通常这类产品由多个项目

    组成)配备专职的项目经理。

    第2章 产品管理与产品营销

    Product Management vs.Product Marketing

    两者不是一回事

    业界权威人士指出，市场上多达九成的产品未能实现既

    定目标，因而是失败的。即使你的产品不在此列，我依然觉得构

    思拙劣、尚不成熟、可用性差、毫无价值的产品随处可见。

    导致产品失败的因素很多，本书尝试从不同角度分析其

    原因。我一直认为，最根本的原因是公司对产品经理的职责界定

    不清，担任这项工作的人缺乏专业训练。我一直在思考这个问

    题，它触及了产品经理的核心工作职责。喜欢本书吗？更多免费

    书下载请***：YabookA，或搜索“雅书” 。

    产品经理的工作是从细节上定义开发团队开发什么产

    品。市场营销的职责是对外宣传产品。两项工作天差地别。

    为理清职责，我坚持为每款产品指派一名专职的产品经理，负责定义产品(将产品需求和用户体验设计相结合)，然而我

    发现产品公司常常会陷入以下三种误区。

    由市场营销人员定义产品由产品营销经理或所谓的产品

    经理负责收集高层产品需求，然后直接交给开发团队开发。这种

    方式忽略了收集详细产品需求的步骤，回避探索(定义)产品的艰

    难决策过程(也绕开了用户体验设计)。

    两人分担定义产品的工作定义产品的工作分给两人完

    成，产品营销人员负责高层商业需求，产品经理负责低层产品需

    求。

    一人兼任两项工作产品营销人员兼任产品经理的工作

    (有些公司称这类人为产品经理，有些公司还是称这类人为营销人

    员)。

    下面分别讨论这三种情况及其引发的问题，最后指出解决问

    题的办法。

    由市场营销人员定义产品

    这种情况很容易辨认。这类产品经理可以为产品团队提

    供市场营销资源，制作数据表格，培训销售队伍，为产品命名和

    定价，但是一旦涉及定义产品的具体工作，他们就显得无能为

    力，只能袖手旁观。呆伯特(Dilbert)系列漫画用了大量笔墨描绘

    这类产品经理，相信大家都很熟悉。

    这类产品经理或许擅长市场营销，但是对详细定义有价

    值的、可用的、可行的产品往往束手无策。除非他们不但具备营

    销技能，还掌握管理产品的方法，那么产品还有成功的机会；否

    则只能寄希望于其他人(比如主程序员、交互设计师、公司高管)

    挺身而出，担负起真正意义上的产品管理工作。然而，更常见的

    情况是产品从一开始就因此陷入了麻烦。

    我第一次接触产品管理工作时，遇到的就是这种棘手的情

    况，这导致我以前对产品经理没什么好感。幸亏后来遇到一位贵

    人，他让我明白了产品经理的真正职责。从那时起，我开始强调

    产品经理的作用，并致力于重新定义产品经理的工作职责。

    两人分担定义产品的工作

    没人单独负责管理产品，这种情况也很常见。产品营销

    人员(有时被称为业务负责人或商务产品经理)负责收集高层业务

    需求，产品经理(在敏捷开发团队中也被称为技术产品经理或产品

    负责人)负责收集低层产品需求。

    问题在于这两个人都不是真正的产品负责人，没人对最

    终的产品负责，而且采用这种模式是基于错误的观点，即认为可

    以脱离具体需求(尤其是脱离用户体验)来定义高层需求。

    这种模式让产品经理的工作蜕变成制作各类文档。这种

    工作不但令人沮丧，而且限制创新思维，很难做出成功的产品。

    大公司由于业务部门较多，很容易陷入这种管理产品的模

    式，他们常常为此苦恼，却找不到原因。

    一人兼任两项工作

    在现实中，很难找到同时具各产品管理能力与产品营销

    能力的人。管理产品与推广产品都对产品的成功至关重要，部需

    要专业的技能，但两者的要求大相径庭。虽然我认识一些能够从容驾驭两项工作的天才，但这样的人少之又少。这种团队模式的

    扩展性很差。即便是最简单的产品，也应该由专职产品经理投入

    全身心进行管理。让产品营销人员兼做产品管理的工作，即便他

    具备两种技能，也没有精力把两边的工作都打理好。

    开发企业级应用软件的公司，由于非常倚重销售，最容易出

    现这种问题。销售代表原封不动地把大客户的需求传达给产品经

    理，再交给开发人员。不用说，这样做很难开发出有价值的、可

    用的产品。上述二种模式背后都有其原因，认识这一点很重要。

    很多公司没有意识到错误的模式给他们带来了多大的损失。他们

    浪费时间，开发出的产品客户却不需要或者只能勉强接受。

    出路

    要解决这些问题，必须清晰界定产品经理和产品营销人

    员的职责。产品经理负责详细定义待开发的产品，让真实的用户

    测试产品。产品营销人员负责向外界宣传和推广产品，负责产品

    发布，为拓展市场销售渠道、组织重点营销活动(如在线营销)、促进产品销售提供支持。

    请注意，我这里强调产品管理的重要性，并不代表产品营销不重要。恰恰相反，我认为产品营销很重要，成功的营销可

    以创造巨大的价值。只是这与讨论产品经理的职责关系不大。

    产品经理和产品营销人员应该经常沟通、展开合作。一

    方面，营销人员是产品经理获取产品需求的重要来源：另一方

    面，产品经理是营销人员获取市场营销信息的重要来源。

    虽后，无论头衔或者组织形态怎么变化，我相信所有成

    功的产品背后都有一个全权负责定义产品的人。

    请记住，如果产品经理定义的产品没有价值、不具备可

    用性和可行性，那么无论开发团队多么出色也无济于事。

    第3章 产品管理与项目管理

    Product Management vs. Project Management

    互联网让两者变得不同

    第2章阐述了分清产品管理职责和产品营销职责的重要

    性。许多公司则遇到另一个问题：产品管理和项目管理相互重

    叠。

    多数互联网公司沿用了开发零售软件的惯例，用产品管

    理涵盖了项目管理。在传统的零售软件领域，产品经理常常兼任

    项目经理的工作(例如。微软最出名的office系列产品就是采用这

    种模式开发的)。这种模式虽然适用于零售软件产品，但不太适合

    开发互联网服务类产品。

    为了解释个中缘由，我先简单回顾一下互联网服务产品

    的历史。互联网服务产品大约出现于1996年.当时我们曾“纠

    结”是否继续称自己为产品经理。毕竟像旅游网站这类产品不是

    传统的零售软件，更像是面向客户的服务。不过这种困惑很快就

    被人们抛到脑后了。

    早期的互联网公司让产品经理继续兼任项目经理的工

    作，网景和雅虎就是这样，但他们很快就遇到了问题。在零售软

    件领域，产品通常以独立安装包的形式发布，发布间隔从几个月

    到几年不等，产品和项目具有相同的粒度，开发频率也相同，产

    品经理兼任项目经理相对容易。但是在互联网产品领域，这种模

    式就行不通了。

    互联网服务类产品对网站代码的局部修改更加频繁，发

    布周期明显缩短(通常是每周或每月发布一次)，大部分项目的开

    发周期明显长于发布周期。为了适应这种变化，很快出现了并行

    开发和火车模型发布模式。许多成熟的互联网公司都在使用火车

    模型发布模式。

    火车模型发布模式本身是一个很大的课题。与本书相关

    的要点是：每次发布都需要强有力的、有效的项目管理，它不局

    限于具体项目，必须统筹全局。每次发布可能包含多位产品经理

    负责的功能，要协调发布管理、程序开发、网站运维、客户服

    务、产品管理各个方面。有些互联网公司把采用火车模型的项目

    经理称作列车指挥员。

    如果采用火车模型发布模式，指派项目经理来控制产品发布，就不需要产品经理兼任项目管理工作了。再回到互联网历

    史，随着雅虎、网景、美国在线等公司的产品线和网站不断发

    展，产品发布流程变得越来越复杂，项目管理职能慢慢从产品管

    理职能中分离出来。这些公司逐渐积累了专业的项日管理能力。

    许多后起之秀，像eBay和谷歌，如果不是拥有强有力的，能够统

    筹产品管理、程序开发和网站运维的优秀项目管理团队，就不可

    能开发出那么多高质量的产品。

    对互联网公司而言，把这两种职责分开至关重要。必须

    持续不断地推动项目，否则产品发布就会延期。

    对传统的零售软件而言，我认为也有必要把这两种职责

    分开。这与产品管理的性质有关，产品管理的职责是探索(定义)

    有价值的、可用的、可行的产品；而项目管理则关注如何执行计

    划以按期交付产品。

    怎样成为优秀的项目经理?

    在所有成功的企业里，都可以找到这样一群人，他们让

    公司变得与众不同：优秀的产品规划、持续的商务拓展、准时交

    付产品。而普通公司的表现恰恰相反：糟糕的产品规划、眼睁睁看着客户流失、产品发布不断推迟。

    eBay就属于这类成功的企业，公司各个部门都拥有最优

    秀的人才。eBay的产品开发流程与众不同，其独特性突出表现在

    三个方面：高效率、严要求、严格遵循项目管理法则。

    琳·丽迪(Lynn Reedy)是我在eBay的同事，她是我见过的

    最出色的项目管理人才。她是eBay项目管理的中流砥柱，我很荣

    幸曾与她共事。加入eBay之前我曾自诩是项目管理的行家里手，但她向我展示了真正的项目管理能力。

    在一些大公司(如微软)，产品经理也负责项目管理的工作。

    我认为，强有力的项目管理能力是产品经理的优势。至少你可以

    使产品更快进入市场，甚至很可能会决定产品能否面市。但我还

    是认为产品经理和项目经理应该是两个独立的职位。

    有些项目经理以为管理能力等同于使用微软Project软件

    的能力，他们没有领悟项目管理的真谛。以下是我从琳·丽迪这样

    优秀的项目经理身上总结出的七个特点。

    工作紧迫感只要琳走进房间，立刻就能传达给大家一种紧追感。每次会议大约60秒闲话开场白后，马上转入正题。这种

    效果表面看来是因为她独特的身体语言和气质，但事实上，紧迫

    感和高效率是eBay企业文化的核心，而且已经升华为琳人格的一

    部分。

    善于捕捉问题有无数原因导致会议效率低下、毫无建设

    性，其中最主要的原因是会议目的不明确，不清楚要解决什么问

    题，也不知道难点在哪。优秀的项目经理能够迅速地、准确地指

    出问题及其要害，改善会议效果。

    思路清晰引发典型业务问题的原因多种多样，比如政治

    因素、日程安排有冲突、同事个性不合等，如果置之不理，稍作

    拖延就会导致整个项目一团糟。项目经理需要排除感情因素，放

    下思想包袱，拨云见日，把待解决的问题逐一独立分离出来，分

    配给每位同事，专注解决。

    用数据说话优秀的项目经理明白数据的重要性，懂得利

    罔数据识别项目方向，确认项目进度。他们知道改善产品和开发

    流程必颓从测量、收集数据开始。在时间紧迫的情况下，最容易

    仅凭直觉草率行事。为避免出现这种情况，项目经理务必坚持根

    据数据和事实制定决策。

    果断在多数公司里，产品团队成员不必向项目经理汇报

    工作，但项目经理必须驱动同事做出决策。项目经理必须向大家

    传迭一种紧迫感，及时向团队收集数据和建议，适时向上级部门

    汇报情况，把问题理顺，用理性的思路和清晰的理由帮助大家，利用数据做出决策。

    判断力以上这些特点都基于起好的判断力。项目经理必

    须清楚何时催促进度，何时向上级汇报，何时需要收集更多信

    息，何时找个别成员私下交流。判断力很难言传身教，只能靠自

    己积累经验获得。

    态度如果产品不能按时交付，我们总能听到各种理由：

    可行性太差、资源不足、时间不够、资金匮乏等等。项目经理绝

    不能为自己找借口，必须克服所有障碍，解决所有问题，一往无

    前、愈挫愈勇，直到梦想成真。

    我相信，如果不是琳将这些卓越的项目管理要素注入企

    业文化，eBay绝不会有今天的成就。

    第4章 产品管理与产品设计

    Product Management Vs.Product Design

    理解用户体验设计

    很多产品经理向我抱怨说，他们的公司不懂用户体验设

    计，公司的用户界面设计师因循守旧，没人负责这方面的工作。

    他们不得不分散精力亲自操刀设计，即便如此，产品的用户体验

    还是很糟糕。有些公司直到产品开发后期才仓促把视觉设计外包

    出去，只为赶在质检前给产品穿上漂亮的外衣。还有些公司压根

    不知道用户体验设计是什么，不明白产品设计对产品有多么重

    要。

    在我看来，这是因为设计界未能充分向外界传达一种理

    念，即产品设计对产品的重要性。虽然设计界内部沟通很流畅，而且拥有一批杰出的设计师，比如马克·赫斯特(Mark Hurst)、休·

    杜伯里(Hugh Dubberly)、艾伦·库珀(Alan Cooper)等，但他们很少

    向外界普及他们的想法。相比之下，缺少设计师的团队更需要这

    些信息。设计界应该向所有产品团队(特别是产品经理)宣传产品

    设计的重要性和价值。

    好产品必须提供舒适的用户体验。舒适的用户体验是产

    品管理和用户体验设计共同作用的结果。这是个很大的话题，我

    们先从了解设计包括哪些角色、分工开始。这里我给出与用户体

    验设计密切相关的分工。注意我描述的是工作角色而不是个人，因为有的人可能承担多项工作。

    用户研究专门研究、分析用户，评估产品或产品原型是

    否符合特定用户的使用习惯。其具体工作包括拟订恰当的测试项

    目，监督测试，评估测试结果，提出改进方案。

    交互设计在理解目标用户的基础上设计有价值的、可用

    的目标功能、用户导航和产品使用流程。交互设计师通常用线框

    绘制产品需求，然后交给视觉设计师。

    视觉设计根据线框设计可见的用户界面(页面)，包括严

    格的布局、颜色和字体设置等。视觉设计能够传达并唤起产品蕴

    含的情感(其重要性常常被低估)。

    原型制作迅速制作融合了产品经理和设计师创意的产品原

    型。让用户试用，并根据反馈意见反复修正原型。

    以上四种角色与产品经理密切合作，将功能与设计相结

    合，满足用户需求。目标是确保产品同时具有可用性(用户明白如

    何使用产品)和价值(用户对产品的渴求程度)。

    除此以外，还要确认软件设计是切实可行的，因此必须

    让软件架构师评估设计和产品原型。这部分内容稍后详细介绍。

    对大型产品(尤其是大众互联网服务)来说，这四种角色

    缺一不可。开发企业级应用软件的公司如果想从众多竞争对手中

    脱颖而出，最简单的办法是提供优秀的用户体验。用户体验是大

    部分企业级产品的弱项。

    对小型产品来说，可以让一位设计师身兼多职。例如，我最近与一家创业型公司合作.开发针对大众的Web 2.0服务。

    对方只有三个人：一位产品经理、一位交互设计师(同时负责用户

    研究)、一位视觉设计师(同时负责开发原型)。他们的工作非常出

    色，很快就拿出了可供目标用户测试的产品原型。

    很多公司希望改善产品的用户体验，把用户体验设计外包给

    设计公司。这在一定程度上是可行的，但是有些工作不适合外包。例如，我认为交互设计不能外包，原因如下。

    1深入理解用户需求非常费时间，需要多个项目的经验积

    累。设计公司没时间深入了解客户需求，就算他们做到了，这些

    经验也很难保存下来，用到下一个版本里。

    2交互设计师必须现场深度参与项目开发，从立项直到产品

    发布。开发和测试过程中会出现各种细节问题，必须有一名交互

    设计师迅速做出决定。

    3产品的用户体验是公司的核心竞争力，必须在内部完成。

    如果让我选择，质量检验更适合外包。

    只要团队中有一位称职的交互设计师，视觉设计也可以

    外包，毕竟视觉设计公司很多，完全可以满足需求。此外，用户

    研究和可用性测试也可以外包，只是成本较高，对我这种重视测

    试反馈(参考第22章)的人来说更是如此，所以我建议让产品经理

    和交互设计师分担这项工作。

    至于原型制作，你可以从开发团队借个帮手来做。要让

    他明白原型代码和产品代码毫无关系，原型代码绝不能用在实际产品里。最好直截了当告诉他，原型的所有代码都是要废弃的。

    这个话题涉及的范围很广，限于篇幅，讨论暂告一段

    落。我希望以上介绍能为今后的讨论奠定基础。你的团队有人负

    责这些工作吗?还有哪些工作被忽略了?

    第5章 产品管理与软件开发

    Product Management Vs Engineering

    定义正确的产品与正确地开发产品

    如果说成功的产品是真实用户需求与现阶段可行性方案

    的结合，那么产品经理与开发团队之间(合作)的关系的重要性自

    然不占而喻了。

    产品经理负责定义产品方案：开发团队最了解哪些产品

    构思是可行的，他们负责产品的开发与实现。作为产品经理，你

    很快能体会到，只有与开发团队融洽合作，才有可能开发出合格

    的产品；否则等待你的将是一段漫长、难挨的日子。

    形成合作关系的关键是双方承认彼此平等——任何一方

    不从属于另一方。产品经理负责定义正确的产品，开发团队负责

    正确地开发产品，双方相互依赖。你要求开发团队完成任务，必

    须先取得他们的认可，确信为了达到产品质量标准必须这么做；

    开发团队也要留给你足够的空间，设计有价值、可用的产品。

    产品管理和软件开发相互促进。开发人员可以帮助产品经理

    完善产品定义。别忘了，他们最清楚你的产品设计是否可行。

    开发人员帮助产品经理完善产品定义的方式有如下三种。

    1.让开发人员直接面对用户或顾客，体会用户的困惑和疑

    虑，了解问题的严莺性，这样好点子常常会随之而来，譬如，可

    以邀请一名开发人员参加产品原型测试。

    2.向开发人员了解最新的技术发展动向，讨论哪些新技术可

    以用到产品里。开展头脑风暴，看看目前已实现的技术或即将实

    现的技术能不能解决手头的问题。

    3.让开发人员在探索(定义)产品的初期阶段参与评估产品设

    计，协助策划方案。产品经理常犯一类错误，即完成产品定义

    后，便扔给开发团队，置之不理。这样做只会贻误协调需求与可

    行性的最佳时机，等到发现问题时，为时已晚。

    同样，产品经理也应该配合开发人员的工作，方式如下。

    1.产品经理只定义满足基本要求的产品(参见第20章)。 产品

    经理应该意识到，自己要定义的不是最终产品，而不是满足基本

    要求的产品。只有这样，产品管理与软件开发之间才能形成良好

    的互动。

    2.一旦产品进入开发阶段，要尽可能避免修改产品的需求和

    设计。虽然有些事情超出你的控制范围，导致项目波动是不可避

    免的(开发人员也能理解)，但是千万不要在此时尝试突发奇想的

    点子。

    3.产品开发阶段难免会产生诸多问题，比如，用例丢失，用例设计考虑不周全等，这很正常，最优秀的团队也避免不了。

    产品经理应该迅速采取行动，在维持产品基本功能、尽量避免修

    改的原则上，拿出解决方案。

    我经常鼓励出色的开发人员尝试产品管理工作。我告诉

    他们，如果产品没有市场价值，那么无论开发团队多么优秀也无

    济于事。很多优秀的产品是程序员抓住用户需求，自己创业研发

    出来的。放宽眼界不仅仅有利于开发人员自己的职业发展，也有

    利于产品、顾客和公司。

    如何与异地的开发人员沟通?

    如今产品经理与开发团队各处一方的情况很常见。如果

    开发团队不在你身边，沟通和执行的难度将进一步加大。提高与

    异地开发困队之间的沟通效率，我有三条建议。

    l.开发团队距离越远，语言、文化.时差带来的沟通难

    度越大。如果产品经理不确定开发什么样的产品(或者反复改变想

    法)，异地开发团队就只能疲于奔命，白费力气。这简直就是一场

    灾难，丝毫不亚于医生开错药方。

    我将在第18章讨论把高保真原型作为产品说明文档基础

    的重要性。如果你与开发团队相隔很远，无论是讨论产品文档的

    内容，还是讨论修改产品设计，一定要借助高保真原型进行交

    流。阅读文档毕竟不轻松，如果文档是非母语的，或者阐述不清

    楚，那沟通效率就更低了。

    2.我们很容易发现和解决本地开发团队里出现的各种冲

    突(比如，两个管理者给出相互抵触的指导意见)。异地开发团队

    则会发生很多意想不到的情况，往往过了好几个月才发现问题，因此，必须有人在本地负责与异地团队的协调工作。这并不是说所有沟通工作都必须经过此人，而是应该明确异地开发团队只接

    受他的命令。这项工作可以由本地的项目经理、资深开发人员或

    者其他主管担任。

    3.如今商业沟通手段很丰富，除了电子邮件和即时消

    息外，还有视频会议可供选择。尽管如此，当面交流的优势依然

    不可替代。每个季度，产品经理至少应该前往异地与开发团队见

    一次面。面对面交流有助于改善(合作)关系，提高沟通效率。此

    外，交换人员也是一种有效的沟通方式，可以让主程序员来本地

    与产品经理共同工作一段时间，或者让产品经理到异地工作一段

    时间。

    如果是与印度外包团队合作，由于时差的原因这种合作

    会让人觉得非常惬意。每天早晨上班时，对方的项目进展已经摆

    在面前。你可以用白天(对方的夜晚)检查、测试代码，反馈信

    息，显著缩短项目的循环周期。

    请注意，如果是在异地开展与产品原型相关的工作，由

    于循环周期非常短(一天迭代好几次)，你必须随时准备处理对方

    的问题，投入更多的精力。

    另一种解决异地开发问题的方式是在异地聘请产品团队。这种趋势正在兴起，我相信它会被更多的公司采用。

    关于业务外包

    我合作过的所有公司都或多或少有业务外包，但是效果

    参差不齐。我认为造成效果不佳的原因是多方面的，比如，产品

    开发流程有问题，或者存在语言、文化差异，但是根本症结在于

    选择业务外包的初衷不对。

    外包不是为了节约成本，而是为了实现合理的人员配

    置。所以才要超越地理位置的局限，雇用另一个州区，或者另

    一个国家的员工，实现最佳组合。

    硅谷的生活成本越来越高，雇主支村给普通员工的薪水

    远不够他们的生活费。愿意长途通勤来硅谷工作的外地人毕竟有

    限。为了聘用优秀的员工，你不得不另寻他法。

    好在硅谷以外还有很多优秀人才。我曾有一支优秀团

    队，团队成员分布在瑞典、印度，以及美国的硅谷和波士顿。我

    们当时开发的平台支持两千万的用户，如果没有这些来自不同国家和地区的精荚协助，这个项目不可能成功。

    我很喜欢MySQL这家公司，他们多年来一直贯彻虚拟团

    队的理念。表面上，公司的两个总部位于硅谷和瑞典，但是他们

    的产品团队分散在世界各地。他们是虚拟的团队，充分利用分布

    在全球的顶尖数据库人才和系统软件高手的力量。虽然管理分散

    的团队不容易，但我相信如果MyS0L是一家集中式的公司，他们

    不可能取得今天的成就。

    正如二十世纪八十年代制造业被迫外迁一样，现在有些

    工作也逐渐从硅谷消失，例如，客户服务和测试。技术研发也开

    始出现类似的趋势。日益普遍的情形是软件架构师、测试经理、产品经理、设计人员留在公司总部，其他团队成员要么集中在异

    地某处，要么分散在全球各地。

    选择业务外包的关键是要挑选有能力的员工。很多管理

    者不明白这个道理，得知相同工种的员工在生产效率上存在着二

    十倍的差异时，他们表现得异常惊讶。你认为哪种团队更好——

    由五位精英组成的异地团队，还是雇用十五个平庸的本地人?提

    高生产效率产生的价值可以轻易超过雇用本地员工节约的成本。

    从这个角度来看，聘用居住在高消费城市的顶级程序员是划算

    的。

    如果你下决心发包业务，希望你是基于正确的原因——

    为产品团队寻找合适的人选，而不是仅仅为了节省一点儿小钱。

    程序员想重写代码?

    产品经理最担心听到开发人员这样抱怨：“不能再增加

    功能了!我们得停下来重写代码。代码库一团糟，就像纸糊的老

    虎，根本应付不了持续增加的用户。我们维护不下去了!”这一幕

    在很多公司上演过，现在依然在不断重演。1999年eBay遭遇这一

    幕时，公司濒临崩溃的情形超出所有人想象。Friendster几年前也

    发生过这种情况，当时他们正在向Myspace开放社交网络用户。

    网景与微软展开浏览器大战时，也发生过类似的事情，最后的结

    果大家都知道。事实上，没几家公司能渡过难关。

    一旦公司陷入这种困境，开发团队往往沦为替罪羊。这

    类问题通常是由产品管理失误引发的，比如，产品经理一直迫使

    开发团队满负荷工作，开发尽可能多的功能。所有软件架构都存

    在功能极限，如果忽视这个事实，一旦系统越过崩溃的临界点，就会造成无法挽回的结局。

    如果重写代码，用户就无法看到产品的任何改进。你可能认

    为重写代码至多也就几个月，但是实际时问无一例外要多得多。

    你只能坐在一旁，眼睁睁看着用户投奔竞争对手，而这个时候，竞争对手恰恰在不断地改进产品。

    如果你还没有遇到这样的情形，未雨绸缪很有必要。你

    需要预留一定的技术能力，eBay称为余量(headroom)。很多因产

    品迅速膨胀产生的问题都与扩展规模有关，余量意味着避免触及

    技术能力的上限，为用户数量的增长预留空间，为事务增长预留

    空间，为新增功能预留空间，保证产品的技术构架能够满足国队

    的要求。

    与开发团队合作应该遵循以下原则：在产品管理上为开

    发团队预留20%的自主时间，让他们自由支配。开发团队可以利

    用这些时问重写代码，完善架构、重构代码库中有缺陷的部分，或者更换数据库管理系统，提高系统一胜能，避免“需要停下来

    重写代码”的情形发生。

    如果你的糟糕处境已经初现端倪，就应该拿出至少20%

    的资源进行调整。我担心有些团队连20%都不愿意拿出来。如果

    你已经身陷重写代码的困境，说明公司危在旦夕，这里给出一点

    建议供你参考。

    第一，针对开发团队确定的产品修改目标制订切实可行

    的计划和时间表。通常，有经验的开发团队估计的开发时间八九

    不离十，但是重写代码是例外，因为多数团队没有重写代码的实

    际经验，估计往往过于乐观。你必须审时度势，仔细检查每处细

    节，确保计划切实可行。

    第二，只要有可能，最好把重写目标分成几大块，实现

    递增修改，让用户感受到产品的改进，哪怕会因此把九个月的工

    作时间延长至两年，也一定要采用这种方式。重写代码时，保证

    让用户看到功能的改进——即使会占用少则25%，多则50%的开

    发资源——对保持产品(尤其是互联网产品)的市场占有率至关重

    要。

    第三，由于开发用户可见功能的资源有限，必须谨慎选

    择正确的产品特性，确保产品定义的正确性。

    eBay起死回生后，我们发誓绝不重蹈覆辙，马上开始新

    一轮的代码重写，把危机甩在身后。事实上，由于发展迅速，eBay已经重写了三次代码，最后一次采用了完全不同的编程语言

    和架构。开发团队花了几年时问，大规模地改写了几百万行代

    码，同时在不影响用户群的情况下，开发了大量新功能。这是我知道的最惊心动魄的中途重建网站的故事。

    临渴掘井不如未雨绸缪，为防惠于未然，别忘了预留

    20%的余量。

    第6章 招聘产品经理

    Recruiting Product Managers

    寻找出色的产品经理

    “哪里能找到出色的产品经理?”CEO经常问我这个问题。

    我总是这样回答：出色的产品经理就在公司里，只不过在其

    他岗位上，有可能是软件工程师、用户体验设计师、系统工程

    师，等着伯乐去发掘。无论你打算从公司内部还是从公司外部招

    聘产品经理，必须清楚合适的人选应该具备哪些特质。这一章，我将列举产品经理应有的特质。

    个人素质和态度

    技术可以学习，素质却难以培养，有些素质是成功的产品经

    理必不可少的。

    对产品的热情

    有这样一群人，他们对产品有一种本能的热爱，把自己

    生活中的一切事物都看成产品，怀揣对优秀的产品的热爱和尊

    重。这份热情是产品经理必备的素质，是他们夜以继日克服困

    难、完善产品的动力。这份热情能感染团队成员，激励所有人。

    辨别这种特质很容易，可以让应聘者谈谈自己最喜欢的产品

    及喜欢的原因，聊聊不同领域的产品和他讨厌的产品，问问对

    方，如果有机会，他打算怎样完善自己最喜欢的产品。热情是难

    以伪装的，虚伪的做作毕露无遗。

    用户立场

    理想的产品经理不一定来自产品的目标市场(这种情况有

    利也有弊)，但是他必须融入目标市场。这一特质对制造大众产品

    的高科技企业尤为难得。我们倾向于从自己的角度去理解用户和

    市场。事实上，目标用户的经验、喜好、价值观、知觉能力、忍

    受程度、技术理解很可能与我们的犬相径庭。

    可以就产品的目标市场向应聘者发问，让他谈谈如何换

    位思考。了解应聘者对目标市场的感觉，最重要的是看对方是尊

    重目标市场希望融入其中，还是打算一意孤行改变用户习惯。

    对国际化的产品和针对特定地域的产品来说，换位思考尤其

    重要。各种文化虽有共通之处，但也存在许多差异。有些差异对

    产品无关紧要，有些则至关重要。应该考察应聘者是否足够了解

    目标市场，能否区分这两种差异。

    智力

    人的智力水平是无法替换的。产品管理需要洞察力和判

    断力，因此必须具备敏锐的头脑。勤奋当然是必需的，但从事这

    项工作光有勤奋还远远不够。

    招聘聪明人是项知易行难的任务，结果在很大程度上取决于

    招聘者的能力和可靠性。常言道，“物以类聚，人以群分”，此言

    不虚。方法之一是测试应聘者解决问题的能力。微软令人称道

    的、深入而有效的面试，即是考察应聘者解决问题的能力，通常

    由一位或多位领域专家就一个问题对应聘者进行深入考察。面试

    官不关心应聘者是否知道正确答案，而看重应聘者解决问题的思路和方法(智力优于知识)。如果应聘者回答正确，面试官会将问

    题略作调整，询问应聘者在新情况下如何应付。重复这个过程，直到应聘者被迫处理他不知道答案的情况，说出解决方法。

    职业操守

    每种团趴角色承担的义务和付出的努力都不相同。产品

    经理肩负着产品的前途和命运，绝不适合贪图安逸的人担任。即

    便掌握了时间管理和产品管理的技巧，产品经理依然要为产品投

    入大量精力。成功的产品经理能拥有时间享受清闲的家庭生活

    吗?只要具各足够的经验，我相信可以做到。但是，如果你期望

    的足一周只工作四十个小时，下班后把工作抛诸脑后，那是不现

    实的。

    成功的产品经理需要付出多少努力?在这个问题上，我

    对应聘者向来坦率，产品管理工作绝不能用时间来衡量，付出多

    少都不为过。紧急情况下临时找来的“救火队员”多半不是合适的

    产品经理人选。

    在漫长的项目周期里，产品经理需要付出的努力和承担的义

    务并非一成不变。有的阶段比较轻松，有的阶段则很紧张。但是称职的产品经理对产品的关注和忧虑程度，以及愿意为之付出努

    力的热情是不会改变的。

    正直

    在所有产品团队成员里，产品经理最能体现公司和产品

    的价值观。通常产品经理不直接管理团队成员，不能要求别人执

    行命令，所以他必须通过行动影响、说服身边的同事。这种影响

    基于相互的信任和尊重，要求产品经理必须是个正直的人。

    产品经理是产品团队、销售团队、公司高管之间的枢

    纽，经常要协调处理各种问题，比如提早供货、满足大客户的特

    殊要求。产品经理如何处理这些难题，同事们都看在眼里。

    信任和尊重需要时间培养，产品经理唯有通过工作展示

    自己的素质和能力，才能成为真正的团队领导。如果产品经理对

    待同事缺乏诚意，怀有私心，一碗水端不平，那么势必会影响整

    体团结和工作效率。产品经理虽然不必事事精通，但应当知道每

    位成员最擅长做什么，尊重大家发挥工作特长的意愿，充分信任

    大家。

    考察一个人是否正直绝不比考察他的智力容易，考察陌生的

    应聘者是否正直就更难了。对那些有工作经验的应聘者，可以问

    问他们如何处理工作中的压力，多追问工作细节。

    信心

    很多人相信经验可以让人产生自信。如果仅凭经验可以

    建立信心，为什么许多工作多年的产品经理却毫无自信?相反，刚刚步入社会的大学毕业生却往往充满自信(虽然这种自信通常源

    自对自身状况的无知)。

    自信是很重要的素质。公司高管、产品团队、销售团队都需

    要看到产品经理的信心，确信他们投入的时间、金钱、努力不会

    付之东流。自信的人更有说服力，更容易成为人们愿意追随的领

    导者。

    态度

    称职的产品经理把自己当成产品的CEO，愿意为产品的

    最终成败承担全部责任，绝不找借口。虽然他清楚产品按时成功上市要克服许多困难——开发难度大、开发时间长、成本过高、产品复杂等，但他明白预见和解决这些问题是他的责任。

    这并不是说产品经理要事必恭亲，监督每个人的工作，而是

    指出现问题时他应该及时承担责任，进展顺利时他应该及时给人

    家以鼓励。称职的产品经理知道.虽然产品的实现离不开大家的

    协助，但是他应该对自己的产品创意负责。

    技能

    掌握一些重要的技能是打造成功产品的关键。我相信，只要

    具备优秀的个人素质，所有技能都可以习得。

    运用技术的能力

    很多成功的产品经理是工程师出身，因为策划产品在很

    大程度上取决于对新技术的理解，以及如何应用技术解决相关的

    问题。

    出色的产品经理并不需要自己发明或实现新技术，但必

    须有能力理解技术，发掘技术的应用潜力。

    培养理解技术的能力有多种途径，可以参加培训课程，阅读

    相关书籍和文章，向程序员和架构师请教，参加开发团队的头脑

    风暴也不失为一种途径。

    注意力

    产品经理要优先解决重要问题。研发产品的过程中有很

    多干扰。能否集中注意力解决关键问题、克制不断增加功能的冲

    动、不受关键人物或重要客户的影响，取决r产品经理是否有足够

    强的自律性——不但要遵守公司制度，还要严格要求自己。

    几乎所有产品都有些不那么重要的功能——这些功能对提高

    销量和用户满意度毫无作用。如果去掉这些功能，产品甚至会因

    为简单、易用获得更多用户的喜爱。我建议过滤多余的功能，缩

    短研发时间，降低生产成本，让产品更早上市。

    时间管理

    电子邮件、即时消息和手机构成的世界充满了干扰。你

    可能一大早就来上班，拼命工作一整天，连吃饭喝水都顾不上，深夜回到家却发现到头来没完成一件重要工作。时间都用来“救

    火”和处理“紧急”事件了。

    熟练、迅速地区分重要任务和紧急任务，合理地规划和

    安排时间是产品经理必备的技能。如果产品经理无法集中精力完

    成真正重要的任务，那产品就难免命运多舛了。

    我认识太多每星期工作七十个小时、累得精疲力竭的产品经

    理。他们把所有的时间和精力都花在工作上，体力透支到了极

    限。对他们而言，最可怕的事实莫过于做的都是无用功。为此，我有意在培训课程中加入了时间管理和合理安排工作任务的内

    容。产品经理的时间应该用来改变现状，而不是疲于奔命参加大

    小会议、逐一回复邮件。有许多事情不值得做。

    沟通技能

    虽然沟通技巧可以学习，但要做到出类拔萃需要经年累

    月的练习。沟通(包括口头表达和书面表达)能力是产品经理必备的技能，如前所述，产品经理只能以理服人，绝不能靠职位压制

    他人。

    口头表达能力可以在面试中测试，测试书面表达能力则

    需另寻他法。我常建议应聘者随身携带文字材料证明其书面表达

    能力，比如，不涉及专利的产品策划文档。

    注意，如果应聘者使用非母语时带有口音或有轻微的语

    法错误，不代表其沟通技巧不佳，只要说话口齿清晰、易于理

    解、具有说服力即可，完美的发音和语法不是必要条件。

    产品经理会花许多时间写电子邮件、产品说明文档、策

    划书、同类产品分析文档等等。聪明的产品经理不会浪费时间写

    没人看的东西，一旦决定动笔就要做到最好，言之有物，让人信

    服。

    书面表达务必条理清晰、言简意赅，闲为同事(特别是公

    司高管)会根据这些文字评估产品经理的工作。有时文字材料是他

    们评判的唯一依据。

    还有一种常见的沟通形式是演讲。对许多人来说，面对听众演讲并非易事，有效地表达观点更是困难。尽管如此，演讲

    是产品经理的家常便饭。产品经理必须用最短的时间向公司高

    管、大客户、销售团队解释产品的内涵和重要性。

    我们都听过糟糕的演讲——幻灯片一张接一张没完没

    了，演讲人死板地朗诵条目，听众不得不费劲地揣摸每张图表的

    意义，既抓不住重点，也不明白价值何在。

    与此相反，成功的产品经理尽可能减少幻灯片的页数，他们

    的演讲充满热情、重点清晰、数据充分、引人入胜，绝不超时(甚

    至提前结束)。他们更喜欢听众提问，即使遇到暂时无法回答的问

    题，也会努力尝试向提问者和听众阐述自己的理解。杰里·韦斯曼

    (Jerry Weissman)的《演讲制胜：讲故事的艺术》是一本非常好的

    提高演讲水平的指南。

    商业技能

    作为产品团队的发言人，产品经理要协调团队与财务部

    门、营销部门、销售团队、公司高管之间的工作——必须使用这

    些人听得懂的概念和术语。

    我认为产品经理应该具备双语技能。这并非指中文和英

    文，而是指产品经理既能与程序员讨论技术，又能与管理层和营

    销人员讨论成本结构、边际效应、市场份额、产品定位和品牌。

    由于上述原因，微多产品经理都是商学院毕业的。企业需要

    懂得商务的人，所以雇佣MBA。虽然MBA也可以成长为出色的

    产品经理，但总的来说商业技能只是产品经理需要具备的多种技

    能之一，而且完全可以在商学院以外的地方学到。比如，技术人

    员进入产品管理领域后，通过阅读、培训学习商业技能是很常见

    的事。

    去哪里招聘产品经理?

    具备以上这些素质和技能条件的人极少见，和优秀的产

    品一样稀少。没有比产品经理更重要的职位了，所以必须用严格

    的标准考察应聘者。

    关于招聘产品经理，有许多不同的看法。许多公司认为

    他们需要的只是营销部门的人或有MBA学历的人，就像教科书对

    产品经理的定义一样。这种看法也许曾经是正确的，但如今无疑

    是一种谬论。

    许多公司喜欢招聘从顶级商学院毕业、拥有技术类学士

    文凭、具有行业经验的MBA。不过别忘了MBA课程几乎不涉及

    产品管理。如果你认为现在的MBA毕业生们知道如何管理产品，那就大错特错了。

    最有效的招聘途径是寻找具有上述特质潜力的人，通过培训

    课程和传帮带把他们训练成高素质的产品经理。这些人可能就藏

    身于公司内部。我认识许多优秀的产品经理，他们曾经是程序

    员、用户体验设计师、客服人员、技术支持人员、营销人员，甚

    至曾经是目标用户。他们利用各自的经验进一步完善产品管理工

    作。出于同样的原因，公司高管应该听取不同岗位员工对产品管

    理的建议。对于高管来说，这是宝贵的经验。

    行业经验重要吗?

    最近一位朋友向我了解一位产品经理应聘者(大卫)的情

    况，我曾经和大卫一起工作过。我的朋友是一家大众网络服务公

    司的主管，他非常喜欢大卫，但他心里有个疑问：“大卫是企业

    级软件产品方面的专家，他适合我们这种企业吗?”

    我忍不住笑了，告诉他四年前我遇到过类似的问题。当

    时大卫现在的主管问我：“这个人对系统软件十分在行，可他能

    够做好企业级软件吗?”

    其实大卫所受的教育与系统软件、企业级软件、大众网

    络服务都无关，甚至与软件技术无关。他是学金融出身的，非常

    聪明，善于快速进入新领域，理解新技术。

    许多产品经理是因为他们的行业经验获聘的。经常有人

    问我产品经理是否必须具备领域和行业经验，我认为对某些产品

    来说，专业知识是必要的，比如，研发心脏除颤器，最好有一位

    懂得心脏护理的产品经理。但这只是个例，并非原则。

    我甚至认为资深行业经验时产品经理的工作可能是不利

    的，因为长期从事某一行业的人通常会落入一种常见的产品的心

    理陷阱：他们以为自己了解目标客户，盲目自信。产品经理应该

    习惯放下自己的成见。拥有资深行业经验的人也能做到这一点，但他们必须付出更多努力，保持开放的心态。

    我并不是说管理产品不需要行业知识，相反，我觉得了

    解产品的领域知识(粗浅的了解不算数)是绝对必要的。我相信通

    过积极学习，高素质的产品经理可以快速熟悉新行业。以我自己为例，熟悉新行业达到自信制定产品策略的程度，只需要两三个

    月时问。

    我相信开发企业级软件、系统软件、大众网络服务和消

    费类电子产品各自有不同的技能要求，例如，企业级软件的用户

    是数目较少的大企业(而不是数量上百万的消费者)，所以有不同

    的手段了解需求、定义产品；不同类型产品的销售渠道各不相

    同；如果产品涉及硬件设备，则必须了解它会对流程和进度造成

    哪些影响；如果开发大众网络服务，必须知道如何展开规模管理

    和社区管理。

    总的来说，我认为产品经理大约有80%的技能和天分可

    以用于不同类型的产品。

    我并非要贬低经验的价值，但我发现最宝贵的经验不是

    行业知识或技术(这些都可能过时)，而是打造优秀产品的流程、领导产品团队的能力、应对产品扩张的经验、个人对自己的认

    知，以及自我激励的能力。

    与行业知识密切相关的是技术专长，业界一度非常看重

    两者的联系。有一次，我看到一家企业级软件心司招聘产品经

    理，要求应聘者具备开发Linux产品的经验。的确，不同操作系统之间差异很大，但产品经理如果连处理不同操作系统对产品影

    响的能力都不具备，那么等待他的麻烦将远比缺乏Linux知识来

    得多。

    高科技产品行业虽然要求快速学习新技术，但曼重要的

    是预见如何应用技术合理地解决问题。

    技术发展很快，所以产品经理必须善于快速学习新技术，解

    决新问题。我面试应聘者时，不关心他们已掌握的知识，只看重

    他们的学习思路。比如，让他们回忆研发产品之前，他们需要学

    习哪些知识，需要多长时间学习，如何利用这些知识。

    年龄不是问题

    各个年龄段都有出色的产品经理。为什么有人二十五岁

    就脱颖而出?首先，互联网真正普及是1995年以后的事情，因

    此，今天二十五岁左右的人和我们的上网经验一样多。互联网兴

    起时，十几岁的青少年很快学会了成年人搞不懂的技术。其次，经验虽然需要时间积累，但其他素质，比如智力和对产品的热情

    则与年龄无关。

    当年为网景公司年轻的创始人马克·安德森(Marc

    Andreessen)工作时，我不得不适应给这个二十出头的年轻人打工

    的事实。但是当我发现他吸收新技术和说服他人的能力后，我很

    快就忘记了他的年龄。未曾与他谋面的人会认为，拥有这种商业

    能力的人至少得年过四十。

    寻找出色的产品经理不能以年龄，性别或种族作为判断

    标准。我知道行业中仍然存在不少偏见。例如，由于重视沟通技

    巧，我们尽量招聘母语是英语的应聘者。

    我指出这一点并不想谴责谁，只是想提醒大家，无意的

    偏见可能会让我们错过出色的产品经理。下次莱个大学毕业生带

    着他的产品创意朱找你时，你或许应该听一听，他的创意很可能

    是下一个Facebook。

    第7章 管理产品经理

    Managing Product Managers

    建设公司从建设团队开始

    我一直提倡设立严格的产品经理入职标准，因为他们的

    工作决定了产品和生意的成败。但我常常听到管理者抱怨公司的

    产品经理是以前的产品营销人员，这些所谓的产品经理具有我在

    前面的章节提到的所有问题。要改变这种现状着实让管理者头

    痛。因此，我想谈谈产品经理管理者的角色和职责。

    管理产品经理的人通常被冠以产品总监或产品副总裁的

    头衔。这是高科技公司里最重要的职位之一。产品总监对公司业

    绩的影响绝非他人可比。成功的产品可以开启新的业务方向，失

    败的产品则可能拖累公司破产。这份工作不成功则成仁，鲜有居

    于二者之间的。

    产品总监的关键职责有两方面。第一，组建优秀的产品经理

    团队。第二，规划公司的全局产品战略，对产品组合负责。下面

    我分别讨论这两种职责。

    建设产品管理团队

    因为产品管理职位非常重要，所以训练和培养产品管理

    团队的工作能力不但是产品经理的任务，更是产品总监的任务。

    不称职的产品经理浪费开发时间、怠慢用户、辜负客户的信任，注定是要失败的。其他岗位可以容许不称职的员工侥幸过关，总

    能找到替补收拾烂摊子，但是人部分产品只有一个产品经理，想

    找替补都难。如果产品经理不称职，只能退而求其次，请其他团

    队成员(比如主程序员)越俎代庖。

    如果你发现手下的产品经理总是无法胜工作，就要立刻

    采取行动。有些人永远不可能成为称职的产品经理——他们就是

    不适合这个职位，无论如何培训、指导都无济于事，但对那些有

    潜力的产品经理，应该多花时间帮助他们提升管理产品的技能。

    不管怎样，产品总监要确保每个团队成员都没有掉队。

    我认为新产品经理必须经过约三个月刻苦学习才能开始

    管理产品。这段时间，他要融入目标用户和客户群，学习相关的

    技术，了解市场和竞争局势。管理者应该为新人创造学习条件，监督学习进度。注意，这三个月还不包括对产品经理的技能和职

    责的培训时间。三个月的学习期也适用于有经验的产品经理，因为他们也需要熟悉产品特有的客户和领域。

    设计一套培训计划，让新入职的产品经理充分接触用户

    和技术。已经入职一段时间的产品经理如果在这方面掉了队，也

    要让他们在工作之余补补课。确保他们明白自己的不足之处。

    如果某位产品经理无法胜任工作，管理者应该重新寻找

    合适的人选。解雇别人并不容易，但这是你的职责所在。为了团

    队、公司、客户的利益，你必须纠正现状，帮助下岗者找到擅长

    的岗位，同时擦亮双眼寻找新人接替他的工作。

    一旦找到有潜力、称职的人选，就应该放手让他们工

    作，尽情发挥其潜力。如果你事无巨细都过问，他们就不可能步

    入正轨成为产品的主人。当然，一定的监督和帮助还是有必要

    的。如果你不相信你的产品经理，那就换一个可以信任的人。只

    要你给他们足够的空间，我保证你不会失望。

    请注意，你必须确信产品经理有足够的能力，才能够授

    权给他们。授权给不称职的人，那是推卸你作为产品总监的责

    任；如果你事必恭亲，那是替他们承担责任。

    聪明的产品总监知道，团队成员的出色表现就是自己的出色

    表现，所以要雇佣比自己聪明的人，尽可能为他们创造宽松的工

    作条件。

    规划公司的产品战略

    产品总监负责管理公司的系列产品，决定公司经营什么

    产品，仔细评审每款产品的产品战略和研发流程。

    他必须透彻理解公司最新的商业战略，确保产品战略直

    接支持商业战略；与产品经理一道完成产品规划，共同实现规

    划；带领产品团队建立产品原则(见第13章)，坚持按产品原则研

    发产品。

    有了最好的产品经理团队，即使每个人的工作都非常出

    色，产品总监还是可能遇到产品间的冲突，毕竟每个产品经理只

    想优化自己的产品。产品总监必须设法识别、解决这种内部冲

    突。

    产品总监要负责制订产品组台路线圈——兼顾用户需求和商业目标，从全局出发制订产品发布计划。

    最后，产品总监要处理好与公司同事的关系，特别是得

    到公司高管(尤其是CEO)的信任。产品总监是公司的关键人物，必须礼贤下士，集思广益，决策有理有据、公开透明。受人尊重

    的产品总监才能得心应手地解决意见冲突，抵制错误决定。

    这是一项极具挑战的工作。工作在这个岗位上的人无一

    例外是公司最优番的员工。

    怎样评估产品经理的工作?

    常常有人问我如何评估产品经理的工作业绩。我相信唯

    一正确的评价标准是看产品本身是否成功。我知道这个答案难以

    让人满意，因为评估产品表现的方式难以确定。是按收益计算，还是按利润计算?是按用户数量计算，还是按页面访问量计算?这

    些指标从不同方面反映了产品的情况，但无法全面反映产品经理

    的业绩。

    最近出现了一种考察业绩的新指标：用户净推荐值(netpromoter score，NPS)。这个标准很简单，请访问http:www

    netpromoter.com阅读相关信息。

    它的原理如下。调查用户是否愿意向他人推荐你的产

    品，满分是10分。选择9～lO分的客户称为推荐者(他们会告诉朋

    友非常喜欢产品，相当于在为你做宣传推广)：选择7～8分的是中

    立分子；选择0～6分的称为贬损者，他们不但不推荐产品，反而

    会在朋友面前诋毁产品。计算出推荐者所占的比例，再减掉贬损

    者的比例，就得到了NPS，它反映用户对产品的态度。

    很多公司采用了这个指标，有些公司的NPS得分很高，如苹

    果，亚马逊、谷歌、eBay——这是意料之中的。

    这个指标反映了产品的用户体验水平。当然，理论上即

    便拥有100%的满意用户，公司也可能因为在每个用户身上都亏

    损而破产。但是就单个指标而言，我认为它有利于让公司关注用

    户满意度。而且口碑营销是最有效、成本最低的营销方式。

    这个标准还能用来区分优质收益和劣质收益。例如，赞

    助商或广告合伙人希望利用你的网站向你的用户群宣传他们的产

    品，这件事可好可坏，取决于如何达成。如果做得不好，短期收

    益可能很可观，但是影响了用户体验(NPS会体现出来)，从长远看，业务增长会减缓。反过来，如果做得好(与广告合伙人密切合

    作)，就会提升用户体验，会让业务增长更快。

    这就是为什么特例产品(参见第32章)是危险的。客户为

    了低价购买产品就必须承诺接受限制备件。特例产品代表了劣质

    收益，它会降低用户的满意度。

    你可以跨公司甚至跨行业比较NPS，这是件有趣的事。不过

    NPS最主要的作用还是用来观察公司产品和服务的优化情况。如

    果你还没用过NPS，不妨一试，观察产品变化如何影响NPS。你

    需要慎重决策，考虑每件事对NPS的影响，提高用户满意度。

    产品管理属于哪个部门

    很多公司不知道产品管理应该归于哪个部门，大多数公

    司选择开发部门或市场部门。如果产品团队工作能力强，则划分

    到哪个部门都可以，但一般来说，划分到这两个部门我都不赞

    同。

    在我合作过的公司里，产品管理通常被划分到市场部门。这种组织结构基于一种错误的观念，即认为产品是通过与客

    户沟通确定的，而只有市场部的人才能与客户沟通。我不想再分

    析这种想法的谬误，我相信有很多原因会导致仅仅与客户沟通得

    不到成功的产品。这种结构还有一个问题，那就是在市场部门里

    产品营销工作和产品管理工作混在一起。产品营销和产品管理要

    求的工作技能和工作职责大相径庭，这样做的结果往往是两败俱

    伤。

    另一种情形是产品管理被划分到开发部门。虽然让设计

    产品的人与实际开发产品的人一起工作有其益处，但是也有弊

    端。为什么?因为开发部门只顾埋头开发产品，他们并不关心产

    品是否值得开发。这种结构容易导致产品管理团队被眼前的产品

    细节包围，忙于制订产品说明文档，看不到市场需求，也无法探

    索制胜的产品策略和途径。毕竟探索产品需要不同于开发的思维

    方式和专业技能。此外，开发团队强调执行力，在强调执行力的

    组织里从事探索性工作是非常困难的。

    既然市场部门和开发部门都不合适，那究竟该把产品管

    理放在哪呢?

    我认为应该把产品管理部门提升到与开发部门和市场部

    门相等的级别。理想的情况下，产品管理部门应该包含设计团

    队，因为产品管理和用户体验设计必须紧密合作。我相信今后会出现越来越多独立的产品管理部门(或产品管理与设计部门)，这

    些部门甚至会由产品总监或者是首席产品执行官亲自管理。

    这样的组织结构好处很多，首先是产品部门的管理者将

    在高管队伍中占有一席之地。公司依赖产品，市场部门和开发部

    门各自有任务和挑战，产品很容易在这些任务和挑战间被忽略

    掉。此外，这种组织结构清晰地表明产品既不是由技术驱动的，也不仅仅是由销售或市场需求决定的。

    很多大公司存在一种特殊情况，即心司的开发人员集中

    在一个部门里，而业务部门是分散的。这样便于公司同时关注多

    条业务线，同时提供高效的通用开发服务。产品管理部门和设计

    部门可能是独立的，也可能被划分到集中的开发部门，还可能被

    划分到业务部门。在这类公司里，业务部门的经理常常承担着产

    品管理的工作，如果产品管理团队不属于业务部门管理，就会产

    生问题。遇到这种情况，我建议把产品管理和交互设计划分到业

    务部门。

    虽然我解释了理想结构的合理性，但是要实现这种结构并不

    容易，公司也许不愿意改变组织鲒构。保持现有姑构不一定会出

    问题，毕竟团队的素质和能力才是决定因素。如果你手下尽是精

    兵强将，公司上下也认同你们的价值观，无论产品管理被划分到

    哪个部门都能够成功。

    范例

    请访问http:www svpg.comexamples浏览产品策略、产品路线图、产品组合路线图的范例。

    第8章 巴顿将军的忠告

    Patton’s Advice for Product Managers

    目标管理

    永远不要告诉别人怎么做。告诉他们做什么，他们自然

    会发挥天赋，给你惊喜。

    ——乔治史密斯巴顿

    巴顿将军是一位声名显赫的大人物。他的名言警句不计

    其数，但我更愿意引用上面这句，从两个角度启发产品经理。

    首先，产品经理收集需求时，常听到客户建议“如何

    做”产品，而不是产品应该“做什么”，毕竟思考问题的解决方法是

    人类的本性。如果产品经理试着思考产品要做什么，就会惊讶地

    发现实现方法如此之多。客户其实不必考虑解决问题的途径。他

    们不知道什么可行，预先想出方案更是难上加难。

    其次，产品经理习惯于告诉用户体验设计师如何设计产

    品，却忘了告诉他们产品要“做什么”。这是普遍存在于用户体验

    设计中的问题。

    在很多公司里，用户体验设计师是稀有资源，通常在产

    品需求说明文档完成之后才参与产品设计，这限制了设计师的作

    用。用户体验设计师应该在产品经理分析目标市场、思考解决方

    案的初期阶段就发挥作用。

    优秀的用户体验设计师.特别是交互设计师可谓风毛麟

    角。如果你发现了这样的人选，就一定要给予足够的创作空间，充分发挥其才能，使设计师成为产品团队的重要组成部分，让他

    们探索各种设计方案，倾听他们分析用户的行为和喜好。

    以上观点也同样适用于软件开发人员。开发团队不会像

    产品经理要求顾客详细描述需求那样要求产品经理提供技术实施

    的细节。据我所知，这种情况极少见，主要原因是产品经理与开

    发人员之间的界限比较清晰。但我看过一些产品说明文档，仍然

    有相当一部分涉及技术实施的细节问题。

    总之，你留给用户体验设计师和开发人员的空间越大，他们就越有可能打造出用户喜爱的产品。

    第9章 产品副经理

    Deputy Product Managers

    办公室里最聪明的人

    从本质上讲，产品就是创意，产品经理的职责是想出好

    点子并加以实现。这需要技巧和实践，难以言传。我们需要好点

    子，有些想法是我们自己的创意，但如果仅依靠自己，就会严重

    限制创意的发挥。

    我有一点工作体会，做产品要找公司最聪明的人合作。

    我发现每个公司都有几个聪明绝顶的人，这些人是公司的潜在资

    源，关键看你能不能发现他们。如果有幸能找到他们，就应该不

    拘一格地任用。我把这些人看做产品副经理，甚至公开授予他们

    头衔，把他们招进产品团队。

    为了说明公司的角落里隐藏着高人.我给大家举几个有

    代表性的例子，都是真人真事，只不过用了化名。

    山姆我花了很长时间才注意到他，因为他的经理一直对

    他评价不高。幸好很快就真相大白了——山姆卓越的才华使得他

    愚笨的经理感到地位岌岌可危。现在他的经理已经不知去向，而

    山姆则成为了优秀的产品经理。

    克里斯我是在和同事一道拜访客户时遇见克里斯的。销

    售人员在介绍当地的情况时毫无章法，我们听得云里雾里，不知

    所云。后来，一位名叫克里斯的系统工程师(他负责为销售人员提

    供技术支持)“临危受命”，清晰、明了地阐明了当地的情况，令客

    户佩服不已。之后，我邀请他去喝一杯。杯酒之间我就坚信，对

    面坐的是个天才。我邀请克里斯为公司提供产品建议和创意。现

    在他是一家“财富五百强”公司的产品总经理。工程师通常对技术

    相当熟悉，所以他们往往对客户需求有极强的洞察力。克里斯不

    仅能深入了解客户需求，还能提出可行的解决方案。

    艾里克斯在开发团队中，艾里克斯显得相当低调。他害

    羞内向，也没什么野心，但聪明过人，重视用户体验。大家没有

    发现艾里克斯在产品创意方面同样才华横溢。在我的帮助下，他

    很快成为了公司产品理念的先锋。

    马特即使是高新技术企业，也存在不同形式的歧视。年

    龄歧视是最不应该的。马特十几岁就大学毕业，并一直奋发向

    上。但我见到马特时，他并未被重用，因为他的经理认为这么年轻的小伙子无法承担重任。后来，马特跳槽与人合伙开了-家新公

    司，他们的产品改善了上百万人的生活。

    来拉她是个天才，却被认为有两个“缺陷”——女人、印

    第安人。在这个男性主导、技术驱动的行业里，女性常被轻视。

    而且大家认为印第安人性格温和，魄力不足。但米拉很快就从枷

    锁中解脱出来，成为一名出色的产品主管。我在华人当中也见过

    类似的情况。不要让文化差异或口青蒙蔽了你。

    产品经理还可以向自己的领导借力，听取他们对产品的

    建议，虽然他们不太可能参与具体工作，但并不表示他们会袖手

    旁观。

    你需要的帮手可能隐身于公司各处——开发部门、销售部、客户服务部门，甚至董事会。如何发现他们呢?

    l打听! 多问问同事，肯定会有收获。

    2采用走动式管理模式。这源于惠普的做法。管理者要走出

    自己的办公室和圈子，花时间与员工相处。

    3认真倾听与会者的对话与发言。

    4敞开办公室的门，让大家知道你随时欢迎他们向你提出产

    品建议。

    5坦率地把你的烦恼告诉同事，大家会热情地帮助你。

    6一起泡吧。工作之余，产品经理总是与产品经理一起消

    遣，高管总是与高管为伍，这是司空见惯的事。如果你能抽出时

    间与普通员工一起休息、娱乐，一定能发现“埋在沙里的金子”。

    许多产品经理不愿意接受这些建议，主要是因为过于自

    负。他们认为自己才是提出创意的人，如果由别人提出创意，还

    要产品经理做什么?虽然我也有些好创意，但是更多的灵感是受

    别人启发得到的。记住，公司的目标是打造卓越的产品，所有可

    以借用的力量都是可取的。

    第10章 管理上司

    Managing Up

    十条经验

    如何管理上司——这是大公司里产品经理最头痛的问

    题。与上司的沟通时常让他们产生挫败感——倒不是因为上司对

    他们有偏见，而是因为上司的指示就像流动的沙子般捉摸不定。

    上司每周给他们的指示都不相同，甚至截然相反，常常是“走两

    步退一步”。大公司里高管和股东尤其多，让大家朝着统一的目

    标前进简直“难于上青天”。

    导致项目波动的原因很多，除了不同上司之间的意见分

    歧，还有其他因素作祟，如竞争压力、技术更替、人力资源匮

    乏、预算不足等等。它们都会对产品计划产生直接或间接的影

    响。这是在大公司工作的代价。在大公司工作的优势在于，一旦

    你能平衡利用这些资源，产品会在市场上引起巨大的反响，这是

    小公司望尘莫及的。

    困难无处不在，小公司和正处于创业阶段的公司也有自己的麻烦，但大公司面临的挑战尤为复杂。我在各种规模的公司工作

    过，积累了…些处理问题的经验。事先说明一下，这些问题是固

    有的，不可能完全消除，唯一能做的是缓解其影响。下面我介绍

    管理上司的十条经验。

    1.为项目波动做好准备我用项目波动代指让你心烦意乱的各

    种返工、计划变更。不要企图消灭项目波动，但是可以尽量降低

    其负面影响。方法是提高警惕，记录工作进度，比如，记录每

    周、每月、每季度有多少时间项目在往前推进，掌握项目波动的

    规律，寻找对策。制订项目计划时，预留出时间应对变化和调

    整，做好“做无用功”的心理准备。这个方法不仅能缓解压力，提

    高计划的准确度，还有助于挖掘有待改善的细节。

    2.注意沟通的方式与频率千人千面，管理者也不例外的。有

    些管理者喜欢事无巨细亲力亲为；有些则希望尽量不被打扰。有

    些喜欢你用邮件介绍工作进展：有些则喜欢简短的口头汇报。弄

    清上司的喜好，对症下药。

    3.会前沟通很多公司频繁开会。公司的高管、股东越多，汇

    报进度和评估工作的会议就越多。为了让大家了解进展，必须确

    保人人到场。组织好会议的诀窍是在正式会议召开前充分沟通，即在会前逐一会见与会的高管和股东，提出你的观点，征询他们

    的意见，确保会议召开前你们已经达成一致意见。如果会前沟通顺利，可以大大缩短正式会议的时间，结果也将毫无悬念。正式

    会议的作用只是让与会人员认识到大家取得了一致意见。

    4.多提建议，少谈问题管理者希望听到解决问题的方法，而

    不是听你报怨。最好根据问题的重要性列举出多种解决方案，并

    附上你的依据和建议。

    5.向上司借力许多员工不懂得向上司借力。假如你通过分析

    得出了解决方案，公司高管没有时间与你进行会前沟通，但你的

    上司能找到机会与他们交流，你可以把想法告诉上司，请他帮你

    转达建议。上司也想尽早结束会议，因而会乐于帮你。

    6.充分准备管理者通常聪明过人，能够立马发现你思路和计

    划上的漏洞。你最好准备充分，弄清问题所在.做到有备无患。

    7.缩短邮件篇幅产品经理喜欢写长篇的邮件向上司汇报工

    作，这是大忌。上司每天可能会收到上百封邮件，他更希望用简

    明扼要的方式进行交流。收件人的级别越高，邮件的篇幅就该越

    短。你可以添加附件，但不要让正文篇幅过长。

    8.多用数据和事实说话与上司(尤其是高管)打交道时，务必要提供数据和事实。网景公司前CEO吉姆-巴克斯德尔(Jim

    Barksdale)说过一句名言：如果我们依照个人看法米做决定，那就

    是臆断。多做准备工作，收集事实和数据，你的建议才有说服

    力。

    9.内部宣传向公司同事宣传产品，让大家认可你的工作，乐

    于帮助你。充分、有效的宣传，可以大大降低与其他部门合作的

    成本。

    10.做让领导省心的员工管理者的工作是保证团队高效运

    作，他们时间有限。不要劳烦你的上司做你的导师，但可以在你

    的直接管理层外另寻导师。思考如何节省上司的时间，你会获益

    匪浅。

    大公司的产品经理屡屡受挫，不足为怪。如果你也有类似的

    苦恼，不妨尝试一下这些建议。

    第二部分 流程

    Process

    成功的实践经验

    一流软件(互联网)公司的流程及技术与普通公司的相比有很

    多不同之处。

    本书第二部分讨论探索及开发富有创意的产品时反复应

    用的流程和成功的实践经验。

    第11章 评估产品机会

    Assessing product Opportunities

    确定待解决的问题

    市场给予新产品诸多机会，即使成熟的市场也不例外。

    因为市场环境充满变数：竞争对手不断被淘汰，新技术、新创意

    不断涌现……

    产品经理必须用他灵敏的“嗅觉”，从纷至沓来的机遇中

    迅速评估、挑选出有市场潜力、可行的创意，过滤那些没有价值

    或时机尚不成熟的点子。

    大多数公司的产品选择权掌握在高管手中，这类决定不

    容置疑，只能执行：有些公司的产品选择权由市场部门掌握；还

    有些公司的产品创意来自开发团队。在这些情况下，评估产品机

    会的流程往往被忽略，一切全凭直觉判断(更有甚者，只要大客户

    提出要求，项目就直接上马)。

    正常情况下，业务人员会撰写一份论证产品可行性的市

    场需求文档，描述待解决的问题。理论上，市场需求文档只描述

    产品机会，不涉及具体解决方案。但是多数公司跳过了市场需求

    文档，有些将市场需求文档误写成产品规范文档，有些则没回答

    该回答的问题。即便完成了市场需求文档的公司，也常常将它束

    之高阁，不闻不问。

    结果出现大批绕过市场需求文档，回避评估产品机会，直扑产品的产品经理。凡事须三思而行。想快捷、高效地开发产

    品谈何容易?

    评估产品机会是产品经理的重要职责。评估产品机会的目的

    在于：淘汰馊主意，避免浪费时间和金钱；挑选合适的产品机

    会，团结团队，理解产品，整合资源。为了评估产品机会，我要

    求产品经理回答如下十个问题。

    1.产品要解决什么问题?(产品价值)

    2.为谁解决这个问题?(目标市场)

    3.成功的机会有多大?(市场规模)

    4.怎样判断产品成功与否?(度量指标或收益指标)

    5.有哪些同类产品?(竞争格局)

    6.为什么我们最适合做这个产品?

    7.时机合适吗?(市场时机)

    8.如何把产品推向市场?(营销组合策略)

    9.成功的必要条件是什么?(解决方案要满足的条件)

    10.根据以上问题，给出评估结论。(继续或放弃)

    以上问题并不涉及具体的解决方案。机会评估只讨论待

    解决的问题，不应涉及具体解决方案。将来有大把的时间来考虑

    解决方案，现在是认真考虑要解决什么问题的时候。产品经理往往把待解决的问题和解决方案放在一起考虑，当具体解决方案遇

    到困难时，他们会放弃产品机会。这是典型的“把洗澡水和孩子

    一起泼掉”的做法。

    最难回答的往往是机会评估的第一个问题——产品价

    值。很多人感到惊诧，这应该是最容易回答的问题!问问产品经

    理产品要解决什么问题。你会发现多数人答非所问，只能泛泛地

    说出产品的功能和特色。

    另一个棘手问题是如何评估市场规模。你可以求助于行

    业分析师、贸易协会、公司财务，再结合自己的分析做出判断。

    评估务必谨慎，避免浮夸，不是所有产品都有十亿美元的市场。

    营销组合策略也很重要。它描述具体销售方式，甚至会

    影响产品需求。

    成功的必要条件(解决方案要满足的条件)指的是在调研

    过程中发现的特殊需求。同样，确定必要条件的任务不是描述解

    决方案，而是搞清楚产品的依赖因素和约束条件。比方说，如果

    要通过系统集成商来销售产品，对方可能会对产品的扩展性、合

    作方式提出要求。

    说白了，产品公司的任务就是挑选合适的产品机会，然

    后向用户提供实用的解决方案。产品经理负责评估各种创意，在

    公司投入宝贵的时间和金钱之前，淘汰蹩脚的创意，找出对公司

    最有利的机会。

    产品的机会评估结果出来后，别忘了呈报给公司高管，与高管讨论，决定是否开发此产品。如果决定继续开发，了解高

    管的想法，有助于你进一步开展工作。

    如果CEO告诉你不管愿不愿意，都要继续开发，该怎么办?

    在这种情况下，迅速进行机会评估，明确产品需求也是必要的。

    你得到的结论可能会改变CEO的看法，即使不能，至少你能明确

    产品目标，大大提高产品成功的可能性。

    开发新产品还是维护旧产品?

    经常有人问我在开发新产品和改善原有产品之间如何取

    得平衡。他们希望知道具体比例。我认为应该换个角度来考虑这

    个问题。对我来说，所有的项目，不管是开发新产品，还是改善

    原有产品，都属于产品机会，与新旧无关。我们要考虑的是哪个机会更好。

    开发新产品能为老用户提供更多选择，还能吸纳新用

    户；改善原有产品能提高老用户的满意度，也能吸纳新用户。两

    者各有千秋。

    关键在于比较两者的机会。产品团队一视同仁地评估两

    者的收益与成本，然后由管理团队做出决策(参见第14章)。新公

    司多半会选择新的产品机会，具有一定规模的公司多半会选择完

    善现有产品。在选择产品机会时，机会主义并不是不可取的。

    很多时候，好机会就在眼皮底下，完善不尽如人意的产

    品特性往往事半功倍。举例来说，100位打算注册使用产品的用

    户最后只有9人顺利完成注册，如果设法把人数提高到18，就能

    让产品的收益翻倍。这种改进往往很容易实现，只要做一些原型

    测试和用户测试，很快就能找出存在的问题，想出解决方案。

    再举一个例子，产品公司往往雇用上百人的客服团队为

    用户提供售后服务，如果能提高产品的易用性，将大幅减少客服

    人员的数量，降低成本，同时提高用户满意度和用户净推荐值。

    每当我指出这类“机会”、提高公司利润后，都会被看做

    英雄。这主要是因为软件公司过于自负，以为产品已经足够好，继续投入也不会有大的改进。他们要么认为产品非常复杂，根本

    无法改进；要么满足于9%的注册成功率，宁愿花钱做营销，投

    放广告；要么认为客户服务的支出是必不可少的。实际情况往往

    是产品缺乏竞争力，公司只能在其他方面寻找补救措施。

    从另一个角度看，这是糟糕的产品设计和蹩脚的用户体验导

    致的结果。更通俗她讲，就是原有产品质量差，公司不愿意想办

    法改进，反而认为开发新产品更容易，导致原有产品无法发挥潜

    力，产生应有的利润。除非这些公司改变研发产品的方式，否

    则，新产品难免重蹈覆辙。

    钱花在哪儿?

    你了解产品经济学吗?你知道产品的收益模式吗?你知道

    产品的成本是多少吗?你知道产品为，公司带来了多少收益吗?

    据我了解，多数产品经理(尤其是技术出身的产品经理)

    对产品(或公司)的营利模式理解非常有限。

    我相信结交一位懂财务的朋友能让产品经理受益匪浅。

    每到一家公司工作，我都会让CFO给我引荐一位财务部门的同

    事。他们往往能为我提供有用的信息，助我一臂之力。这种帮助

    主要表现在以下三个方面。

    1帮助你了解产品

    让他们帮你分析财务方面的问题，问问他们前面提到的

    这些问题。请他们帮你评估产品，看看公司的投入是否划算，他

    们对产品的预测如何。

    2.帮助你了解用户

    我们通常只能利用软件工具了解用户在网上的活动，但

    是财务部门掌握着交易记录、支付信息、客户数据和经营报表。

    要注意哪些信息是你有权获取的，以及应该怎样利用这些信息。

    我不止一次从财务人员那里获得有用的信息，每次都给我不

    小的惊喜。这些信息暗示着绝佳的产品机会。我曾经问财务部的

    朋友，为什么其他人不知道这样的机会?他回答说，因为没有人问过他。财务人员的工作通常费力不讨好，而且有着严格的财务

    进度要求，他们不会跑到你面前推销机会，你应该主动去找他

    们。

    3确认商业上的可行性

    你有一个绝好的主意，但你不知道这种商业模式是否行得

    通，怎么办?财务部门的朋友能帮忙。你提供信息，他们帮你分

    析整合。当你与高管讨论产品的可行性时，能得到财务部门的支

    持真是再妙不过了。

    结交一位财务部门的朋友。你既需要他们提供的信息，也需

    要他们帮你解读信息，还需要他们帮你充分利用信息。我相信他

    们也希望借这样的机会帮助公司发展。

    ◎范例

    请访问

    http:www.svpg.comexamples

    阅读有关机会评估的范例。

    第12章 产品探索

    Product Discovery

    定义正确的产品

    软件项目可以划分为两个阶段：弄清楚要开发什么产品

    (定义正确的产品)；开发该产品(正确地开发产品)。第一个阶段探

    索产品，第二个阶段则强调执行。

    在探索产品的阶段，产品经理负责分析各种创意，广泛

    收集用户需求，了解如何运用新技术，拿出产品原型并加以测

    试，从全局视角思考产品方向，兼顾短期需求和长期规划。总而

    言之，就是探索出兼具功能性与设计性的产品(此书更多分享搜

    索@雅书B)。

    一旦完成产品定义，进入开发阶段，产品团队就要切换

    工作重心。现在的重心在于执行——开发、测试、发布。产品经

    理要确保大家集中精力，捕捉软件开发不可避免的问题并迅速予

    以解决。开发过程中可能会出现各种干扰，比如，竞争对手的干

    扰、公司组织变动，甚至公司问并购等，产品经理有责任确保产品团队不受干扰，专注完成项目，按时发布产品。

    许多产品团队没有意识到，或者很晚(比如到了测试阶

    段)才意识到要转变工作重心。更糟糕的是，产品经理还时不时冒

    出新点子：公司高管认为产品说明文档还可以继续修改，导致开

    发要求大幅变更，严重影响开发团队的工作。结果不是发布日期

    一推再推，就是某些功能被迫取消，或者产品质量下滑。

    产品经理必须在执行阶段转换工作重心；否则，产品经

    理自己很可能成为产品上市的最大障碍。每位产品经理的个性都

    不相同。如果你天生喜欢探索发明，喜欢自由和创意，那么在执

    行阶段就要努力控制创造的欲望；如果你天生是“项目经理”类型

    的人，喜欢排除外界干扰，按部就班完成任务，那么你需要培养

    自己的宏观思考能力和设计能力。

    我有个方法可以解决这种冲突：采用流水线方式并行开

    发产品。也就是说，一旦1.0版本的产品进入项目执行阶段，就开

    始定义2.0版本的产品。一旦前一个版本进入开发阶段，就把你的

    创造热情投入下一个版本。

    唯一需要注意的是，不要让这种做法干扰正在执行的项目。

    我个人觉得这个方法很管用。如果下次公司高管再要求你增加新功能，也不会影响正在开发的产品，因为你已经开始构思新版

    本，可以把新功能纳入其中。7

    探索产品的进度可控吗?

    你有过这种经历吗?公司看好一个创意，要求你据此定

    义新产品。这时开发团队还有四周才能完成手头的项目，也就是

    说，你有四周时间探索新产品。

    你觉得没问题，计划第一周先评估产品机会，尝试理解

    待解决的问题，拜访潜在用户，收集基本需求：第二用与交互设

    计师一起制作产品原型；第三周利用产品原型展开用户测试；第

    四周完成产品用例，与开发团队一起评审产品原型和说明文档。

    这是理想状态，执行中往往会出纰漏。用户可能对创意

    不感兴趣，或者对你的产品原型不感兴趣。但是已经没时间了，开发团队等米下锅。不得已，你只好让他们开发有缺陷的产品。

    几个月后，开发团队依样画葫芦完成了产品，但糟糕的

    可用性让管理层大失所望。这不能怪开发团队，毕竟他们只是按你的要求工作。那是谁的错呢?当然是你产品经理的错。如果不

    改变观念，同样的问题迟早还会出现。

    软件产品行业存在一种根深蒂固的偏见，认为分析需求

    和设计产品的工作是可预测的、可控制的。这通常是产品团队最

    难逾越的心理障碍。定义产品本质上是创造性的工作，更像一门

    艺术而不是科学。：

    所以我喜欢把定义产品的过程称为“产品探索”，而不

    是“需求和设计”，为的是强调如下两个观点。

    首先，产品经理应该探索是否有用户需要产品，也就是

    说，要寻找市场，让用户验证你的构思。

    其次，产品经理要探索能够解决问题的产品方案，它必

    须是有价值的、可用的，可行的，也就是说，要设计解决方案，请用户和开发团队来验证。

    有时产品探索很容易完成，有时却非常围难。以我的经

    验来说，发现和验证市场机会并不难，但探索产品解决方案的难

    度很高。有些问题即便有出色的设计师和开发人员协助，也还是难以解决。

    制药行业也面临着同样的问题。他们寻找市场机会并不难

    ——有很多问题值得解决(比如挽救生命、延年益寿)，难的是探

    索产品解决方案(研发药品)。制药公司清楚没人能保证一定能研

    发出新药。就算能研发出来，时间也不确定，而且研发新药的时

    间成本会影响药品的定价。

    但在软件行业，尽管大家知道定义产品有难度，也承认

    大部分产品没能完成既定目标，但我们仍然像制订建筑施工计划

    一样，为探索产品设定期限。管理层坚持给产品探索设定期限，主要有如下原因。

    1探索产品的过程不可预测。管理层担心花几个月研究

    解决方案，最后却做不出产品，而如果按计划进入开发阶段，至

    少有事可做。

    2开发人员是紧缺资源，开发团队无事可做会让管理层

    抓狂。问题是，这反而导致开发资源被浪费。

    不管大家意识到没有，所有的公司都会执行探索产品的流程，只不过有些公司不是利用产品原型完成这项工作，而是孤

    注一掷，用实际产品搭上全部开发时间进行产品探索，他们开发

    的是一款非常昂贵的原型，让不知情的用户掏钱参与原型测试。

    这些公司需要一两年时间(发布几个版本)才能赢利。

    这也是很多处于创业阶段的公司失败的原因——它们往

    往没有足够的资金维持两年，因求胜心切，盲目招聘开发人员拼

    力一搏。结果可想而知。

    处于创业阶段的公司和大公司都应该重视产品探索流

    程，在确定有价值的、可用的、可行的产品解决方案后，再全面

    转入执行阶段。在此之前不需要招聘大量开发人员，已有的开发

    人员也可以参与探索产品，或者利用这段时间准备基础软件设

    施。

    你应该帮助管理层理解探索产品的本质，明白产品经理

    的职责是保证开发团队开发有价值的，可用的产品，这样你才能

    安心完成探索产品的任务。

    第13章 产品原则

    Product Principles

    确定什么最重要

    产品原则是对团队信仰和价值舰的总结，用来指导产品

    团队做出正确的决策和取舍。它体现了产品团队的目标和愿景，是产品战略的重要组成部分。从形式上看，它是…系列明确的、体现团队特色的产品价值准则。

    每次加入新团队，我要做的第一件事就是制定产品原

    则。制定产品原则意味着决定什么重要、什么不重要，哪些原则

    是根本的、战略性的，哪些是临时的、战术性的。

    产品原则不是产品功能的清单，不依赖于任何单独的产

    品，它是整个产品线的战略指南，是公司的价值宣言。好的产品

    原则甚至可以激发设计产品的灵感。

    制定产品原则的过程也是学习的过程，我可以从中了解新公司企业文化，以及公司创始人设立的企业目标。产品原则是

    一套价值判断的框架，帮助公司做出正确的决策。

    举例来说，某电影网站的产品原则是相信社区用户的影

    评比专业人士的影评更有价值。如果某家制片厂希望借网站发表

    评论，产品团队就可以根据这条产品原则决定是否采纳。

    产品原则是否公开因公司而异。它既可以用做团队内部

    的指导工具，像是产品战略文档，也可以公开给客户、合作伙

    伴、投资人，用于向公众宣传公司的理念。

    此外，产品原则还可以用来团结产品团队，让产品经

    理、产品设计师、开发团队和营销团队形成共同的价值观，在认

    识上保持一致性。这是任何产品说明文档都做不到的。

    注意，仅仅罗列出产品原则还不够，还要按原则的重要

    性排序。所有产品都希望做到既易于使用又安全可靠，但总有需

    要优先考虑的原则。最重要的究竟是易用性，还是可靠性?

    制定产品原则时容易出现两类错误。第一类是原则过于

    空泛，失去了指导作用。第二类是把设计原则误当成产品原则.比如，为用户提供清晰的导航路径(方便用户完成下一步操作)属

    于常见的设计原则，不是产品原则。

    如果你所在的团队还没有制定清晰的、有关产品理念的产品

    原则，应该把大家召集起来，花点时问讨论分析，确定团队最看

    重的价值理念。

    解决意见冲突

    不少产品经理向我抱怨说，他们受够了没完没了的会议

    (既无议程也无结果)，以及会议中的那些争论、冲突。公司高管

    还时不时打断会议进程，扔下没头没脑的意见，然后拂袖而去，留下他们丈二和尚摸不着头脑。

    这种情况在产品决策过程中经常发生，原因主要有以下

    几点：第一，每位同事对公司的产品都有自己的看法；第二，大

    家都非常在乎产品，明白公司营利得靠用户，只有产品才能吸引

    用户；第三，许多人以为自己比其他人了解目标用户，事实上并

    非如此。

    另外，产品团从大多不必向产品经理汇报工作，产品经

    理没有管理产品团队的实权。如果需要产品团队的配合，产品经

    理只能摆事实、讲道理，不能强制执行。所以产品经理总觉得施

    展不开拳脚，非常沮丧。

    有时大家各持己见，僵持不下，只能请高管出面定夺。

    出现这种局面，说明沟通方式有问题。产品创意在辩论中可以得

    到完善，但前提是大家形成一致意见。请高管出面决笨、解决冲

    突会激化团队内部矛盾，得不偿失。

    制定产品决策的过程中存在的困难着实不少。这些困难

    是不可避免的，因为建设性的辩论和论证是定义优秀产品的必由

    之路。不过即使认识到这一点，我也很难把争论当成一种享受。

    为了鼓励创新，改善讨论效果，同时降低外界干扰，在作产

    品决策之前，应该先确定决策要解决什么问题，让大家在以下几

    个要点上迭成共识。

    1.究竟要解决什么问题?

    2.要为哪类人物角色解决这个问题?

    3.产品要达到什么目标?

    4.每项目标的优先级是什么?

    在我看来，每当团队内出现严重的意见分歧时，并非是

    大家对事实的认定有争议，而是对目标和目标的优先级有不同的

    理解。

    比如说，团队首先应该确定哪个目标对用户最重要，是

    易用性、响应速度、功能、成本、安全性，还是用户隐私?只有

    先统一对产品目标和目标优先级的认识，大家才能在此共识上进

    一步讨论各种方案的合理性与可行性。

    务必认真分析产品目标的优先级(从最重要到最不重要逐

    项排序)，让团队达成共识。切不可囫囵吞枣地把所有目标都贴

    上“关键”和“重要”的标签。一定要区分什么最重要，什么第二重

    要……

    我常被请去解决产品决策中出现的争议，我发现，多数团队跳过了这关键的一步。由于缺少基本评估标准，每个人对目

    标和优先级的理解都不同，大家往往情绪激动，在细枝末节上争

    执不下。

    即使大家已经达成共识，也应该在讨论开始前再次予以

    强调，最好把目标按优先级顺序写在白板上，这样每位同事都可

    以看到评估方案和制定决策的确切依据。

    制定决箍的过程和依据必须完全透明，不要让人觉得你

    只凭直觉判断。务必告诉大家决策的依据和理由，清楚地展示每

    一个决策环节。

    激烈的会议争论会影响大伙的斗志和工作效率。如果再出现

    这种情况，请先回顾产品目标和目标优先级，确保大家达成共

    识。

    ◎范例

    产品原则的范例请参见：

    http:www.svpg.compeamples。

    第14章 产品评审团

    The product Council

    制定更及时、更可靠的产品决策

    即使对小公司来说，制定决策通常也是既耗时又费力

    的。产品公司需要一套机制让决策者和相关人员及时做出明智的

    产品决策。我认为成立产品评审团是最好的解决途径。

    我通常不热衷于出席会议或参加各种委员会，但是产品

    评审团除外。产品评审团让所有决策者坐到一起，为把产品推向

    市场共同制定决策，可以有效地加快研发产品的速度。

    组织产品评审团的难点在于既要为高管制定产品决策、监督产品流程提供透明的信息，又要避免高管插手干预产品团队

    的具体工作，比如亲自参与设计产品。

    不少公司都有类似的组织，但我认为最早提出这个概念的人

    是eBay前COO梅纳德·韦布(Maynard Webb)。多年来，我一直在实践中不断规范产品评审团的具体职责，完善其流程。

    产品评审团的工作目标

    成立产品评审团的目的是决定产品战略方向，从宏观上监督

    公司产品的研发流程，合理地配置资源。产品评审团不制订公司

    的商业战略，而是在给定商业战略的条件下，提出与之相匹配的

    产品战略。产品评审团的决策直接影响企业的运营。

    产品评审团的成员组成

    产品评审团由公司各个部门的管理者组成。虽然各个公司的

    情况不同，但通常都包括以下人员。

    ·首席执行官首席运营官部门总经理

    ·产品管理总监副总监

    ·用户体验设计总监副总监

    ·市场总监副总监

    ·开发总监副总监

    ·网站运营总监副总监

    ·客户服务总监副总监

    产品评审团的工作效果很大程度上取决于会议组织者的

    技巧。他必须不受干扰，善于阐明问题、促成决策。在大公司

    里，组织者通常由公司的产品负责人担任：在小公司里，则通常

    由老板担任。

    要确保每个关键部门都有代表参加产品评审团，但最好把人

    数控制在十人以内。如果有的部门不止一人参加评审团，应该选

    一个人代表部门陈述观点。例如，销售总裁代表市场部发言，质

    检(OA)主管代表开发部门发言。

    产品评审团的职责

    产品评审团并不是设计和开发产品的团队，它的职责是监督

    产品研发流程，制定关键决策。它根据研发产品的四个里程碑来

    评审产品，制定决策。

    1.评审产品战略和产品路线图，启动评估产品机会的工作，即选择值得投入精力的产品，请产品经理开始评估产品机会。

    2.根据评估产品机会的结果，决定是否开始定义产品的解决

    方案。

    3.评审产品原型、用户测试结果、成本估算明细，决定是否

    开始开发产品。

    4.评审最终产品、产品品质、发布计划、社会效应，决定是

    否发布产品。

    注意事项

    1.小公司的产品评审团通常负责评审公司所有的产品；大公

    司可能需要根据业务单位的大小，设立若干个产品评审团。

    2.产品评审团不负责评审对产品细节的更新或修正。这是为

    了加快对细节问题的处理，保证公司业务运作流畅。

    3.产品评审团不负责具体的产品设计工作。如果产品存在缺

    陷，应该由产品团队着手处理，然后重新提交产品评审团评审。

    4.在2号里程碑处，由于产品解决方案尚未形成，不可凭直觉

    估算产品的成本.至多只能估计大致的项目规模；但是在3号里

    程碑处，应该仔细估算开发时间和成本，让公司上下做好准备。

    5.尽量避免产品评审团讨论具体执行策略，讨论这些问题非

    常费时间。如果必须讨论。一定要控制好时间，不要影响产品评

    审团监督产品流程的主要工作。

    6.产品评审团开会的频率取决于具体产品的进度，可以每个

    月开一小时会议，或者每个星期开两小时会议。

    7.产品评审团还应该回顾、分析产品上市后的表现。可以在

    产品发布3～6个月后，请产品团队汇报产品的市场业绩表现，产

    品评审团可以反思之前的决策是否明智，今后应该如何调整。

    8.每次评审会议，最好由产品经理向产品评审团汇报产品的

    进展情况。由产品经理的直接领导指导产品经理准备陈述内容，确保产品经理准备充分。在会议召开前，产品经理最好逐一向产

    品评审团成员做简要汇报，存在疑问应及时解决，避免在汇报过

    程中措手不及。

    如果公司制定产品决策的效率太低，应该考虑组织产品评审

    团。产品评审团可以替代以往各种冗长的决策会议，大大缩短决

    策时间，制定明智、及时、透明的产品决荒。

    何时估算项目成本?

    尽管软件行业早就有估算成本的传统，但直到今天仍然容易出现混乱的估算结果。我认为混乱的原因在于管理层总是希

    望尽早获悉成本信息，但开发人员往往要较晚才能精确估算成本

    (至少要等到具体的解决方案出炉)。结果，要么过早估算导致结

    果与实际出入很大，要么结果虽然准确，但远远超出预算，让管

    理层难以接受。

    我这里要介绍的估算方式虽然源自我提倡的产品研发流

    程，但同样能解决大多数公司的问题。

    开始研发产品前，应该先评估产品机会(参见第11章)。

    评估产品机会的目的是看产品创意宣称要解决的问题是否有价

    值。此时，解决方案尚未出炉，手头但有产品创意和待解决的问

    题，所以产品团队只能大致估算项目的规模(建议分成小型、中

    型、大型三个等级)。再根据项目规模粗略估算项目成本。虽然这

    种估算与实际情况会有出入，但通常不会出现跨级别的误差。

    确认产品机会有价值，粗略估算的成本也可以接受，管

    理层才能允许项目组着手定义产品解决方案。理想情况下，详细

    的产品解决方案还应该包含可供用户测试的高保真原型。

    在定义解决方案的过程中，产品经理和交互设计师需要

    一位开发人员的协助来评估不同解决方案的成本。然后产品经理和交互设计师根据评估结果进一步调整解决方案。待完整的产品

    说明文档形成后，即可根据文档细节生成详细、可靠的成本估算

    结果。

    此时，手头有了详细的产品说明文档、可信的成本估算

    结果，管理层可以很方便地决定是否开始开发产品。如果解决方

    案有问题，或者成本估算结果超出了预算，管理层可以马上叫

    停。如果决定开发产品，产品团队就可以在充分了解产品定义与

    成本细节的条件下全力开始工作。

    总而言之，我建议分两个阶段进行成本估算。在评估产

    品机会时做粗略估算；根据最终的产品说明文档做详细估算。

    第15章 特约用户

    Charter User Programs

    产品开发伙伴

    大部分市场人员认为拥有群忠实的、乐于推荐产品的用

    户会让产品发布变得更容易、效果更好。如果是平台产品(为他人

    在平台上开发和部署应用提供支持)，最好还提供一批起示范作用

    的应用程序。但让我吃惊的是，许多平台产品在这方面几乎毫无

    准备。

    如果有若干知名人物公开声明使用过产品，并且表示满

    意，就可以大大降低潜在用户的顾虑，营销推广工作也会容易很

    多。反之，如果缺少用户推荐，再高明、再新颖的销售策略所起

    的作用都有限。

    大众对无人问津的产品非常谨慎，要么怀疑其质量，要

    么认为还不成熟，谁都不愿意第一个吃螃蟹。

    如果面向大众的产品只有一两家网站推荐，会让人误以

    为这是针对特殊用户群的定制产品。无论是平台产品、商业应

    用.还是针对大众的互联网服务，用户都希望看到他人使用的效

    果后再尝试。

    接下来让我们把关注的重点从产品发布阶段转移到项目

    最开始的阶段上来。

    产品经理要深入了解目标用户，明确产品需要解决的问

    题，定义出满足用户需求的产品，因此产品经理必须和用户紧密

    合作，这样，开发的产品才可能满足更广泛的用户需求。但问题

    在于，同时和这么多用户打交道显然是不现实的。

    为了解决这两个问题——既深入洞察目标用户的需求，又赢得用户对产品的推荐，我建议征集特约用户(也叫用户顾问委

    员会、用户评审团)协助完成产品研发。这不是什么新方法，我二

    十年前就在惠普用过。

    方法很简单，在项目的开始阶段物色至少六位积极、活跃、乐于分享的目标用户(可以先招募8～10人，然后从中筛选)，要求

    是他们在产品的目标用户中具有一定影响力。至于他们是否使用

    过公司原有的产品并不重要，只要他们认为未来的产品可以解决他们手头亟待解决的问题就行。

    成为特约用户的好处

    l.参与构思产品创意，解决他们手头的问题——他们最清楚

    产品要解决的问题，因为这些麻烦正在困扰他们。

    2.提前试用产品，越早使用产品意味着越早解决麻烦。

    3.通常，提前试用产品还可以显著降低用户的各种成本。

    产品经理的收获

    1.聚拢一批积极的用户，他们可以为定义产品和开发产品提

    供建议和协助。

    2.提供调研便利，便于产品经理去特约用户的工作场所调

    研。如果是平台产品的话，便于产品经理去开发人员的工作地点调研。

    3.可以定期组织特约用户进行小组讨论。

    4.特约用户第一时间试用、测试产品，迅速反馈意见。

    5.如果特约用户满意产品的表现，会乐意公开推荐产品。

    组织特约用户的注意事项

    1.不要向特约用户收取参与费用，否则合作关系将会变味。

    产品经理需要的是开发产品的伙伴，不要变成为特约用户开发产

    品。如果特约用户愿意，你尽可以等正式产品发布后再向他们收

    取费用。

    2.由于可以免费试用产品，通常会有大量的申请者申请成为

    特约用户。公司的销售部门为了提高业绩，可能会要求产品经理

    招募更多的用户。这会消耗产品经理大量的精力，而且这些用户

    不一定符合要求。为了满足大批心急的用户，公司可以发布预览版产品。特约用户的人数绝不能超过十个，否则产品经理不可能

    有时间和精力与每位用户深入沟通。

    3.如果在寻找特约用户时遇到困难，很可能是因为产品要解

    决的问题不像产品经理想象的那么重要，将来也很难销售出去。

    这可以初步验证产品创意是否有价值。出现这种情况，产品经理

    应该重新考虑产品计划。

    4.产品经理需要确保特约用户是产品的潜在目标用户。我们

    很容易把产品尝鲜者(early adopter)误当成特约用户。产品尝鲜者

    常常能容忍产品的不足和缺陷，根据他们的建议研发的产品，很

    可能只适合他们自己，无法满足大众的需求(参见第35章)。

    5.产品经理务必向特约用户说明，我们要开发的是面向大众

    的通用产品，不是为某家公司开发的定制产品。特约用户也不希

    望出现这种情况，因为小众产品的生命周期比较短，一旦产品被

    淘汰，售后服务也将被取消。产品经理应该向特约用户承诺产品

    不会昙花一现。

    6.产品经理应该把特约用户当成开发伙伴对待，视他们为

    同事，互相帮助。许多特约用户和我结下了深厚持久的友谊。

    7.产品经理与特约用户的合作贯穿产品研发的每个环节：

    向他们展示产品原型，请他们参加测试，向他们请教产品的细节

    问题，让他们帮你部署、测试待发布产品的各选版本。

    8.正式产品发布之前，一定要先请特约用户试用，确保每个

    人都满意，一旦发布，他们会坚定不移地向大众推荐产品。

    9.产品经理还要和产品营销团队紧密合作。一方面，营销团

    队可以帮助你物色特约用户：另一方面，他们可以协助你提高特

    约用户受关注的程度。

    10.如果是平台产品，特约用户的作用就更突出了，只不过

    六个特约用户要换成六个应用。产品经理要与特约应用的开发者

    紧密合作，确保在平台上构建的应用让用户感到满意，最好鼓励

    应用开发者发展自己的特约用户。

    注意，虽然我提到的例子多数是企业软件和平台产品，但这

    些方法同样适用于针对大众的互联网服务和消费类产品。如果是

    互联网服务，特约用户的人数应该增加至10～15人，不过要保证

    产品经理有精力充分了解每位特约用户，以及他们使用服务的环境(家或办公室)。设计和规划网站时很容易犯一类错误，即对用

    户需求把握不够，收集的用户反馈信息不充分，直到项目尾声才

    发现产品的定位有问题。这样作风险很大，而特约用户可以帮助

    产品经理把握用户需求。

    另外，从营销的角度来看，大众消费者对口碑营销的反

    应可能与企业采购经理的不同。大众消费者更容易受媒体和网站

    评论的影响，但是他们也希望看到真实用户的评价。在这一点上

    两者是相同的。

    使用特约用户是确保产品不偏离用户需求最简单有效的办

    法，同时也是向潜在用户宣传、推荐产品的最佳手段。

    该不该与用户交流?

    经常有产品经理向我抱怨，公司不允许他与用户接触。

    导致这种情况出现的原因很多，可能是公司认为应该由营销人员

    与客户打交道，也可能是公司担心产品经理言论不当或者向用户

    做出不恰当的承诺，还可能是销售代表怕人抢了他的客户，或者

    产品是通过特殊渠道销售的。不管什么原因，如果公司不允许你

    直接与用户交流，你一定要尝试改变这个政策。如果不成功，我建议你翻出自己的简历另谋高就，寻找可以大展身手的地方。

    我无法想象不深入理解用户需求，特别是在禁止与用户

    面对面交流的情况下，产品经理怎样打造出让用户满意的产品。

    有些大企业设立了多种渠道帮助产品经理理解市场需

    求，比如，让营销团队展开市场调查，组织用户研讨会收集用户

    需求，让销售工程师(销售代表的技术助理)收集客户要求，让客

    户服务经理提供月度问题汇总等。这些工作都没错，但它们都不

    能替代产品经理亲自与用户交流的作用。

    我认为产品经理应该尽可能地亲自拜访用户，与用户交

    流，参加每一次的可用性测试和特约用户讨论会。

    产品经理必须与用户充分沟通，挖掘每个人的潜在需

    求，捕捉产品创意。“重新定制这个页面，同时记录各类用户的

    访问量”，“72%的用户要求提高视频的分辨率”，从这类呆板的报

    告里是不可能洞察用户需求的。

    产品经理还应该充分利用，公司的可用资源。许多公司

    设有用户研究部门，他们可以协助分析用户行为；营销人员可以协助确定产品定位和宣传计划。我个人还喜欢邀请主程序员参与

    前期定义产品的工作，让他提前考虑产品开发的细节问题。

    这些工作你都可以请人协助，唯有理解用户需求的工

    作，产品经理不能推诿他人。

    最后补充一点，与用户打交道的过程中，你会发现一些

    富有洞察力、善于思考的用户，应设法与他们建立长期联系(记下

    他们的联系方式)。他们是特约用户的最佳候选人。

    第16章 市场调研

    Market Research

    理解市场调研的作用与局限性

    市场部门与产品部门往往存在意见分歧。争议的焦点是

    市场调研工具和市场调研方法在探索(定义)产品中所起的作用。

    这些工具和方法包括用户研讨会、用户调查、产品使用分析、拜

    访用户、可用性现场测试、周类产品分析。

    我认为产生分歧的原因是双方不清楚市场调研的作用与

    局限性。市场部门夸大了市场调研的作用，而产品部门只看到其

    局限性。结果有的团队忽视市场调研，产品偏离了正确的方向：

    有的团队又太依赖市场调研，陷入了偏执。

    这个话题涉及的内容很多，这里我只讨论市场调研方法

    的作用和局限性。

    过去十年，市场调研手段取得了长足的进步。随着技术发展，大规模调查用户和顾客的难度降低，很多过去无法解决的

    问题现在都已经解决了。新技术甚至可以帮你分析用户活动和行

    为——他们是谁.他们用产品做什么。尽管如此，市场调研最基

    本的、固有的局限仍然存在，了解这些局限很重要。市场调研的

    作用先介绍一下常用的市场调研工具和方法。

    用户调查网络降低了用户调查的难度，提高了调查的效

    率，以至于现在几乎所有产品都要求做用户调查。做用户调查要

    注意两点。第一，设计调查问卷需要技巧和经验，不是一件容易

    的事。要结合具体情景，仔细设置问题，如果调查问卷措辞不

    清、先入为主，其他部门的同事就会质疑调查结果。第二，调查

    结果为获得解决方案提供了一条途径，但不是解决方案本身。哪

    怕所有用户都回答喜欢x特性，我们还是可以通过提供Y特性更实

    际地解决他们的需求。

    产品使用分析如果你的产品是网站，有很多实用的工具

    可以分析用户访问网站的行为。这些工具正确安装和配置后即可

    使用，非常划算。越早使用分析工具越好，不断地观察学习，然

    后调整产品。如果你的产品不是网站，可以在产品中添加分析工

    具，记录用户使用产品的行为。应该明确告知用户分析工具的用

    途，声明只收集统计数据，不涉及用户隐私。这样做虽然麻烦，但很值得。

    数据挖掘收集数据的渠道很多，除了上面提到的产品使

    用分析，还有用户的账单和账户信息、产品数据等。新的数据分

    析工具的功能越来越强。想知道同时使用几项服务的用户性别比

    例?想知道特定人物角色的活跃程度和分布情况?新的数据分析工

    具可以轻松回答这类问题。

    拜访用户没有一种方法可以替代前往用户使用产品的场

    所(家、办公室)实地考察的作用。虽然拜访用户成本高、耗时

    长，但我每次都能收集到从其他途径无法了解的信息。拜访用户

    很有效，但出于对资金和时间成本的考虑，建议谨慎使用。

    人物角色我喜欢在定义和设计产品的过程中使用人物角

    色。市场调研也可以借助人物角色展开。请记住，你要面对的绝

    不是单一类型的用户，务必找出若干主要用户类型，深入了解他

    们，弄清哪些是当前的用户，哪些是潜在的用户。具体内容请参

    考第17章。

    可用性测试我主张尽早、反复地进行可用性测试(请参

    考第22章)。观察用户使用现有产品的反应，收集反馈意见，了解

    他们的真实想法。从用户的视角重新审视产品，不光阅读反馈信

    息，更要观察、记录墙户的行为和反应(比如兴奋、沮丧)。现在

    还有工具带有远程功能，可以在异地进行可用性测试，记录、分

    析用户行为。

    同类产品分析产品团队常常低估了竞争对手。就我的经验而

    言，每款产品都有做得好的地方。有必要找出竞争对手的优势，学习对手的成功经验。

    合理地利用市场调研工具和方法可以回答以下几个关键问

    题。

    1.谁是目标用户?

    2.用户会怎样使用产品?

    3.用户能想明白怎样使用产品吗?障碍在哪里?

    4.用户为什么选用你的产品?

    5.用户喜欢产品的哪些特点?6用户希望如何改进产品，增加

    哪些功能?

    市场调研的局限性

    注意，虽然以上这些问题很重要，但它们不直接回答最根本

    的产品问题：打造什么产品?市场调研结果可以作为研发产品的

    依据和参考，但不能决定产品研发的方向。

    探索(定义)产品的过程则要回答如下问题。

    1.采用什么技术来更好地解决产品要解决的问题?

    2.设计什么样的用户体验?

    虽然市场调研很重要，但我从来没听说过仅仅通过市场

    调研就成功定义出来的产品。Google、eBay、iPod、iPhone、Face Book、MySpace都不是仅通过调研产生的。

    成功的产品基于以下两点认识：深入理解用户需求，以

    及明白什么样的解决方案在现阶段是可行的。

    我也希望可以简单地根据客户的要求设计产品，但这样

    做会陷入不断添加新功能、修改产品架构的怪圈。你会为缝缝补

    补的任务疲于奔命，无暇思考创新的解决方案。

    如果你的产品已经面市，有一群活跃的用户，可以多与

    他们沟通，了解他们喜欢产品的哪些方面，不喜哪些方面，据此

    逐步完善产品。但这些建议只能用来修补现有产品的不足之处，不能用来定义新产品。

    总而言之，市场调研结果可以用于完善现有产品，精益求

    精，但不要指望从市场调研中发现下一个FaceBook、Flickr、YouTube。

    关于用户研讨会

    上文没有介绍用户研讨会的作用和局限性，因为我不能

    肯定其功效。我支持产品经理多接触目标用户，组织用户研讨会

    可以让大家面对面交流，但只有谨慎筹划，才能发挥其作用。

    虽然组织用户研讨会可以面对面了解目标用户对产品的看法，但我保证在用户研讨会上不可能讨论出成功的产品。为什

    么?有两个根本原因。

    1用户不知道什么样的想法是可行的，多数用户对现有

    技术一无所知；

    2用户不知道自己想要什么，没见到实际产品，用户很难凭

    空想象自己需要什么。

    用户研讨会还有其他弊端：

    1人群聚集时容易冲动，相互影响，难以获取每个用户

    的真实想法，取而代之的是那些善于表迭者的一家之言。

    2.除非让用户试用实际产品，否则他们不清楚自己想

    要什么，而通常组织用户研讨会时产品还没有眉目。

    3与用户调查一样，组织用户研讨会也需要经验。主持

    人不但要熟悉组织技巧，能随机应变，还得掌握产品领域的知

    识，擅长引导话题，才能获得预期的效果，这样的人实在是可遇而不可求。

    所以比起了解目标用户需求来，用户研讨会的形式更适

    合于搞政治运动。

    退一步讲，如果你必须组织用户研讨会，务必让产品经

    理亲自参加。布置会场和后勤服务的工作可以外包，但是收集信

    息和分析数据的工作绝不能外包。

    第17章 产品人物角色

    Personas for Product Management

    理解目标用户

    产品管理的核心在于制定决策——应该抓住哪些机会，解决什么问题，哪些功能最有价值，谁是主要用户。有决策就有

    失误，但要打造成功的产品必须保证大部分决策是正确的。

    人物角色又称为用户特征记录(user profi1e)，是指通过

    与用户沟通交流，确定典型的目标用户类型，在理解各类目标用

    户的特征的基础上建立的人物原型。人物角色是合理地描述用户

    特征的人格化虚拟原型，重点关注用户的行为、态度、目标。这

    个概念虽早出现在艾伦·库珀(A1an Cooper)的著作《交互设计之

    路》里。

    设计界似乎已经广泛采用了人物角色，我见过的大多数

    设计团队都在使用这种工具。不同团队创建人物角色的方法不

    同，有些正规，有些灵活，但在我看来，他们都很出色。

    营销团队甚至也开始在产品宣传中使用人物角色。虽然

    两者使用人物角色的方法类似且富有成效，但目的不同，不能混

    为一谈。营销团队使用人物角色是为了找准目标消费者，激发消

    费需求；产品设计师则是为了分析用户的需求与在线行为。

    人物角色对产品经理而言同样有用。创建人物角色的工

    作越早开始越好，但很遗憾，它往往被搁置，直到探索(定义)产

    品的最后阶段才发挥作用。原因在于创建人物角色的工作多由产

    品设计师完成，而产品设计师在团队中发挥作用的时间通常都太

    迟。

    为了发掘潜在的人物角色，产品经理必须深入参与创建人物

    角色的工作，尤其要亲自参加用户交流和用户调查。产品经理、交互设计师、用户研究团队(如果有的话)之间必须密切合作。这

    项工作千万不能外包。产品经理应该参与所有的产品可用性测

    试，抓住一切机会与用户交流，深入了解目标用户。

    作为产品管理的工具，人物角色的主要用途如下。

    1.人物角色可以用来筛选重要的产品功能。假设目标用户是“玛丽”，就该添加对“玛丽”重要的功能；如果某项功能只是针

    对“山姆”的，就该被淘汰。人物角色既有助于决定谁是目标用

    户，也有助于决定谁不是目标用户，两者同样重要。面面俱到的

    产品往往一无是处，使用人物角色可以避免犯这种错误。

    2.产品团队常常把自己的需求当成用户需求，我在别处讨论

    过这个问题，使用人物角色可以避免犯这类的错误。

    3.许多产品的用户类型不止一种。如果只是简单地针对每种

    用户添加功能，结果会是一团乱麻。这主要是设计上的问题，使

    用人物角色有助于对用户类型的优先级进行排序，识别需要重点

    考虑用户体验的地方。

    4.有了人物角色，可以方便地向团队描述产品的目标用户是

    谁，他们怎样使用产品，他们关心产品的哪些方面。

    5.和产品原则一样，人物角色可以帮助团队成员达成共识。

    产品发布之前有数以千计的细节问题要解决，产品经理和设计师

    不可能事必躬亲。如果产品经理、设计师、文案创作人员、开发

    人员、测试人员在产品原则和人物角色上达成共识，解决问题的

    效率会更高。

    以上是使用人物角色的优点，下面谈谈注意事项。

    1.有些产品团队创建人物角色后就把它束之高阁，回避为产

    品挑选关键人物角色的难题。宣称产品老少皆宜是自欺欺人。每

    个发布周期，我总是竭尽全力让产品经理集中精力关注一类关键

    人物角色。这并不是说该版本对其他用户就没价值、不可用，而

    是强调每次应该针对一类目标用户，把产品的优势发挥到极致。

    2.有些产品团队不花时间与用户交流，只是基于想象和刻板

    的印象创建人物角色。我在这方面栽过不少跟头，没接触真实用

    户之前，我不会先入为主地下结论。与目标用户面对面交流是创

    建人物角色必不可少的环节。

    3.邀请用户参加产品原型测试，我们常常面临这样一个问

    题：是不是只挑选关键人物角色范围内的用户参加测试?当然应

    该测试关键人物角色对产品的反应，但实际使用产品的人不可能

    完全与关键人物角色的设定相符，所以还需要测试范围外的用

    户。我建议邀请多样化的用户参与产品原型测试。

    ◎范例

    人物角色的范例请参考

    http:www.svpg.comexamnles。

    第18章 重新定义产品说明文档

    Reinventing the product spec

    安息吧，纸质说明文档

    我认为产品说明文档的形式早就该改革了。有人说敏捷

    方法已经解决了这个问题：干脆放弃产品说明文档。虽然这样做

    存在一些问题，但我认为他们的方向没错。

    讨论如何改革前，先来看看现今纸质的产品说明文档存

    在的问题。产品说明文档包含的范围很广，名称五花八门，有产

    品需求文档、市场需求文档、业务需求文档、功能规格书等等。

    内容覆盖范围、详细程度、文档本身的质量差别很大，就连形式

    也变化多端，有的是word文档，有的是电子表格，有的是wiki页

    面，还有的是用专业需求管理工具生成的。这些不同的文档本来

    作用各不相同，但是随着时间流逝，彼此间的界线越来越模糊。

    我确实读过几份很不错的产品说明文档，但大部分产品

    说明文档既没有提供必要的细节，也不包含关键信息，更不能解

    决问题，虽然花费了大量时间撰写，却很少有人阅读。更要命的是，对管理层和产品团队来说，产品说明文档很容易成为一个幌

    子，仿佛一切都进展顺利。

    产品经理的核心责任是确保向开发团队交付具有成功潜

    力的产品说明文档。认同这一点的人只要仔细审视产品是如何定

    义的，就不得不承认现有产品说明文档存在不足之处。

    我认为理想的产品说明文档应该满足以下要求。

    1.产品说明文档应该完整地描述用户体验——不只是用户需

    求，还包括交互设计和视觉设计。希望大家已经明白用户需求和

    用户体验是密不可分的。

    2.产品说明文档必须准确地描述软件的行为。文字和图片的

    表达能力实在有限，不足以完成这项任务。

    3.产品说明文档的受众较广——开发人员、测试人员、客服

    人员、市场营销人员、运维人员、销售人员、管理层等等。因

    此，产品说明文档必须以某种直观的方式把产品信息和产品行为

    告诉所有人。

    4.产品说明文档应该可以修改。虽然进入开发阶段后，应该

    尽量避免修改产品说明文档，但总有意想不到的问题出现，需要

    修改产品说明文档以适应新情况。

    5.撰写产品说明文档的过程中会出现许多衍生物，比如，按

    优先级排列的需求列表、线框图、实体模型，但应该有一个主体

    来代表产品，避免混淆不清，版本错乱。

    在我看来，只有一种形式的产品说明文档可以满足以上

    所有要求，那就是高保真产品原型。

    “高保真”的含义是原型应该真实地体现用户体验。除了

    描绘用户界面的某些细微之处以外，我不建议使用“纸上原型”。

    如今使用工具创建高保真原型既简单又快捷，成本也不高，没理

    由不这么做。为了获得接近真实的用户体验，甚至应该模拟后台

    处理流程和某些数据。

    过去几年，我的想法一直在改变。以前我认为原型只需

    要包含关键的用户体验组件，现在我要求原型尽可能地体现产品

    细节——包括所有的页面和主要的用例。尽管还是会出现一些意想不到的错误和极端状况，但原型毕竟能让产品团队更直观地把

    握设计要求，其优势完全可以弥补增加的成本。

    当然仅仅有原型是不够的，因为有些产品行为不容易用原型

    体现，比如业务逻辑(税务表单和运费等)、发布要求(性能表现、可靠性、扩展性等)、平台交付要求(安装要求、浏览器兼容性

    等)。用例可以作为有效的补充，用来描述重要的产品行为。

    另外，如何展示补充的说明文档也值得考虑。最理想的

    方法是在原型上增加注释，不过这种技术还没有实现，退而求其

    次，我建议使用wiki或内部网站。这样团队成员可以随时读到最

    新的信息，再不用浪费时间查找版本混乱的纸质文档。网站可以

    定期通知大家产品说明文档的更新情况，方便大家提问和讨论，并保存所有决策记录。

    当然，产品说明文档的主体应该是高保真原型，由它体

    现产品的功能需求、信息架构、用户体验、交互设计、视觉设

    计。

    在我看来，除了符合以上要求外，高保真原型最突出的

    优势是可以用于测试。你可以把它放到真实用户面前，观察他们

    是否清楚如何使用(可用性)，是否渴望使用你的产品(价值)。只有通过这两项测试，产品说明文档才算合格，产品才值得开发。如

    果等到质检或公开测试阶段再验证，就太迟了。

    我保证如果你尝试一次，创建体现功能和用户体验的高

    保真原型，产品团队一定会拥护这种做法。开发人员是最直接的

    受益者，因为他们终于看到了明确有效的产品说明，遇到不清楚

    的地方，随时可以参考。测试部门的工作也变得容易了，因为他

    们终于知道什么样的测试结果是正常的。市场部门、销售部门和

    客服部门也会很高兴提前了解产品。管理层也会支持这种做法，因为向投资者、董事会成员和商业伙伴展示产品时，产品原型远

    比PPT来得有效。高保真原型的优势还不止于此。

    最让人吃惊的是，使用高保真原型可以大大缩短产品上

    市时间。没错，我知道这听起来不可思议，但只要我稍稍解释传

    统软件开发的情况，你就能理解了。因为传统的产品说明文档起

    不到应有的作用(不完整、含糊不清，特别是未经测试)，而且几

    乎没有确定关键细节，也不解决实际困难，必须等到开发阶段这

    些问题才能得到解决。这导致项目要么被迫反复调整(产品说明文

    档不断变更，造成项目延期、士气低落)，要么开发人员只能凭空

    猜测，交付的产品一团糟，用户不得不等待下一个版本或多个补

    丁发布后才能使用。无论哪种情况，产品上市的时间都将推迟。

    所以我建议大家尝试高保真原型，与其花几个星期撰写冗长的word文档，既没人读，也无法测试，还不如和设计师一起创建

    产品原型。把产品原型拿给团队榆查，交给目标用户测试。也许

    要反复修改多次才能确定原型，但现在修改总比开发几个月做出

    糟糕的产品强。等产品原型确定后，用它代替产品说明文档交付

    开发，看看会有什么结果。

    ◎范例

    高保真原型和产品说明文档的范例请参考

    http:www.svpg.comexamples。

    第19章 用户体验设计与实现

    User Experience Design vs. implementation

    先定义用户体验再动手开发

    在软件开发过程中，有很多工作可以同时进行。比如，我一直认为需求调研和产品设计(用户体验设计)是互相影响的，应该同步展开。我不喜欢老式的瀑布式开发模型，产品经理先完

    成需求调研，然后交给交互设计师设计。业界已经认识到这是一

    种陈旧的产品开发思路。

    此外，多数软件开发团队已经尝到了开发与测试交叉进

    行的甜头，我认为这是巨大的进步。以前的做法是开发人员先编

    写代码，全部完成后再交给测试人员测试，不但耗费时间，而日

    可靠性差。

    尽管如此，有些工作不能同步展开。许多团队把用户体

    验设计和软件开发放在一起进行，这是行不通的。原因如下。

    1.与软件开发团队合作的人要记住一点：一旦产品进入开发

    阶段，再修改设计思路是非常困难的，而且越往后修改的成本越

    高。因为开发团队必须根据确定的用户需求和产品定义设计软件

    架构，然后进行开发。前期架构决策极大地制约着后期的开发工

    作，事后修改软件架构，无异于推翻重来。另外，从心理上说，事后修改设计会打击开发人员的斗志，引发消极的心态。随着时

    间一分一秒过去，返工和波动会增加团队的压力。尽管敏捷方法

    提倡不断修改和完善，但并非所有的修改都受欢迎。

    2.用户体验设计要保证产品同时具备可用性和价值，任务很

    重。为了拿出既可用又具有价值的设计，必须尽早、反复地验证

    设计思路。有些人觉得可以等到每个迭代周期结束再观察设计思

    路是否合适，甚至等到产品公开测试时再收集用户反馈，这样低

    效的验证方法肯定是行不通的。优秀的用户体验设计师一两天内

    要尝试几十个点子，哪怕只是2～4周的迭代周期都会慢得让人无

    法忍受。

    3.我认为验证设计思路必须使用高保真原型。有人说，迭代

    结果和公开测试的产品可以当做原型。抛开要等很长时间不谈，这些开发中的产品与产品原型有很大的区别，不能混用。为了验

    证各种设计思路，产品原型应该可以随意修改，完成其任务后应

    该被丢弃。而开发中的产品应该以固定的原型为基础。

    4.尽管产品开发可以分成多次迭代(这样做可以降低风险，提

    高质量，便于产品集成)，用户体验设计却不能拆分。设计师必须

    全面地、连贯地看待用户体验，考虑以往用户的使用习惯。让用

    户放弃不可用的软件很容易，要他们放弃使用习惯却很难。

    5.用户体验设计不一定是最费时间的工作(像软件开发一样，所需时间取决于具体的方法、特定的产品需求，以及从业者的技

    能和经验)，但至少需要一两周时间。

    如果产品设计和开发同步展开，那么多半会出现这样的

    情况：一方面，开发人员等着设计师的设计结果无事可做；另一

    方面，设计师饱受压力，要在几天内完成原本需要几周完成的工

    作。为了应付差事，设计师只好不情愿地拿出仓促完成的设计交

    给开发人员。开发人员一边开发，设计师一边修改设计。等设计

    师最终完成设计，为时已晚，开发人员会说：“等下一轮再修改

    吧。”但下一轮又有下一轮的重点。设计师对产品不满意，用户

    更不会喜欢这个结果。

    如果我遇到这种情况，肯定会辞职，到一家看重用户体

    验的公司去谋职。

    还好，这个问题不难解决，关键是确定先后顺序。虽然需求调研和产品设计可以同步展开，产品开发和测试可以交叉进

    行，但是用户体验设计应该在软件开发前完成。

    敏捷方法里有个概念叫“第零次迭代(sprint zero)”，产品

    经理和用户体验设计师利用这段时间先完成产品设计工作，然后

    交由开发人员开始迭代开发。这需要更详细地定义待开发任务

    (backlog)，但团队工作会更愉快，产品也会更好。

    只有在开发人员要开发大量后台基础软件的情况下，用

    户体验设计和软件开发才能并行展开。在这种情况下，开发团队

    可以利用设计师设计产品的时间完成这部分工作。虽然双方的工

    作会有一些依赖关系，但可以解决。多给设计师一些时间定义详

    细的待开发任务。

    请注意，尽管我提倡需求调研和产品设计都要在软件开

    发前完成，但是在此期间至少应该邀请。位软件开发人员检查设

    计工作，他可以协助你评估设计的可行性和成本.做出更明智的

    决策。别忘了，我们的目标是打造有价值的、可用的、可行的产

    品。

    许多产品团队在尝试敏捷方法的时候，出现了设计上的

    混乱。这实在是可惜，因为只要稍作说明和调整，敏捷方法相对于传统的瀑布式开发方法来说是巨大的进步。我在第26章会讲述

    出现混乱的原因，以及如何合理利用敏捷方法。

    第20章 基本产品

    Minimal Product

    削减功能还是延长工期?

    我号召产品团队放弃老式的产品设计方式。比如，不再

    试图定义最终产品，转而定义只满足基本要求(价值、可用性、可

    行性)的产品，简称基本产品。一旦基本产品定义完成，通过了用

    户测试，它就是一个不可分割的整体，去掉任何元素，都不可能

    获，得预期的效果。

    你见过这样一幕吗?产品经理制作了完善的产品说明文

    档，详细标注了各项产品功能的重要等级。然后，开发部门根据

    这份文档估算开发成本和开发时间。虽然剔除了开发团队力不能

    及的功能，但得到的进度表还是比产品经理设想的多几个月时

    间。于是双方开始协商，先是争论估算是否准确，然后不得不削

    减功能，缩小测试范围，减少公开测试时间，要求雇佣额外的开

    发人员……不知不觉时间已经流逝。我猜测你多半见过这一幕，即使没有见过，也能猜到结果：最后开发出来的产品完全不是有

    机的整体，产品经理不满意，开发人员不满意，用户更不会满

    意。很多团队把这种情况看成理所当然的、不可避免的，其实这是不合理的流程造成的结果。因此，我建议采用另一种产品设计

    方式。

    第一，产品经理与设计师合作设计产品的高保真原型，这个原型只具备实现商业目标的最基本功能要求，以及良好的用

    户体验和吸引力。只设计基本功能的产品可以把复杂度降到最

    低，把开发时问减到最少，因而是非常重要的。

    第二，邀请一位开发人员(比如架构师或主程序员)参与

    设计原型。请他检查原型，帮助产品经理和设计师估算各种功能

    的直接成本和间接成本，指出设计上的误区，并分析、评估尚不

    确定是否可行的功能。等产品原型确定时，他详细估算出所有产

    品功能的时间成本。这样一来，各项功能孰去孰留已经明了，而

    且对各方都是透明的，开发团队心里也有底了。

    第三，请真实用户验证(测试)产品原型，这一点至关重

    要。在产品团队全力开发产品前，产品经理和设计师必须确信产

    品是用户需要的，然而仅仅相信还不够，必须通过用户测试来验

    证。这好比不能仅仅因为开发人员相信代码没问题，就允许发布

    代码一样，必须对代码展开测试。

    一旦基本产品确定，通过了目标用户的测试，就不可能再削减任何功能。如果还能削减，那说明你定义的不是基本产

    品。

    当然，根据产品原型估算的开发时间也不是完全准确，比如，对某些功能的开发时间的估计可能过于乐观。如果出现这

    种情况，只能延长工期，不能削减功能，因为你已经没有东西可

    削减了。尽管如此，由于估算的依据从一纸文档变成了精减功能

    的原型，精度还是大大提高了。即使延长工期，情况也远没有以

    前严重。

    由于开发的是基本产品，一旦进入软件开发环节，产品

    经理就不能再随意修改设计。过去产品经理经常要求更改产品设

    计，主要是因为一开始构思不全面、不彻底。设讨高仿真原型能

    够迫使产品经理改掉这个坏毛病。

    有人认为，类似scrum这样的敏捷开发方法可以用另一

    种方式解决这个问题。虽然我也建议大家采用敏捷方法(因为敏捷

    方法确实有其优点)，但它并不能解决这个问题，反而可能带来新

    问题。相关内容请参考第26章。

    因此，设计产品时一定要考虑哪些功能是最重要的，争

    取设计出只满足基本要求的、不可删减的产品。就像我从前的老板常说的——断腿的狗打不了猎。

    第21章 产品验证

    Product Validation

    证明产品的价值、可用性、可行性

    前几章里已经提到了产品验证的概念。产品验证是指在

    正式开发、部署产品前，验证产品说明文档描述的产品是否符合

    预期要求。

    过去验证产品的代价不菲，而且困难重重。通常只有生

    产成本极高的产品才会这样做，比如汽车。如今创建仿真原型的

    成本已经非常低了，如果还有不做产品验证的团队，我会感到非

    常惊讶。

    产品团队对自己的产品往往过于自信，不愿意验证产品，只

    顾埋头开发，总想等到公开测试时再收集反馈意见。毫无疑问，到那时再想大幅修改产品是不可能了，因此许多产品刚发布时表

    现得非常糟糕，这也不足为奇。

    产品经理向产品团队提供最终的产品说明文档前，需要

    进行以下三项重要的验证。

    可行性测试

    首先要明确在现有的技术条件下，能否成功开发出产

    品。邀请架构师和开发人员深度参与技术调研，寻找可行的方

    案。有些方案通向死胡同，但总有些是可行的。

    重点是让开发人员寻找产品设计里那些难以克服的障

    碍，现在发现远比损失了时间和资金后发现来得好。

    有些产品的技术风险较大，如果你的产品存在可行性风

    险一定要提前解决这些问题。

    可用性测试

    交互设计师应该与产品经理密切合作，想方设法突出产

    品的功能特性，让不同类型的用户都能明白如何使用。

    可用性测试往往能发现没能成功实现的产品需求，如果

    测试得当的话，甚至能发现原本被忽略的产品需求。最好规划多

    次迭代测试，确保实现最佳的用户体验效果。

    一定要请真实的用户来试用可用性原型，从目标用户那

    里可以得到宝贵的反馈信息。虽然产品经理和设计师也能从设计

    和使用原型的过程中掌握大量信息，但这些都不能代替让真实用

    户体验原型的作用。

    请注意，为了测试可用性，即使要模拟复杂的后台处理

    过程也是值得的，关键是要评估用户体验的实际效果。

    价值测试

    最后，仅仅知道产品能够开发出来、方便使用，这还不

    够。同样要紧的是知道用户是否觉得你的产品有用，是否愿意购

    买，有多喜欢产品的设计。

    价值测试可以和可用性测试同时进行，使用的原型也是一样的。只不过可用性测试重在观察用户如何设法完成必要的操

    作，而价值测试重在观察用户是否喜欢这些功能，是否满意功能

    的具体实现方式。

    简单的产品也许在纸上画画原型就够了，但对于大多数

    采用复杂用户界面、运用新技术的产品来说，必须借助产品原型

    评估设计是否符合要求。

    不同的产品有不同的原型.比如，常见的原型是可点击

    的页面，当然，原型也可能是物理设各，或是软件与硬件的结

    合。无论哪种形式的原型都必须足够真实(高保真)，可以提供给

    目标用户测试，并获取有效的用户反馈信息。

    不久前，还有人争论究竟应该使用高保真原型(如我所提

    倡的)还是低保真原型(主要是图纸)。我认为这样的争论已经没有

    意义了，因为使用高保真原型的成本已经大大降低，而通过它得

    到的反馈信息绝对物超所值。

    过去使用原型丰要有两个的阻碍。其一是缺少制作原型

    的工具.制作原型非常耗时：其二是管理层不明白原型和真实产

    品的区别，产品团队被追在原型的基础上开发产品，展终的产品

    质量可想而知。

    如今有各种原型制作工具可供选用，设计师和开发人员

    只要几天时间就能根据要求制做出原型，模拟未来的产品，提供

    给用户测试。多数管理者已经明白，制作原型与开发产品完全是

    两码事，好比制作房屋模型和建造房屋的差别。

    使用原型并非验证产品(尤其是互联网服务)的唯一方式 ......