B2B产品供应商的盲点(以及如何解决) “产品人员-产品经理,产品设计师,UX设计人员,UX研究人员,业务分析师,开发人员,制造商和企业家 July 07 2020 真正 B2B,B2B产品,公司文化,持续交付,Crm,文化,企业,企业产品管理,Saas,用户体验,Ux, 注意产品 介意产品有限公司 2772 构建B2B软件产品的盲点 产品管理 11.088

B2B产品供应商的盲点(以及如何解决)

通过 ON

在企业对企业(B2B)领域中开发软件的有趣的事情之一是,即使您认为自己确实需要,也经常不知道用户的需求。这样的盲点可能并不完全是您的错。

在我职业生涯的早期,我为销售人员的笔记本电脑上运行的CRM解决方案开发了一种软件分发工具。 (这是基于Web的应用程序成为规范之前的很长时间。)为了更新便携式计算机上的软件,我假设可以使用从登录用户那里继承来的管理员特权。但是在发布第一个版本后不久,我收到了令人担忧的消息:由于公司政策的原因,一些客户没有向销售人员授予其笔记本电脑的管理员特权。这些客户没有考虑到我们采访过的客户,但它们很重要。我们回到了绘图板上,设计了一个解决方案,该解决方案对于没有管理员权限的登录用户透明地工作。

让我们检查一下为什么会发生这种情况。

不了解会导致盲点

模拟B2B软件环境可能很棘手。它可以包括相互依赖的B2B应用程序网络-复杂的格局。业务流程可以扮演不同的角色,并且可以长期运行。可能存在特定于公司的策略来管理软件的使用。用户可能不在办公室里工作,而可能在工厂车间或石油钻机之类的地方工作。要了解用户的需求,您首先需要模拟其环境,这在B2B领域并不容易。

如CRM示例所示,这种缺乏理解会导致我们思维中的盲点。

B2B软件也很复杂。这并不是出于自己的利益,而是因为它试图对那些真实的业务进行建模和自动化的现实是复杂的。解决这种复杂性的一种方法是将解决方案分解为较小的模块或应用程序,每个模块或应用程序均由一个小型团队独立设计,开发和交付。虽然这样的团队可以提高效率,但他们往往错过了全局,并不太了解在更大的产品环境中如何使用其本地模块。

这再次导致盲点。此处的影响超出了用户体验。

Siloes和其他问题

以停机时间为例。您交付的SaaS应用程序会基于预定义的SLA暴露停机时间窗口。您认为一切都很好。但是,使用您的应用程序的客户也正在使用您公司的其他六种应用程序。他们都有独立的停机时间窗口。实际上,此类不重叠窗口的整​​体业务停机时间可能会对客户的业务产生严重影响。

这只是企业软件中常见模式的一个示例:应用程序或模块在其本地环境中可能运行良好,但是当与其他应用程序一起使用时,对用户的影响可能是巨大的。配置可能会变成噩梦;工作流程可能变得笨拙—跨模块的任何流程都可能导致结果不佳的风险。

B2B软件的用户通常不是购买它的用户,而这种特征是盲点的另一个来源。由于B2B软件的购买中心没有充分重视出色的用户体验(由于诸如集成,开放等竞争性利益),因此B2B供应商错过了深刻理解用户的强烈动机。在没有这种激励措施的情况下,供应商将其他质量放在首位,这会导致他们对用户的理解存在差距,从而导致盲点。

以上案例突出了由于对业务环境或上下文,全局以及用户需求的了解不足而导致的盲点。但是,如果这种理解不足,加上供应商确实确实了解需要什么的谬论,那么可能会更难解决出现的盲点。让’s see why.

以供应商为中心的世界观引发的盲点

B2B供应商可能会沦为以供应商为中心的世界观的猎物,从而导致对消费者的正确选择产生谬论。这些盲点也是由于对消费者上下文的了解不足造成的,但在这种情况下,卖方—被狭窄的世界观蒙蔽了双眼—相信对它的理解是正确的。

我曾经是一个组织的成员,发起了一项旨在协调该组织所有工具的用户界面技术的计划。从消费者的角度来看,这些工具被不同角色的人用于不同的用例-如果它们全部使用相同的UI技术,他们将毫不在意。包裹在我们自己的气泡中,看不到用户上下文,我们看不到它仅仅是 提供者视图 协调的界面。对这些消费者的影响几乎为零。提供商从一种技术的重用中受益匪浅,但这并不是最初的意图:我们确实认为我们的行为将对消费者产生积极的影响并给消费者留下深刻的印象。这是一个谬论。

