说说产品需求文档撰写和讲解那些事儿。
一、需求文档撰写:
大部分产品经理可能没有注意到,自己写的产品需求文档像一坨屎,十分杂乱,关键信息不突出,分类不清晰。怪不得程序员拒绝看文档。产品经理要把自己的产品需求文档看作一个产品,每次交付产品需求文档时,要想着自己的文档也是产品,如果做,别人才能用,并且用的爽。然而大部分产品经历可能只记着自己所负责的产品是否有人用,却忘记了自己交付的产品“需求文档”有没有人看,程序员们是否会用,是否用着爽。
还有一个点就是,特别是产品新人,写需求一定要想好产品的价值,每个功能点的取舍与权衡,避免别人问起时,答不上来,如果提前思考过做好应对,说出自己的考虑。不说体现自己专业性,至少不会被怼和鄙视吧。
二、需求讲解:
在讲解需求时,也要讲究技巧。
2.1提前沟通产品方案:
虽然产品需求文档是要在产品需求评审会上要评审的,但是如果可以提前与各个参与方能在线下提前沟通一下,会有以下两个好处,评审效率提高和产品方案被怼。
因为有了线下沟通,不确定有争论的地方,在线下就已经解决了,会议上也就没有了争议点,会议效率也就提高了。如果有争议的地方都已经提前沟通清楚和解决,那么也就不会出现产品经理轮番被技术、测试和运营等各方怼的机会了。
2.2从大到小:
先从大的框架说起,再是功能细节,而不是一上来,就深入细节,特别是别人不了解背景的情况下,技术很容就会懵,不知所云。
2.3先讲背景和价值,后讲产品功能:
对方了解了背景和对产品有整体了解后,在深入了解细节就比较清楚了,尤其是对方第一次接触和了解需求时。
先大后小,先背景和价值后讲产品功能的好处就是,别人对要说的东西有了一个整体的认知,心里有了一个框架,后面再讲细节时,就很容易理解了,主要原因在于,人都是对结构化的信息很容易吸收,对杂乱无章的信息不容易理解和记忆。
2.4讲对方需要做的和关心的
最后一点就是,特别是各个部门合作时,要有针对性的讲解,讲对方要做的以及对方关心的,相关性不太强的一笔带过即可。别人没有那么多时间去关注。
领取专属 10元无门槛券
私享最新 技术干货