根据需求的类型，你面临的需求可能来自以下几个方面，本文从五个部分讲述了需求从产生到上线的过程。

产品的第一优先级永远是有用。 一个好的产品是能解决问题的，也就是我们常说的需求。是需求决定了流程和页面，流程和页面决定了交互。

而对于一些刚入门的产品经理，通常上来就会沉浸在页面实现中，而没有理清楚需求，本末倒置。还有一些产品经理，是面向老板设计产品，老板说我要这个我要那个，就忙不及的去按照老板的想法做，而不顾自己手中所有的开发资源和用户端的需求。

这样做出来的产品往往是没有人会使用的。 产品在日常的工作中所有的核心都是围绕需求展开的，而需求往往来自于各个方面，一个好的产品应该是各个方面需求综合作用的产物。

根据需求的类型，你面临的需求可能来自以下几个方面，本文从五个部分讲述了需求从产生到上线的过程。

A 战略层需求（一般来自老板）

一个公司的方向性需求，一般不是产品经理所能决策的，这个层面的需求一般来自于决策层。老板一般会根据自己拥有的资源优势，以及对市场的分析，决定产品的战略方向。

比如为什么微信是做熟人社交，陌陌是做陌生人社交，360是做杀毒。对于这个层面的需求，一般不会有太具体的需求。通常产品经理会听到的需求会是，产品大概要面向什么样的用户，帮助用户解决什么样的问题，这种类型的需求可能在初期的创业公司会听的更多，例如饿了么的诞生是来自于他的创始人想要解决校园里叫外卖不便的现状 。

在相对成熟的公司孵化新项目时，你听到的需求可能会变成：公司有哪些资源优势，我们利用这样的优势能切入哪个行业，解决什么问题。比如小程序的诞生，一定是（wo cai de） 微信的决策层在思考自己拥有这个体量的用户后 ，产品能做更多的事情。在这个思路下，逐渐衍生出了小程序的概念。利用小程序，微信实现了流量的转化，实现了自己平台化、系统化的想法。

在这个阶段产品经理更多的事情应该是去了解老板提出的方向。基于这样的需求，可以确定人群，确定要需求范围（就是要做啥事），以及手里面可用的一些资源。（比如流量资源，内容资源，算法资源等）。

简单的来说，如果把做产品比作开店，那么这个阶段差不多菜系（要解决问题）和大厨（资源）应该是选好了，以及卖给什么样的人。但是开在什么地方，面积选择，店面装潢，详细的菜品和定价都还没有确认。

B 用户需求调研

在接到了战略层的需求，接下来要做的事情是分解和完善需求，将需求细化。这个时候你要做的事情包括：找到目标人群、了解目标人群的使用习惯。

比如你要做一个外卖平台，你的用户群里可能包含了两个人群，商家和用户。针对这两个人群，又会派生出很多需求。你需要考虑商家的使用环境，普通的小店很可能收银、送货、点餐全部加起来只有一到两个人。他们可能就没有办法专职的关注下单情况，这种情况下你的推送机制，语音提醒可能就要保证时效性。同样的因为生产环境的原因，订单管理需要人工来确认，保证不会过载，影响用户的体验。商品的上架和下架就要尽可能简单、清晰，在商家没有货的时需要及时下架。（不同于客户端的丰富、种类繁多）。

用户端则面对学生群体，不同于在食堂购买，在PC或者手机上，如何展示有哪些商家，每个商家又有什么样的特色，如何帮助用户去挑选商家，怎么评判商家的口味，价格如何展示。需求和商家端有很大的不同。

文章中举例的外卖软件，在我们日常生活中比较常见。很多需求依托常识就可以做出判断。但是如果遇到小众的需求，例如二次元社区、情趣用品等，如果产品经理没有这些产品经验，则需要去找到用户群体，比较常见的做法有联系公司内部的工作人员，例如运营和客服，这些经常需要和用户去打交道的职位，能给够你一些最真实的意见。还可以维护种子用户微信群，做调研问卷等。

但是小公司一般不太会采用这些方式，因为这些方式成本高，耗时长。最好的办法还是产品经理能变成产品的忠实用户，去真实的使用产品。而不是假想自己是产品。

在这个环节，其实产品经理基本上可以将方向性的需求转变为更详细的功能范围，以及对应的优先级。还是拿开饭店的那个例子，在这里其实我们根据老板给的菜系和大厨以及开店预算。

我们基本上确认了我们的菜是要卖给什么人，这些人来吃饭的需求是工作餐还是周末聚会，还是情侣约会，以及他们大概的预算会在什么范围（目标人群及核心需求） 。在这些条件的支撑下，我们基本可以确定菜谱上的内容，要设置凉菜、热菜、招牌菜、主食（需求转化为对应的功能列表）。根据这些人的性格特点，店面的装潢也可以确定了（页面风格，排版）

C 协作部门的需求

确定了用户的需求之后，我们要继续确认内部的工作流程。产品不仅是用于服务用户，同时还要服务自己内部体系的其他部门。例如：

