B端的需求和C端有比较大的差异：C端的用户画像，在B端更多是以角色、权力和义务的划分。在这种情况下，我们的需求处理方式也会有所不同。
交互设计其实就是用户的行为设计，既然是围绕用户的行为，那么我们首先得清楚我们的用户是谁。
《俞军产品方法论》里提到“用户不是自然人，而是需求的集合”
不同于我们常见的C端产品，在B端中，用户主要是职场人，而不是基于性别、年龄或喜好等个人特质来划分。相反他们以角色、权利和义务来区分。因此用户需求分析更侧重于角色需求，而不是个人特征。举例来说一位财务经理在审批报销单时，无论其性别或兴趣如何，他们只关心有效管理财务流程。
如果企业有众多的职能和职位，他们都是我们接下来新产品的需求对象，我们该如何搞懂需求？
接下来我将从需求背后的角色分类，以及如何从中提取需求这两部分展开，一起来看看吧~
B端产品服务所面向的角色多种多样，不是单一的一个人，通常包括决策者、管理者和执行者三个不同维度。这些角色在使用产品时具有各自不同的需求和关注点。我们需要在全局的角度去精准定位以及抽取不同角色的需求。
决策者通常是企业的高层管理人员，他们对产品的采购决策至关重要，这可能是公司的CEO、董事会成员，或者是科研院所的院士、教授等。尽管决策者很少甚至完全不使用产品，但他们的关注点在于产品能否为企业带来实际价值，解决现实问题，从而实现企业的利益最大化。
与C端产品不同，B端产品的设计必须以满足决策者的需求为首要目标。这意味着我们需要重点关注产品能否在降低成本、提升效率、增加收入等方面给企业带来直接的经济效益。因此在产品设计过程中，我们需要将解决企业问题作为优先考虑的核心，而不是仅仅追求用户体验的完美。
在与决策者沟通产品需求时，我们不应过分强调产品的美观或交互体验，而是应该更专注于产品的商业价值和实际效果。因此我们的目标是确保产品能够在解决企业问题和实现商业目标方面取得最佳效果，以此来赢得决策者的信任和支持。
B端类型的产品除了一线的执行者外还有一个重要的角色——管理者。他们通常负责业务的管理与监督，属于次要的执行者或者间接的执行者。他们一般是是公司的中高层人员，产品是否被公司所接纳，还在于管理者是否买账。他们的需求也要放在优先级相对较高的位置。
管理者的需求是对公司总目标的分解。不同级别的管理者关注的业务需求也不一致。中层管理者侧重过程数据，高层管理者侧重结果数据。他们的期望通常比较具体，能简单快速的找到自己的任务并顺利的完成就好。因此在需求整理阶段要特别关注他们的诉求。
执行者是产品最频繁的使用者，类似C端「用户」的概念。他们格外关注产品的易用性，希望产品界面简洁明了，功能易于操作，能够快速上手，以提高工作效率。
执行者对产品的操作会直接影响到管理者对数据的分析和决策，进而影响其监督和评估团队的工作情况。因此执行者对产品的反馈可能影响管理者对产品的印象。若我们希望客户持续选择我们的产品，我们就必须确保在NPS（净推荐值）上能够满足执行者的需求。
需求提炼就是搜集和梳理需求的过程，这期间我们经常会遇到各方不同的观点。在这种情况下，如何在众说纷纭的环境中做出权衡是一个困扰我们许久的问题。接下来我希望分享一些我的想法，或许能给同学一些启发。
当涉及到需求争议时，我们需要牢记B端产品多人协作与集体诉求优先的原则。因为B端产品是为了服务整个组织或团队，而不是个人。因此在处理时，我们倾向于优先考虑应用更广的集体需求。在白盒SONiC项目中，我们曾遇到过这样的情况：在设计网络拓扑结构时，部分团队成员主张采用一种复杂的结构，而另一些则倾向于简化设计。在这种情况下，我们更倾向于采纳能够满足大多数人需求的简化设计方案，因为这能够提高产品的整体适用性和易用性。
在同一个用户群体内，不同的用户通常有着相似的工作环境和职能角色。这意味着他们对产品的期望和需求往往是趋同的。举个例子，对于白盒SONiC产品的网络管理员而言，他们更关注产品的稳定性和性能优化，而不太在意个性化的用户界面。因此在产品设计中，我们会更加注重满足整体用户群体的共性需求，而不是过分迎合个别用户的特殊偏好。
此外在需要多人协作完成的场景中，我们会更加倾向于考虑人数较多的需求。例如在白盒SONiC产品的开发过程中，我们面临着需要多个团队同时协作的情况，如网络架构师、开发工程师和运维团队等。因此我们会优先考虑那些能够促进团队协作、降低操作冲突和数据错乱的功能需求，以提高整体工作效率和协作质量。
敏捷开发作为目前主流的开发模式，以快速迭代、小步快跑为特点，在较短的开发周期内提交软件，强调在每个迭代周期结束时逐步交付需求。
在处理鱼龙混杂的需求时，我们需要有效评估它们的优先级。需求管理实质上也是优先级管理，需要合理安排有限的时间和资源。因此我们可以采用“四象限法则”来划分需求处理顺序的评估标准。
首先，重要且紧急的需求通常涉及产品的核心功能或主要流程，应当列为研发周期的最高优先级，重点跟进。
其次，紧急但不重要的需求通常是临时性的，对整体产品的后续迭代影响有限，可以暂时放置，考虑在二期规划中实现。
重要但不紧急的需求往往具有长期收益性，可以作为紧急需求之后的次优先级。
最后，不重要也不紧急的需求优先级较低，可以考虑不予实现，以节省资源集中精力应对更紧急、更重要的事务。
提炼需求的最终目标是为了更好地解决业务问题，实现商业目标。
在B端产品中，由于各产品干系人拥有不同的权力和付费能力，他们对需求的重视程度也不尽相同。一般来说，决策者＞管理者＞执行者的顺序决定了需求的优先级。因此权力和付费能力较高的决策层和管理层的需求通常会被优先考虑和满足。
因此我们在提取B端需求时，可以采用一个重要性公式来量化需求的重要程度：
重要性=触达量×优先级×权重值
在实际的B端需求沟通中，各部门常常为了谋求自身利益而激烈地争论各自需求的优先级，追求局部效益的最大化。这种情况下，不同部门间往往会出现激烈的辩论，每个人都试图争取自己需求的优先权。
面对来自多方渠道的需求输入，建立一套公开、透明、可靠的需求评估机制尤为重要。采用类似于”需求重要性公式”的机制可以有效协调各方对于需求优先级和上线时间的期望，从而避免对产品部门产生抱怨和不配合的情绪。通过明确的评估标准和流程，可以确保所有利益相关者都能参与到需求决策的过程中，并最终达成共识。
以上只是我针对公司角色类型以及需求评估内容的个人感悟，希望该文章对你有所启发，也欢迎感兴趣的同学一起探讨~
专栏作家
江鸟，微信公众号：江鸟的设计生活，人人都是产品经理专栏作家。8年互联网行业经验，擅长体验设计思维、设计方法论、交互设计研究。
本文原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Pixabay，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。