第二部分 流程

第二部分 流程
第11章 评估产品机会
第12章 产品探索
第13章 产品原则
第14章 产品评审团
第15章 特约用户
第16章 市场调研
第17章 产品人物角色
第18章 重新定义产品说明文档
第19章 用户体验设计与实现
第20章 基本产品
第21章 产品验证
第22章 原型测试
第23章 改进现有产品
第24章 平滑部署
第25章 快速响应阶段
第26章 合理运用敏捷方法
第27章 合理运用瀑布式开发方法
第28章 创业型公司的产品管理
第29章 大公司如何创新
第30章 在大公司施展拳脚

第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.com/examples

阅读有关机会评估的范例。

第12章 产品探索

Product Discovery

定义正确的产品

软件项目可以划分为两个阶段：弄清楚要开发什么产品(定义正确的产品)；开发该产品(正确地开发产品)。第一个阶段探索产品，第二个阶段则强调执行。

在探索产品的阶段，产品经理负责分析各种创意，广泛收集用户需求，了解如何运用新技术，拿出产品原型并加以测试，从全局视角思考产品方向，兼顾短期需求和长期规划。总而言之，就是探索出兼具功能性与设计性的产品。

一旦完成产品定义，进入开发阶段，产品团队就要切换工作重心。现在的重心在于执行——开发、测试、发布。产品经理要确保大家集中精力，捕捉软件开发不可避免的问题并迅速予以解决。开发过程中可能会出现各种干扰，比如，竞争对手的干扰、公司组织变动，甚至公司问并购等，产品经理有责任确保产品团队不受干扰，专注完成项目，按时发布产品。

许多产品团队没有意识到，或者很晚(比如到了测试阶段)才意识到要转变工作重心。更糟糕的是，产品经理还时不时冒出新点子：公司高管认为产品说明文档还可以继续修改，导致开发要求大幅变更，严重影响开发团队的工作。结果不是发布日期一推再推，就是某些功能被迫取消，或者产品质量下滑。

产品经理必须在执行阶段转换工作重心；否则，产品经理自己很可能成为产品上市的最大障碍。每位产品经理的个性都不相同。如果你天生喜欢探索发明，喜欢自由和创意，那么在执行阶段就要努力控制创造的欲望；如果你天生是“项目经理”类型的人，喜欢排除外界干扰，按部就班完成任务，那么你需要培养自己的宏观思考能力和设计能力。

我有个方法可以解决这种冲突：采用流水线方式并行开发产品。也就是说，一旦1.0版本的产品进入项目执行阶段，就开始定义2.0版本的产品。一旦前一个版本进入开发阶段，就把你的创造热情投入下一个版本。

唯一需要注意的是，不要让这种做法干扰正在执行的项目。我个人觉得这个方法很管用。如果下次公司高管再要求你增加新功能，也不会影响正在开发的产品，因为你已经开始构思新版本，可以把新功能纳入其中。7

探索产品的进度可控吗?

你有过这种经历吗?公司看好一个创意，要求你据此定义新产品。这时开发团队还有四周才能完成手头的项目，也就是说，你有四周时间探索新产品。

你觉得没问题，计划第一周先评估产品机会，尝试理解待解决的问题，拜访潜在用户，收集基本需求：第二用与交互设计师一起制作产品原型；第三周利用产品原型展开用户测试；第四周完成产品用例，与开发团队一起评审产品原型和说明文档。

这是理想状态，执行中往往会出纰漏。用户可能对创意不感兴趣，或者对你的产品原型不感兴趣。但是已经没时间了，开发团队等米下锅。不得已，你只好让他们开发有缺陷的产品。

几个月后，开发团队依样画葫芦完成了产品，但糟糕的可用性让管理层大失所望。这不能怪开发团队，毕竟他们只是按你的要求工作。那是谁的错呢?当然是你产品经理的错。如果不改变观念，同样的问题迟早还会出现。

软件产品行业存在一种根深蒂固的偏见，认为分析需求和设计产品的工作是可预测的、可控制的。这通常是产品团队最难逾越的心理障碍。定义产品本质上是创造性的工作，更像一门艺术而不是科学。：

