第2章 赢在产品定义
交付的下一个阶段是让你的产品方案具体且可理解。通过制定使命和策略，你知道了你的客户是谁，他们的需求是什么。你也知道如何做才能比对手更出色、更具备差异性，有了这些知识再加上一些头脑风暴，便可以得出一个大致的产品方案。
当设法细化产品方案时，你会发现产品要解决的一些客户问题都是你主管臆断的，而且因为你的使命和策略都是建立在客户问题上的，因此这些主观臆断也混入了其中。要采用一些方法来证明臆断是否正确。即便他们十有八九是正确的，也要经过证明，而证明的最好方法就是把产品提供给客户使用，然后听听他们的意见。
多次在软件行业创业的埃里克.莱斯比较认同这个方法。他在《精益创业》一书中充分论证了为什么该构建一个最小化可行产品（Minimum Viable Product, MVP）。最小化可行产品是指产品最小的组成部分。通过把它提供给一定量的用户使用，你可以验证之前关于客户问题的臆断是否正确。你可以是需要来定义最小化可行产品、选择参与测试的客户数量以及决定一次验证几个问题。但不管最小化可行产品是大是小，你都可以参照下面的产品定义过程来定义产品。
产品定义过程主要分为10步：
1.撰写新闻稿。亚马逊喜欢这个不同寻常的第1步。新闻稿是一篇脱胎于策略的文章，篇幅不超过1页，主要用于促进各方了解和公开透明。你可能需要几天时间才能成稿。
2.创建并不断更新FAQ文档。你可以使用Wiki或Google Doc等现成的工具搭建和维护FAQ，这样可以节省费用。
3.绘制线框图和流程图。线框图和流程图是产品的可视化描述，在讨论或答疑中使用可以让观点更明晰。
4.撰写产品单页或10分钟的演示文稿。产品单页是一篇写给高管或多数风险投资人看的产品介绍文章，你需要把控好介绍的详略程度。演示文稿和产品单页内容一致，只是表现形式不同。
5.在FAQ中添加API文档。API是产品的第一个技术触角，在第6步会把他们全部整合到需求文档中。
6.撰写功能规格文档。功能规格文档又名产品需求文档（Product Requirements Document，PRD，谷歌常用此名），或市场需求文档（Marketing Requirements Document，MRD，微软常用此名）。它是阐述产品各功能详情以及为什么要有这些功能的最权威的文档。你可以将新闻稿、FAQ、线框图、产品单页和API文档等内容粘贴到功能规格文档的不同章节中。除去这些主料，还需要添加负载规划、非目标以及非常见用例（用于清晰表述FAQ中各种非常贱情况的用例）等佐料。
产品的规模以及成熟度决定了你需要几天还是几周才能写完功能规格文档。如果产品尚不成熟，你应当尽可能缩小产品规模以快速验证客户需求的真实性。如果产品规模庞大且已臻成熟（如苹果的iPhone），你就需要一份健全的功能规格文档了。
7.邀请设计团队和工程主管参与产品评审。这一步是为了获得项目组对产品的认可，并让他们帮忙寻找产品中存在的各种极端及边缘情况。
8.找客户测试产品概念。在此阶段，你需要了解产品方案是否真正能解决客户问题。花一天时间做一次完整的认知走查或花数天时间进行在线调研都是不错的测试方法。
9.命名、定价以及预测收益。你可以晚些时候再想这些事情，只要对产品有足够的信心。
10.向管理层汇报。上面9步完成之后你便可以向管理层或VC汇报你的产品了。你可以使用10分钟产品演示文稿来汇报，并视需要展示FAQ、线框图等。一旦通过，就可以动工了。
2.1 第1步：撰写新闻稿
撰写新闻稿是产品定义的一个另类却有效的开始。它是由亚马逊CEO杰夫.贝索斯率先倡导的。所谓新闻稿是指一篇向市场宣布将要推出新产品的通告。
好的新闻稿包含以下六大要素：
产品命名
发布时间
目标客户
解决了什么问题
如何解决（务必简明扼要）
CEO的公开赞辞
请注意，新闻稿不要深入细节。它很少包含图片且从不包含财务信息。它只是从用户视角触发简明扼要地阐述产品是什么、什么时候发布以及为什么要做这个产品。
亚马逊智能硬件Echo部门副总裁迈克·乔治（Mike George）说，Echo的诞生，起源于一个伪造的、假装有抱负的新闻稿，这个新闻稿是亚马逊内部逆向工作法的第一步。
（“逆向工作法”是贝索斯倡导的一种工作方式，其最关键的就是找到你一开始做这件事情的最初目的，然后根据这个目的去工作。）
延伸阅读：《连亏20年后冲击世界首富，亚马逊CEO贝佐斯的独特思维是什么？》http://mp.weixin.qq.com/s/JrMKm38C-ZyprBYmNL2SYQ
每当有人想出一个新的创意时，亚马逊的大佬们会问，这个产品对用户来说最重要的吗？它能够改变行业的游戏规则吗？我们能做出来吗？
然后开始逆向工作法的第一步：先写出一份新闻稿，暂时忽略所需要的技术。写完新闻稿，亚马逊的团队还会写一个“常见问题解答”手册，里面会解答每个有可能受到的问题，就像真发了新闻稿一样。“我们以同样有抱负的方式回答这些问题，在那一刻忽略掉技术障碍。”
接下来，与新产品相关的专家会展开具体讨论。从副总裁到初级软件开发人员，都会在一个屋子里共同讨论，这时每个人都有义务发言。因为亚马逊给工程师们的格言是：要有主见（have backbone）。
亚马逊希望所有与新产品相关的人相信自己与这个项目有关。迈克·乔治说：“屋子里的人如果觉得哪里错了，势必要大声说出来，因为一旦整个团队都同意了，这代表所有人都赞成。”接下来，“如果我们觉得自己手里有了什么可做的，就会执行”。按照逆向工作法做出来的产品，不一定都能像Echo那样大卖（截至2016年第一季度末，Echo总销量为400万台），也会有失败，比如智能手机Firephone，但是亚马逊不会因为几次失败而轻易放弃项目。
延伸阅读：《连亏20年后冲击世界首富，亚马逊CEO贝佐斯的独特思维是什么？》http://mp.weixin.qq.com/s/JrMKm38C-ZyprBYmNL2SYQ
2.2 第2步：创建并不断更新FAQ文档
随着产品方案的不断细化，各种问题也层出不穷，其中大部分都非常重要，指出了产品的不足之处。我会迅速把这些问题记到一个内部FAQ文档中并尽我所能回答提问者。
创建并维护FAQ文档有两大好处。第一，它能节省你大量回复邮件的时间，还能抵御一些内部责难。第二，当你的客户支持团队和科技写作团队开始整理所有面向公众的内容时，FAQ将是一个很有价值的资源。
2.3 第3步：绘制线框图和流程图
流程图可以帮助你更准确地解释用户工作流和系统交互相关问题，简要线框图则可以帮助你具象化产品各环节的用户体验，并在之后的汇报中发挥不可思议的作用。
2.4 第4步：撰写产品单页和制作10分钟的演示文稿
到现在为止，关于客户是谁、要解决他们的什么问题以及采取哪种解决方案应该都有定论了。接下来你需要去争取工程团队、管理层、VC（风险投资人）或其他利益相关方的初步支持。你需要弄清楚他们对产品的认可程度，否则等到第7步功能规格文档都快完成了，而他们对产品的价值存有疑义，你将面临不断的返工。另外在这时准备还有一个优势，因为经历上面几步后你对产品方案的细节以及可能受到的挑战都有了更全面的理解，所以在应对他们的诘问时能胸有成竹、进退有度。
这一步你只需准备产品单页和10分钟的演示文稿，也可以两者选其一。在产品单页中根据需要来添加线框图或流程图就可以了，不必考虑它们所占用的篇幅。
下面介绍这两份文档所需包含的五个要素：
产品名称
目标客户+数量有多少
解决了什么问题+这个问题对于目标客户来说有多大价值
解决方案+这个解决方案类似线上哪个产品，为什么你的方案能让竞争对手在长时间内都无法模仿
何时交付+主要的里程碑有哪些？
团队背景（仅针对VC）
你会发现产品单页和演示文稿实际上是新闻稿的延伸，他们增加了市场机会（用户量）、收益机会（解决方案的价值）和长期竞争优势（对手长时间内无法模仿）这三方面内容。
2.5 第5步：在FAQ中增加API文档
API文档可以说明你的团队如何与其他团队协作、外部开发者如何使用这套系统以及你需要存储什么数据。预先定义清楚API还有个好处，它可以帮助你搭建由这些API构成的面向服务的体系架构（SOA，Service-Oriented Architectures）。因此预先撰写API文档对每个人都有很大帮助。
不止如此，API最重要的作用是明确系统的各个边界，而明确的边界有助于人们了解各类功能或输出分归哪方负责。这样在项目初期各方就建立了理解和术语上的一致性，为后续高效沟通产品需求打下了坚实基础。
虽然API的作用很大，但也会带来一些麻烦。和你合作的开发工程师或许会觉得你抢了他们的工作，所以谨慎起见你应先了解他们的立场。
2.6 第6步：撰写功能规格文档
微软称这份文档为市场需求文档，因为它挣了了市场研究者从客户访谈中收集到的一些列需求。谷歌称之为产品需求文档，因为它通常是产品经理负责撰写的。亚马逊则把它称为功能规格，因为它描述的是产品应提供什么功能给用户使用。虽然各家命名不同，但对于它功用的看法却是一致的：它是用来详细描述用户应该如何体验产品的文档。它不包含系统在后台如何运行之类的技术细节，这列细节应该包含在工程主管撰写的技术规格和设计文档中。
功能规格文档包含以下9个内容块：
简介（使命和策略）
目标与非目标
用例或用户场景
原型图或线框图
API
负载规划
依赖
FAQ和开放问题
关键事件
2.6.1 简介
它说明了为什么要做这个产品以及做些什么，每个新进入项目的成员都可以从中了解到必要的背景信息。同时它还说明了文档中一些术语的含义，你可能因为使用习惯了这些术语而忘记别人其实并不理解。
2.6.2 目标与非目标
如果说目标是告诉别人你要做什么，那么非目标则是告诉别人你不要做什么。所以设定非目标非常有用，那些持不同意见的人能通过非目标来理解你为什么要这么规划产品。
2.6.3 用例或用户场景
用例是指用简要的语句来描述哪些用户必须执行的操作，用户场景则是指用叙述故事的方式来描述用户是如何体验产品的。
下面是一个Google+ Hangouts的用例：用户能共享屏幕。
再看一个更有意思的用例，它包含了上述用例：当用户试图共享屏幕时，如果其他用户正在共享，该用户会收到系统让他确认是否替代目前正在共享的其他屏幕的提示。
用例描述非常精细，你不加思考便能读懂，工程师也能根据用例准确地判断该作哪些工作。因此用例（或者用户故事）在敏捷开发中发挥着巨大作用，每个核心人物都会描述成一个类似下面结构的用例：
作为视频聊天参与者之一，我希望能【共享我的屏幕给其他视频聊天参与者】。
无论是只写用例还是只写用户场景甚至两者都写，你都需要敲定它们的优先级。谷歌和亚马逊用的是相同的优先级规则，共分4级：
P0：没有该功能产品无法演示。
P1：没有该功能产品无法交付。
P2：锦上添花的功能。
P3：哈哈哈！
2.6.4 原型图或线框图
2.6.5 API
如果你还没写API文档，那就现在写，不过前提是已征得工程团队的同意。
2.6.6 负载规划
负载规划是指对未来一段时间内用户的使用量进行粗略估计并制定应对计划，这对工程团队来说非常重要。他们会根据你预估的使用量来确定哪些地方需要添加缓存，哪种类型的服务器和存储需要准备，哪些授权问题可能发生，等等。
你需要制定备用策略以应对最坏的情况，一次分布式拒绝服务（DDOS，Distributed Denial-Of-Service）攻击、一篇《华尔街日报》的报道或者一次数据中心故障都可能置你的产品于最坏的境地。不过灾难并不可怕，可怕的是你没有任何准备，你应该适当部署一些有效的微机管理系统，如流量限制系统、“系统目前繁忙，请稍后再试”的出错页面或保存在CDN上的应用静态版本。
2.6.7 依赖
你需要将全部依赖方及负责人列出来，如果有应急方案也一并列出来。功能规格定稿后你也应该发给各依赖方的负责人，让他们知道你需要他们的支持。
2.6.8 FAQ和开放问题
你可以直接将FAQ和开放问题的链接地址放入功能文档中，也可以把内容复制过来，不过我建议最好保持FAQ的独立性，这样就不需要维护多个版本的FAQ了。
2.6.9 关键事件
你可能有一些硬性时间要求（比如苹果有它的世界开发者大会，又比如你的资金只能支撑到某个时间），这些时间都需要放入文档。你最好能列出主要事件的达成时间，如特性完成时间、可信测试者发布时间，如果具体的工程量尚未评估出来，那预计的时间应该保守一些。在这一部分应该把重点放在硬性时间而非工程时间，另外再当上项目计划的链接。
2.7 第7步：找出边界情况并得到团队认可
你的团队将开始寻找边界情况（edge cases，指在一个最大或最小运行参数下发生的情况。）或者极端情况（corner cases，指在多项运行参数同时处于极端水平下发生的情况。） ，即极少出现的产品行为或场景。不要抱怨这个看似繁琐的事情，如果找不到所有边界和极端情况，你就无法采取应对措施，他们迟早会给你带来伤害，现实世界中尤为如此。
Motricity的资深项目经理，成为摩托罗拉等客户管理过大型项目的艾伦.阿布拉姆斯认为，发现边界情况的最好方法是“漫步于功能之中”。你需要时间来仔细地、创造性地思考用户会如何弄坏你的软件或者在某种意义上没有按照你的预期来使用软件。当你“漫步”时，请将所有可能的边界情况以及应对策略写在FAQ或者产品需求文档中。
除了确保处理好边界情况，你还需要确保工程和用户体验团队认可你的产品规划。最好的做法是在开始时就把产品需求文档发给开发主管、测试主管以及用户体验主管。如果有其他主管也对产品感兴趣，如客户支持、法务、公关等，也一并发给他们。他们未必都有时间阅读你的文档，最好邀请他们开一个类似于设计评审的会议，给他们充分评论这份文档的机会。
2.8 第8步：客户测试
亚马逊和谷歌会向部分客户发布一些实验性功能，然后检测他们的使用情况。除了客户测试，亚马逊还会专门雇佣一些测试团队，而谷歌坚定不移地奉行单元测试（不是功能测试）。作者在这里主张的“客户测试”并不是让你马上把软件开发出来然后扔给客户挑刺，他主张的是去找一批现存的或潜在的客户，向他们介绍你的产品设想和原型，并听听他们的反馈。
这个测试可以避免你做出一个没人想用的产品或者遗漏一些核心功能。谷歌高级副总裁艾伦.尤斯塔斯曾指出，团队会轻易陷入一场为莫须有的客户问题构建完美解决方案的狂欢中。所以你需要这个客户测试来验证你的目标、非目标以及优先级是否合理。
有些人把这种测试叫做“焦点小组”，也有些人把它叫做“试售 ”或对现存客户的“路线图演示”。你的用户体验团队或许认为这个过程试一次认知性遍历：客户通过你对产品原型图的介绍来体验产品，然后通过关于功能和实用性的反馈。以上林林总总的叫法或做法并不重要，重要的是你去做了这个测试！
2.9 第9步：想清楚基本的商业要素——命名、定价和收益
产品命名：你需要一个客户喜欢的、能注册商标并通过版权检查的名称，后者可以让律师把关。事实上讨论名称是一件极其主观且争议较大的事情，能比它还夸张的也只有定价了。名称并没有那么重要，它再出色也不能帮你做成这个产品或者毁掉这个产品，所以不要浪费太多时间纠结于此，赶紧定一个！
产品定价：作者不建议花时间阅读300多页的深度经济分析报告，他们大多时候都毫无用处。你只需理解产品定价的三个基本方法：按成本定价、按价值定价以及对比定价。
软件行业通常不适合按成本定价，除非你提供增值技术支持或售卖软件许可协议（SLA，Software License Agreement）。不过即使这样也不适合按成本定价，因为成本定价的一个最大弊端就是很难真正统计成本，比如投资成本、一线支持成本、工程支持成本等等。你能通过记账来估算今天的成本，却很难知道明天的成本。
如果打算按价值定价，可以去调研客户，看看产品在什么价位他们愿意购买，在什么价位即使需要他们也不会购买。不过，你的产品还不存在，客户很难真实评估是否需要，而且他们还经常出尔反尔或者因为不想伤害你的信心而欺骗你。
对比定价相比其他两种办法要合理得多，但它有两个前提：①有一个合理的比较目标；②假定市场是弹性的，即产品会在价格下降时销量增加，价格上升时销量减少。所以得现在市场上找到比较目标。当你的产品比对手功能强大时，收费就高一些，反之亦然。如果市场上没有类似的产品，或者你的产品大体上算一个新产品时，对比定价就不起作用了。
再给你一些针对高科技产品的宽泛的行之有效的建议。
-分析竞争对手。如果能够对比定价，你就有了一个好的起点。
-调研客户愿意支付多少钱购买产品，虽然他们不一定会说实话。
-简化初始定价以降低用户理解成本。Google Apps的价格分两个：50美元1年或免费（仅限10个以内用户使用），而微软Live365的定价则五花八门，让人眼花缭乱，莫非这正是他们的策略之一？
-把已经满足需求的定价再抬高一些。等正式推出后再想涨价就难了。
-不要在定价上争吵不休。定价不是交付的全部，它只不过是其中一个小步骤。
有了定价之后就可以开始建立收益模型了，收益模型一般都是拍脑袋拍出来的，那为什么我们仍然需要构建它？
第一，你需要让VC或业务主管感知到你规划的是一个多么重要的任务。因此你需要一个模型来向他们展示未来3年的月度收益预测。
第二，构建收益模型能使产品设想具象化并证明产品机会有多大。收益模型包含了你的市场研究、你作为消费者的直觉以及一些数学运算，它们组合在一起可赋予你深刻的洞察力。
第三，一个简洁的模型支持你任意调整变量并反复进行预测。你可以借此了解定价、支持成本、市场费用等财务维度是如何影响盈亏的，这有利于你做出理性的决策。
所以无需担心收益模型大部分是基于假设的，只需尽力保持它的间接性。即使你再介绍这个模型时被人质疑了，那不妨根据他们的意见进行调整，毕竟你做这个模型的目的是争取资源以尽快开发出真正的产品，而不是预测未来。下面教你如何构建一个非常简洁的收益模型。你可以从http://www.shippinggreatness.com下载电子表格的副本。
1.估算买家总体市场规模。比如在作者负责Google Talk时，通过估算企业在视频会议、语音会议以及长途IP电话上投入的费用，我发现这个市场规模极具吸引力。
2.预估市场规模的增速。它将是你的基线。当市场规模扩大时，你的销售规模也应扩大。
3.估算你的目标市场占总体市场的比率：①估算你针对的细分市场（比如小型企业、中型企业或者大型企业）占总体市场的比率。②估算你可触及的国际的市场规模占总体的比率。
4.估算通过市场推广你能触碰到的用户规模。你可以把预估的市场预算除以关键词的千人印象成本（CPM,Cost Per Mile/impress）来简单估算出该值。
5.预估触碰产品的人中会有多少转化成产品用户。
6.找到其他新用户增长渠道并加入到模型中。假设你的产品中有一套“邀请朋友”机制，你便可以预估它的转化率并加到模型中。
7.最后，将产品定价乘以每个时期增长的用户数便是收益了。如果产品是付费订阅类的，你还可以预估一个续费率然后计算利润。
2.10 第10步：取得上层的认可
预售：为了让最后的产品汇报跟容易一些，建议先花点时间预售产品。预售是一个非常直接的爬向食物链顶端的过程，为了让负责决策的高管最终认可你的产品方案，你需要预先争取中间每一级老板的支持，然后让直接向该高管汇报的家伙预先顺畅地了解你的产品概念。如果预售得不好，你可能会提前出局。产品理念无法被理解，自然也就无法准确地传达给最终决策的高管。
还有一种预售方式是“路过式”预售。趁着负责决策的高管站在走廊或者倒咖啡的时候走到他身边和他聊一两分钟你想做的产品，这时候你追求的不是一个决策， 而仅仅是让他知道有这么一个事，这样你之后的汇报至少会顺畅些，同时你对他可能有什么激烈反应也心里有个底。
等到直接和高管汇报产品方案时你又得体会另一番折磨。以向杰夫·贝索斯汇报为例，让作者印象深刻的是他从未有机会按照正常顺序演示幻灯片。杰夫会让你快速反倒后面去直接讨论方案细节。这种不让你按常理出牌的情况会发生在谷歌、亚马逊、VC以及所有的给聪明绝顶的亿万富翁做演示的时候。
因此，在向这种位高权重的人汇报产品方案时，首先请确保你了解产品的所有信息。万一被问到一些忘记了的事情或者还没来得及去了解的事可千万别想着糊弄过去，继续保持你英明神武的状态并回答他们："这点我不是很清楚，我之后会去了解一下然后给您反馈。”其次，他们想了解什么你就说什么，不要坚持你的顺序，带他们去了解他们想了解的地方。
2.11 产品已经准备就绪，去构建它吧
在这个点上你已经找到了一个覆盖面广、重要性高的用户需求，你还提出了一个独特的解决方案。你能通过产品单页或者10分钟的演示来介绍方案，也能凭借功能规格（包括FAQ、API和依赖清单）来讲述产品的所有细节。你还努力构建了一个简陋却令人振奋的收益模型，它正是你做这块业务的原动力。产品已经准备就绪，准备好和你的团队将它变成可用的软件或功能吧。
（未完待续）
