谷歌和亚马逊如何作产品归总(二)

赢在产品定义

撰写新闻稿

新闻稿是指一篇向市场宣布将要推出新产品的预告，简单明了地传达关于产品的关键信息。它天生就更简洁，可读性更强且更关注真实的产品能给真实的用户带来什么价值

好的新闻稿包含如下六大要素:

• 产品命名
• 发布时间
• 目标客户
• 解决了什么问题
• 如何解决(务必简明扼要)
• CEO的公开赞辞

建立并不断更新FAQ文档

建立并维护FAQ文档有两大好处。

1. 它能节约你大量回复邮件回复消息的时间，在产品研发过程的诸多关键时候它也能节约时间，还能抵御一些内部责难。
2. 当你的客户支持团队和科技写做团队开始整理全部面向公众的内容时，FAQ将是一个颇有价值的资源。

绘制线框图和流程图

流程图能够帮助你准确地解释工做流和系统交互相关问题，简要线框图则能够帮助你具象化产品各环节的用户体验，并在以后的汇报中发挥难以想象的做用

撰写产品单页和制做10分钟的演示文稿

这两份文档所需包含的五个要素:

1. 产品名称
2. 目标客户 + 数量有多少
3. 解决了什么问题 + 这个问题对于目标客户来讲有多大价值
4. 解决方案 + 这个解决方案相似线上那个产品，为何你的方案能让竞争对手在长时间内都没法模仿
5. 什么时候交付 + 主要的里程碑有那些？
6. 团队背景(仅针对VC 风险投资人)

增长API文档

API文档能够说明你的团队如何与其余团队协做，外部开发者如何使用这套系统以及你须要存储什么数据。预先定义清楚API还有个好处，它能够帮助你搭建由这些API构成的面向服务体系结构

撰写功能和规格文档

1. 简介
   它说明了为何要作这个产品以及作些什么，每一个新进入项目的成员均可以从中了解到必要的背景信息。同时它还说明了文档中一些术语的含义，你可能由于使用习惯了这些术语而忘记了别人其实并不理解
2. 目标与非目标
   简介中虽已大体描述了产品的方向，但你须要将其细化成不一样目标，每一个目标都应保持清晰简介并将它们按优先级排列，这样工程团队就能够合理地进行设计与开发。
   
   若是设定的某个目标表面上与产品没有多大关联，你须要解释清楚为何将它设为目标，不然工程师会认为这些目标以及后面的功能需求都是你拍拍脑壳定下来的。他们不喜欢这种随意的需求，就像他们不喜欢随意定下的交付日期同样。你要慎重对待这件事情。
   
   若是说目标是别人你要作什么，那么非目标则是告诉你不要作什么。因此设定非目标很是有用。那些持不一样意见的人能经过非目标来理解你为何会这样规划产品。
3. 用例或用户场景
   用例是指用简要的语句来描述那些用户必须执行的操做，用户场景则是指用叙述故事的方式来描述用户是如何提要产品的。用例描述很是精细，你不加思考便能读懂，工程师也能根据用例准确地判断该作那些工做。所以用例在敏捷开发中发挥着巨大做用，每一个核心任务都会描述成一个用例。
4. 原型图或线框图
   因为正在遵循一个行之有效的产品定义过程，所以你已经绘制了一些粗糙的原型图或者线框图，将这些图粘贴到功能说明中，它们是用户场景的重要补充。
5. API
   如何尚未API文档，那就如今写
6. 负载规划
   负载规划是指对将来一段时间用户的使用量进行粗略估计并制订应对计划，这对工程团队来讲很是重要。他们会根据你预估的使用量来肯定哪些地方须要添加缓存，那种类型的服务器和存储须要准备，哪些受权问题可能产生，等等。
   关于负载规划你要作的就是进行合理的预估，你的工程主管负责根据预估值来构建一个稳定运行的系统。不要花太长时间在预估上面，只须要花几个小时写个初稿，再找几个团队成员讨论一下并将讨论出来的数值翻倍就大功告成了。
7. 依赖
   你须要将所有依赖方及其负责人列出来，若是有应急方案也一并列出来。功能规格定稿后你也应该发给各依赖方的负责人，让他们知道你须要他们的支持。他们可能只会阅读你的简介部分，不过这就够了，由于这部分已经清楚阐释了你要作些什么。
8. FAQ和开放问题
   你能够直接将FQA和开放问题的连接地址放入功能文档中，也能够把内容复制过来，不过建议最好保持FQA的独立性，这样就不须要维护多个版本的FAQ了。
9. 关键事件
   你可能有一些硬性时间要求，这些时间都须要放入文档。你最好能列出主要事件的达成时间，如特性完成时间，可信测试者版发布时间，若是具体的工程量还没有评估出来，那预计的时间应该保守一些。

找出边界状况并获得团队承认

你的团队将开始寻找边界状况或者极端状况，即极少出现的产品行为或场景。若是不找出全部边界和极端状况，你就没法采起应对措施，它们就早晚给你带来伤害，现实世界中尤其如此。

客户测试