One of the big questions when building a developer product is what type or size of company to go after, with a particular question mark around large companies. Is targeting enterprise inevitable? A lot of products start for individual developers, small teams, and the long tail.
Why enterprise?
When a company starts out, its product is usually well aligned with a certain set of developers and use cases. They’re easy to get: the internal developers speak the same language as the external developers, and the product is tightly matched to their needs. Often, that initial audience is a pretty high velocity one, with lot of energy and appetite for change. Think: Heroku and Rails at the beginning.
As a company grows though, it begins to saturate its initial market. The product may have some users outside that group, but growth is harder to come by. To keep the growth going, the company needs to:
-
Pick a new group to serve
-
Understand the needs of that group
-
Understand how to communicate with that group
-
Find a channel to present that group with the company’s solution
All of this is hard, which is why you see new hires at this time, someone who has “done it before”, “understands Node developers”, etc.
Often these newer markets aren’t as open to change as the original one — right now you might find selling a service to Rust or Swift developers easier, for example, but you’ll have to do more convincing for PHP or Python devs: there’s just more best practice and known ways of doing things built up.
At each new market juncture, the product adds some sophistication, adds some complexity, and adds some customers. The next transition point is when that strategy no longer works: when there just don’t seem to be that many customers to add, or the current customers are churning at a higher rate. That churn doesn’t even have to be a product issue: if you sell to startups, a good number of them won’t be around in three years!
Hitting a limit targeting developers seems odd in a world of 20m or so software devs, but it is usually pretty straightforward: whatever your product is, and whatever it does, there are only so many people that really need it, and can pay for it. I have no idea how many people use the MongoDB OSS or community edition (probably a lot), but I do know that in August only 7400 customers paid for it.
When the absolute number stops growing as quickly (to their credit Mongo have doubled theirs over the last year!), the way to keep growth going is to earn more from each customer— and that means serving a wider variety of needs within those organizations, or serving bigger organizations.
The product is not just serving the developer, but all the people that help that developer take your product from something they like to something their whole organization can use.
Elastic had a really nice formulation of this approach:
We believe in building products that provide value and appeal to the people who use them, including developers, architects, DevOps personnel, IT professionals, and security analysts. At the same time, a software company should be able to engage and build relationships with departmental or organizational leaders who make large technology purchasing decisions. At Elastic, we do both.
It’s true that enterprises are often big, slow, hard to sell to, full of company specific requirements, and surrounded by a bevy of compliance folks, lawyers, and other corporate defense mechanisms (as documented wonderfully in this post).
All of those factors can turn into positives from a certain point of view though:
-
Enterprises are big: the annual revenue can be much, much higher at a large enterprise than an SMB.
-
Enterprises are slow, hard to sell to: enterprises don’t change technologies often, and even if they do, they often keep previous solutions around. This can mean long life times and retention rates.
-
Enterprises are complex: Building things that enterprise buyers care about (like certifications) tend to make a product more appealing to other enterprises, helping referrals.
It’s not uncommon to find one large customer making up a significant percentage of revenue. This doesn’t even to be some old-world monolith: Twilio has made between 10% and 20% of its total revenue from just Uber and WhatsApp over a large part of its history. There are relatively few businesses that can pay that much for a product, and access to that revenue can be vital.
Building a product for enterprise.
The costs of building out for enterprise fall into some pretty regular buckets.
Extensibility/Integrations: Enterprises have a lot of data stored in a lot of different stacks, so a challenge for developer products can be integrating with stores, message buses, and frameworks they may not have used before.
Sometimes this is accomplished by providing a richer or more complete set of APIs, and supporting the internal developers at the enterprise in building that out.
It’s also worth noting that sometimes these features or requirements are really just superficial: polish (in all its forms) gets treated as a signal that the vendor is serious about quality, despite the obvious disconnect between the two.
Professional Services: Getting a large company on to a new system is non-trivial, and fraught with risk. I once worked at a telco that had (at least) 4 different versions of the same case management system running, all interoperating through hacks and scripts, because transitioning specific teams was too difficult.
This can lead to bad outcomes for both customer and you — a customer might sign a deal but never get the product properly implemented. This will not lead to good renewal rates or referrals.
Offering professional services, usually consulting, implementation support, and training, is a good way to provide expertise and land the product successfully.
In general, these are priced at break-even, but some companies make a decent profit from their services. One alternative to staffing is to work with partners — these are companies that provide professional services (often agency development work) and might be interested in re-selling your product — for a cut.
Support: Similar to above — large companies want to be able to pick up the phone when something breaks. This isn’t just having agents to take the call, it means building out the support tooling and escalation procedures so that agents can really fix the problem. It also means setting up the processes to ensure that features are supportable before they launch.
Compliance, Terms and Certification: Large corporations manage a great deal of risk. Do that badly, and it can be the death of the company. This means they have checklist of criteria their suppliers need to meet, and tight restrictions on the kind of contracts they can sign.
Some alphabet soup you’ll sift through:
ToS (Terms of Service): The agreement required to use your service. Often new companies have one drafted by their first lawyer, or borrow one from another product. This can backfire when customers actually read it. Terms of service should be straightforward about what the responsibilities are, and what your service can do with customer data. Speaking off, you may also need…
DPA (Data Processing Agreement): Under the GDPR and other privacy regulations, companies need to understand how user data that they control is being processed by their vendors. This document should lay that out, and also cover any services you use (sub-processors).
Security Questionnaire: See this great post by Magoo, but in short this is a list of questions that the enterprise’s compliance and security folks ask to evaluate whether you are doing a good job keeping your data secure. Which may lead them to ask about…
SOC 1, 2, 3: Accounting auditing standards — SOC1 is financial controls, but 2 and 3 assess whether you have the right kind of processes in place for privacy, data security and so on. They’ll need an independent audit: SOC1 and SOC2 are just for the requester, but SOC3 can be shared publicly, for marketing purposes.
ISO270XX: More information processing standards, which also need to be audited.
Sales: It is quite possible to get a Fortune 500 customer on your books via a developer at that company putting in a credit card and signing up. That will rarely deliver the kind of results you want though — for that, you need sales. Sales professionals work to understand the potential customer, keep a full idea of their structure and their needs, and make the right pitch to the right decision maker.
A software developer signing up to download your IDE is likely not paying much attention to your terms, but a CIO looking to buy a license for her whole organization most certainly will (or at least will be sending it to the lawyers). For this work to have value, it has to be presented to people that appreciate it, which means marketing and sales.
Finally, it is worth noting that enterprises (and many SMBs) are unlikely to want to pay with a credit card. They’ll look to have an invoicing capability, and payment terms.
What to do?
At some point, a large enterprise customer will come knocking on your door. Whether that’s a moment of panic or a moment of joy will depend on your company structure, goals and situation. There is no reason a company has to keep growing, and no reason it has to serve enterprise customers. I think every developer-oriented company would benefit from laying the groundwork though. In particular:
-
Make sure your terms of service are sensible and scalable: don’t just copy and paste something from another supplier. Take some time to think about how you want customers to use your service, and what kind of promises you make to each other. Getting this right early will force you to consider what is going to happen long term.
-
Make your product supportable. Once you’ve got the access controls and logging you’ll probably need for your terms, you need to find a way to get back into customer data and customer services in order to debug and fix. Building in the option to do that will help your architecture, and give you the option of scaling support and professional services in the future.
On the flip side, if you’re thinking more of an enterprise focused approach, I would recommend looking at self-service options too! Organic growth and usage provide top-of-funnel for your sales efforts, and can help you take the pulse of the market much more regularly than waiting on large customer deals.
In a really healthy product a diverse range of customers benefits everyone, and helps keep the team agile and focused on solving real problems.