编辑导语：在与B端客户交流的过程中，有很多需要注意的问题，在产品的不同风格阶段，客户都会提出很多需求，而对于客户的需求产品经理需要有判断以及解决的能力；本文作者分享了关于B端大客户的需求问题的解释，我们一起来看一下。

2021年换工作，要做一下阶段性知识总结，另外跟Jira社区马畅老师聊到C端产品经理在B端的不适应，由此想到B端大客户交付中棘手的需求问题。

照例，先说下视角基础，笔者有10年软件行业经验，近7年交付过多个大客户项目，做过各种不同的项目，遇到过各种类型的客户；视角局限性在于，所有大客户均为运营商。

本文主要讨论做需求时的棘手问题，在职责上与项目经理有些交集；讨论的主题包括：需求变更、交付不一致、需求收集、需求池管理、高管需求应对等，每个主题先分析原因，再给出解决思路。

注：文中“客户”通常代指甲方或公司内部统一接收业务方需求的接口人。

01 客户是变更狂魔

客户需求经常变更是个头痛的问题，意味着我们没能解决客户的问题，同时浪费了时间，也会让团队产生挫败感而影响士气。

客户频繁变更可能的原因有4个：需求与产品间有鸿沟、客户非原始需求提出人、客户本身没想清楚，客户业务频繁变化。

• 需求与产品间有鸿沟主要是客户描述的需求和他真实想要的东西不一致，直到把产品给他用时，他才知道这是不是他要的；
• 客户非原始需求提出人是客户接到需求后，经二次理解加工转述给我们，即使我们给了他想要的，一旦原始需求人说不对，他分分钟甩锅给你背；
• 客户本身没想清楚是客户直接把解决方案告诉我们，但他本身可能并没有找到或者遗漏了真正的问题，这种功能即使交付了也解决不了问题。
• 客户业务频繁变化是个伪命题，更多是客户对业务的理解频繁变化，这种场景并不常见。

我们分3种场景来解决变更，分别是开发前、开发中和开发后。

1）开发前

开发前是需求分析阶段，这里做好了可以解决80%的需求变更，解决方法是“多确认、多验证”。

• 首先，我们一定要找到原始需求提出人，通过反复提问、多做假设、多做求证的方式，挖掘到需求“痛”的场景（5W1H）；
• 其次，借助纸、Xmind、Visio等工具把需求物化下来，让需求方确认文字是否能表达他的想法；
• 再次，如果需求较大，还需要设计原型图、需求说明书，让需求方提前看到、摸到实实在在的功能和操作，来验证是否满足他的期望；
• 最后，我们作为B端产品经理，应该比客户想的更多，提前把功能交付后可能的异常、引发的问题等与客户沟通。

2）开发中

开发中是已经进入开发过程中，客户突然要求改方案，这种要么确实是突然业务变化了（如高管有新的指示），要么就是客户描述需求时漏掉了关键信息。

在这情况下更多是评估变更影响，改动量大小是否影响本次交付，是否将未完成的先简化交付，抑或需求延迟至下期交付等。

采用敏捷方法中“双周迭代”可以弱化开发过程中变更产生的影响，小步快跑、迭代试错。

3）开发后

开发后是开发上线后，每隔段时间客户就要优化功能。

如果这种需求变更是无法避免的，解决方法是总结历史所有变更，尝试对功能进行抽象，看是否可以将功能设计成可配置的，抑或是否需要借用中台的思想封装出一个新产品；比如，我们在做各类流程时，发现列表页、详情页、甚至流程本身经常变化，消耗了大量开发团队的时间，后来，我们做了“流程中台”，此类变更迎刃而解。

02 客户翻脸不认账

明明跟客户确认清楚需求了，开发交付后客户翻脸不认账，这种场景同样既没帮到客户，又浪费团队的时间。

客户不认账的原因可能有2个：需求分析阶段不负责任、参与度低，客户承受了不便明说的压力。

解决这个问题分2种情况：

1）客户不负责

这种首先把上文谈的“开发前确认”工作做好；其次，养成邮件确认的习惯，把确认过程留痕，留下物证；再次，大型需求召开多人评审会议，并在会议结束后将会议纪要抄送所有人，留下人证。

2）客户承受了不能明说的压力

比如高管插手、本身无决策权等，这种情况首先要了解客户的组织关系和他的处境，跟他以及其他人建立一定的私人关系，通过非正式沟通渠道尽可能多的了解情况，理解客户面对的压力，帮他一起应对，适当加班修正，终有回报。

另外，尝试把关键决策人拉进需求确认过程，比如将需求确认邮件抄送给关键领导知会等。

03 客户太没想法（需求不明确）

客户没想法并不意味着给了B端产品经理自由发挥的空间，如果你体会过出数十个版本，结果客户都不认可的痛苦就能理解这种场景了。

客户没想法的原因可能有2个：真的没想法、不敢说想法。真的没想法背后可能是懒得想，也可能是不懂业务；不敢说想法背后可能是不愿承担决策的责任。解决这个问题有4个技巧：

1）对接Key Person

找到能明确需求的关键决策人，比如客户的上级领导、关键业务需求方等；这种方法最直接有效，但有时客户并不喜欢这种方法，需要产品经理、项目经理视场景拿捏尺度。

2）全面材料收集

收集跟需求相关的所有材料，包括Word文档、汇报PPT、内部邮件等，尝试通过内部材料分析可能的需求。

3）借鉴友商及互联网思路

分析友商或互联网相关产品功能模块，根据需求相似度确认思路。

4）低成本、频繁确认