这种以供应商(或提供商)为中心的世界观,无视消费者的观点,导致了导致“浪费”的盲点:使少数用户受益的产品功能。 B2B软件提供商可以避免使用它,因为大多数情况下,它导致的不良产品质量不会充分(或足够快)地影响他们的业务。至少不会影响B2C软件公司的程度和速度。

“改善”是一个视角问题

以软件提供商为中心的世界观的另一个例子是软件的持续更新。这里的条件很微妙,不容易分辨。

具备将SaaS软件连续交付生产的能力,B2B提供商认为,更频繁地交付更新正是消费者所需要的。对于B2B提供商而言,这似乎是轻而易举的事,但消费者方面的情况则更为复杂。

这些更新引入的错误可能会导致业务中断,这些错误会对企业用户产生经济影响。但是供应商仅将错误视为售票系统中报告的需要修复的项目,这种假设会导致盲点。他们以提供商为中心的世界观使供应商比消费者更轻松地进行此类部署。

我已经看到这种态度会导致客户的退缩。至少,这会导致需要一种交错的部署方法,在这种方法中,首先将软件部署到测试租户,在此之前,消费者可以在特定于消费者的环境中对软件进行测试,然后再推广到生产环境。

以卖方为中心的观点也是对消费者了解不足的结果,但这种世界观所造成的盲点导致的谬误比仅由了解程度较弱的谬论难以识别和解决。无知可以纠正,但是错误的信念很难解决。

图片包含文字,地图说明自动生成

B2C角度

很容易看出为什么B2C供应商通常不会遭受此类盲点的困扰。 B2C用户环境更易于模拟,这使得更容易理解和收集用户需求。大多数B2C应用程序很小(相比而言),通常是孤立使用的,因此了解全局并不是真正的问题。 B2C软件的用户是购买该软件的用户,因此提供商有强烈的动机通过卓越的用户体验来脱颖而出。

B2C供应商获得的激励(使他们的用户满意)超出了最初的购买行为。对于B2C应用而言,转换成本非常低:错过该标记的新产品版本可以迅速开始使采用率下降。在B2B方面,用户通常更愿意忍受次佳体验。在B2C领域中,B2B供应商享有的那种锁定式奢侈品很少见。这导致更好地了解最终用户的强大动力,从而减少了盲点。

…大多数B2B公司的文化(人员,流程,价值观等)都比客户更注重客户。

我们看不到B2C空间中残留盲点的另一个原因是,这里的反馈环路更快。软件可以更快地为B2C用户提供服务,他们可以直接提供反馈-B2B用户无需分层就可以导航,然后再为该问题赋予足够的优先级并将其报告给供应商。

但是,近年来B2B领域发生了变化。随着SaaS成为其首选的交付模式,并且随着采购中心从公司IT转移到业务线,用户体验现在也被视为与众不同的地方。 SaaS还简化了测试用户体验的过程,并且缩短了反馈循环(与本地软件相比)。像Slack或Box这样的新时代B2B供应商提供的体验可以与目前最好的消费者软件相匹配。

尽管发生了这种转变,但大多数B2B公司的文化(人员,流程,价值等)都比客户更侧重于客户。而且,要改变这种文化,这是由经济学,B2B软件的销售方式以及向谁出售所驱动的,这比我们想象的要难。

识别盲点

这些盲点该怎么办?意识到它们的存在是一个开始。下一步是确定它们。这需要对客户的业务环境有更广泛的了解,对B2B产品的全面理解以及对B2B用户需求的更好了解。

这些目标大致可分为两种类型的措施:

  1. 减少与客户的距离
  2. 缩短内部职能之间的距离

1.缩短与客户的距离

随着企业规模的扩大,保持效率所需的劳动分工导致客户与开发软件的团队之间的许多层次。在大型企业中,遇到从未与客户或最终用户交谈过的开发人员并不少见。

