产品经理的工作目的就是为了讲好一个故事，让听者信服，如果故事没有说好，就容易变成事故。

对于产品经理而言，我们需要向不同角色的人讲述一个需求，可能是老板，可能是研发，可能是运营，也可能是你的投资人， 在沟通中，你有没有这样的经历：为什么对方就是不明白“这么简单的一件事情”？这头你急得直跺脚，那头听你说话的人依旧是一头雾水。

比如你如何去叙述“分享到朋友圈”这个功能呢？你会怎么描述这个需求呢？是不是需要一个分享功能，让用户分享到朋友圈吗？当我们看到某篇文章时，非常喜欢这篇文章，希望把有帮助或者有趣的信息推荐给朋友。但是，如果这需要我们很费力地复制粘贴，那么大家可能就不愿意这么做了，因为实在太麻烦了，当朋友看到一长篇密密麻麻的文字时，也会疑问，发的是什么东西。这样的话，我们需要一个分享功能，能够直接非常简单地将某篇文章传递给朋友，并且他们看到的，和我们看到的是一样的。

所以，分享至朋友圈，并不是一个需求，而是两个。①分享出去②能够在外部被访问。

很多时候，我们沟通不顺畅的原因，不是因为不明白做什么，而是不明白为什么要做，怎么做。在产品里，基本不存在完全独立的功能，每一个功能之间必然会和其他的功能产生呼应，这一点会直接反映到我们的需求里。对于分享而言，研发并不是不知道如何做分享，而是不知道，为什么做，在哪里做，怎么做？互联网团队里，每一个人都是具备创造性思维的，不仅仅是产品而已，切勿将研发或者其他环节的角色定义为执行机器。

一个完整的需求故事，会遵循一些原则：

除了必要的描述，尽量避免多余的叙述，这会干扰大家的思绪，产生不必要的争论。避免不确定的词汇，比如，可能，也许，这会让他人感觉这个需求是不确定的。故事完整，这是避免需求衍生的核心点，如果无法对你的需求故事进行提问，这就是最好的故事了。一个完整的故事，是指听故事的人，能够从头看到尾，而不产生疑问，似乎一切就如故事里讲述的那样，顺理成章。

user： 故事的主人公是谁

scene： 故事的背景是什么

want： 他想要什么

defect: 现在有什么缺陷

action: 他需要做的行为

我们再来看看，关于分享至朋友圈的需求故事：

user：我们

scene：当我们看到某篇文章时，非常喜欢这篇文章，

want：希望把有帮助或者有趣的信息推荐给朋友，传递给自己的朋友。

defect：如果这需要我们很费力地复制粘贴，那么大家可能就不愿意这么做了，因为实在太麻烦了，朋友在看到一长篇密密麻麻的文字时，也会疑问，发的是什么东西。

action：我们需要一个分享功能，能够直接非常简单地将某篇文章传递给朋友，并且他们看到的，和我们看到的是一样的。

产品经理还会经常遇见这样的场景：对方会不断的向你提问，目的在于索要更全面的信息，而这个过程中，我们会展开原本不必要的争论。避免这个情况的办法只有一个，完整的向对方描述一个故事，让沟通能够基于故事本身而展开，而不这是一个很小的需求沟通技巧，但却不仅仅是被应用在这样的场合里，通过设计需求故事，也能让我们更清晰用户想要的是什么。

很多产品经理在做需求分析这一步时，由于没有一套合理的知识结构，导致很多时候需求分析变成了空想问题，从下面2步入手，让你的需求分析时更加专业化。

一、收集需求

1.无针对性的用户访谈

一般来说，特定的用户是主要需求的提出者，而产品设计是为特定用户服务，在这种情况下，我们有机会与特定用户进行深度的沟通。如果特定用户不止一个，一定要区分“最终拍板的用户”和“产品的直接用户”。通过区分用户身份，理清楚用户需求和产品需求。

明确用户想要什么，而不是用户想做成什么。

用户想要什么，是用户的原始需求；而用户想做成什么，是用户将原始需求经过自己的理解得到的需求。所以，在你提出一个问题的时候，不妨再加上一个为什么，往往会起到意想不到的效果。

使用通俗的语言，避免专业词语

如今社会，每个人都对互联网有不同程度的了解，作为用户你无法预估他的专业程度。在访谈过程中，产品经理要尽量用通俗、严谨的语言去谈话而不是一堆专业词语去显示自己的专业度。一旦用户的理解有偏差，你收集的需求将会把你引向歧路。

2.头脑风暴

头脑风暴是比较常见的需求收集方式，作为产品经理，你更多的起到监督和控制的作用。

第一，确保会议围绕你提出的话题展开，而不是漫无边际地聊天。

第二，不要对任何一个人员提出的话题进行评价或者议论。

最后，控制时间、控制时间、控制时间。

3.用户反馈

用户反馈分为主动反馈与被动反馈两种。

用户在客服、官方微博、QQ群、贴吧、论坛、留言板、投诉等场合提出的意见都可以算是主动反馈；而调查问卷、有针对的用户访谈、用户回访等方式是被动反馈。

一般来说，主动反馈属于更紧急需求，被动反馈属于重要需求，并可以以此来定义优先级。

4.内部需求（领导、运营、运维、客服）

一般来说，产品经理是对产品结构、流程最熟悉的人，面对内部需求，你需要做的是明确需求提出的目的，并提供解决方案。

5.数据分析反馈

数据是客观反映产品的重要指数，也是收集需求的重要来源，前期是收集的数据是可靠、客观的。数据是零散的，在进行数据分析前一定要有明确的中心，划定一个界限，收集同一个框架内的数据。单独的数据是死的，有对比的数据才有意义。为了避免主观意识的影响，同一份数据参考其他人员的分析结果。

二、处理需求

处理需求的阶段，也是产品经理将需求进行筛选，梳理业务流程，设计产品架构的阶段。

1.需求筛选、分类

尽管我们保持严谨的态度收集大量的需求，其中还是有很多需求是“伪需求”，甚至是不合理的，我们第一步就需要将这些需求进行“清洗”，择优去重、去伪存真。

2.竞品分析

由于在这个阶段，产品经理不仅要定义目标用户、产品使用场景，还要确定核心功能，产品流程等等，因此通过竞品来辅助处理需求是一种很有效的方法。通过相似竞品的用户定位、功能反推竞品的需求，与自己的需求进行对比；将自己的需求代入竞品中，看流程是否符合逻辑；与竞品进行对比，分析需求的异同。

3.设置优先级

一般来说，从需求类型来看，基本型需求>期望型需求>兴奋型需求；

从需求来源来看，战略性需求（领导提出）>功能性需求（核心功能）>业务性需求（拉活、存留）>体验性需求（提升用户体验）。做好最常用的是用四象限法则去评定优先级，另外可以使用RICE评定方法，KANO模型等。

4.需求评审

在这个阶段之前，作为产品经理对于产品应该有了一个完整的模型，但仅仅是理论上的模型，确保UI、UE、前端开发、后台开发、测试参与，从产品开发流程的各个角度对需求进行拆解、分析。需求评审可以看做是产品开发的初始化或者预开发。

迈向一名合格产品经理的第一步，就是说好需求故事。一款产品能否走得远、走得好，关键就是这点是否做了足够充分、足够深入的准备。