Spotlight on Developer Community and Go-To-Market

Recently at Accel we hosted Dev Connect, an event bringing together leaders from developer-focused companies to share advice, ideas and best practices.

As the role and voice of developers and DevOps within enterprises has grown over recent years, at Accel we have increasingly backed companies that place a premium on developer experience. This year, Humio and Rasa have joined a list that already included Atlassian, Cloudera, Instana, PagerDuty, Segment, Sentry, Snyk and XebiaLabs.

At Dev Connect, we were fortunate to be joined by the leaders of many world-class companies in this space. Speakers were James Governor, co-founder of industry analyst firm RedMonk, and the CEOs of three Accel portfolio companies: Geeta Schmidt of log management platform Humio, Guy Podjarny from open-source security provider Snyk, and Mirko Novakovic of Instana, an emerging leader in application performance management (APM).

In this conversation, they share their valuable lessons on go-to-market strategy and community building best practices for developer-focused companies.

Sometimes the developer isn’t ultimately the buyer. How do you handle that?

Mirko: When we started, APM was something you typically sold to operations. It was only after we had got our first customers, and saw hundreds of users logging in, that we figured out it was developers who were actually using it. The budget might not be theirs, but they have day-to-day responsibility and that gives them a lot of influence. That realization was a major pivot for Instana, and it’s made developers our No.1 customer, even though much of the budget is still in ops.

It’s also changed how we structure our sales team. When you’re selling to this market, every discussion quickly becomes a technical one, and you need people who are comfortable talking with developers about the details of the product.

Guy: In our case, often the dollars are coming from security, but the buy-in has to come from developers. Even if it’s not developers who are getting us into an organization, we need them to love the product and support it.

Should you ask for a sign-up to download / access your product?

Guy: When doing bottoms-up, the most frictionless approach should be the default. With our first interface, we felt very strongly that we didn’t want to have any barriers to getting started. As a result, we had great usage, but no idea who was using the product. About a year in, we introduced a free registration wall that allowed us to know our users better. We were nervous about doing it, but by this stage we had a higher level of trust and it wasn’t a problem.

Geeta: Our discussion is usually about the least amount of information we need. Also, bear in mind it might not be that useful to have someone’s email. When we’re communicating with developers it will more often be through our online Slack community than getting someone from sales to contact them via email. There are so many other ways to engage with developers now.

Where do you stand on the question of commercial vs. open source? What’s your approach?

Mirko: We start with a self-serve free trial, which gets over some of the initial friction about developers not wanting to talk to sales. Our experience is that, if they like the product, they will then initiate a conversation. We have open source elements, but it’s not our core.

We’d like to move into freemium, but you need the right feature set for that. It has to solve a problem, but not the problem. A freemium model only works if it’s attractive enough to get users engaged, but not so attractive that there’s nothing left to buy.

Geeta: One of our big competitors is open source, and there’s a lot of love for that approach and the ideology that surrounds it. Some people just don’t want to buy a product from a vendor. For us, as we sell licenses, it’s about staying focused on who we’re selling to and why. We believe that, if we can make log management an order of magnitude easier for our customers to handle, then it’s cheaper than free. There are some areas of a business in which you need to have total reliability: the real cost is not in paying for that, but when something goes wrong.  

Also, if you’re considering an open source approach, you have to be completely sure you can commercialize it, which can be really hard. You need a very clear strategy to explain why you are going down that road, and how you are going to execute.

What about on-premise vs SaaS?

Mirko: We would love to do only SaaS, but on-premise is something our biggest customers want. It represents the majority of our revenue, even though it’s only a small share of our customer base. We make it work by charging additionally for the extra support work needed, and the time it may take an engineer to troubleshoot a system they can’t immediately access.

Things are changing, and we now have banks and insurance companies on the SaaS product. But for the moment, many of the largest companies still want on-premise, so it’s crucial for us to provide it.

