产品入行半年了，大大小小的坑遇到不少，这些血泪经验是最宝贵的财富，一直告诫自己，要常总结、常反思，希望n年之后，再看到今天写下的这些东西，能有更多的感悟。今天主要说的是PRD中遇到的那些大大小小的坑，不一定适用全部情况，欢迎各位纠错，欢迎各前辈指导！
最近半年， 最主要的工作就是写PRD，PRD的重要性不言而喻。
在产品的整个开发流程中，PRD的作用有以下几个方面：
1、PRD指导其他部门进行工作的准备工作
测试根据PRD写测试用例；开发经理根据PRD写开发文档；UI根据PRD和原型设计。
2、PRD承担字典的工作
测试人员可能更多的是根据测试用例工作，而开发看的更多的是开发文档。但当大家发现某个细节在测试用例或者开发文档描述不清楚或者难以理解时，就会翻出PRD查找相关内容。PRD在这个时候是承担了一个字典的功能。
3、PRD是打架必备。
测试和开发的天然属性决定了他们之间微妙的关系，很多时候bug的定义是似是而非的，很多时候涉及到用户体验的问题，而用户体验有带有很大的个人主观性，此时矛盾就出现了。当测试和开发就某个问题争论的面红耳赤，几乎要干架时，最后一句压场的话就是”别瞎bb，看PRD！“，此时要是PRD上有关于此问题的详细描述，那开发要么找产品经理改需求，要么只能自己改代码了。要是PRD上没有相关内容，那开发就可以傲娇的说”需求就是这么写的，你要改，先去找产品改文档！“。所以一般来说，测试是希望PRD写的越详细越好，这样他们的bug才提的有理有据，而开发希望提出的需求能够逻辑严密，但不太希望产品经理将所有的细节都规定死，毕竟产品对于技术的了解并不深。所以产品要注意把握好度，这点我自己还在不断的思考之中。
貌似现在也有很多公司不需要产品人员写PRD，但我觉得PRD应该是产品人的必备技能，他可以不要求你写，但你不能不会。作为一个新手，特别是一个没有技术基础的新手，写PRD时，是一个很好的梳理思维的过程。
刚开始写PRD的时候，不知道有些功能可以整合在一起说明，每次都罗里吧嗦的全部重新说一遍。比如，分享功能，应用里很多地方都涉及到了，每一次涉及分享，我都会把分享的机制从头到尾说一遍，其实这就很\0嗦，文档的文字本来就够多了。所以，建议将一些在软件里反复涉及的功能提炼出来统一说明，当后续涉及到的时候，简单阐述一下就行，不用再重头说一遍。
微信扫码上方二维码，可领取2025年最新互联网创业项目！
项目收款截图
