产品经理需要把想法落实到笔头上，于是就有了产品文档。如何写出一份精炼、易懂的产品文档？今天我们就来聊聊这个问题。
常见的产品文档类型有哪些？
I Product Roadmap 产品路线图
产品路线图的横坐标是时间段，纵坐标是各时间段末的主要产出，这里的“产出”包括各时间段内出现的主题、产品类别等。
那么在公司内部有哪些人需要看产品路线图？首先，产品经理需要逐层递交产品路线图，让他的各层上级进行审核和完善；在管理层确定线路图没问题以后，再与开发部门和工程师们进行分享，这一步骤使它成为全公司的线路图。
例：某公司的产品路线图，有清晰的时间段、产品线和计划（initiative）
II PRD（Product Requirement Document）产品需求文档
产品需求文件是包含特定产品所有要求的文档，向其读者解释此产品应该做什么。它的目标读者包括开发人员，UX／UED，测试人员，项目经理，市场人员。
PRD内容的举例：
  1. 总结摘要：为x用户构建y产品来解决z问题。
  2. 目的。
  3. 目标用户，市场细分（Use Cases/ Business Cases）。
  4. 假设与范围 Assumptions & Scope：假设就是指产品经理在做产品时一般心里有个数，比如，他可以基于从市场调查获得的信息对用户行为进行预判；范围是指，产品经理可以在某次PRD中选择做什么做，不做什么。
  5. 发布里程碑：确定关键交付成果，成功标准、目标日期。
  6. 功能说明。
  7. 工作流程/线框（如果需要）。
  8. 数据分析要求：有哪些指标？观测了多久？
  9. 性能要求：设定正常功能的响应时间，如果产品运行不正常应该怎么办。
  10. 整合集成要求（如果需要）。
  11. 测试计划：给在设备、浏览器、操作系统、测试用例/用户故事方面测试给出指导。
  12. 发布计划：发布整个还是部分？在什么时间发布？要不要做A/B Testing？是不是要做Dry Run？如果产品发布后出问题，在出了什么样的问题、在什么样的阶段需要把产品拿下线？ ……
PRD需注意的事项：
1. 避免定义产品的做法，以便界面设计师和工程师利用他们的专业知识为需求提供最佳解决方案。
2. 灵活性：文档长短及包括的章节以沟通效率为主要目标。
“PRD的内容有自己的灵活性，文档最主要的目的还是为了达到沟通的效果。”
——Lake
III Workflow 产品流程图
产品流程图用来显示解决方案的步骤，关联的决策标准和最终的输出。
如果产品包括几个简单的页面，用户需要在它们之间做不同决策的时候，使用产品流程图很有效。并且，拿这种图很方便跟程序员沟通。
椭圆形代表起始点；菱形是决策点；长方形代表中间的环节（例图中，决策点后缺少Yes/No）
IV Wireframe 线框图
Wireframe也称为页面原理图或屏幕蓝图，是一个视觉指南，代表网站或应用程序的骨架框架。
Wireframe的图片示例
线框图制作上并不容易，所以可以手绘
V User Story 用户故事
Ø  用户故事是Agile Development的环节之一
Ø  从产品经理角度撰写需求转移到从用户角度谈论需求
Ø  每个用户故事包括一到两句话
Ø  是一系列关于所需功能的对话
模板：
As a <type of user>, I want <to achieve a specific goal> so that <specific reason or motivation>
(我是？，我想？，因为？)
举例：OpenTable的用户故事模板
PRD与用户故事可以共用，因为如果只关注用户故事，无法提炼出一个产品成功的标准。
——Lake
VI Integration Document 产品整合文档
文档内容及形式取决于读者——内部或者外部、业务或者技术团队。个性化非常鲜明。
内容举例：
－ 总结摘要：包括用户、产品、解决的问题
－ 需求背景
－ 目标和假设
－ 整合步骤
－ 测试内容及流程
－ 客户支持流程与联系方式
VIII Product Description 产品说明书
服务群体：销售人员。用于向客户介绍公司有几种产品，哪种产品更适用于他/她。
嘉宾分享
沈思维曾经就读卡耐基梅隆大学，毕业后加入谷歌，任开发工程师，后加入Twitter 任高级研发经理，现为Lyft 的技术总监，专注于风控领域，在反欺诈反垃圾信息方向有非常丰富的经验。
1.您是从工程师一路做到技术总监的，请问在决策转换的过程中，您对产品团队中不同角色的理解发生了那些变化？您是怎样培养对管理和激励团队的能力的？
我做过的三家公司在团队管理上比较相同，硅谷近十年形成了一套比较规范的管理方法。一个团队的领导小组可能有三个角色，研发经理、产品经理和技术负责人。这里说的是三个不同的职责，不是说有三个不同的人。
2.开发人员和产品经理的合作流程是怎样的？产品经理的什么行为你不能接受？
有PRD、Roadmap各种文档在帮助信息传递，整个流程从市场调研、了解商业价值到确定用户故事，再到初版的MVP（minimum viable product）——什么时候发布、做什么功能等，每一步都需要产品经理和研发团队有非常紧密的联系。以前，许多公司靠功分组，现在，组织架构把产品设计和技术人员都放在一个组，这就证明产品和技术的交流变多了。
从我的角度出发，我希望产品经理能信赖这个技术团队。在做PRD或者研发的时候，及早的将不同人员参与进来，这样可以在后期极大地降低沟通障碍。另外，沟通一定是要有连续性的。除了及时沟通之外，还要在长远和短期的计划中做一些技术上的平衡，这是产品经理给技术团队带来的最大贡献之一。
3.个人观点分享：
1）自己做技术管理并不是自己一定能做到技术最强，同样的，能让团队、让别人变成最强的
产品经理很可能做出一个很好的产品。不过再资深的产品经理也很难很好地管理人，这并不意味着他不是一个好的产品经理。
2）关于产品路线图（Roadmap），我觉得Lyft有个挺好的方法。它在做产品流程图的时候，提出了一个概念叫 living roadmap。这个Living Roadmap 是一个文件，它永远在那，没有具体的细节。所有的人，无论做产品的、市场的等等，都有权限进入这个文档，任何部门的需求变化都能在Living Roadmap在第一时间体现出来，这就使得在任何阶段都有可能发生改变的需求高度一致。这样做也对管理有好处。不过如果有些东西解决不了还是需要面对面交流。
喜欢这堂产品经理课？这里是前三课的传送门哦：
产品经理究竟是怎样的存在？| Lake硅谷产品管理课程第1课
如何寻找用户痛点，发掘产品需求？| Lake硅谷产品管理课程第2课
如何设计一款让人爱不释手的产品？| Lake硅谷产品管理课程第3课
关注硅谷密探
紧盯全球创新趋势
（长按上方二维码即可关注，神马，这居然是二维码！）
继续阅读
阅读原文