当写下这个题目, 心中又是一片风声鶴戾。需求分析是一生的功课，这个课题在产品或服务的任何阶段、任何时间都挥之不去。什么都可以遗忘，唯有需求不可辜负。 你或许会质疑：关于需求林林总总的说法已经铺天盖地，还有什么可说？是的，貌似全宇宙都知道“按照客户的需求提供服务”，也有很多方法模型教你如何分析客户需求，但几乎全世界的产品经理或客户经理仍在为“需求”苦苦挣扎，这是为什么？ Brief写了老长老长，产品会开了无数个晚上，各种灰度测试加起来堪比50度灰…... 为什么还是扯不明白需求？ ——“我的要求很简单？你要我怎样说才能明白？” ——“你到底要什么？” 如此纠结的状态至少说明一点：客户的需求常常不是听上去或想象的那样，或者甲方表达晦涩，或者乙方理解失误，而这一点，对于企业级服务尤甚。 市场上多数关于需求分析的观点都是2C层面的，相对于2B，2C用户需求的解读“稍微”容易一些，至少作为产品经理本人，他可以以一个样本用户的身份去亲临或体验产品场景，这是一个很重要的需求判断指标。 然而对于2B的需求，情况就复杂很多。其实2B产品开发团队大都是行业出来的，他们都是专业人士，比如很多营销产品的开发者本身都是作为乙方服务甲方多年，具有丰富的实战历练，这本身就是一个门槛。 然而即使如此，A企业与B企业对于一个相同专业项目的需求也会很不一样，有许多因素决定这些不同，比如行业、体制、规模、发展阶段、预算水平，甚至是具体执行人的专业素养等等，都会让一个听上去很easy的需求衍生出不同的版本。 所以，如何以正确的姿势解读多种因素共同作用的客户需求，其实是一个系统任务，其重要性堪比著名的“Customer Success客户成功”。 需求的满足主要涉及产品和服务两个层面，因为产品的相对固定性，不如纯服务来的灵活，如果一步错则步步错，所以正确解读需求对于产品开发显得尤为重要，而我们今天讨论的重点就是企业级Saas产品的核心需求分析。

一、刚性的需要才叫需求

但凡成为需求的，都必须是硬道理，所谓刚需是也。 理论上，但凡人们要去做的企业级产品都不会是一拍脑门而来，都会有这样那样的取证路径，因此从“需要”这个角度讲，都是没问题的。但“要”和“求”显然程度大不相同，这也是理论需求与现实需求的关系。 从大的方面讲，所有的企业服务产品都是为解决三件事：提高效率、提高营收和保障安全，显然没有企业不需要这些，但需要就一定会做吗？显然不是。 产品开发者要时刻保持警醒的是：对某个功能的需要是否已经上升到了需求的程度？以及客户或用户是否已经意识到了这一点？这个衍变的过程就是我们所说的“时机”。很多产品遭遇挫折就是因为非刚需满足，这意味着早产或先天不足, 可想而知成长的路会有多艰难。 那么怎样辨别需要和需求？其分界线又在哪里？

二、客户说不出来的往往是真需求

大多数企业产品对接的用户都是某某具体职位的人，他更多关注的是一些点状的功能如何实现，不太容易将各个相关环节进行模块化连接，更缺少趋势洞察。 但一个好的产品必须同时考虑“功能实现+模块整合+趋势吻合”三 个层面，所以仅为满足某个功能实现是不足以支撑一个产品的，产品开发者必须要站在全局、看到远处与想用户未想，你的产品才有可发展的空间。 用户看到的主要是问题，但你需要看到问题的原因，这个原因往往就是产品的底层逻辑。 最美妙的需求碰撞是这样的：有一天你把某个产品交给用户试用，他顿时高呼“哇塞！这东西太牛了！这就是我要的！” 呵呵，你知道，在你没有做出这个东西之前，他其实不知道要什么，关键是你得知道。所以SaaS产品都是做未来，只有未来才有增长，否则为客户做一个定制开发就足矣了。 如这个冰山图所示，我们听到的用户需求常常只是露出水面的那部分，叫“观点”，而他最真实的需求是在水下看不见的，比如第4部分“渴望”，这意味着我们要对“听到的需求”进行去噪处理。 延循这个逻辑往下走，若你等到用户提出一个需求，那么我可以说这个需求的开发时机已过。除非这个用户是一个极客式的人物，他有着与你一样前瞻的预判能力。 这种情况也是有的, 主要见于纯工具类产品, 但企业级产品越来越向功能类靠拢、是技术与业务的合体, 这更不是大多数用户所擅长的，依靠用户驱动的产品模式会很被动。 想起一个故事，尽管不全与2B产品有关，但也很有参考意义。 2012年微信刚推出的时候，我有一个朋友表示出如下的质疑：这个东东也就是给90后用，你不觉得象咱们整天拿着手机语音很傻吗？而现在，这位朋友用微信用的不亦乐乎，也经常使用语音…… 所以还是那句话：不要轻信用户的判断，他们嘴上讲出来的可能仅是线索或素材，而非答案本身，因为他们常常处于待启蒙或者混沌状态。

三、真实需求靠挖掘和论证

