4 Strategies For Building Best-In-Class Enterprise Products

Building software for enterprise customers is never easy. 

Enterprises have complex needs, many different stakeholders, and they sometimes bring up requests that stem from unique settings, and which may not directly deliver value to other customers. What’s more, some requests might be positioned as mandatory to close a deal and may come up with specific delivery dates. If you’ve worked with enterprises before, I’m sure this sounds familiar.

As a software vendor, your enterprise customers usually represent an important segment—often a strategic one. But to create a successful product you must deliver product functionality that drives impact across your entire customer base.

Faced with this, how do you find a balance, and can you keep the enterprise customers happy without slowing down innovation for others?

Gong recently won the #1 spot on G2’s enterprise software list for 2021 (across all software categories). So, I thought it would be useful to share a bit about our enterprise product-building process. Specifically, how to maintain an impact focus for all customers, but at the same time, deliver to enterprises.

Here are 4 strategies to build best-in-class enterprise products:

1. Carefully assess true impact—and optimize for that.

Enterprise customers often request features that, as the vendor, you aren’t certain will drive impact. Maybe it’s because the request came from a group that hasn’t used your software yet, so you can’t be certain they’ll use it as requested. Maybe it’s because the request comes from seeing some competitive product, which isn’t necessarily valuable in your case. Or, maybe it’s because it stemmed from a team dynamic that makes stakeholders happy, but isn’t necessarily impactful. 

You can’t always avoid building a feature that’s unlikely to provide a deep impact (more on that below). But at the very least, you can be aware and truthfully assess the situation. Then, do everything possible to prioritize features that drive impactful business outcomes. 

2. Focus on real users, not proxies.

Enterprise customers often have tens of thousands of employees, and thousands of potential users. As a software vendor, you obviously won’t have the chance to interface and get feedback from every single one. Instead, there are people and functions that serve as a proxy to vendors. It could be a liaison in the business unit deploying the software, or a cross-functional function such as IT or security. Often, enterprise customers designate a program manager to manage the software. 

The problem is, this can create a game of telephone, where end-user feedback is filtered through multiple people unfamiliar with day-to-day problems, and who may have limited visibility into the desired impact. In some cases, those people may know the software well enough to suggest solutions, but they are still not trained to design the software for you. By the time a request gets to you, it may not fully represent the end-user's needs or the best solution that your product can provide.

To combat this, resist the temptation to implement requests as they arrive. Instead, insist on good product discovery. Identify real user problems first, then use them to design the kinds of features that will deliver impact for the customer. Finally, coordinate with the supporting functions to ensure that the solutions you have in mind are aligned with their view of the business.

3. Leverage smaller customers for fast product iterations

Enterprise customers are like cruise ships: They take a long time to get going and to adjust course. As a result, it might take them several months to roll out a feature and give you feedback on its impact. 

Smaller customers are more like speedboats. They’re much nimbler. The buyer may be a user, and perhaps even the decision maker on how to use a feature. By keeping smaller customers in addition to enterprise customers, and leveraging them for product feedback, you can release new features to them first, receive feedback quickly, and iterate. Then, once the features are refined and perfected, you can extend them to your enterprise customers. 

4. Use a continuous release model to deliver efficiently.

Historically, the process of purchasing software at enterprises has been long and tedious. It involved lengthy RFPs (requests for proposals) and prolonged implementation cycles. IT organizations, who drove such processes before the SaaS age, wanted to ensure the vendor of choice supported all needs. So, they pushed vendors to add functionality to match other vendors’ capabilities. Because vendors had little incentive to deliver after the initial sale, and because they released software infrequently, enterprise buyers mandated strict delivery dates for such functionality.

In the modern subscription era, the interests of enterprises and vendors are aligned: both want the implementation to drive impact, or else the subscription will not renew. At the same time, enterprises might have needs that prevent them from realizing the impact promised by the vendor. For example, they may have a unique system that needs to connect to the product. Or, they may have unique legal requirements. Such requests may be highly specialized, and it’s sometimes unclear whether they would deliver the desired outcome to the customer, let alone to other customers. 

Rather than commit to a set of requirements and to a hard date, we at Gong attempt to optimize for impact.

We use a continuous release model, where we deliver dozens of updates per day, and control which users see which features. A public release happens monthly and includes those features that are deemed ready for public consumption.

When an enterprise customer has a unique need, we turn the customer into a design partner in the respective area. We conduct product discovery with the primary audience and determine what set of capabilities might help them achieve the full impact. 

Then, we create a minimal version of the needed feature, and make it available in a limited release mode. In this method, we do not yet invest in productizing the feature—no configuration options, no edge case handling, no detailed documentation, and, in many cases, very restricted functionality.

Because of the limited scope, we are usually able to deliver some initial value much faster than developing the feature all the way through. We can then obtain feedback and, after an iteration or two, ensure we deliver full impact—that is: see that the feature works and that it’s used as originally anticipated. 

If the feature does provide value, we can fold it into our main product over time. We can take the time to architect it appropriately. And, in some cases, rethink how it’s built and designed. When ready, we roll it out to all our customer base. In the meanwhile, we can still sign up additional design partners who may need the capability in a timely manner.

This gives us the best of all worlds: We address customer desires in a timely manner, while experimenting in a resource-efficient way, without requiring significant roadmap changes.

So, in the 6+ years we’ve been doing business, we have had only 4 cases I can think of where we committed a specific feature to a customer with an associated date.