所以我喜欢把定义产品的过程称为“产品探索”，而不是“需求和设计”，为的是强调如下两个观点。

首先，产品经理应该探索是否有用户需要产品，也就是说，要寻找市场，让用户验证你的构思。

其次，产品经理要探索能够解决问题的产品方案，它必须是有价值的、可用的，可行的，也就是说，要设计解决方案，请用户和开发团队来验证。

有时产品探索很容易完成，有时却非常围难。以我的经验来说，发现和验证市场机会并不难，但探索产品解决方案的难度很高。有些问题即便有出色的设计师和开发人员协助，也还是难以解决。

制药行业也面临着同样的问题。他们寻找市场机会并不难——有很多问题值得解决(比如挽救生命、延年益寿)，难的是探索产品解决方案(研发药品)。制药公司清楚没人能保证一定能研发出新药。就算能研发出来，时间也不确定，而且研发新药的时间成本会影响药品的定价。

但在软件行业，尽管大家知道定义产品有难度，也承认大部分产品没能完成既定目标，但我们仍然像制订建筑施工计划一样，为探索产品设定期限。管理层坚持给产品探索设定期限，主要有如下原因。

1探索产品的过程不可预测。管理层担心花几个月研究解决方案，最后却做不出产品，而如果按计划进入开发阶段，至少有事可做。

2开发人员是紧缺资源，开发团队无事可做会让管理层抓狂。问题是，这反而导致开发资源被浪费。

不管大家意识到没有，所有的公司都会执行探索产品的流程，只不过有些公司不是利用产品原型完成这项工作，而是孤注一掷，用实际产品搭上全部开发时间进行产品探索，他们开发的是一款非常昂贵的原型，让不知情的用户掏钱参与原型测试。这些公司需要一两年时间(发布几个版本)才能赢利。

这也是很多处于创业阶段的公司失败的原因——它们往往没有足够的资金维持两年，因求胜心切，盲目招聘开发人员拼力一搏。结果可想而知。

处于创业阶段的公司和大公司都应该重视产品探索流程，在确定有价值的、可用的、可行的产品解决方案后，再全面转入执行阶段。在此之前不需要招聘大量开发人员，已有的开发人员也可以参与探索产品，或者利用这段时间准备基础软件设施。

你应该帮助管理层理解探索产品的本质，明白产品经理的职责是保证开发团队开发有价值的，可用的产品，这样你才能安心完成探索产品的任务。

第13章 产品原则

Product Principles

确定什么最重要

产品原则是对团队信仰和价值舰的总结，用来指导产品团队做出正确的决策和取舍。它体现了产品团队的目标和愿景，是产品战略的重要组成部分。从形式上看，它是…系列明确的、体现团队特色的产品价值准则。

每次加入新团队，我要做的第一件事就是制定产品原则。制定产品原则意味着决定什么重要、什么不重要，哪些原则是根本的、战略性的，哪些是临时的、战术性的。

产品原则不是产品功能的清单，不依赖于任何单独的产品，它是整个产品线的战略指南，是公司的价值宣言。好的产品原则甚至可以激发设计产品的灵感。

制定产品原则的过程也是学习的过程，我可以从中了解新公司企业文化，以及公司创始人设立的企业目标。产品原则是一套价值判断的框架，帮助公司做出正确的决策。

举例来说，某电影网站的产品原则是相信社区用户的影评比专业人士的影评更有价值。如果某家制片厂希望借网站发表评论，产品团队就可以根据这条产品原则决定是否采纳。

产品原则是否公开因公司而异。它既可以用做团队内部的指导工具，像是产品战略文档，也可以公开给客户、合作伙伴、投资人，用于向公众宣传公司的理念。

此外，产品原则还可以用来团结产品团队，让产品经理、产品设计师、开发团队和营销团队形成共同的价值观，在认识上保持一致性。这是任何产品说明文档都做不到的。

注意，仅仅罗列出产品原则还不够，还要按原则的重要性排序。所有产品都希望做到既易于使用又安全可靠，但总有需要优先考虑的原则。最重要的究竟是易用性，还是可靠性?

