Enterprise Retention Means Solving Hard Problems
Enterprise products defend their long-term value by solving really hard problems. To see why, here’s a common enterprise customer lifecycle:
You build a useful product. A large enterprise company buys it.
You support your product. Enterprise teams are like airplanes where new people and crews are constantly joining and departing the same hull; the customer’s team evolves as people are promoted, hired, fired, and reorganized.
One day, a new customer leader decides to re-evaluate their software. Sometimes the reason is political, sometimes it’s financial, but the story is always the same – to some degree, all software spend is potentially on the chopping block.
When leadership turns over, many executives will bring in tools they’ve used elsewhere to demonstrate value faster. Additionally, it’s reasonably common for enterprise executives to try to make a name for themselves by building replacements to SaaS vendors – particularly technical buyers at technical companies. In both of these cases, buyers will try to remove products even if they don’t actually have viable alternatives and are otherwise happy.
Solving an obviously hard problem helps you deter these impulses and is a critical part of driving high retention rates. If replacing your product feels like a meaningful career risk, you move to the back of the line of software vendors on the chopping block.
The best hard problems are either really technically difficult, or require really dirty solutions. So what exactly makes a technically difficult or really dirty problem?
Technically Difficult
Buyers should look at your product and say “I do not know if my current team is literally capable of solving this problem, even with significant time and money.” Your problem should be obviously intimidating, like watching someone throw a 101mph fastball; it should be immediately obvious that this isn’t a feat that can be accomplished by just working harder.
A good example here would be AWS / Azure / GCP. Being able to self-host a high scale application has increasingly become a lost art, the stick shift of systems engineering. If your team has been built with the assumption that you’ll have cloud resources at your disposal, you may literally not have the knowledge of how to self-host your business. How many servers do you own – how many industrial-grade air conditioners? Has anyone on your team run a NOC before? How do they feel about doing it again?
Another example is Figma or Adobe Photoshop. Could you really build these products if you had to? How many engineers on your team are badasses at WASM or machine learning models for interpolating cloud cover in a photo?
Really Dirty
Dirty problems are solvable – it’s not like your team isn’t good enough at math to tackle them – but they look really unpleasant. Plaid or Stripe are great examples of extremely dirty problems as both are built in large part on the fact that they’ve gone and manually integrated with icky parts of the broader financial ecosystem.
These problems aren’t technically impossible for most teams, but are structurally infeasible because it would either take too much time or your team would quit before they ever got it done. If you look at a solution and think “I can’t believe someone is actually doing that as a business,” you’re on the right track.
A great way to visualize the difference between a “clean” and “dirty” problem is to think about the spectrum of data products:
Some products get to work with clean data piped fresh from the crystal-clear springs of a modern API: Think of a SaaS product built entirely on Shopify’s APIs. Engineers love this stuff.
Some products sit on top of chaotic but structured data, like Monte Carlo or Looker which run on top of a data warehouse or ensemble of data environments. This is a lot dirtier since schemas and setups can vary, but at least you’re working with data that has some kind of shape to it.
And some products sit on top of completely unstructured data, or potentially even more exotic data sources. Versions of this type of product include whatever wild company goes out and collates all of the data for shipping vessels across the world and puts them together for sale on Bloomberg.
What To Do
There are two broad takeaways here. The first is that some businesses are structurally harder to build highly defensible businesses around because the problems that they solve aren’t as difficult or dirty. These types of markets often have naturally lower barriers to entry:
Analytics: Tracking, collecting, storing, and displaying data is tough, but since you control all of the inputs and outputs it’s hard to dig a deep moat
Data middleware: Passing data around often isn’t that hard on its own, and many of the data middleware products on the market are essentially shuffling data between very clean APIs or at least highly structured data
Project management software: Low scale, structured data is relatively easy to work with
Wiki technology (anything in the Confluence, Sharepoint category): Same as project management software, but even lower scale
Forms or surveys: Forms and surveys involve collecting and displaying structured data – it isn’t that hard to replicate their technology
The other takeaway is that you can increase your stickiness by aggressively pursuing the hardest vital problems in your solution space. Most companies get traction by solving a hard but narrow problem well. Once you gain a lead in your market, use the time and resources that you’ve gained to solve the ugliest problems that are related or adjacent (note: they still have to be important). This lets you use your momentum to slam the door on new entrants to your market.
One typically starts by solving the dirtiest problems in their market:
Build all of the integrations into other platforms that your customers want, including ones that require significant configuration or complexity to set up. Wade into the muck while you have time so that others can’t.
Deal with the regulatory issues that make a market challenging to enter – for example, set up the ability to operate in every country that has meaningful addressable market, co-locate your data in every jurisdiction that cares about it.
Build all of the enterprise features that don’t make sense for your smaller competitors to invest in. Use your momentum to justify this roadmap focus.
Making your problem harder is a little bit trickier, but there are usually ways to spin a technical advantage once you’re at scale:
Improve performance. Part of the brilliance of Google Search is the fact that it’s so fast, and they’ve made it faster and faster over time. This is a hard technical problem, but once you’ve solved it, you’ve put a hard technical problem in between you and the competition.
Improve scalability. Sure your product works at food truck scale – can you make it work at McDonald’s scale, stably? If so, you’ve just locked down the largest segment of the market. Building scalable software systems is hard and most competitors won’t do it until a customer prompts them to… and hopefully they never find that customer, because you’ll win the biggest customers in the market first.
Make your product much cheaper, allowing you to offer it at more competitive prices. Many companies such as AWS, Snowflake, and Azure have worked on making their products more affordable on a marginal basis over time.
Make your product significantly more usable, and have better UX. Great UX is actually extremely hard to build because of the level of detail that needs to be captured in complex workflows.
Figure out a key feature that requires very specific technical skills, such as the ad optimizations that drive Google and Facebook’s ads businesses.
Takeaways
To build a defensible moat around your product, solve the hardest problems that your customers have. The hardest problems usually have one of two traits: They’re very technically difficult, or they’re dirty and unpleasant. One of the best ways to approach these hard problems is to use your momentum once you’re doing well in a market and intentionally invest in solving the hardest problems to dig a moat.