post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

How to build a companion product and win user trust

mission statement

Deep dive: Crafting your product vision and mission

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Join us at #mtpcon London in 2025 – mark your calendars

How Google makes AI work at Enterprise scale – Miku Jha (Director, AI/ML and Generative AI, Google Cloud)

5 ways to invent and simplify as an AI/ML product manager

Why teams often struggle with OKRs: A conversation with Jeff Gothelf

Building your own user experience and software stack: This week’s product news

Manohar loves to craft great customer experiences together with problem solvers from Product Management and Engineering. He has over two decades of experience in the enterprise software industry. Until recently he was with SAP in Germany, heading a unit developing cloud-native services for the SAP Cloud Platform.

Advisor - Product & Tech Strategy

Manohar Sreekanth

<div></div>
<p>One of the interesting things about developing software in the Business-to-Business (B2B) space is that you often don’t know what users need, even when you think you do. Such blind spots may not be entirely your fault.</p>
<p>Early in my career, I developed a software distribution tool for a CRM solution that ran on the salesperson’s laptop. (This was long before web-based applications became the norm.) To update the software on the laptop, I had assumed the availability of administrator privileges inherited from the logged-in user. But soon after the first version was released, I received worrying news: due to company policy, some customers did not give their salespeople admin privileges on their laptops. These customers hadn’t figured among those we had interviewed, but they were important. We went back to the drawing board and designed a solution that worked transparently to the logged-in user who didn’t have admin rights.</p>
<p>Let’s examine why this happened.</p>
<h2>Blind Spots Caused by Poor Understanding</h2>
<p>Simulating B2B software environments can be tricky. It can include a network of interdependent B2B applications — a complex landscape. Business processes can span different roles and can run for a long time. There may be company-specific policies that govern software usage. Users may work not in offices but in spaces like a factory floor or an oil rig. To understand a user’s needs you first need to simulate her environment, which is not easy in the B2B space.</p>
<p>As the CRM example showed, this lack of understanding leads to blind spots in our thinking.</p>
<p>B2B software is also complex. Not for its own sake, but simply because the reality it tries to model and automate — those real businesses — is complex. One way to manage that complexity is to break the solution into smaller modules or applications, each of which is designed, developed, and delivered independently by a small team. While such teams can be efficient, they often miss the big picture and don’t quite see how their local module is used in the context of the larger product.</p>
<p>This again results in blind spots. And the impact here goes beyond user-experience.</p>
<h3>Siloes and Separate Concerns</h3>
<p>Take downtime windows, for instance. The SaaS application you deliver exposes a downtime window, based on a predefined SLA. You assume all is well. But the customer using your application is also using half a dozen other applications from your company. And they all have their independent downtime windows. In effect, the overall business downtime of such non-overlapping windows can have a serious impact on the customer’s business.</p>
<p>This is but one example of a common pattern in enterprise software: an application or module may work well in its local context, but when used in concert with other applications the impact on the consumer can be overwhelming. Configuration can turn into a nightmare; workflows can become unwieldy — any process that spans modules runs the risk of a sub-optimal outcome.</p>
<p>The users of B2B software are generally not the ones who buy it, and this trait is another source of blind spots. As buying centers of B2B software do not place enough emphasis on great user experience (due to competing interests like integration, openness, etc.), B2B vendors miss a strong incentive to deeply understand the user. In the absence of such an incentive vendors prioritise other qualities, which results in gaps in their understanding of users, which in turn leads to blind spots.</p>
<p>The above cases highlight blind spots caused by poor understanding — of the business environment or context, of the big picture, and of the user’s needs. But when this poor understanding is coupled with a fallacy that the vendor truly does understand what’s needed, the blind spots that occur can be harder to address. Let&#8217;s see why.</p>
<h2>Blind Spots Triggered by Vendor-Focused Worldviews</h2>
<p>B2B vendors can fall prey to a vendor-focused worldview that leads to fallacies about what’s right for the consumer. These blind spots are also caused by poor understanding of the consumer context, but in this case the vendor &#8212; blinded by its narrow worldview &#8212; believes that the understanding it has is correct.</p>
<p>An organisation I was once a part of launched an initiative to harmonise the user interface technology of all tools coming from that org. On the consumer side, these tools were used for different use-cases by people in different roles — they couldn’t care less if all of them used the same UI technology. Wrapped in our own bubble, blind to the user context, we couldn’t see that it was only <span style="font-style: italic;">the provider view</span> of the interface that was being harmonised. The impact on those consumers was close to zero. The provider benefited somewhat from the reuse of one technology, but this was not the original intent: we really thought our actions would impact and impress consumers positively. Which was a fallacy.</p>
<p>Such vendor (or provider)-focused worldviews that disregard the consumer perspective lead to blind spots that result in “waste”: product capabilities that benefit few users. And B2B software providers can get away with it because most often the poor product quality it results in does not impact their business enough (or fast enough). At least not to the extent and speed with which it would impact a B2C software firm.</p>
<h3>“Improvement” is a Matter of Perspective</h3>
<p>Another example of a provider-focused worldview comes up in the matter of continuous updates to the software. The condition here is subtle, not easy to discern.</p>
<p>Armed with the ability of delivering (SaaS) software continuously to production, the B2B provider assumes that more frequent delivery of updates is just what the consumer needs. While this may seem like a no-brainer to the B2B provider, the situation on the consumer side is more complicated.</p>
<p>Bugs introduced by these updates can mean disruptions to businesses — the bugs have an economic impact on the enterprise consumers. But the vendor treats bugs merely as items reported in the ticketing system that need to be fixed, an assumption that results in a blind spot. Their provider-focused worldview makes vendors take such deployments much more lightly than the consumers do.</p>
<p>I’ve seen this attitude result in push-backs from customers. At the minimum, it leads to a demand for a staggered approach to deployment, where the software is first deployed to a test tenant where the consumer can test it in the consumer-specific context, before promoting it to production.</p>
<p>The vendor-focused perspective is also a result of poor understanding of the consumer, but the blind spots caused by such a worldview lead to fallacies that are harder to identify and fix than the ones caused only by poor understanding. Ignorance can be rectified, but mistaken beliefs are a lot harder to fix.</p>
<p><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2020/08/b81fb029-a7b5-45bd-a5fd-1354ee2923d7_image1.png" alt="A picture containing text, map Description automatically generated" /></p>
<h2>The B2C Angle</h2>
<p>It’s easy to see why B2C vendors usually do not suffer from such blind spots. The B2C user environment is simpler to simulate, which makes it easier to understand and gather user requirements from. Most B2C applications are small (in comparison) and typically used in isolation, so understanding the big picture is not really a problem. And the users of B2C software are the ones who buy it, so providers have a strong incentive to differentiate themselves with superior user-experience.</p>
<p>The incentives B2C vendors have (to keep their users happy) go beyond the initial buying behaviour. Switching costs are very low for B2C applications: new product versions that miss the mark can quickly start a slide in adoption numbers. On the B2B side, users are generally more willing to tolerate sub-optimal experiences for longer. And the luxury of lock-in that B2B vendors enjoy is rare in the B2C space. This results in a strong drive to better understand the end user, which leads to fewer blind spots.</p>
<blockquote><p>&#8230;the culture (people, process, values, etc.) of most B2B companies is oriented more towards the customer than the user.</p></blockquote>
<p>Another reason why we don’t see blind spots linger in the B2C space is that the feedback loops are faster here. Software reaches B2C users faster, and they can provide feedback directly — without layers of hierarchy a B2B user has to navigate before the issue is given sufficient priority and reported to the vendor.</p>
<p>But the B2B scene has changed in the recent years. As SaaS becomes its preferred delivery model and as the buying center moves from corporate IT to the lines of business, user experience is now being touted as a differentiator here too. SaaS has also made it easier to test user experience, and it has shortened the feedback loop (in comparison to on-premise software). New age B2B vendors like Slack or Box offer experiences that match the best consumer software out there.</p>
<p>Despite this shift, the culture (people, process, values, etc.) of most B2B companies is oriented more towards the customer than the user.  And changing that culture — which is driven by economics, by how B2B software is sold and to whom — is harder than we think.</p>
<h2>Identifying the Blind Spots</h2>
<p>What can we do about these blind spots? Being aware that they exist is a start. Identifying them comes next. This requires a broader awareness of the customer’s business context, a holistic understanding of the B2B product, and a better grasp of the B2B user’s needs.</p>
<p>These goals roughly map to two types of measures:</p>
<ol>
<li>Reducing the distance to the customer</li>
<li>Reducing the distance between in-house functions</li>
</ol>
<h3>1. Reducing the distance to the customer</h3>
<p>As enterprises grow in size, the division of labour needed to retain efficiency results in many layers between the customer and the team developing software. In large enterprises, it is not uncommon to run into a developer who has never spoken to a customer or an end-user.</p>
<p>There are several approaches you can take to reduce this distance.</p>
<ul>
<li><span style="text-decoration: underline;"><a href="https://whatis.techtarget.com/definition/Genchi-Genbutsu">Gentchi Genbutsu</a></span>, a practice that originated in Toyota, involves <span style="font-weight: bold;">watching users in their own work environments</span>. Few techniques can match this one in understanding the user.  It also enables you to find out if what the users say they want is what they actually need. Surprisingly, the two can sometimes be different.</li>
<li>Regularly <span style="font-weight: bold;">inviting customers to speak to your teams</span> helps them see how the software they design and build is being used in a broader context, and what the real-life challenges are.</li>
<li><span style="font-weight: bold;">Customer co-innovation projects</span>, where a B2B provider works together with one or more consumers to develop a solution, are an effective way to bridge the disconnect between providers and consumers. They offer excellent exposure to the business contexts of customers, which is valuable beyond the project time-frame itself.</li>
<li>Getting designers and developers to participate in <span style="font-weight: bold;">customer interviews at the product level</span> helps to create big picture awareness. In such interviews it is important to explicitly ask for the customer context: What does their environment (software and physical) look like? What other solutions — 3rd party or open source — do they use? What are the roles in their organisation? How is their org placed in relation to other orgs that use the software? Such questions are key to understanding the reasons behind those concrete demands you hear.</li>
<li>Another way to get closer to the customer is to set up a <span style="font-weight: bold;">customer-like environment in-house for testing purposes</span>. Maintaining such an environment (or landscape) can be expensive and hiring testers with domain-specific customer experience is not cheap either. But such tests help identify issues that fall within the provider’s blind spots and are found only later, by the customer (which turns out more expensive to deal with and fix).</li>
<li>Consultants who have experience with a diverse set of customers serve as a useful<span style="font-weight: bold;"> proxy to customers</span>. Interviewing them helps you identify patterns common to many customers, and they are also attractive candidates to recruit for user research activities.</li>
</ul>
<h3>2. Reducing the distance between in-house functions</h3>
<p>The division of labour in enterprises also creates silos. While small (and siloed) teams operate efficiently in their local contexts, their output in the context of the larger product can reveal cracks in unexpected places. Silos also increase specialisation, and specialists in a given function are typically not equipped to detect issues in processes that span functions. To identify such blind spots, you need generalists: people who’ve spent time in different functions and can take a broader view. David Epstein’s recent book <span style="font-style: italic;">Range: Why Generalists Triumph in a Specialised World</span> shows why, in a knowledge economy, solving complex problems needs people to see connections between different fields. Specialists, restricted by their tunnel vision, are unable to identify and negotiate these blind spots.</p>
<blockquote><p>Nowhere is the impact of silos more visible to consumers than in the user experience of the product.</p></blockquote>
<p>Fostering generalists and dealing with the effects of silos can be achieved by bringing together people from different functions. The DevOps approach – which brings development and operations folks closer to one another – is a great example of a cross-functional practice now codified as a software engineering principle. To identify blind spots that emerge from silos, we need more such cross-functional alignments: across engineering and customer support, across engineering and user-experience, and so on.</p>
<p>The user-experience (UX) angle merits greater focus, because nowhere is the impact of silos more visible to consumers than in the user experience of the product. User experience is where the <span style="font-style: italic;">behaviour</span> of a product surfaces.</p>
<p>But the matter isn’t only about the UX function. User experience related blind spots can also originate in decisions not related directly to the user interface. For instance, a team’s choice of technology stack can lead to poor integration with other applications or products — something that isn’t visible early on in the lifecycle. To address this, UX must work closely with different functions involved across all lifecycle stages. Design, as someone said, is too important to be left to designers.</p>
<p>Blind spots also occur at the edges of our understanding of user experience. When the focus is on identifying UX issues at the core of an application, problematic facets at the margin can be missed — like finding where to access the application, how to configure the application, getting the right user permissions, and so on. UX needs to address the entire product lifecycle, and not just the runtime of applications. This too requires a cross-functional approach.</p>
<h2>Fixing the Blind Spots</h2>
<p>Identifying the blind spots is in itself a big step towards fixing them. Insights found in that stage can lead to solution ideas, and the methods used to identify blind spots often suggest ways how to fix them. For instance, cross-functional teams are the ideal construct to fix blind spots that arise at the boundary between these functions. Customer co-innovation projects not only help B2B vendors understand the customer context and needs, they also are the place where those needs can be met.</p>
<p>Some of those methods are easy to initiate at a small scale, within a team. Reducing the distance to the customer is something every team can work on. Other methods demand a collaborative effort between a network of stakeholders.</p>
<p>Such cross-functional collaboration is more the exception than the norm. Org structures are typically designed around individual functions, and it is hard to work around such structures. This explains why many blind spots remain, even when their existence is known. Sometimes a strategic, top-down imperative is needed to address it. Recall the downtime windows example mentioned earlier: such a problem can be solved only through a company-wide initiative to get those downtime windows aligned.</p>
<h2>A Long-Term Approach</h2>
<p>What we’ve seen so far is that blind spots among B2B vendors are not one-offs — they arise out of systemic issues that exist in the B2B software space, and are closely linked to the nature of the B2B software business itself.</p>
<p>Having a one-off strategic initiative to fix a specific issue is at best a temporary solution. Only a shift in culture can affect long-lasting change and lead to behaviours that can identify and deal with blind spots as they arise. What’s needed is a culture that values, across the company, a conscious and persistent focus on staying close to customers and their users; a culture that fosters generalists who can spot things that specialists miss; and a culture that prioritises regular cross-functional collaboration.</p>
<p>In other words: to identify and resolve the blind spots endemic in the B2B software industry, a sustained long-term approach is needed.</p>

The Blind Spots of B2B Product Vendors (And How to Fix Them)

Manohar Sreekanth

Read more

Comments