产品需求文档撰写和讲解那些事儿

说说产品需求文档撰写和讲解那些事儿。

一、需求文档撰写：

大部分产品经理可能没有注意到，自己写的产品需求文档像一坨屎，十分杂乱，关键信息不突出，分类不清晰。怪不得程序员拒绝看文档。产品经理要把自己的产品需求文档看作一个产品，每次交付产品需求文档时，要想着自己的文档也是产品，如果做，别人才能用，并且用的爽。然而大部分产品经历可能只记着自己所负责的产品是否有人用，却忘记了自己交付的产品“需求文档”有没有人看，程序员们是否会用，是否用着爽。

还有一个点就是，特别是产品新人，写需求一定要想好产品的价值，每个功能点的取舍与权衡，避免别人问起时，答不上来，如果提前思考过做好应对，说出自己的考虑。不说体现自己专业性，至少不会被怼和鄙视吧。

二、需求讲解：

在讲解需求时，也要讲究技巧。

2.1提前沟通产品方案：

虽然产品需求文档是要在产品需求评审会上要评审的，但是如果可以提前与各个参与方能在线下提前沟通一下，会有以下两个好处，评审效率提高和产品方案被怼。

因为有了线下沟通，不确定有争论的地方，在线下就已经解决了，会议上也就没有了争议点，会议效率也就提高了。如果有争议的地方都已经提前沟通清楚和解决，那么也就不会出现产品经理轮番被技术、测试和运营等各方怼的机会了。

2.2从大到小：

先从大的框架说起，再是功能细节，而不是一上来，就深入细节，特别是别人不了解背景的情况下，技术很容就会懵，不知所云。

2.3先讲背景和价值，后讲产品功能：

对方了解了背景和对产品有整体了解后，在深入了解细节就比较清楚了，尤其是对方第一次接触和了解需求时。

先大后小，先背景和价值后讲产品功能的好处就是，别人对要说的东西有了一个整体的认知，心里有了一个框架，后面再讲细节时，就很容易理解了，主要原因在于，人都是对结构化的信息很容易吸收，对杂乱无章的信息不容易理解和记忆。

2.4讲对方需要做的和关心的

最后一点就是，特别是各个部门合作时，要有针对性的讲解，讲对方要做的以及对方关心的，相关性不太强的一笔带过即可。别人没有那么多时间去关注。