制定产品原则时容易出现两类错误。第一类是原则过于空泛，失去了指导作用。第二类是把设计原则误当成产品原则．比如，为用户提供清晰的导航路径(方便用户完成下一步操作)属于常见的设计原则，不是产品原则。

如果你所在的团队还没有制定清晰的、有关产品理念的产品原则，应该把大家召集起来，花点时问讨论分析，确定团队最看重的价值理念。

解决意见冲突

不少产品经理向我抱怨说，他们受够了没完没了的会议(既无议程也无结果)，以及会议中的那些争论、冲突。公司高管还时不时打断会议进程，扔下没头没脑的意见，然后拂袖而去，留下他们丈二和尚摸不着头脑。

这种情况在产品决策过程中经常发生，原因主要有以下几点：第一，每位同事对公司的产品都有自己的看法；第二，大家都非常在乎产品，明白公司营利得靠用户，只有产品才能吸引用户；第三，许多人以为自己比其他人了解目标用户，事实上并非如此。

另外，产品团从大多不必向产品经理汇报工作，产品经理没有管理产品团队的实权。如果需要产品团队的配合，产品经理只能摆事实、讲道理，不能强制执行。所以产品经理总觉得施展不开拳脚，非常沮丧。

有时大家各持己见，僵持不下，只能请高管出面定夺。出现这种局面，说明沟通方式有问题。产品创意在辩论中可以得到完善，但前提是大家形成一致意见。请高管出面决笨、解决冲突会激化团队内部矛盾，得不偿失。

制定产品决策的过程中存在的困难着实不少。这些困难是不可避免的，因为建设性的辩论和论证是定义优秀产品的必由之路。不过即使认识到这一点，我也很难把争论当成一种享受。

为了鼓励创新，改善讨论效果，同时降低外界干扰，在作产品决策之前，应该先确定决策要解决什么问题，让大家在以下几个要点上迭成共识。

1．究竟要解决什么问题?

2．要为哪类人物角色解决这个问题?

3．产品要达到什么目标?

4．每项目标的优先级是什么?

在我看来，每当团队内出现严重的意见分歧时，并非是大家对事实的认定有争议，而是对目标和目标的优先级有不同的理解。

比如说，团队首先应该确定哪个目标对用户最重要，是易用性、响应速度、功能、成本、安全性，还是用户隐私?只有先统一对产品目标和目标优先级的认识，大家才能在此共识上进一步讨论各种方案的合理性与可行性。

务必认真分析产品目标的优先级(从最重要到最不重要逐项排序)，让团队达成共识。切不可囫囵吞枣地把所有目标都贴上“关键”和“重要”的标签。一定要区分什么最重要，什么第二重要……

我常被请去解决产品决策中出现的争议，我发现，多数团队跳过了这关键的一步。由于缺少基本评估标准，每个人对目标和优先级的理解都不同，大家往往情绪激动，在细枝末节上争执不下。

即使大家已经达成共识，也应该在讨论开始前再次予以强调，最好把目标按优先级顺序写在白板上，这样每位同事都可以看到评估方案和制定决策的确切依据。

制定决箍的过程和依据必须完全透明，不要让人觉得你只凭直觉判断。务必告诉大家决策的依据和理由，清楚地展示每一个决策环节。

激烈的会议争论会影响大伙的斗志和工作效率。如果再出现这种情况，请先回顾产品目标和目标优先级，确保大家达成共识。

◎范例

产品原则的范例请参见：

http://www.svpg.com/peamples。

第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％的用户要求提高视频的分辨率”，从这类呆板的报告里是不可能洞察用户需求的。

产品经理还应该充分利用，公司的可用资源。许多公司设有用户研究部门，他们可以协助分析用户行为；营销人员可以协助确定产品定位和宣传计划。我个人还喜欢邀请主程序员参与前期定义产品的工作，让他提前考虑产品开发的细节问题。

这些工作你都可以请人协助，唯有理解用户需求的工作，产品经理不能推诿他人。

最后补充一点，与用户打交道的过程中，你会发现一些富有洞察力、善于思考的用户，应设法与他们建立长期联系(记下他们的联系方式)。他们是特约用户的最佳候选人。