作为产品经理，你做完一件事，别人问你怎么做的，你能说好吗？如何在说的过程中，体现出你的逻辑思考能力、需求分析能力、优先级排序能力和解决问题的能力？如何让你的经历变成经验，变成可迁移的能力，变成别人可复制的技术？
今天给大家介绍一个案例，主人公叫Ver。他是我的学员，Ver曾给我讲了一个故事，听完他的故事之后，我觉得这就是产品经理的工作典范，能成为复制到需求分析阶段的蓝本，照着这个做，不会有问题。
一、故事背景
Ver之前在一家在线教育公司，做面对学校的基于SaaS平台的在线排课系统。这一看就是TO B的产品岗位，B端客户，那都是客户爸爸呀。可李悦就是把B端金主爸爸的需求优先级排在了后面，为什么他敢这么干？
大家都知道，从事B端的产品经理可能经常会遇到这样一种情况：当你已经完成最近的需求排期后，新功能开发也在有条不紊地进行，这时候，BD和销售却跑过来跟你反馈说，有一个重要客户急需某个功能，需要我们尽快开发出来，这时你应该怎么做，是赶紧去重做需求排期吗？
其实，不止是B端，还是C端，总会有一些临时突发的需求出现，发生这种情况的时候，很可能就打破我们之前的产品节奏了。更何况，作为产品经理，你是接受需求的前线，你接到需求后，和研发去提，研发不同意咋办？这是一个天雷，劈在了你的身上，到底怎么办呢？
别急，身为产品经理的我们需要有一套清晰的逻辑思维去甄别、去分析，这时我们可以使用产品经理最常用的“三板斧”——用户、场景、需求。
万变不离其宗，“用户——场景——需求”这个公式，一定要变成下意识的判断。
二、确定用户
首先我们要知道提需求的人是谁，可能有人说，当然是用户了。但我们了解真的了解我们的用户吗？
我们知道，B端产品服务的对象通常是企业、商户、政府部门、事业单位等。
通常情况下，决定是否使用产品的决策人和真正的产品使用者并不是同一类人，很可能是上下级的关系，而产品面向的使用者通常是对应某类职业的人群。
这时请注意，这类人在使用产品时的身份标签是他所做的职业，产品面对的用户是剥离个体兴趣，更多是带有集体属性的人群。
这也意味着用户更关注产品能否满足我所做的业务场景需要，至于页面美不美观，图标好不好看，并非核心重点。
三、场景需求分析
面对需求，我们应该有什么样的处理方式呢？
首先，任何需求都是基于场景的，我们需要弄清楚：用户提到的需求中的场景是什么？
一天销售跟我说：“学校老师希望在“教师无课查询”模块里面，增加“文件导出功能”，并说是老师特别提出来的，是个刚需。”
这时，我跟销售说：“需要跟老师进一步沟通下这个需求的具体场景。”
之后老师表示需要根据无课的时间情况做调课，但因为有时出差在外不方便，所以需要导出文件用手机看。
这时就可以发现：老师提出的需求场景是实际存在的，但他提出的需求并不是真正能完成他任务的需求，而给出一个问题的解决方案。
请注意这里，老师是直接提出了一个解决方案。这是什么意思呢？
一个问题，往往包括了两部分：一部分是问题空间的，只有问题；另一部分是解决方案空间的，是这个问题的解决方案。
很多时候，用户或者产品经理，其实都会把问题空间的事情，直接变成解决方案空间的。就问题而言，这里老师遇到的问题是什么呢？
老师的问题是：如何在无课的时候进行调课？
所以，通过进一步询问，就会发现：其实老师真实需求是需要在移动场景下去完成工作上的调课，真正需要做的是做移动端的调课功能，而不是导出课表文件。
导出课表文件，能让老师收获一个什么呢？
老师能收获一个课表文件，然后老师就在课表文件上，找哪里没有课程？找到之后呢？老师就会想着把课程调到这里呀。但是，之后怎么办？老师肯定还会和销售说，我想把这个课程调过来，完成了这个需求，才出来真需求。产品能接受，研发能接受吗？
所以，要分析老师真实的使用场景，以及场景下的需求分析。
四、优先级排序
接下来才是需要思考的是我们真的需要做这个需求吗？或者说这需求是真的有必要马上去实现吗？
还是以上面的案例为例，排课系统的实际使用用户是学校的教务老师，大多数学校老师的工作场景主要是围绕在学校内的，也就是说有经常出差的老师占比并不高。
那做移动端的调课功能是需要经常出差的老师的痛点吗？
在实际调研中发现平均每周学校的调课记录有十几条，说明调课在学校使用中是一个较高频的场景，作为经常出差在外的老师来说，有这个移动端调课功能的确是能方便不少。
但在当时我们还没有开发移动端的APP，即使要实现周期也很长，所以这个需求并没有被采纳。
五、服务 = 产品 + 人
这时可能有人会问，B端的一个客户可能就养活了大半个公司的人，就因为分析后需求优先级不高就不满足客户提的要求了吗？
通常来说若客户对公司足够重要，公司也会尽量满足客户的需求，这时产品经理要各种资源更容易一点，即使再小众的需求也能被提到很高的优先级。
但出现需求不能马上实现的情况又该怎么办呢？
首先，要明确我们提供的是服务，产品只是个外在形式。虽然现在许多B端的产品主推SaaS（产品即服务），这个叫法实际并不准确，我认为对B端的服务=产品+人。
正所谓“产品不行人来补”，当产品不能马上很好满足用户需求时，就需要通过运营人员的工作代替产品的不足。
如上面的案例，给出的解决方案是若老师在外有调课需要，可以告知公司的排课人员代为调课，并将调课后结果告知给老师。
别忘了我们之前分析的B端用户特征，他们核心关注的是业务能否顺利完成，至于形式如何是次要的。
六、总结
总结一下，当有突如其来的需求时，我们考虑的思路：
首先，是看我们需求来源——他们是谁？是否为产品的直接使用者？并且B端用户特点是是更关注业务实现效率，他们的行为特征往往更取决于所处职业的集体特征。
其次，需求对应的场景是什么？是否为用户真实要解决的问题场景？解决方案是否仅为一种，是否还有其他方案？
最后，通过分析需求价值公式（需求价值=用户广度*需求强度*需求频率）决定需求的优先级。
最后，B端的服务效果往往取决于产品与人（运营人员）共同努力，当无法通过产品及时解决用户需求时，可以考虑通过人工的方式为用户解决问题。