Geeta: We actually built for on-premise, because for our use case the log data has to be stored somewhere, and many of the enterprises we’re dealing with need it in their own environment, whether that’s AWS, a hub of their choice, or their own datacenter. For our use case it makes the most sense.

Guy: Some companies refuse to provide on-premise and have done well. You have to ask yourself why are customers asking for this, and is on-premise necessarily the best solution for that need? We do provide it, but we ask for a minimum deal size because it’s more costly for us to manage.

Another issue is about software delivery. We’re so used to being able to ship upgrades immediately, but with on-premise customers they might be on different versions, and you don’t have the same kind of instant control.

And how do you price services?

Mirko: As we are driving land-and-expand deals, customer success is key, and we don’t charge for it. For us, training customers in how to get the most out of the product is an investment in future sales. The expectation is that a successful, satisfied customer will buy more from us over time. So we have zero service revenue, and treat it as a business development tool.

What do developers want and how is that changing?

Guy: Developers are becoming the destination for all responsibility; they already own a lot of functionality, and that trend is only going to continue. For instance, they are going to become the eventual owners of a lot of security practices, just as they currently are for much of quality, functionality, ethics and performance practices.

Mirko: There is no single type of developer. There can be a world of difference between someone working for a tech company like Google or Netflix and a developer in a more traditional industry, like an insurance company that also builds software. At one of the tech companies, you have developers who probably want to do everything themselves, with full flexibility to configure – often the problem space is also very specific and narrow. But at the traditional enterprise company, the developers will have to focus more on the business (code) and therefore no-one has capacity to develop APM. The requirements are very different, and your approach has to be as well. Or you might choose to focus on one group over the other, and tailor your product accordingly.

James: Developers are defining enterprise choices in a way they never used to. The different communities that existed in the enterprise, start-up and ISV worlds are also starting to converge. Enterprise developers now want to use the same platforms as those working in start-ups. The idea that these are different markets, to be approached individually, is breaking down.

How can developer-focused companies best meet developers’ needs?

James: Developer experience is the killer app. The platforms that succeed are those which are the easiest to use, like Stripe. Remember that developers want to live in three places: their code editor, Slack, and Github. They don’t want anything that takes them out of those environments, so you have to make life easy for them.

To do that, you need empathy for the developer experience and a real understanding of how they use your product. That means having developer relations work closely with product management, ensuring that what has been learned on the ground is reflected in product decisions. If you’re not doing that, you’re just wasting money on relations.

Guy: Our strategy is to make it as easy as possible for developers to improve security. That can be about cost, usability of the product, or integrations. Or for an enterprise developer it might be about a feature like single sign-on. You have to work out what ease-of-use looks like for each of your developer groups and match the product features to their needs.

How do you build a developer community? Is it different from a user base?

Mirko: As an enterprise software vendor we have users who like our product, but not a genuine community. To create one we would have to open up more of our platform, allowing others to build plug-ins and even create their own businesses on it. It’s harder to build a community if you’re not fully open source.

A working community is great if you have it, creating advocates and broadening your effective sales team. It’s also a lot of fun. But as a vendor you can never just talk to someone: at some level you are always trying to sell.

Guy: We think about three different kinds of communities. There are user communities, which we don’t really have because the product is plug-and-play. There are platform communities, where people collaborate, share scripts and help each other to build stuff. And then there are subject matter communities, where you are trying to get developers to embrace a certain concept.

We focus on the latter, advocating for why developers should get serious about security. This can be an important part of your developer relations, but you have to manage it carefully. A community like this can’t be too product-centric, and you have to be friendly to competitors being there. It should be about knowledge-sharing and ideas, and it’s not the right place to have KPIs about people registering for product trials.

Geeta: You need the right people on your team to engage with the community. We all know that developers hate talking to salespeople. In our online Slack community, our CTO and VP Engineering are the ones leading the conversation.

Thank you all for your perspectives!