序言

原本以为这本书是讲产品如何从客户那里总结故事的方法和具体事例的，通过序言发现和开始的认知完全不同，书中应该把整个软件从无到有的整个过程进行统一为：交付。书中会围着交付的不同过程进行步步讲解，期待。。。

第一部分：交付卓越产品，步步为赢

要知道正确的组织交付过程，共7个阶段：
1.确定正确的产品方向。问题：怎么才知道是正确的产品方向？要能满足众多客户所共有的某个真实需求。
2.尽可能清晰详细的定义产品。
3.设计用户体验。问题：2和3阶段如何做到迭代过程？
4.做一些基础的项目管理工作，不要太多也不要太少。问题：如何判断多少？
5.开始测试。
6.差不多可以准备发布了，不过在发布之前要清楚地知道怎样才算成功，这就是建立一套衡量产品成败的标准。
7.正式发布。
以上阶段可见：缩小项目范围，简化用户体验，提升推进速度。整个过程越快，迭代就越快，交付的产品也就越好，因为每次迭代都会吸收上一次地阿呆中客户提出的建议和意见。
问题：七个阶段如何提升推进速度？

赢在使命和策略

使命：解决客户的问题。
策略：找到一种独特的方法满足这个群体或细分市场的共同需求
1.1如何找到正确的需求
以客户为导向，而不是以竞争为导向
必须专注于解决真正的客户问题。还得确保这个问题是个很多客户都存在的大众问题。
Google Pack之所以成功，要诀便在于它解决的问题比我们最初意识到的那个问题要难得多。
1.2如何构建卓越的使命
团队一定要有自己的使命。目标不一致会导致各自为战。
何为卓越的使命：能够唤起人们的兴趣；提供言之有物且能指明方向的原则；适合印在T恤上；可以为一贯团队找出使命。
需要的是一个能够反映代表性的使命，而不是一个面面俱到的使命。
1.3如何制定正确的策略
策略是指在竞争对手的压力下，利用公司独特的优势来争取目标用户的错略计划。不是产品描述、不是详细计划。需要阐明：客户、公司和竞争。
本质：如何长期未客户提供比竞争对手更优质的产品。
方法：用最多三段文字写下来，再浓缩成一段文字。越简短的策略越容易实现，也越容易获得他人的认可。
使命和策略制定需要大家认同和支持。然后再开展细化的工作。

赢在产品定义

交付的下一个阶段是让你的产品方案具体且可理解。通过制定使命和策略，你知道了你的客户是谁，他们的需求是什么。也知道如何做才能比对手更出色、更具备差异性。
如何证明臆断是否正确：吧产品提供给客户使用，然后听听他们的意见。
产品定义主要分为10步。每一步都建立在上一步完成的基础上。10步是不是太多了？
2.1. 撰写新闻稿。新闻稿：一篇向市场宣布将要推出新产品的通告。应简明的传达关于产品的关键信息。新闻稿的媒体属性注定了它天生就更简洁、可读性更强且更关注真实的产品能给真实用户带来了什么价值。六大要素：产品命名、发布时间、目标客户、解决了什么问题、如何解决（务必简明扼要）、CEO的公开赞辞。不要深入细节，很少包含图片且从不包含财物信息。从用户视角出发。
2.2. 创建并不断更新FAQ文档。随着产品方案的不断细化，各种问题也层出不同，其中大部分都非常重要，之处了产品的不足之处。吧这些问题记录到内部FAQ文档中并尽力回答。分为外部问题和内部问题。好处：能节省大量回复邮件的时间，还能抵御一些内部责难；需要整理所有面向公众的内容时，FAQ是一个很有价值的资源。
2.3. 绘制线框图或流程图。流程图可以帮助你准确的解释用户工作流和系统交互相关问题，简要线框图可以帮助具象化产品各环节的用户体验，并在之后的汇报中发挥不可思议的作用。
2.4. 撰写产品单页或10分钟的演示文稿。现在需要去争取工程团队、管理层、VC或其他利益相关方的初步支持。产品单页或演示文稿都是新闻稿的延伸，他们增加了市场机会（用户量）、收益机会（解决方案的价值）和长期竞争优势这三方面内容。需包含的五个要素：产品名称、目标客户+数量有多少、解决了什么问题+这个问题对于目标客户有多大价值、解决方案+与类似产品的长期优势、何时交付+主要的里程碑有哪些、团队背景（针对VC）。演示的最佳方式是先讲用户现状，再延伸开来（参考五大要素），迅速把药店讲完后再留出时间供这些聪明的听众就他们关心的点刨根问底。
2.5. 在FAQ中添加API文档。API文档可以说明你的团队如何与其他团队协作、外部开发者如何使用这套系统以及你需要储存什么数据。API最重要的作用是明确系统的各个边界。API的详细程度？是不是可以适当放宽？
2.6. 撰写功能规格文档。用来详细描述用户应该如何体验产品的文档。它不包含系统在后台如何运行之类的技术细节，这类细节应该包含在工程主管撰写的技术规格或设计文档中。此时需要写出所有部分的详细描述？在完成共10步过程中是不是和敏捷中的产品story细化过程是否一致？
包含九个内容：1. 简介（使命和策略）。2. 目标与非目标。3. 用例或用户场景。4. 原型图或线框图。5. API。6. 负载规划。7. 依赖。8. FAQ和开放问题。9. 关键事件。
这里说的用例（用户场景）和UML中的用例是否是一个含义？
2.7. 邀请设计团队和工程团队主管参与产品评审。
2.8. 找客户测试产品概念。
2.9. 命名、定价以及预测收益。定价和预测收益是否可以忽略或简化，毕竟软件行业的变化比较快，而且国内大家没有花钱在软件上的意识？
2.10. 想管理层汇报。

赢在用户体验

用户体验不仅是产品的外观样式，它还是产品的使用方式。交付卓越产品就是指交付卓越的用户体验。你的工作不是去解决所有的用户体验问题，而是确保产品尽可能提供最好的用户体验。为了让设计团队发挥出最佳水平，需要了解以下内容：
3.1了解各类设计角色：
用户体验：关注用户如何完成任务以及该如何优化向用户展现信息的方式。工具有流程图、原型图、可点击原型。用户使用流程？
用户体验设计师：对信息架构尤为关注。对信息进行优先级排序？
视觉设计：是关于如何通过一种即赏心悦目、夺人眼球又清晰明了的方式来展示内容的一门学问。相当于装修？如果以上三个角色有不同意见应如何协调?
用户体验研究：是用户体验的一个特殊组成部分，他专注于研究用户是如何看待你的产品的。通过数据统计、调研等帮助研究用户对于产品的想法。但他不管解决提出的问题。
角色建模：提供给你和你的设计团队、工程团队一个苹果设计的框架。是否和UML中的角色建模是一样的概念？
3.2了解如何评价设计：在没有接受过设计师的训练和相关知识时如何检查原型或设计是否优美、直观？可以使用下面的6个问题。
该用户界面要求用户完成的最重要的任务是什么？这个问题确认主要角色的主要任务和设计的主要任务是一致的。
这是最简单的解决方案吗？简单化框架：SHE（简化、隐藏、附加）
信息是否组织得当？
设计是否易用并且一目了然
标准是否一致
能否减少用户点击次数
3.3了解如何与设计师沟通：应避免直接说问题，从用户、原则、惯例、数据之类的侧面或原始出发点沟通
以用户的口吻说话
以提问的方式建立共识
反复讲述业务目标，如果有些目标相互冲突，则反复简书他们之间的相对优先级。
用数据说话
一共一些竞争对手或类似体验中运作良好的案例