5 Questions to Design a Developer GTM

As everyone who sells to developers knows, developers hate marketing! So, how do you think of designing your product’s go-to-market strategy? Do you just copy a great company like Twilio? Or, is there more nuance?

There are certainly things that are generally right and wrong. You need to be very authentic and useful in your communications with developers. And, developers generally want to play with technology before they buy. You have to get them successfully using your product to grow your business.

But the nuances are tricky. Do you invest heavy in evangelism? How much product do you give away for free? How and when do you have salespeople reach out to customers?

The path to answering the nuance, is in understanding the nature of value your product offers to developers and to the organization that employs them. A deep understanding of the value gives you a roadmap for solving the go-to-market puzzle.

Let’s take a quick look at the breadth of products that matter to developers. I’ll include DevOps teams too here. You can roughly divide the world into tools that help developers / DevOps be more productive and tools that reduce the amount of code developers have to write.

Developer Productivity

Cloud infrastructure like AWS, GCP and Azure simplify the operational requirements of building software.

As infrastructure shifted to the cloud, DevOps tools from companies like GitHub, Ansible, Jenkins and Chef automated code integration and deployment.

Developers use all kinds of tools to make writing and debugging and optimizing their code and apps easier. From logging and performance monitoring tools like DataDog and New Relic, to code editors like Visual Studio, Sublime Text and IntelliJ. Some tools integrate multiple functions for a specific purpose, like Postman for API development.

Code Reduction

The tools above all make developers more productive. Another approach is to reduce the need for custom code entirely, thereby reducing the need for developers. You do this for parts of your digital experience where you are not trying to do something novel or different from your competition. You just want it to be great, and fit with the rest of your experience.

Opens source code is the default way to do this. Find code someone else has written, and use it in your code.

Go a step further and you enter the realm of API products and platforms. You might have heard of some of the more notable ones out there:

• Twilio for communications
• Stripe for payments
• Okta for authentication and user management

But, there are a ton of APIs developers can use to tap into all kinds of capabilities for their apps without having to build those capabilities themselves. There’s even a marketplace now for all the APIs you might use!

Many categories, many strategies

Across all these categories of products, there are five key questions you need to answer to help you design your GTM strategy:

• How hard is it for a developer to build it themselves?
• How hard is it to use your product? (for a basic use case, or for a complex use case)
• Does the problem get bigger over time for an individual developer?
• Does the problem get bigger over time for a larger engineering team?
• How beneficial is it for an organization to standardize for this type of tool? (none, moderate, required)

These five questions give you the insight you need to make some key GTM decisions. Let’s look at some scenarios.

Scenario 1: Hard to build an alternative, easy to set up your product, problem gets bigger over time, organization standardization is moderate

• There’s a lot of up-front developer value AND strong organizational value over time
• Requires a balanced approach between developer GTM and enterprise GTM
• Offer tiered pricing. Base edition for developers, premium edition for organizations
• A lot of what I’m dubbing “developer productivity” tools fall into this bucket. Examples: GitHub, DataDog

Scenario 2: Simple alternatives for basic use cases but complex for advanced use cases, complexity to set up product depends on use case, problem gets bigger over time, organization standardization is necessary

• Minimal up-front value for developers, but grows tremendously over time and strong organizational value
• Developers will be a key stakeholder, so need to have a good developer experience and a way to enable trial and proof of concept. Focus should be then on arming a sales team to sell to senior engineering leaders, and bring in technical sales as a resource for the developers during evaluation.
• Offer tiered pricing, but design lower-end tiers more for trial than consumption. You’re not making a ton of money here on individual developers.
• Some DevOps, developer security and API management products tend to fall in this category. Examples: Hashicorp, Apigee

Scenario 3: Complex alternative, easy to deploy your product, problem grows minimally over time, low value from organizational standardization

• This is a transactional business for developers with strong up-front value
• Focus entirely on developer GTM (i.e. evangelism, dev marketing, developer experience)
• Pricing needs to weigh up-front value with potential for transactional volume. If usage volume per customer might increase a lot over time, then a transactional model could work well. However, if volume stays steady, then you’ll want to extract as much value up-front, since the pain for building it in-house doesn’t grow over time.
• Some API products fall into this bucket like the basic communications products from Twilio, or financial products from Stripe are great examples. Those companies have gone on to build on this success with products that have more organizational value beyond developers.

The 5 questions are a thorough way to solve for your developer GTM strategy. But I think I can take this one more level up with a nice, neat 2x2.

Minimal, up-front pain means you’ve got a tactical product for developers if you can make it easier to consume than an open source alternative. If the pain is longer-term, then it’s worth the energy to use open source software.

If there’s massive pain, and enough of it is up-front for devs, then you’ve got a developer to enterprise growth motion. If most of the pain shows up longer term, then it’s a strategic sale where you have to have a hybrid approach of reaching senior decision makers and getting developers to like you and your product.

Align your pain, and find your path!