当你确定了一个基本需求，常常要做需求调研进行论证，这是很有意思的事情，其中有很多逻辑游戏。以下是三种具有代表性的提问方法： 1、我想做这样的东西，你觉得有用吗？ 2、你在什么情况下会用这个产品？(可以给出一些选项) 3、你平时遇到的主要困难或问题是哪些？ 在第1个问题下，你只能粗略地判断这事儿可行或不可行，无论对方回答YES还是NO，你大约会有75%继续做下去的可能 ( 因为用户认知的混沌性,对其否定性回答可留一半相信度，当然其肯定性的回答也并非全然可靠，但会给你100%正向的激励) ； 根据第2个问题，关于做还是不做，你会有更具象的判断标准； 而到了第3个问题，结合问题2你就有更多的证据去论证你的预设是否正确，以及如何调整或优化产品逻辑...... 实际可提的问题还有很多，但关键在于，需求不是YES或NO这么简单，而是要对具体语境或情境进行甄别和挖掘。 上述有一个前提是，产品开发者必须深入了解这个行业的操作流程，他最好是从这个流程里出来的，然后他又具有了更深更广的洞察，如此一来他才可能对用户的应答做出判断。 通过上述种种复杂的情况可以看出，需求判断类似一个多元函数求解的过程，因此一个好的需求模型是必要的，它可以帮你透过现象看本质、厘清产品底层逻辑的层级、可能的发展空间甚至是天花板在哪里。 其实严格讲，真实需求是论证出来的。大多数产品的原始需求与底层逻辑是基于你多年行业积累的怦然一动，然后你再用诸如上述需求调研的方法去求证或证伪, 当底层逻辑求证无误，接下来各种细分功能的添加以及产品的升级迭代就会倚赖一些推理的过程，当然这时你会更多的依靠数据分析。

四、最高阶的需求处理是“引导”，而非“满足”

如前文所说，客户大部分的需求是点状和碎片化的，甚至是混沌模糊的。 这类需求最多可以称为种子需求，开发者需要辨别种子需求背后的原因是什么、后续的需求会是什么、以及是否需要把几个相关的需求叠加到一起等等，这种情况主要针对产品前期开发或底层逻辑形成阶段。 当底层逻辑被基本证明是正确的以后（比如，你有了一部分活跃用户，或者拿到了VC的钱），后面最主要的工作其实是“引导”。 在用户不排斥的前提下，你需要持续编织梦想，用户总体上是被你带着走的，他很难提前想象出你编织的梦境的样子，所以总体上你是主动的，但这时的挑战有二： 1、监测他既有的需求是否被满足。 2，如何帮他“制造”新的需求，这就是所谓“潜在需求引导”、或高级的满足。 如果说产品初期你还可以通过面对面沟通去捕捉用户需求，这是一种相对的静态互动。 而当产品进入实际运营，双方就都进入动态的互动，这时对用户的洞察就需要启用更高阶的手段，比如数据分析。好在这时你已经积累了一些运营数据，那么就可以通过分析去发现潜在的、尚不被用户意识到的新的需求（这也是商业智能的一部分）。 上述这个过程的描述还是偏理想化，现实中的产品迭代是迂回曲折的，比如，当数据不足以支撑需求挖掘怎么办？说到这里，就必须引入另外一个话题，即最近很火热的一个讨论“做产品还是做服务？” 其实这是个伪命题。企业大多数环节的运营都是发散性的系统，SaaS产品也只能实现部分标准化，即：仅可以释放部分人工或服务，因此它不可能独立唱主角。 你可以想象如果企业运营都能靠产品运营实现，那么时代就不是现在这个时代。未来或许会有这样一天，但需要一个缓长的过渡。 一款SaaS产品若能达到70%的自动化已经是相当不错，另30%还是要留给服务，更为重要的是，对于最真实的产品使用反馈以及不可言传的经验体会，只有在实际服务过程中才能获得，再牛的数据分析与推理都代替不了一线的体验。 很多人都知道纯服务是很苦逼的事情，甲方的需求一日千变，你要有多少真身才能Hold得住过山车般的反复刺激?（各位甲方多有得罪，我知道你也是被逼无奈或身不由己） 关键是纯粹的服务模式效率低下，尤其当标准缺失，双方很多时间都消磨在各种无效沟通与掰扯中；但纯做产品的也喊苦逼，你与用户之间隔的是产品，那其实是一道屏障，很多时候你是在盲打...... 一个是需求泛滥，一个是需求稀缺，OK，那为什么还要人为的隔离？答案很简单，产品要做，服务当然也要做。 产品给甲乙双方指定了一个相对确定的行为空间与相对客观的标准，各种运营指标就摆在这里，可以减少很多纠结与掰扯，而服务又给了你近距离感受用户体验的机会，这让你在进行产品优化时不缺底气。 所以无论是做产品还是做服务，其精髓都是引导用户在你建立起来的矩阵里持续玩下去，而且要玩得High （所以有DAU与MAU），这个矩阵里的需求管理必须是循环往复、丝丝入扣。 最后必须要说的是，其实需求远不仅仅与开发或用户体验相关，它是一个全域课题。如果把需求管理做透，你完全可以用需求管理的方法把全业务线串到一起、以及把各种影响产品发展的因素都做到需求矩阵里。 这如一个指南针，让你不会轻易迷失方向、以及当有问题发生时能找到症结所在。 产品的壮大成熟枝枝节节繁多，越是迷雾重重的地方，越发需要拨开迷雾看本质，产品发展的任何一个环节其实都与需求有关，所以表面上无论是运营还是服务的问题，都可以归因于需求管理系统。（呃？你不觉得做一个需求管理的SaaS其实会很有用吗？）