“需求”是种很玄的东西浅谈需求管理

　　自从三年前走上了产品的“不归路”，几个高频词汇像“用户需求”，“用户体验”，“用户疼点”等等，就不断的在耳边响起，自己也时不时的跟各路人士侃上一番。随着经验值的增加，对“用户需求”这个词有了愈加深刻的认识，它不仅仅是个名词，它贯穿产品设计的始末如何定位需求，如何对待需求，如何将这些需求成为有效输入到产品路线的规划中，如何后续去验证需求是否有被满足。
　　尤其是开始做面向企业（2B）的产品，更是了解到需求管理的重要性。当你产品的revenue绝大部分依靠少数几个大客户贡献时，某个大客户突然提出了新的需求；要求A功能尽快加入到你们近期开发计划当中，如果不能满足，就考虑其他竞品。这时候，作为产品经理的你，应该如何处理面对。
　　确定需求明确问题本身，比需求反馈更重要
　　用户一定明确的知道自己需要什么吗？？需求的产生源自于问题，说白了也就是用户实际遇到了现有产品无法解决的问题时产生的。然而每个人都自认为是解决问题的好手，用户融入自己的经验、理解提出他认为的解决方案propose给你的产品。举个最通俗易懂的例子，一个人觉得冷了，他说他希望获得更多的衣物保暖，但也有可能是他病了，或是饥饿导致寒冷感。因此，确定需求的目的是要发现问题本身，而不是停留在需求层面。了解用户在什么场景当中会遇到怎样的问题，是确定需求阶段的主要目标。
　　评估需求做对的事情，比把事情做对更重要
　　回到开篇谈到的那个例子，你的某个大客户突然提出了一个紧急的需求，并claim如果不能尽快实现，就有流失的可能性。作为一个有“节操”的产品经理，是否因为这个客户是大客户，对于来自他的需求就加以更高的权重呢？我认为产品经理应坚守产品设计的“初心”，判断需求是否具有代表性（可以通过反馈统计，用户访谈，竞品分析等等途径），判断需求是否符合产品的战略目标，正确评估资源的投入和产出（不仅仅是短期利益，以及产品发展的长期利益）。
　　有人可能认为，大客户这样就跑了啊。如果你有充分的理由或workaround，客户未见得会跑；如果你真的投入很多资源为某个客户专门开发了某项功能，即便是这个客户短期内留住了，真正服务给更多用户的功能被停滞了，又何尝不是得不偿失呢。当然，如果公司的各项资源都足够支撑，玩儿得起，这另当别论。
　　排序需求不以技术实现的难易为主要衡量标准
　　确定了这个需求要做，但是开发现在已经被各种需求堆满，不经意的一根稻草，就可能引发暴力事件。因此，合理的排序需求，不仅对于产品经理而言，是保障不成为“群殴对象”的良方，也同时保障产品在健康的生态下得以不断提升。
　　然而很多产品经理都会不经意在实践中陷入一种误区，开发说容易实现的优先，短时间内不容易实现的放在最后。特别是一些懂一定技术的产品汪，还不用跟开发聊，自己就能判断出大概的实现的难易，默默以此排序了。我自己也曾陷入过这个坑，当时还记得被一个开发不留情面的说，“你排需求不应该从技术实现角度考虑，而且你凭什么代表开发评估难易。”一时被问的语塞。
　　这是否意味着Roadmap的设定就不考虑技术实现？当然不！排序要考虑的核心是怎样以最低的成本，做出对市场效益最大的影响，收获最大的利润。技术实现所需的资源也是成本考量的一部分。因此，作为产品经理，应着重对于市场进行分析，根据市场影响、收益等因素进行排序，交由开发团队评估，并一起讨论确定优先级，通过团队协作以达到利益最大化的目的。
　　验证需求知道自己不知道什么，比什么都不知道要好
　　功能上线，这个需求就被close了吗？你如何判断这个新功能是否解决用户的问题，并如何评估这个新功能的有效性。“知道自己不知道什么，比什么都不知道要好”，这是之前当实习生的时候，师父常说的一句话，当时没有太深的体会。不一定每一次把握痛点都是稳准狠，特别是对经验值没攒高的产品汪，知道gap在哪里，不仅能不断增加自己对于市场需求的sense，同时也是对产品负责。
　　验证的方法是多样的，主观的用户访谈、反馈收集等，客观的数据分析都可以帮助评估。在此，想着重说下数据这一途径。对于产品功能的验证数据，更多是要在设计初期计划好，确定核心KPI去度量，确定如何衡量成功与否。如果等功能上线后，突然意识要去抓取某些数据，可能会遭遇后台根本统计不到的尴尬。所以，产品汪更要具备一定“未雨绸缪“的能力。
　　正如开篇谈到的，需求是贯穿产品设计的始终，需要从初期考虑需求管理的完整周期确定、评估、排序、实现和验证。文章中谈到的都是之前经历的感悟，也多是自己踩过深坑后切身的感悟。