赢在产品定义
撰写新闻稿
新闻稿是指一篇向市场宣布将要推出新产品的预告，简单明了地传达关于产品的关键信息。它天生就更简洁，可读性更强且更关注真实的产品能给真实的用户带来什么价值
好的新闻稿包含以下六大要素:
- 产品命名
- 发布时间
- 目标客户
- 解决了什么问题
- 如何解决(务必简明扼要)
- CEO的公开赞辞
创建并不断更新FAQ文档
创建并维护FAQ文档有两大好处。
- 它能节约你大量回复邮件回复消息的时间，在产品研发过程的诸多关键时候它也能节约时间，还能抵御一些内部责难。
- 当你的客户支持团队和科技写作团队开始整理所有面向公众的内容时，FAQ将是一个很有价值的资源。
绘制线框图和流程图
流程图可以帮助你准确地解释工作流和系统交互相关问题，简要线框图则可以帮助你具象化产品各环节的用户体验，并在之后的汇报中发挥不可思议的作用
撰写产品单页和制作10分钟的演示文稿
这两份文档所需包含的五个要素:
- 产品名称
- 目标客户 + 数量有多少
- 解决了什么问题 + 这个问题对于目标客户来说有多大价值
- 解决方案 + 这个解决方案类似线上那个产品，为什么你的方案能让竞争对手在长时间内都无法模仿
- 何时交付 + 主要的里程碑有那些？
- 团队背景(仅针对VC 风险投资人)
增加API文档
API文档可以说明你的团队如何与其他团队协作，外部开发者如何使用这套系统以及你需要存储什么数据。预先定义清楚API还有个好处，它可以帮助你搭建由这些API构成的面向服务体系结构
撰写功能和规格文档
- 简介
它说明了为什么要做这个产品以及做些什么，每个新进入项目的成员都可以从中了解到必要的背景信息。同时它还说明了文档中一些术语的含义，你可能因为使用习惯了这些术语而忘记了别人其实并不理解 - 目标与非目标
简介中虽已大致描述了产品的方向，但你需要将其细化成不同目标，每个目标都应保持清晰简介并将它们按优先级排列，这样工程团队就可以合理地进行设计与开发。
如果设定的某个目标表面上与产品没有多大关联，你需要解释清楚为什么将它设为目标，否则工程师会认为这些目标以及后面的功能需求都是你拍拍脑袋定下来的。他们不喜欢这种随意的需求，就像他们不喜欢随意定下的交付日期一样。你要慎重对待这件事情。
如果说目标是别人你要做什么，那么非目标则是告诉你不要做什么。所以设定非目标非常有用。那些持不同意见的人能通过非目标来理解你为什么会这样规划产品。 - 用例或用户场景
用例是指用简要的语句来描述那些用户必须执行的操作，用户场景则是指用叙述故事的方式来描述用户是如何提要产品的。用例描述非常精细，你不加思考便能读懂，工程师也能根据用例准确地判断该做那些工作。因此用例在敏捷开发中发挥着巨大作用，每个核心任务都会描述成一个用例。 - 原型图或线框图
由于正在遵循一个行之有效的产品定义过程，因此你已经绘制了一些粗糙的原型图或者线框图，将这些图粘贴到功能说明中，它们是用户场景的重要补充。 - API
如何还没有API文档，那就现在写 - 负载规划
负载规划是指对未来一段时间用户的使用量进行粗略估计并制订应对计划，这对工程团队来说非常重要。他们会根据你预估的使用量来确定哪些地方需要添加缓存，那种类型的服务器和存储需要准备，哪些授权问题可能产生，等等。
关于负载规划你要做的就是进行合理的预估，你的工程主管负责根据预估值来构建一个稳定运行的系统。不要花太长时间在预估上面，只需要花几个小时写个初稿，再找几个团队成员讨论一下并将讨论出来的数值翻倍就大功告成了。 - 依赖
你需要将全部依赖方及其负责人列出来，如果有应急方案也一并列出来。功能规格定稿后你也应该发给各依赖方的负责人，让他们知道你需要他们的支持。他们可能只会阅读你的简介部分，不过这就够了，因为这部分已经清楚阐释了你要做些什么。 - FAQ和开放问题
你可以直接将FQA和开放问题的链接地址放入功能文档中，也可以把内容复制过来，不过建议最好保持FQA的独立性，这样就不需要维护多个版本的FAQ了。 - 关键事件
你可能有一些硬性时间要求，这些时间都需要放入文档。你最好能列出主要事件的达成时间，如特性完成时间，可信测试者版发布时间，如果具体的工程量尚未评估出来，那预计的时间应该保守一些。
找出边界情况并得到团队认可
你的团队将开始寻找边界情况或者极端情况，即极少出现的产品行为或场景。如果不找出所有边界和极端情况，你就无法采取应对措施，它们就迟早给你带来伤害，现实世界中尤为如此。
