PRD对于产品人员而言，就像开发文档对于开发人员、测试用例之于测试人员。
但PRD又有些不一样，产品的PRD需要给业务人员、内部产品人员、开发人员、测试人员阅读。所以PRD不仅要详细，同时还要对开发、测试等非产品岗的人员友好，让他们便于阅读。
对于产品人员来说，我们的期望开发能够认真阅读PRD的原型、批注部分，了解页面和逻辑，开发出来的产品能够达到我们预想的效果；同时期望测试在了解PRD原型和逻辑的基础上能够了解功能的变化，是全新的功能还是复用以前的逻辑，顺利进行测试。
此外，产品把PRD写的详细且易于阅读，有一个非常直观的好处：在项目进行时，开发、测试来找你询问的次数越少，在开发的过程中，PRD在后期的改动越少，整个项目进行的会更顺利。
所以产品人员在写PRD时，要记住两个要点：1、尽可能写详细 2、易于开发、测试人员阅读
对于把PRD写详细这一点，我总结出一个重点“用测试思维写PRD”。
这个观点是我从测试用例和测试工作上反推出来的。测试人员在写测试用例的时候，会对PRD进行非常详细的解构。大到业务的逻辑，小到一个按钮的各种特殊情况，都是他们需要进行测试的。产品可以借鉴这个思维来写PRD。
1、阅读测试用例
新手产品可以向测试要一份测试用例，仔细研读。看看测试用例中的分析。这样在写PRD的时候，也能够大概清楚测试会关注哪些细节。你写的PRD也就越对测试的胃口。到时候测试找你确认的问题越少。