如果对接人确实无法明确需求，此时应该以最低成本频繁确认，比如口头确认、Xmind梳理核心方向等。

04 客户太有想法（强给方案）

客户直接给解决方案看似为产品经理省事了，但如果客户本身缺乏对业务的理解深度或不懂产品设计，会出现上线后变更率高、功能复杂等问题，对用户、客户和开发团队都不利。

客户强给方案的原因可能有2个：客户本身控制欲强、解决方案源于更高层。

解决这个问题有4个技巧：

1）倾听

多问问题多倾听，搞清楚客户解决方案背后的思考。

2）用数据和用户说话

把平台的数据和用户意见领袖的反馈呈现给客户，尝试说服客户转变。

3）用竞品说话

拿有相似需求竞品的功能设计，尝试引导客户向我们期望的方向转变。

4）适当妥协

按客户的想法做，但争取少做、分阶段做，根据数据和用户反馈，引导客户做出转变。

05 需求太多

需求太多是个很可怕的事，它意味着需求等待引发的业务方抱怨、频繁加班引发的团队怨气、经常被投诉引发的高管负面印象等；团队明明干了更多的活，却收获了更多的差评。

需求太多的原因可能有4个：对接的业务线过多、低价值需求过多、产品缺乏边界、团队研发效能低。

解决这个问题有4种技巧：

1）建池

建立需求池和业务资源配额池，把团队资源、当前需求积压队列、各业务方消耗的资源量等数据公开、透明的展示出来，把资源争夺推给各业务方内部、不同业务方之间。

2）边界

明确团队支撑的业务线和产品边界，明确拒绝不属于产品范围的需求。

3）拉援

跟客户打好关系，让客户看到团队辛苦程度，帮忙拒绝一部分低价值需求。

4）交付改善

包括3方面：

• 简化，复杂需求先交付核心功能；
• 复用，抽象常见功能为可复用的能力；
• 提效，通过DevOps等工具提升交付效率。

06 需求太少

需求太少同样很可怕，它意味着我们的项目和团队不再被需要，从长远看可能会遭遇生存危机；需求太少的原因可能有2个：用户有需求但没反馈渠道、业务稳定用户真没需求了。

解决这个问题有2种技巧：

1）建通道、打关系

建立便捷的需求反馈渠道，可以让用户直接反馈工作中实际需求；跟用户意见领袖打好关系，让他们在一有需求时能直接联系到我们。

2）造需求

首先要明确，B端造需求是件不道德的事，我们不能臆想需求；但有2种方法可以在缺需求时创造需求，一是产品使用数据，通过数据分析发现问题点并跟用户进行确认；二是通过新技术、竞品等借鉴式创新，发现改进点并跟用户进行确认。离开了用户确认，我们就走到了“伪需求”的路上。

07 考验灵魂的高管需求

高管需求是把双刃剑，做好、做坏的影响都很大。

高管需求主要有2个难点：如何理解高管需求、如何与高管沟通需求；高管需求通常描述极简单、抽象、空洞、难落地；理解高管需求还是要落在沟通上，与好相处的高管沟通相对容易，所以，我们从3个角度聊聊与脾气不好、“官威重”的高管如何沟通。

1）调整心态，保持平常心

首先，我们要认识到很多高管在某些方面确实能力出众，但同时，他们也存在认知的局限性，可敬仰，但无需神化。

其次，要理解在有些环境中，高管的无力感在于想法不能落地执行；此时，官威是一种简单粗暴的执行力，很无奈、很悲哀，脾气差、有官威的领导容易争取到更多资源和下属的执行力，以对比其他高管形成政治竞争力，应对他们，我们只需表现出自身的执行力即可。

最后，有些高管拿脾气、diss下属当树立权威的手段，更有甚者，只顾自己业绩不顾下属死活，同时如果他们缺乏深刻见解；那这类人不值得追随（又累又没成绩），能远离就远离，远离不了就自带“情绪过滤器”，忽视他们的情绪，做好自己能做的事即可。

2）做事精细，少即是多

首先，多想少做，做的功能越多，越容易被挑刺，不如只做核心的功能，也给高管一个展示他思考全面的机会。

其次，凡做的功能必须要思考清晰、细致，用专业度镇压高管，此时，通过高保真、设计原则、细节等清晰的把想法表达出来。

3）思考、表达重逻辑

首先，表达简洁有逻辑，比如结论先行、主次分明、因果清晰等，具体可读《金字塔原理》。

其次，软硬结合，面对自负的高管，适当的认同，不重要的点不纠正解释，核心理解偏差该硬刚就硬刚。

08 客户工作敷衍or组织内斗

客户工作敷衍或客户组织内斗是一个敏感的话题，当存在这种场景，挖掘需求、确认需求、对需求达成一致等都很难。

应对这种场景，笔者暂时没有好办法，但提供2种应对思路：

1）少即是多

在这种场景下做出成绩很难，反而做多了被挑刺的概率更大，不如做少、做精。

2）谋与不谋

可以尝试接近高管、贴近业务方等收集高价值的需求做，甚至尝试谋求新的业务机会；但不应该尝试将客户接口人替换掉，更换其他客户接口人，除非足够了解组织的政治、有足够的政治影响力。

作者：李晓杰；微信ID：ecdoer；微信公众号：产品晓思（ID：pmxiaosi）。10年以上产品、项目管理实战经验，近7年服务大B端客户运营商（移动、联通），核心产品为企业信息化与协同，包括研发管理、财务管理、办公自动化OA、数据可视化等。喜欢读书、分享，希望与同路人共同探索产品经理成长之路。

本文由 @李晓杰 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。