Selling developer products into large companies is often vital to the success of those products. Bigger annual contract values can make or break a business.
We know this involves both sales professionals and adoption by developers within the company. What isn’t so clear is how developers influence this process, and what you can do to help translate developer goodwill into winning larger deals.
Procurement
For small purchases, people just buy things. Someone decides they need something, buys it, and uses it. Large purchases often go through procurement departments. These are buying teams dedicated to using volume, market knowledge and negotiating ability to get good deals for the company. They also centralize concerns from security, risk management and compliance and ensure that all vendors and suppliers meet the bar.
This process works really well for buying dish soap or industrial chemicals, but can be painful for uncommon, low volume or specialized purchases, which describes a lot of technology. Procurement is often not a fun process to go through. Employees that want to use a service don’t like the length of time the process takes, vendors don’t the myriad hoops they have to jump through to conform to a predefined buying process.
While some products are solid by going directly to the top execs and the into procurement, most cloud/SaaS developer products take a bottoms up route. This is the approach practiced by companies like Slack, GitHub, AppDynamics, Elastic and MongoDB.
In this approach, individuals start using the product either for free or for small monthly payments. Usage spreads through other parts of the company or grows with a project of increasing significance. At some point either the amount individual teams are spending exceeds their purchasing authority or enough different teams are using the product that the company wants some higher level controls. Then the buying team gets involved, and the company negotiate a larger annual contract, with sign off from (several) executive decision makers.
In order to get through that buying process you’ll need to prove you can solve a real problem with clear business value, and deliver in production. Getting from small usage to a large sales is much easier if you engage with and listen to the individual technical practitioners using your product each step of the way.
Identifying the problem
As engineers ourselves, its easy to get focused on technology: how clever our replication strategy is, or how low our latency is. Developers and businesses adopt technologies to solve their own problems though, and to succeed we need to understand what those problems are. Often these boil down to questions of cost, continuity and capability.
Cost is often driven by parts of the business outside of the engineering group — the challenge is to keep delivering the service but to do so more efficiently. This saving can be in operations, e.g lower server costs, or in investment, e.g. lower development time. As an example, SGN describe the difficulty of continuing to meet business needs in a cost effective way:
Rather than being driven by the IT department, this was driven solely by our corporate strategy and cold, hard economics. The only way we could achieve the challenges our board had set out for the business was to adopt a far more agile, secure, cost effective, and durable way of delivering IT services — Cloud.
Where cost is the problem, enlisting developer support means helping them see the benefits in satisfaction and productivity, while still being ready to show a lower-cost story to the executive decision makers.
Continuity is about improving production quality: avoiding outages, improving service reliability, handling disaster recovery and so on. Unlike cost controls, this can come from either business concerns or from the developers themselves, who aren’t keen on getting paged in the middle of the night.
LiveRamp are a good example of a business risk:
Creating a comprehensive backup and recovery strategy has proven a difficult task, and having our crown jewels resting in an earthquake zone makes us nervous. With our move to GCP, we look forward to multiregional data replication being a breeze compared to what we have today.
Spotify instead had the push coming from the data center engineering teams themselves:
[T]he driving force behind the move to cloud came, somewhat surprisingly, from the engineers tasked with maintaining those data centres. “A big part of that was asking what their job looks like once we move to cloud,” he said. “The net result was that group of engineers, some of the most deeply respected at Spotify, ended up being advocates for our cloud strategy.”
Similarly, IHeartRadio moved from self-hosted MongoDB to Mongo’s Atlas service because of production pain:
Our various stakeholders had begun to experience negative MongoDB-related impact in their stacks, whether due to a component’s use of outdated drivers, a less-than-optimal driver setting, lack of a proper index in high-traffic collection…or the like. As more changes were made to our apps, we found more reasons to tune the clusters and engage Support.
Developers, operators and other technical practitioners are your biggest ally when continuity is the concern: they will be your champions inside the organisation, and often your job will be to get them what they need to convince their bosses.
Capabilities are about meeting a product need beyond the abilities of the current product. HTC dealt with this around app sync and offline:
“Who hasn’t had a mobile app freeze when going into a tunnel or underground subway?” says John Song, senior director of engineering of HTC Studio Group. “It can be incredibly frustrating, so improving data reliability was important to us. On top of that, we wanted to reduce bandwidth usage, particularly for regions where bandwidth is costly.”
Engineering teams usually have to make a buy-vs-build decision: do they roll out a perfectly aligned (but usually more fragile) home-grown solution, or do they buy-in and tailor something from a vendor? Without careful handling, its easy to turn a capabilities problem into developer conflict: positioning your product against their skills. For capability problems, building the feeling of a single team between developers at the customer and your own engineering group is key.
Selecting and evaluating options
Once you see usage of your product in a company and understand the problem it is solving, it’s tempting to think that you’re exempt from a further comparison and evaluation phase. Unfortunately, if there is a large bet to be placed — either in engineering commitment or dollar amounts — almost every organization will want to validate you can deliver better than competitors before signing.
This is particularly true for large companies where business units operate fairly autonomously: usage in one unit may mean very little for usage in the broader (and more lucrative) sense. Luckily, almost any well functioning organization will want their experts to evaluate any technology, and that means the developers and other technical practitioners who have started to get hands on with your product.
It’s important to understand how the product is being assessed: is it a labs or skunkworks project, is it a regional trial, or maybe a bake-off where multiple products are being used to solve the same problem?
Capital One are a good example of a very traditional company — a bank! — which is also very forward looking. They used a labs approach to test out cloud services for their core infrastructure.
Back in 2013 & 14, we started out our Public Cloud journey with what we called our “Experimentation Phase”, leveraging AWS in our innovation labs to test out the technology and operating model. In this initial stage, we had a limited number of individuals that touched the technology, and minimized the need for education to the broader organization. Those that did participate were highly motivated software engineers, some of which had familiarity with AWS before joining our company.
Once you’ve identified how the product is being evaluated, it is entirely valid to try and put your thumb on the scale! If you would be using a customer story or a use case pitch on a sales prospect, you should have developer-focused materials that helps practitioners actually build a similar experience. For example, appliance retailer AO describe:
We also found MongoDB’s 10-step methodology guide to building a single view — it was clear many customers had done this before with MongoDB — and they offered a unique blend of expertise, processes, and technology to help us deliver.
Having a real, working implementation within a company is always going to put you at an advantage versus potential competitors, but that isn’t an excuse to sit back: keeping in contact with the team who built the prototype is important to ensure their experience is good, and they’re supporting the case you’re making to the final decision makers.
Making the business case
While the technical practitioners are performing the evaluation, the final decision making on a contract is often elsewhere. These people — sometimes C-suite executives or VPs — will have a different priority set and concerns, even if they defer on the technical details to their folks on the ground.
Assuming you understand the core problem that you are solving, the next steps are to:
-
Identify who the buyer is — who is getting primary benefit
-
Find the budget that will fund the purchase
-
Demonstrate that the return from solving the problem is more than cost of the product
The second can be a surprise for startups used to pivoting and making decisions quickly, and budget can be an endless source of pain and frustration on both sides of a relationship.
If you’re pitching a straight replacement, you’re proposing taking money spent on their current provider and spending it on you. In a lot of cases though, there isn’t a simple like-for-like, and budget for entirely new things is much harder to come by, particularly as the dollar amounts get bigger. This means that most money spent comes from a budget line that was earmarked for something else.You need to understand how the business sees the value of the product, which can help you think about which existing budgets can be called upon.
As an example, if you’re trying to shop your hot new graph database into a company where developers have been enthusiastically using the free OSS version, you might assume that the VP of engineering is the ultimate buyer. However, if the data is being used for a marketing workload, the Chief Marketing Office may well be the one with the existing “analytics” budget that could be spent on your service.
The developers who have been building on top of your database likely know who is making noise about a project, and by building a relationship with them you can set your sales reps up with the information to pitch the right people at the right time.
That understanding also helps translate the problem being solved into a real value that can be compared to the cost of the service. The AppDynamics founders described their process for this in a recent a16z podcast:
If I’m talking to, say, a director of DevOps, I would say how do you make the business case to your boss to buy AppDynamics. They might say: “We have one outage a month, every time we have an outage we put 6 engineers on it and this is how much it costs us. Because our users have a bad experience, we lose revenue, this is how much is costs us.”
Finally, there are cultural factors beyond just price, and the best way to get a sense of them is regular conversations with people living that culture. For example in Lush’s case the source of the electricity their cloud provider used was a meaningful element in a decision:
A very large percentage of our network electrical costs come from renewable sources, and that was something that was important to them. From technology to philosophy, it was just very well aligned and made sense to make that move quickly.
Landing an implementation
Getting the deal signed is just the start of a deeper relationship, and from a revenue perspective the chance to increase contract values over time. Even the most self-serve product has hard edges and difficult integration points, and the customer’s developers and other technical practitioners will be running in to them.
They’ll need access to support engineers that have the tools and abilities to dig in and fix problems, training content and opportunities to improve their skills with your technology, and perhaps experts to collaborate with on the implementation.
Primero touched on this in their migration story:
Hands up for the Udemy and A Cloud Guru online courses. Besides the AWS official documentation, those online course (very cheap) were essential for training
[…] A real big mind changer was attending the Re:Invent 2017 event in Las Vegas. It was an overdose of AWS. The boot camps, chalk talks, sessions and all the other fun stuff really convinced me of thinking different.
From the executive side there is a significant amount of risk and fear around investing in a new technology: what if the database loses data, or the bills are too high? The executives signing off the purchase order are going to be the ones explaining that, and the peace of mind that comes from spending a percentage of a contract amount on professional services to ensure the system has been reviewed by those with expertise can be worth it.
You want to engender a certain kind of relationship with developers at the customer company. They need to feel like respected peers of the engineering teams on your product — whether they’re working with support teams or along side a professional services organization. If you can build a team that crosses both companies you’ll ensure your product delivers real value, and your customers keep coming back (and buying more)!
Summing Up
The days of top-down technology roll outs may not quite be numbered, but at least for developer products they’re the exception, not the rule. Successful companies build products that appeal to technical practitioners in small teams, make it easy to get started, then use that relationship to ladder up to the large contracts.
This does not, and cannot, happen by luck: it requires active engagement with developers to understand the business value they are delivering, and the organizational structure in which that value is realized. It requires an effective relationship between engineering, professional services and sales, and it requires time. By listening to developers (even if they’re not paying much right now) you can lay the foundation for that success.