产品的第一错误率永远是管用。 三个好的产品是能解决问题的，也是我们常说的需求。是需求下定决心了流程和网页，流程和网页下定决心了可视化。

而对许多刚进阶的产品副经理，一般来说上来就会沉浸于在网页同时实现中，而没有理清楚需求，舍本逐末。还有许多产品副经理，是面向全国老板娘设计产品，老板娘说我要那个我要那个，就忙不及的去按照老板娘的设想做，而不顾自己手中所有的开发资源和用户端需求。

这种做出来的产品常常是没有人能采用的。 产品在日常生活的工作中所有的核心都是围绕需求展开的，而需求常常源自于方方面面，三个好的产品如果是方方面面需求综合作用的乙醛。

依照需求的类型，你面临的需求可能将源自以下几个方面，本文从四个部分讲诉了需求从产生到上架的过程。

 

A 发展战略层需求（一般源自老板娘）

三个公司的路径性需求，一般不是产品副经理所能重大决策的，那个层面的需求一般源自于领导层。老板娘一般会依照自己保有的资源竞争优势，和对市场的分析，下定决心产品的发展战略路径。

比如说为什么微信是做老同学社交，陌陌是做其他人社交，360是做防毒。对那个层面的需求，一般不会有太具体的需求。一般来说产品副经理会听见的需求会是，产品大概要面向全国什么样的用户，帮助用户解决什么样的问题，这种类型的需求可能将在初期的创业者公司会听的更多，例如饿了么的问世是源自于他的创办人想要解决大学校园里送餐不便的现况 。

在相对成熟的公司幼体新项目时，你听见的需求可能将会变成：公司有什么样资源竞争优势，我们借助这种的竞争优势能瞄准别的行业，解决什么问题。比如说小流程的问世，一定是（wo cai de） 微信的领导层在思索自己保有那个规模的用户后 ，产品能做更多的事情。在那个路子下，逐渐派萌发了小流程的概念。借助小流程，微信同时实现了流量的转化，同时实现了自己平台化、系统化的设想。

在那个期产品副经理更多的事情如果是去介绍老板娘提出的路径。基于这种的需求，可以确认人群，确认要需求范围（是要做没事儿），和手里面可用的许多资源。（比如说流量资源，内容资源，演算法资源等）。

简单的来说，如果把做产品想像成展店，那么那个期差不多湘菜（要解决问题）和厨师（资源）如果是选准了，和买下什么样的人。但是开在什么地方，面积选择，门店室内装饰，详细的菜谱和定价都还没有确认。

 

B 用户需求考察

在接到了发展战略层的需求，接下去要做的事情是降解和完善需求，将需求细化。那个时候你要做的事情包括：找到目标人群、介绍目标人群的采用习惯。

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

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

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

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

在那个环节，其实产品副经理基本上可以将路径性的需求转变为更详细的功能范围，和对应的错误率。还是拿开饭店的那个例子，在这里其实我们依照老板娘给的湘菜和厨师和展店预算。

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

 

C 协作部门的需求

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

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

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

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

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

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

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

 

D产品配套需求

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

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

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

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

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

 

E数据侧需求

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

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

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

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