Building an effective developer-focused go-to-market framework

I've been in the B2B space predominantly for most of my career, and it's only been recently that I’ve jumped head-first into developer marketing. And boy, has this been a ride so far.

I’ll be talking about my experiences and learnings in the last few years as a product marketer moving into this developer marketing space, along with:

The typical challenges that come with go-to-market (GTM) motions when it’s a developer-focused product
The changing landscape
What are the certain developer-focused flavors that exist in a GTM motion?
How to measure the success of your GTM execution

The changing landscape of go-to-market

To begin with, as product marketers, technologists, and even founders, I think it's remarkable the amount of attention that we give to the changing landscape of technology trends. But, as a community, we’re not that cognitive or even aware of the changing evolution trends that happen in go-to-market itself.

Go-to-market itself evolves rapidly. What we were 20 years back, and even 10 years back, has definitely changed from what we are today.

Take a classic example: the first typical go-to-market motion from the 90s. There's an Oracle database and you're selling it to the CIO over lunch. At least that's the mental model I have. And there’s a certain kind of asymmetry between the user and the buyer in this scenario.

I'm not saying that enterprise sales is dead. It’s still there. But the way that we’ve reached, or are currently reaching, enterprise sales has definitely changed.

So, with this 90s model, there was this product quality experience that diminished from the journey of the buyer to the user.

The CIO buys the database and, by the time the user typically uses it, the user is probably embedded deep within the organization and isn’t even aware of this particular decision.

Then came the radical shift to SaaS. And this was a time when it was so easy. You could just sign up, go and plug in your email ID, and sign up for a particular SaaS application. And you could sell to a department or team where the team didn’t have the burden of any implementation complexity when it came to using that particular tool.

This was quite radical to think about at the time.

And then came the next go-to-market motion, which is 3.0, the current one where Web3 is present and decentralization is happening in terms of the buying power.

In this particular GTM motion where we are today, it’s quite interesting because this is where a lot of your developer marketing noise is happening. Developer as a buyer with the budget power is currently present.

And this is where product adoption or, rather, the bottoms-up product-led growth is also happening where your end goal is to get product adoption, give that power to that individual user who can test your product, and then slowly move that to a self-serve online motion for teams. And then, perhaps, it even moves to the enterprise motion.

There are certain changes or trends that have led us to this particular point, starting with an increase in cloud adoption. It’s easier now than ever before for companies to build and scale DevTools. The purchase power with developers is definitely there. Developers are becoming the buyers with the budgets to purchase.

And the fast-paced change in technology itself is enabling developers to test multiple tools and give an impressive feedback loop back to the technology in such a way that it's becoming a continuous improvement cycle.

Again, these are just a few trends that are currently under the radar that has led to the GTM 3.0 motion. I'm not going to touch base on all the other socioeconomic factors that have influenced this in the last few years.

Now, moving slightly deeper into this changing landscape, we’re going to look at Heroku’s one, two, three framework. What this essentially talks about is that the value proposition of what you’re going to give an individual user should definitely be different and unique. Not ideally unique, but different to the value proposition that you have for a team's user.

What I mean here is, say a developer is using the Heroku app and deploying an app. The value proposition here for an individual is unique, and you compare that to a team's product where it’s almost always centralized around collaboration. So, that's a shared process. Multiple team members are using the product and there are shared business processes that they’re trying to achieve with that.

The main takeaway is to understand this particular motion. Ideally, you’re now running almost three distinct business units. One is the free individual product, one is your team's product, and one is your enterprise product.

And this is of interest mainly because a developer as a buyer becomes more important. Once a developer uses the product, they recommend it to their team, and the team uses it. And sometimes even that can turn into an enterprise motion as well.

Take the example of Postman. Postman is an API creation management tool at an individual developer level. This tool is basically something that helps a developer in creating APIs. But you take that and move it to a teams level. It's the same thing. It becomes a shared process between the teams where they’re working on their API creation activities.

So what Postman quickly realized is that with the same product with different value propositions that you can highlight from an individual to a teams product, you’re able to highlight a real strategic business value and take that growth story from your 0 to 1 and the next million.

4 developer-focused flavors in a go-to-market motion

Now, with this understanding of the changing landscape in the overall GTM motions, what are the different flavors of dev-focused software?

In an open-source scenario, open-source audiences demand high value in exchange for payment, but they consistently innovate and provide impressive feedback loops for commercial purposes. Examples are your MongoDB Elastic, etc.

And the second is API-first applications. API-first applications are pretty much the backbone of most products. Audiences of these products can be challenging to target from a messaging and a website perspective, mainly because most of the APIs don't have as much of a user interface as a developer application.

This is why your documentation becomes super, super important for API-first applications. One of my favorite API-first applications is Stripe. I think they’ve done a brilliant job with their documentation, even including as much as leveraging their documentation as a conversion channel.

The third is developer application. Any product that’s built for developers that doesn't fall into the open source or API category is a developer application, like Datadog and Squadcast.