上一篇从收到一个需求谈起 我们主要介绍了收到需求之后应该怎么和需求方沟通，这一篇将介绍具体怎么分析这个需求。

产品经理收到需求之后，切记不要急着开始画原型图，深入分析思考是第一步。磨刀不误砍柴工，全面得思考可以让后续的步骤走得越来越稳、越来越快。

首先，要判断这个需求是某个产品的一个功能，还是一个相对独立的产品。如果是某个产品的一个功能，则这个需求相对较小，需要考虑怎么兼容产品现有的功能。如果是一个相对独立的产品，那么恭喜你，轮到你上场表演了，撸起袖子准备干吧。

针对上文早报的需求，很明显，是一个相对独立、功能完整的产品，姑且称之为「简报生成器」。

这个产品定位可以简单总结为：生成用户想要的简报。

那这种类型的产品应该怎么做需求分析呢？

1. 这个产品的用户是谁？用户有什么特点？

你是不是和刚入行的我一样以为回答这个问题，需要做大量的用户调研、用户访谈，然后还得画一个高大上的用户画像（persona）。当然掌握用户调研、用户访谈、用户画像的技能也是 okay 的，但是大多数情况下，公司不会给你太多资源、太多时间去做这件事，你只能自己想办法。

同时，调研 100 个用户和调研 10 个用户带来的结果可能相差不大，前提是你找到了「对的人」，而不只是寻求调研的用户数量。

在早报这件事情上，因为我本身就是资深用户。所以，就「凭经验」简单分析下，早报的用户群体分为两种：

1. 一帮因为工作而整日奔波在各个公司用户社群的社区运营或运营实习生；
2. 一帮管理兴趣爱好组和其它学习小组的兼职（义务）运营。

那这帮用户有什么特点呢？

不同点：

• 做事目的不同。第一类用户是出于工作的目的，期望高效得完成工作任务。第二类用户是出于兴趣，期望获得群体的认同感，位于马斯洛需求层次的较高级别「尊重的需要」。
• 早报格式要求不同。第一类用户要求的早报格式相对比较正式，第二类用户要求的早报格式可能偏向活波。

相同点：早报的内容素材（比如：AI 产品早报、黄金每日行情等）都是相似的，不会有较大变动。

2. 这个产品满足了用户什么需求？解决了用户什么问题？

最好能用一句话回答这个问题。为什么？因为面试官喜欢这么问。

这个产品满足了用户快速生成每日自定义早报内容的需求，节省了用户整理早报的时间，提高了输出每日早报的效率。

3. 用户在什么情况下有这个需求？不同场景下的需求是一样的吗？

「简报生成器」的使用场景：用户需要在自己管理（运营）的社群里发送早报 / 午报 / 晚报的时候，才需要用到这个产品。相对来说，这个需求是一个很低频的工具类需求，而且不同场景下的需求是一样的。

插句题外话，你认为用户是不是每天必须要打开「简报生成器」，才能完成自己的任务？

如果这个产品是一个商业产品，面临生存和盈利的压力，那作为产品经理的你是需要仔细考虑一下这个问题。不过，作为用户，效率是第一位的，能在不打开这个产品的情况下达到自己的目的当然是最好的了。

很多时候，尽可能高效得满足用户的需求和尽可能多得创造商业价值之间是存在冲突的，具体怎么权衡就要依情况而定。如果你运气很好，遇到一个不在乎 KPI 只在乎产品质量的老板和公司，那么你真的是烧了高香了。

4. 现在没有这个产品，用户是怎么做的呢？现在的解决问题有没有什么问题？

现在没有「简报生成器」，用户都是手动保存简报格式，修改日期等信息，然后手动复制各大新闻网站的新闻标题到预定的简报格式中，最后将整理好的简报发送至各大社群。

现在的解决方案主要问题是重复性工作比较多，比较浪费用户的时间。复制格式、复制标题、复制标题、复制标题…转发到对应的社群，其它没有什么问题。

5. 你有没有比现在的解决方案更好的方案？

嗯，是的，你没看错，答案肯定是有的。比如：复制标题的那部分，机器（爬虫）完全可以替代人工，这一步的简化已经可以节省 90% 的工作量了。

那还有没有更好的解决方案？

比如：设置一次，终生免费的那种。咳咳…不要跑偏，我说的是设置一次，然后就可以静静地当个读者那种，当然是有的了～

「简报生成器」将自动生成用户期望的早报内容，并可以自动发送至用户。最终用户只需要复制转发到各大社群即可。如下图，红色圈出来的部分是用户需要完成的步骤，其余步骤均可通过产品实现。当然，前提是提前设置好早报格式。

有的时候，你辛辛苦苦整理了很久的用户反馈，做了很久的需求分析。但最后，却找不到比当前解决方案更好的方案。这种事情也是会经常有的，可能是技术不够成熟，也可能是资源不够，也可能老板觉得有更重要的事情要做。产品经理就是一个看似很厉害，但实际上权力还不够大的虚名「经理」。当然，这并不影响产品经理改变世界。

到这里，我们就完成了从用户需求到初步的产品解决方案的形成，也就是需求分析的部分，下一步我们将初步的产品解决方案变成具体的产品功能列表。

总结

（1）需求分析究竟分析些什么？

• 用户：产品的用户是谁（有几类）？有什么特点？
• 场景：用户会在什么情况下有这个需求（对我们的产品感兴趣）？不同场景的需求一样吗？
• 需求：产品满足了用户什么需求？解决了用户什么问题？
• 当前解决方案：现在没有这个产品，用户是怎么做的呢（当前解决方案是什么）？现在的解决问题有没有什么问题？
• 产品解决方案：你有没有比现在的解决方案更好的方案？

（2）怎样做一次让领导满意的需求分析？

把事情说清楚。找一个不懂业务、不懂逻辑的人看看，看他能不能看懂。当然，不一定适用。很多时候，很多人就是为了分析得高大上、分析得让别人读不懂，方才显示自己的牛逼。

比需求方想得更远。以「简报生成器」为例：这个产品的用户是发早报的人，但最终消费「简报生成器」生成的内容的却是读者，如果你能在满足用户需求的前提下让最终的读者满意，那么用户又有什么理由拒绝你的产品呢？

（3）如果别人质疑你的分析结果？

首先，不要怕被挑战，不要怕被质疑。产品经理在日常工作中很容易被挑战，大到老板、领导，小到团队的 UI、研发、测试，所有人都有充分的理由挑战你。试想如果你的分析结果和所有人想得都一样，那还有谁会质疑你。被质疑恰恰说明你想到了别人没有想到的点。

其次，产品这个东西本身主观性比较大，你觉得这个产品很烂，但有可能你的领导就会觉得这个产品很好。不是说领导品味有问题，只是每个人思考问题、看待问题的方式不同。当别人质疑你时，大胆说出你的思考过程就好。

（4）接下来要做什么？

将产品解决方案落地为具体的产品功能。

好的，今天这篇文章到这里就结束了，我们的《一个项目带你走进产品经理的世界》系列文章完成进度如下：黄色为当前进度。

相关阅读

一个项目带你走进产品经理的世界（1）：从收到一个需求谈起

作者：左耳，微信公众号：产品碎月

本文由 @左耳 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议