7 个回答
敏捷开发的PRD自然应该符合敏捷开发的需求。
首先产品经理需要有敏捷开发的意识，将大需求拆成一个一个小的需求安排到每一个版本的迭代中，以适应快速迭代。
在敏捷宣言遵循的原则中明确说到：“不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。”
在敏捷开发中， PRD应该是与同事充分讨论后的记录文档，应该是一种补充。
压力山大……
交互+说明+标签吧
不过这种开发模式，一定要让整个开发团队加入到项目初期的建设中，有关于为什么要做这个，怎么做这个，这个做给谁用，一般什么时候用，用了又有啥用，对咱又有什么好处……等一系列问题最好在初期建设中尽量让开发团队就了解。在实际开发的时候，如果原型的交互、说明已经标签足够ok，还是能够避免不少问题。
so，粗略聊聊问题。其一在于，pm自己要对自己的业务非常清晰了解，业务流程啊逻辑啊什么的，应当是用工具模拟过N次的。其二，每一次思维的迭代需要找个地方记录下来，有据可循，其实长篇大论的PRD也会出现类似问题，前者的风险在于无迹可寻，后者的风险在于要从一堆内容里去找所谓的迹。其三，就是最大的问题了，一般来说，没有详细的PRDor业务说明文档，团队里一旦有人员更迭，真是苦啊……新加入团队的哥们几乎都会一脸懵逼.jpg，这个鬼团队在开发什么鬼？尤其是，pm自己离职orLeader离职，简直爆炸……
所以，敏捷归敏捷，该写的不省，能写的就找业务和沟通之余的时间补一补吧。
强烈反对上面几个人的说法，敏捷开发不是让你少写或不写文档了。PRD该怎么写就怎么写，一个PRD一天就能出了，你是多快的敏捷开发连个写PRD的时间都没有？实在没有PRD，原型图总有吧
文档还是必要的，只不过文档详细到什么程度要视团队而定。在敏捷或者题主所说的小步快跑模式中，可以用产品原型代替PRD文档，注意产品原型应包括但不限于如下信息：
1. 变更记录：用来记录每次修改的内容；
2. 版本说明：记录每次迭代的更新说明；
3.产品的信息架构：直观的反应产品层次机构；
4.流程图：用来说明业务逻辑；
5.交互说明：可以采用注释的方式，清晰的标识页面之间的跳转等信息即可；
6. 状态信息：某些控件，数据，文本等的一些状态。
7. 操作反馈：交互的跳转，用户操作的提示信息等等；
欢迎补充。