产品经理如何做好需求管理
系统学习过项目管理(无论是PMP还是信息系统项目管理师)的同学应该都有感触，很多项目失败的重要原因是需求管理做的不够好。
这些项目往往在开始的时候就已经注定了失败，无论项目组后面再怎么努力再怎么加班，都很难力挽狂澜把项目救活。
很多产品经理认为需求管理这是PMO和项目经理的事情，自己只需要做好需求分析，需求(原型)设计，需求评审和需求跟进即可。殊不知项目经理和产品经理是需求的第一道防线，需求如果一开始没管理好，那后续的项目推进会特别难。
1.需求是什么
关于需求最著名的就是马斯洛的“需求金字塔”，马斯洛把需求分成了5个层次：生理需求、安全需求、社会需求、尊重需求、自我实现需求。
但上面这个需求的定义太泛泛了，在产品经理的语言体系里面，需求就是可以解决内外部客户具体问题而提出，当前尚未满足的要求。
以我们经常使用的微信朋友圈举例说明。
我准备五一小长假去成都绕城绿道骑行打卡，但小红书攻略太多找了半天都没找到合适的，DeepSeek给的建议不够全面，然后我猛然想起好友张三去年五一去绿道骑行打过卡并且还在朋友圈分享了详细的攻略。
于是我就去翻张三的朋友圈，虽然张三朋友圈的内容全部可见，但张三本人酷爱分享，平均每天能发2-3条朋友圈，要想翻到1年前的内容就有点费劲了。
于是我就有了个需求：查看朋友圈内容时能不能按年份和月份筛选？这就是上文说的解决客户(也就是我)具体问题(快速查找定位)而提出的，当前尚未满足的需求。
有人说你可以用微信的(朋友圈)搜索功能，这里还可以选择朋友和发布时间，但问题是这种搜索的前提是朋友圈内容有文字才会有效，纯图片或者纯视频的搜不出来。
还有种情况就是搜索关键字和好友朋友圈的文案内容可能不匹配。例如上图我搜索的是年夜饭，好友发的文案里面都是新年祝福语，根本没有年夜饭这个关键字。
上面那个翻好友朋友圈历史记录的事情，我遇到过，我周围的朋友同事也遇到过，在不愿意打扰好友且不知道内容关键字的前提下，只有不停地向前翻找查看。
好友的朋友圈无法按年份月份筛选，但我自己的朋友圈内容却可以按年月来快速查找(如下图所示)，读者们可以想想看微信为何会差别对待呢？
上面朋友圈的那个算是正常的需求，知乎上有人跟帖分享过各类奇葩的需求，比如：10多人的小公司老板要求员工写一款Java这样的编程语言，2000块钱做个淘宝，3000块钱做个百度等等。
2.需求的来源
需求按照不同的维度可以有多种划分方式，如下就是比较常见的需求类型分类方法。
那么需求又是从哪里来呢？常见的典型途径有下面这些。
公司战略：这个相对比较好理解，产品为了获得更多的用户和市场份额，公司为了打造自己的核心竞争力，提高准入门槛或壁垒，就需要有一些差异化的功能来实现。或者公司为了开辟新业务，就会有新需求。
例如海底捞面向直营门店的内部订货平台要打造为开放性的订货平台，这就会有供应商入驻，供应商审核、商品发布、订单支付、供应商管理端、清分结算等一系列的需求诞生。
用户反馈：用户可能会在产品内的建议反馈模块给产品提需求，也可能在微博、小红书、百度贴吧、微信群和知乎等渠道吐槽提意见。为什么要覆盖这么多的渠道呢？
因为我们的用户也是这些平台的用户，他们习惯于在自己熟悉或喜欢的平台去发声，而每个渠道的用户特点也有所不同。
产品内得到的反馈多来自重度用户，毕竟这个反馈入口不好找。
微博的用户喜欢发表观点，有时会出现挺有启发性的需求。
小红书的用户喜欢分享和发起话题。
百度贴吧的用户年龄相对偏低，或者是老网民。
微信群内的反馈简单直接，用着不爽就开始怼或者吐槽。
知乎会出现一些深度解析，应该是众多渠道中反馈最认真的。
以下是知乎上的一个帖子，2421个用户给微信提意见反馈。难怪张小龙2019年某次分享上调侃每天有1亿人教他做产品。
产品数据：如果说前面2个渠道收集到的是定性的描述性需求，那么产品数据则是定量性需求，例如注册页面的跳出率太高，下单到支付的转化率较低等等，这就需要去优化，就会有优化类需求。
运营市场：在大部分公司内，运营、市场和销售的同事都会背很多量化的KPI指标的，比如年度销售额或利润或注册用户数或付费用户数达到XXX或者增长XXX，而要完成这些业绩任务，除了前端产品需要增加功能外，还需要管理后台提供工具支撑。
举例说明。某消费金融公司运营部门的任务是年度完成2000万新增注册用户，500万授信用户，运营部门就提出前端产品要有MGM分销裂变的活动来做老带新，管理后台要能快速配置各种MGM活动并且做全流程的数据追踪和统计分析，这些就是运营市场提的需求。
脑洞：上述需求都来自于产品部之外，产品内部有时也需要搞一些头脑风暴来想一些产品的亮点或者特色出来，要不季度和年度的汇报PPT怎么写？要不怎么去向上面要资源要HC？
当然需求的来源渠道不止上述这些，还有行业调研，用户访谈、行业变化等。
行业(需求)调研：目前市面上大部分的产品，都可以在行业内和行业外找到竞品。产品经理在打磨自家产品的同时，还得经常性的看行业、看标杆。
比如京东商城的产品经理，就要时刻关注淘宝和拼多多这2款产品，要时刻留心他们出了哪些功能，哪些值得京东跟进并做微创新，哪些暂时不需要跟但需要长期关注。
除了淘宝和拼多多之外，京东的产品经理还需要定期(比如每个季度)把市面上用户基数大或者交易体量大的电商类APP挨个做一次摸排调研，找找他们的新功能或者亮点特色，再纳入到京东APP的需求池内。
当然，京东如果要做某个新功能比如PDD的仅退款时，可能也得做一次深入全面的行业调研。
行业(需求)调研的方式多样，产品阶段不同、产品所属行业不同，可供选择的调研方式也会有很大的区别。
用户访谈：主要有电话访谈、在线访谈和面谈3种，这个对产品团队的要求会比较高，这个高主要体现在3个方面。
问卷要求高：既然是访谈就得有提纲，这个问卷提纲和内容怎么设计？太短则收集到的反馈不够全面，太长则对被访谈者不友好。
筛选门槛高：怎么筛选出具有代表性的客户？人数太少则样本数量不够，数据参考意义打折扣，太多访谈起来会耗时耗钱，那么多少位比较合适？
费用预算高：委托外部机构做需要预算，自己团队做则需要给被访谈者发放酬劳或礼品，这也需要费用，团队耗费的时间也算人力成本。
综上：用户访谈这个对小公司不太友好，中大型公司会相对比较适用些。
特别需要注意的是，产品经理不要拒绝任何渠道任何人的需求。不管这个人是用户、同事、老板或陌生网友。
在收集需求的时候，产品经理要将需求与提交者的身份、地位、利益和动机等全部摒除，即原原本本的记录每一项需求，不能在记录时凭个人喜好或者主观经验删掉自己认为不合理、不靠谱的需求。
需求收集的过程与头脑风暴差不多，以获取需求的数量为唯一目标，而不用考虑其他因素，例如需求是否与现阶段的业务目标匹配、需求实现复杂度、投入产出比ROI等。
这些我们需要在分析/筛选需求的时候再去综合考虑。
3.建立需求池
收集需求之后，我们就需要记录需求，建立需求池。
由于需求提交人和接收人在工作资历、理解能力、表达能力、身份背景和岗位职级等各方面存在差异，会导致需求在传递、表述和记录的过程中出现需求失真，即提交者想要表达的信息和接收人收到的信息会有差异，这种差异可能很小，可能很大。
所以我们在需求收集、整理和记录的时候要尽可能的规范，尽可能的详细，这样才能在后面做需求重要度(优先级)分析的时候相对容易一些。
图.需求池的相关要素
日期：除了可以按时间维度来查找需求，也可以按时间维度来统计需求，例如2025年4月接收了需求X条。除此之外日期还是我们评估需求的重要依据，有些需求几个月或者几年前记录时会觉得离谱或实现不了，但当前来看可能恰如其分，比如淘宝生态的应用中用户希望支持微信支付，几年前根本不可能，现在刚刚好。
来源：这个来源包括人的维度，当有些需求存在不确定性或需要了解更多需求背景或出发点时，可以通过需求来源找到提出者做进一步沟通。来源还包括地点(场景)的维度，即我们记录需求时还需要记录场景和背景。
举个例子。老板在某事业部的某次月会中提到我们订货平台的体验不好，我真的以为是UI/UE方面做的不好，但我后面找参会的几位同事求证，事实并非如此。
老板会上讲到其它订货平台的商品详情页有视频和精美的图文介绍，我们平台视频欠缺，图文不全且没有购买欲，这是老板眼中的体验不好，而并非是真的UI/UE不好。
需求描述：本小节开头的时候说过，需求从提出人到记录人再到接收人流转的过程中存在需求失真的情况，比如前面那个“体验不好”的需求。那怎样才能做好需求描述减少失真呢？
有2个切实可行的方法，条件允许的情况下优先方法1，不允许的情况下用方法2。
方法1：记录人和接收人变成同一个人，还是上面这个体验不好的例子，如果产品经理亲临现场而不是由别人记录并转达，就可以如实的记录下“需求”背景和需求内容。
方法2：利用飞书的会议录制功能，会议开始到结束全程进行录音，再将会议内容转成文字，飞书可以识别出不同的发言人，这样方便产品经理快速定位并甄别内容。
4.判定需求的优先级
这个环节很考验产品经理功力。面对各种渠道收集到的上百个需求，怎么排出优先级？有没有好的模型或思路？答案是有的，这里推荐3种。
4.1 影响复杂紧急度
排需求优先级的时候，我们可以通过影响面、复杂度和紧急度3个维度来进行综合评估。为便于记忆，我将其简化为7字箴言：影响复杂紧急度。
为了让优先级排名可量化，可以采用评分制，再给每个维度赋予不同的权重，最后加权得出每个需求最终的分数，按分值高低排定优先级。
影响面：即该需求能够影响的用户范围，对用户影响范围越大，优先级越高，反之越低。分值可以为1-5分，5代表影响范围最大，1代表影响范围最小。
复杂度：同理，如果该需求复杂度越高实现就越困难，反之越容易，开发测试需要的时间或人力成本就越大，复杂度同样也可以用分值来表示。
紧急度：可以根据需求对于业务的紧急或重要程度来判断。不做该需求会导致APP下架或用户无法完成支付，这个紧急程度最高。如果只是无法批量审批，无法在线预览这种问题，其紧急程度就低了很多很多，其同样也可以用分值来表示。
但这个方法有局限性，即权重和分值不太好赋分。假定复杂度如果用1-5分来赋分的话，那最优计算这个需求的复杂度肯定是5分，注册页面手机号段的正则表达式只能是1分。
前者复杂度可能有1万需要300个小时完成，后者复杂度顶多10，1小时就能完成开发测试发版。两者复杂度差了1000倍工作量差了300倍，但赋分上面仅仅差了5倍。
但换做大部分产品经理来决策的话，大多都会选择优先做手机号这个需求。我们讲的方法论感觉不适用了？
所以我开始就写了“可以”采用评分制，但是否适用就见仁见智了。
4.2 优先级核对单
这里再提供1种优先级核对单的方法，具体内容如下。即把需求和下表的7个等级来做对照，然后给出优先级。
不做会造成严重甚至恶劣影响的：比如支付存在的BUG。
做了会产生巨大好处的：比如淘宝接入微信支付。
跟核心（高质量）用户利益相关的。
跟主要（大部分）用户利益相关的。
提高效率的：批量打印或数据导出。
降低成本的：结算页自动选择最大折扣。
提升用户体验的：搜索页效率提升。
以B2B产品举例说明。前提是当前阶段的业务核心是以卖家为重点(3.核心高质量用户)，那么对应符合等级3的就可以先做，然后才是符合等级4567的需求。
读者应该看出来了，这种方式也有局限性和不足。例如同样是核心高质量用户即等级3的需求有5个，又该怎么排？再有某些功能例如售后功能涉卖家和买家，也就是以上表的等级3和等级4，又该怎么排？
聪明的读者应该想到了，可以把上述2种方式有机结合起来。公司和行业不同，结合的方式可能也会有很大差异，这里就不做延展了，读者朋友们自己发挥吧。
4.3 KANO模型
该模型是由日本的卡诺博士（Noritaki Kano）提出的，KANO模型定义了三个层次的用户需求：基本型需求、期望型需求和兴奋型需求。小白型用户、主流型用户和专家型用户这三个层次的用户和 KANO模型中的三个层次的用户需求有些类似，有兴趣的可以详细研究下。
KANO模型
当然，行业内还有很多判定需求优先级的方法，限于篇幅这里就不做展开了，欢迎大家在留言区补充。
以上，欢迎留言交流。