• 运营部门日常的内容和活动维护，那你就会需要一个管理后台；
• 客服要可以收集和解答用户的问题，那我们的页面上就会需要客服的展示位以及后台给客服回复的页面；
• 像饿了么这个例子，它的协作部门还包括了外卖配送人员，这个时候就需要给配送员一个可以快速查看和管理订单的页面（体量足够，可以变成app）；
• 网站类的产品可能收到来自seo部门的需求，他会要求的你的页面上增加很多的内链、会要求一些搜索词要有落地页面。（这个可能会直接影响你的网站结构，seo会让你做很多专门给爬虫抓取的页面）。
• 可能还会有一些页面上看不到的需求:比如财务可能有做账的需求，BI有数据统计的需求。

确定了你可能需要协作的部门之后，有的时候你还需要继续确认他们的人员配置和工作流程是什么样的，这些会影响到前后端的设计。

以我所在的公司为例，产品是垂直领域的内容类产品，在我规划内容展示的时候，首先需要明确我们内容的生产的范围和内容数量、以及内容的展示形式（音频、视频？），这些东西决定了你的页面如何展示。

如果说内容是自己产生，每天大概有几篇？如果只有十几篇，可能就不适合信息流的展现形式，包装成为栏目做深度阅读或许更好（例如每日精选）。

如果你的产品定位又是内容服务，主要服务场景是提供多而全的内容，而运营每天的内容生产上限就是十几篇，那么这个时候内容从哪里来呢？是去利用爬虫抓取内容，还是做PGC平台？ 抓内容是哪里抓，中文还是英文，是英文是否需要机器翻译。内容抓取过来，运营是否需要二次处理。如果是做PGC平台，运营是否去做第一批种子用户，去用各种马甲活跃社区气氛。

延续我们开饭店的那个例子，在这个阶段，你可能需要根据后厨的人员配备和菜系（用户需求和内容生产能力）决定厨房添置的什么道具，是否需要购置烧烤架（内容生产的类型），原材料是使用半成品还是自己制作（内容生产的流程）。

D产品配套需求

一个在客户端呈现的需求，往往伴随着的很多你看不到的功能需求。以一个社区类评论功能为例，用户只能看到普通的回帖评论，但是背后可能伴随着一套超级管理员系统。管理员可能需要有禁言、删、拉黑。

拉黑的人是否可以被解除黑名单，黑名单在哪里管理，由于前端页面展示有限工作效率低的问题，就需要做一个后台来管理。禁言多久后可以发言，在别的帖子是否可以发言。规则都需要设置清楚。还有评论中如果有敏感词汇，需要如何处理。这里有一个很有趣的例子，在某二次元论坛对一些敏感词汇进行了替换，例如“你他妈”会被他替换为“你他喵”，想象一下两个对骂的人，说出来都是你他喵，这还怎么骂的起来。在我们的社区中还发现了有人利用接口，在帖子里面刷广告怎么办，我们就需要设置回复间隔。这些都需要产品去设计周边的系统。

再比如社区有一个竞彩功能，配套的就要有出题，结算功能。结算有可能会错，是否需要二次确认。竞猜是否给予用户奖励，奖励是否可以兑换奖品？奖品是否需要商城系统？或者奖励不可以兑换，那是否可以提现，提现就需要一套给用户提现系统，要有提现记录，要可以添加提现的转账账户，是支付宝还是银行卡。这些又需要配置API接口。

因此在需求分析的时候，往往不能只看到表面上的功能，背后的完整流程，产品经理都要清晰。并对实现成本有个大概的估计，从而决定是否要拓展周边功能。比如说你的竞猜功能初衷只是想提升社区的活跃，但是你却花很大的精力做了一套竞猜系统，可能就极大的浪费了开发资源。

在我们开饭店的那个例子里，再上一个环节里面我们确认了我们要做烧烤店，以及整个烧烤的流程如何开展。在这个环节里面，我们就需要确认我们是用钢签还是用竹签，签子应该怎么整理，饭桌上是否需要设置专门盛放签子的容器（评论体系中的管理员），如果是钢签，如何回收清洗，如何降低签子的丢失率，签子如何消毒（帖子后台管理系统）

E数据侧需求

以上的这些需求理清楚之后，差不多产品的需求也算完整了。1.0的版本基本做完之后，我们还需要进行持续的线上数据观察。这里我们跳过你产品的冷启动时期，假设你的产品已经拥有了自己的用户群体。

在这个阶段产品需要通过数据来验证之前产品经理推理（拍脑袋）定的需求是否合理。帖子的评论功能是否使用，你给帖子提供的快捷回复，和表情包是否有人使用。设置的收藏和分享点击率怎么样。分享是放在评论旁边，让用户方便触达。还是放在帖子结束时，让阅读完帖子的可以第一眼看到并触发分享。

我们筹划了好久的饭店，在这个环节也进入了正常的营业节奏了。你需要通过数据来检验这个店是否符合你最初的预期，例如你的是面向白领的中午餐，你需要验证客单价、平均上菜时间，以及翻台率等关键数据，来优化你后台的生产流程，菜单的设置。

来保证用户在短时间完成用餐，并且消费在白领的工资可承受范围内。还要确定这样的定价和人员配置和生产成本下，你的饭店是可以盈利的。我们还希望我们的大厨们，能看到自己的菜被用户所喜欢，干的有动力。我们的服务员可以很高效的完成用户的要求，从而得到用户的称赞。这些东西的实现和饭店整体（产品）的设计密不可分。

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

题图来自Pixabay，基于CC0协议