您可以采取几种方法来缩短此距离。

  • 根奇玄武起源于丰田的一种做法 在自己的工作环境中观察用户。在了解用户方面,很少有技术可以与这一技术相匹配。它还使您能够确定用户说的是他们真正想要的。令人惊讶的是,两者有时可能会有所不同。
  • 经常 邀请客户与您的团队交流 帮助他们了解如何在更广泛的环境中使用他们设计和构建的软件,以及现实生活中的挑战。
  • 客户共同创新项目B2B提供商与一个或多个消费者共同开发解决方案的方法是弥合提供商与消费者之间的脱节的有效方法。他们可以很好地了解客户的业务环境,这超出了项目时间范围本身的价值。
  • 让设计师和开发人员参与 产品层面的客户访谈 有助于提高全局意识。在此类采访中,明确询问客户的环境很重要:他们的环境(软件和物理环境)是什么样的?他们还使用其他什么解决方案(第三方或开源)?他们在组织中扮演什么角色?他们的组织与使用该软件的其他组织之间的关系如何?这些问题是理解您听到的这些具体要求背后原因的关键。
  • 接近客户的另一种方法是建立一个 内部客户环境,用于测试。维护这样的环境(或环境)可能很昂贵,并且聘请具有特定领域客户经验的测试人员也不便宜。但是,此类测试有助于识别出属于提供商盲点的问题,这些问题只有在以后才被客户发现(事实证明,这些问题的处理和修复成本更高)。
  • 拥有丰富客户经验的顾问可以为您提供帮助 proxy to customers。采访他们有助于您确定许多客户共有的模式,并且它们也是吸引用户研究活动的有吸引力的候选人。

2.缩短内部职能之间的距离

企业中的劳动分工也造成了孤岛。虽然小型(孤立的)团队在当地情况下有效运作,但在较大产品范围内的输出却可以发现意外地方的裂缝。筒仓也增加了专业化程度,给定功能的专家通常不具备检测跨功能的过程中的问题的能力。要发现此类盲点,您需要通才:花了很多时间从事各种职能并可以放宽视野的人员。大卫·爱泼斯坦(David Epstein)的新书 范围:为何通才在专业化世界中获胜 说明了为什么在知识经济中解决复杂问题需要人们看到不同领域之间的联系。受隧道视野限制的专家无法识别和协商这些盲点。

对于用户而言,筒仓的影响无处比在产品的用户体验中更明显。

通过召集具有不同职能的人员,可以培养通才和解决孤岛的影响。 DevOps方法使开发人员和操作人员之间更加接近,这是跨功能实践的一个很好的例子,该实践现已编纂为软件工程原理。为了识别筒仓中出现的盲点,我们需要更多这样的跨功能组合:跨工程和客户支持,跨工程和用户体验,等等。

用户体验(UX)角度值得重点关注,因为孤岛的影响对消费者而言比在产品的用户体验中更明显。用户体验是 行为 产品表面的形状。

但是问题不仅仅在于UX功能。与用户体验相关的盲点还可以源自与用户界面不直接相关的决策。例如,团队选择的技术堆栈可能会导致与其他应用程序或产品的集成不佳-这在生命周期的早期就不可见。为了解决这个问题,UX必须与所有生命周期阶段涉及的不同功能紧密配合。正如有人所说,设计太重要了,不能交给设计师。

盲点也出现在我们对用户体验的理解的边缘。当重点是确定应用程序核心的UX问题时,可能会漏掉一些有问题的方面,例如找到在哪里访问应用程序,如何配置应用程序,获得正确的用户权限,等等。 UX需要解决整个产品生命周期,而不仅仅是应用程序的运行时。这也需要跨职能的方法。

修复盲点

识别盲点本身就是朝着修复盲点迈出的一大步。在该阶段发现的见解可以得出解决方案的想法,并且用于识别盲点的方法通常会提出解决方法。例如,跨职能团队是解决这些职能之间边界上出现的盲点的理想架构。客户共同创新项目不仅可以帮助B2B供应商了解客户背景和需求,而且可以满足这些需求。

在团队内部,其中一些方法很容易在小规模范围内启动。缩短与客户的距离是每个团队都可以进行的工作。其他方法需要利益相关者网络之间的协作。

这种跨职能的协作比常规更多的是例外。组织结构通常是围绕各个功能设计的,因此很难围绕此类结构进行工作。这解释了为什么即使已知盲点仍然存在许多盲点的原因。有时需要采取战略性,自上而下的命令来解决。回想一下前面提到的停机时间窗口示例:只有通过公司范围内的计划来对齐停机时间窗口,才能解决此问题。

长期方法

到目前为止,我们已经看到B2B供应商之间的盲点并不是一次性的-它们是由B2B软件领域中存在的系统性问题引起的,并且与B2B软件业务本身的性质紧密相关。

具有一次性的解决特定问题的战略计划充其量只是一个临时解决方案。只有文化的转变才能影响持久的变化,并导致可以识别和处理盲点出现的行为。所需要的是一种在全公司范围内重视并始终专注于与客户及其用户保持密切联系的文化;一种培养通才的文化,这种通才可以发现专家遗漏的事物;和优先考虑定期跨职能协作的文化。

换句话说:要识别和解决B2B软件行业中常见的盲点,就需要一种持续的长期方法。