Design in Enterprise Software Companies
Enterprise Software Companies Are Getting Design Wrong
by SVPG Product Partner Chris Jones
A frequently cited difference between B2C and B2B products is the relationship between a product’s users and its buyers. For B2C, the common wisdom says the user and buyer are one in the same; but with B2B, user and buyer are different people with different goals. Buyers need to know that the product will provide a return on investment, while users care more about how easy it is to use and how well it maps into their workflow. This shorthand is particularly prevalent with enterprise software vendors that have a large, expensive, specialized field sales force selling into highly-placed buying centers.
Unfortunately, many of these companies use this model to justify an underinvestment in product design. They believe success is more dependent upon sales and engineering as those are the things that most impact the acquisition of new customers. For them design is a luxury that serves the end-users who will be fully served only after some degree of commercial success.
This is a mistake and reflects a misunderstanding of the role of product design in creating successful products. I’m not making another “focus on the user” pitch. My motivation for investing early in product design has as much to do with buyers as it does the users. This rests on the understanding that our job in product is not only to be the thing that is sold by the sales force; the product itself must also connect customers to its value. Our design must serve both users and buyers.
Here are just a few ways where product design is relevant to connecting buyers to your product’s value.
(1) Product Design Communicates Product Positioning
The enterprise sales process is complex, involving a large collection of buyers and influencers coming to some level of agreement before purchasing an expensive solution. These people have lots of conversations often without the sales person being present. The sale depends on the customer using the terms and concepts that appropriately frame our solution and the value it brings. This is the product “positioning” and in many cases it is carried by the product itself.
I was an early product manager for an enterprise software company called Vontu (ultimately acquired by Symantec). Our initial product allowed companies to monitor their outbound network traffic for evidence that their confidential data was inappropriately leaking out of the company. This technology came to be called Data Loss Prevention (DLP) and is commonplace now, but at the time it represented a fundamentally different approach to information security.
One critical decision we made early on was to invest heavily in the design of the product in order to better educate and influence the buyer. Yes, the users would be the ones actually operating the system but our buyers were the ones who needed to be brought on the journey first. Our approach to the data loss problem was new and it was important for us to own the the mental space of how it would fit into the customer’s world. We needed to show exactly how our product related to their current conceptions of “confidential data”, “data policy”, “incident”, “remediation” and how it would help them manage these real-world concerns.
To be sure, we had some great product marketing and sales people, but we also made sure the product was telling its own story. Through demos and screen-shot workflows, we put the product at the center of the sales process. These communicated the value proposition, but more importantly they established the conceptual framework upon which all other competitive solutions were evaluated. Not only was Vontu delivering real value to its customers, it quickly became the solution to which all other venders were compared.
(2) Product Design is Fundamental to a Product’s Core Value Proposition
Traditional waterfall-minded development follows a strict sequence: functionality (in the form of requirements) drives a user interface, which in turn drives the technical solution. In a few cases, these last two steps are inverted, but either way the process usually entails a single pass through the sequence. In contrast, modern product practitioners know that these three parts are deeply intertwined with interactions that rarely follow that simple pattern. Often, it is a design insight that motivates a technical approach which uncovers new possibilities (requirements). In some cases, a design insight may actually motivate the core product value itself.
Building on the Vontu example, the early design decisions we made for representing things like data policy or security incidents were not simple window-dressing on a set of realized requirements. These designs, validated through many customer interactions in prototype form, fundamentally affected how we positioned the core value of the entire product. One particular aspect of the design — the way we highlighted non-compliant data in a transmission — was the most frequently cited reason why a customer purchased our product. This representation of information had huge architectural ramifications. It was not something we could have simply added later either to our product or to its positioning.
(3) Product Design Enables New Paths to Market
Consumerization-of-IT trends continue to raise the bar of an acceptable user experience. For some categories of enterprise software the trends are even affecting the route to customers. Instead of the typical enterprise-wide procurement process, departments and smaller working groups make their own decisions about many of the tools they use. Users and buyers converge; as with b2c, customers of these products have very high demands on the user experience.
The Poster Child for this Go-To-Market dynamic is Slack whose initial growth was entirely organic and involved very little marketing spend and no direct sales. Individual employees and department leads discovered the product through word-of-mouth, PR, and social media. The product experience included painless installation and a very short time-to-value. This resulted in further adoption and word-of-mouth evangelism. In short, the product experience itself was a primary driver of customer adoption.
Of course not all enterprise products are compatible with this type of Go-To-Market, but it is becoming an increasingly important part of the conversation for more and more classes of product in the enterprise. If you are not investing in design there’s a good chance a new competitor is, and that competitor may be in a position to attack your market in a whole new way because of it.
The important realization is that you should never fixate on just the user or the buyer in isolation. Instead, your notion of the customer must include both. I prefer to think of a the customer as an ecosystem of interests each relating to different facets of buying, using and supporting the solution. Our job as product people is to understand this ecosystem so that we can design and build our product to best deliver its value.
When you look at it this way, enterprise software is really not that different from any other type of product. It must serve the design needs of the whole customer, even if that customer is split across multiple individuals.