本文作者Gaurav Oberoi 是 SurveyMonkey 的前联合创始人，曾于 Amazon、Xmarks 就职，在硅谷有十余年工作经验，负责过多款数百万以上用户量的产品。

全文由刘涵宇翻译，译者为FellowPlus 产品负责人，个人关注产品设计、效率工具和投融资行业，微信公众号“不安静的书桌”，欢迎关注交流。

温馨提示：本文为万字干货文，全部读完约需要15分钟。

写在前面的话：

产品经理在一家互联网公司往往掌管着所有的需求，需要沟通的对象也包括了设计、开发、测试、运营等角色。所以，一名产品经理需要处理和面对的信息量常常是巨大的，也因此往往会面临到沟通低效、产品开发进度和质量不可控等等问题。

这时候，最好的解决方案，其实是一份清晰高效的产品文档。可惜，大部分产品经理对于“文档”的价值和意义认知都是不够的。

在本文中，作者Gaurav Oberoi分享了他对于产品文档的看法以及撰写产品文档的常用流程。此外，本文还含有一份真正完整的产品文档示例，以及详细的产品文档写作指南（包括格式+思路），希望对你有所帮助。

以下是正文

很多人听到「产品文档」这四个字就像吞了苍蝇一样，人们通常会认为这意味着又要花几周写一个根本没人看的文档。如果一个团队总被产品文档这种事情拖累，怎么可能「敏捷」得起来，怎么可能高效地产出代码？

　　我在过去十几年创造了多个数百万人使用的软件产品之后，越发认为这种观点是完全错误的。根据我的经验：

　　高效的产品文档是创造伟大产品的过程中所不可或缺的重要组成部分。撰写产品文档可以强制所有人从项目初始就理性思考，频繁沟通，明确权责——所有的这些都会带来更好的软件质量，更低的进度风险，以及更少的时间浪费。

　　在这篇文章中，我会通过一个案例来分享一些普适的建议，这些建议会对产品经理，尤其是大中型（超过二百人的）公司中的产品经理们非常有帮助。

　　首先，让我们来看个例子

　　假设你需要解决这么一个问题：

　　一家从事在线旅游预订服务（就像 Hotels 或者 Airbnb 但是规模更小一些）的公司。目前这家公司的支付转化率偏低，所以这个季度大家打算尝试通过在支付环节加入在线客服的方案来提升转化。

　　你的计划是：

　　通过在支付环节增加在线客服来尝试提高支付转化率。

　　支付转化率目前仅有 18％，而业内平均转化率有 30％。我们打算测试下在支付时展示在线客服聊天窗口是否可以提高这个转化率。用户运营团队已经同意了提供1人月的客服人力支持。

　　在你没有产品文档时，你会这样做：

　　比方说，你觉得行动起来总是最重要的，因此直接开始动手：

　　1. 在迭代计划会上，你和团队讨论了这个需求；

　　2. 然后你挑选了一个靠谱的第三方客服供应商（例如 SnapEngage ）；

　　3. 提交一个工单来让工程师添加一些 Java 代码；

　　4. 和支持团队开个会，确定他们都准备好了。

　　搞定了！这么简单的事情怎么能要我们写产品文档呢？

　　那么现在问题来了：

　　如果你是在一个小型创业团队，你也确实可能并不需要一份产品文档——因为产品改动相对小，涉及到的人也相对更少。

　　但如果你是在一个更大的组织之中，或者产品更加成熟/复杂，就会陆续出现下列这些问题，并且相比写文档，这些问题会需要更多时间来处理。例如：

工程师把工单标记完成了，但是一验收测试，就发现这个功能完全没有考虑移动端的适配。（唉呀！你忘了提醒大家手机端的使用才是核心场景。）

用户运营经理打算开展一个漫长的评审流程，以确定最合适的聊天服务商。（啊……需要定一个会议，向大家解释下这次上线只是一个灰度测试。）

发布一小时后，客服报告说他们收到了西班牙语的在线聊天请求。（啥？要追加一个紧急发布，把这个测试限定在英语用户中。）

(责任编辑：本港台直播)