敏捷开发，并不意味着产品经理在写PRD的时候可以偷工减料，相反，这更考验产品经理的功力，因为产品经理需要精简信息，将真正的有效信息简单且清晰地传达给PRD阅读者，从而真正达到敏捷开发的目的。
　　敏捷开发这个词越来越为大家所熟知了。简单来说，敏捷开发是以用户需求为导向，通过快速开发将产品投入市场，获取市场反馈，从而快速迭代、优化升级、循序渐进的开发方法。
　　我们不去片面评价敏捷开发的好坏，毕竟事物都具有两面性，任何事物都有各自的优劣。但在创业团队建立的前期，在产品还处于一个idea状态、开发人员并不多的场景下，敏捷开发还有具有一定的优势的。
　　敏捷开发，其中一个重要原则是“多沟通，尽量减少文档”。因此，敏捷开发中，产品经理在撰写PRD时，应该尽量做到精简。注意，此处用词是“精简”，而非“简化”。那么，撰写一份精简的PRD，产品经理具体要怎么做呢？
　　1、直接将PRD在原型上标注
　　如今，越来越多的产品经理已经摒弃了word冗长的产品需求文档，直接在产品原型上通过备注的形式来说明需求和描述功能点（造成这个现象的原因很大程度上是由于PRD的重要用户——程序员更偏向于直接看着原型进行开发，经常直接忽略word格式的PRD）。那么，遵循敏捷开发的“尽量减少文档”原则，在形式上，我们更提倡直接将产品需求文档内容标注在原型图上。我想，这对于PM和RD都是一种减少工作量的好方式。当然，前提是你的PRD需求完整且逻辑清晰。
　　2、产品全局结构图和重要流程的图示不可省略
　　再精简的PRD仍旧不可或缺结构图和流程图。
　　首先，全局结构图，作为整个PRD的骨架，可以让PRD阅读者对产品的总体功能构成一目了然，这样在接下来继续阅读每个部分的原型图和对应的说明文档时，思路能够更加清晰。像每本书都会有目录一样，目录是让你快了解这本书大概的内容的捷径。
　　其次，一些基础功能的流程图（如登录注册之类），我们是可以有选择性地不将其呈现在PRD里的；而那些实现重要业务需求的功能流程，我们还是必须将其用流程图清晰展示出来的。这样即使在需求会议后，程序员对某个流程比较模糊了，也可以翻一翻PRD来确认。
　　所以，重要功能的流程图，可以说是一份PRD的灵魂，是千万不可以省略的（为了避免全是文字，产生视觉疲劳，以用户端的优惠券功能为例，特附优惠券总体结构图和优惠券功能下的一个流程图）。


　　3、重要名词需要有清晰简洁的定义
　　并不是每个名词都需要写解释、下定义！
　　我记得刚入行时，第一次写产品说明文档，我甚至还写了“用户”二字的定义。当时的PRD是直接参照公司产品前辈的，他之前写了“用户”的名词解释，于是我也照抄了过来。

　　现在想想觉得略为搞笑。因为这个词的定义在APP 1.0版本的时候已经确认过了。而且，这个名词应该属于比较容易理解、不容易产生歧义的范畴。所以我相信，像类似这样的词的解释，对于PRD阅读者来说是一个无用信息。
　　好吧。说正事。那么什么时候你需要写名词解释呢？什么词才是重要的词呢？
　　这个名词在产品设计中第一次出现且是业务需求的重点
　　例如，当你在设计优惠券功能时，那么“优惠券”这个名词是一个重要名词。可能大家会说：“不对啊，优惠券不是很好理解吗？需要名词解释吗？”我可以明确告诉你，在这个场景下，需要！这是我之前在一家O2O公司工作时，曾写过的定义：“优惠券是指由xxx平台发行的，用户使用XXX APP 结账时，用于抵扣订单金额的电子券”。这个定义指出了几点关键信息，一优惠券的发行方，仅仅可以使平台，不能是平台的商家；二使用场景是用户在结账时；三作用是抵扣订单金额；四优惠券非实体券，是电子券。
　　容易混淆的名词
　　让我们再来举个例子。比如，“连锁店”这个词已经在之前的设计中出现过，也解释过了。但是在你当前的产品设计中，有了一个“商户组”的概念。乍看之下，真的会让人云里雾里，有点懵。光从字面理解，好像都是指代一组商户，具体的区别并不是那么清楚。那么这个时候，你需要将两个概念好放在同一个页面中以对比的方式解释清楚，以免造成程序员的大脑短路。