How to sell your product to developers

April 15, 2022

4 min read

When asked about what factors are considered before integrating with an API, more than two-thirds of Postman’s 2021 survey respondents cited 4 major factors: security, performance, reliability and documentation.

We introduced reliability as a major metric to monitor and how including a Service Level Agreement can help your users trust your product. We’ll now dive deeper in what’s product-led growth and how by having this growth model, you can sell to developers.

What is product-led growth?

It’s a customer acquisition model that relies on the product and its viral hooks to drive customer acquisition, conversion, retention and expansion. It’s been around for more than 10 years now and generally applies to products that sell themselves without the intervention of a sales team.

Users can use the product without having to talk to a salesperson. Product-led products are user-first and they’re easy to sign-up, buy and integrate. And they make a perfect match for developers.

OpenView’s VP of Growth, Sam Richard, created this framework to help PLG companies perform better via the following steps:

Activation
Start
Discovery
Convert
Scale

She explains in the “Convert” stage, that “Product-led businesses focus on […] getting users to subscribe” so they can receive value before hitting the paywall. And that’s how one should approach the act of selling to developers. Examples of drivers to convert are self-serving buying experience and free trial offerings.

(She also demonstrates that PLG companies perform better than all companies, but that’s another article)

Examples of high-performing PLG companies include Twilio, Slack, Calendly, Dropbox…

Sell to developers through good documentation

Developers don’t like to have to talk to sales. They prefer a self-service experience where they can find all the information they need to start using the product.

Twilio’s ex-CMO, Sara Varni Bright, explains how Twilio managed to successfully sell to developers for 11 years without a sales team by “not making them pass through a sales rep call asking them what their budget is or their timeframe “. They instead chose to “focus on every step of the journey where [they] can unblock developers and get them to what they need to do”. They did that by investing a lot of time and effort in their documentation and code snippets so users could get a clear idea of what they could do with Twilio.

As you can see, their API documentation has a lot of great features to make the developer’s experience flawless:

Each endpoint has been documented in 10 different libraries
Each endpoint has a code snippet ready to be copy-pasted
A feedback survey has been provided to monitor performance and spot improvements
In-depth tutorials and specific use cases examples are provided
All properties are explained with their limits
Twilio’s status is a click away and available on all pages.

They also created a sense of community and a real eco-system for devs to thrive in:

A Postman collection is available to facilitate the learning curve
A tag on Stack Overflow has been created to easily filter Twilio questions
A community is dedicated to supporting users (from being hosted on their website, it has recently been moved to a Stack Overflow collective)

Sell to developers by reducing the TTFHW

TTFHW is a metric used to know how much time a developer would need to publish their first “Hello World” using a platform or API. If you don’t have it yet, it should be one of your north star metrics as it includes adoption, usage, marketing and support performance information.

Time To First Hello World is the time spent by a developer to reach an MVP with your API.

Optimizing your TTFHW is crucial for your developer users and the viability of your product. A short TTFHW builds developer confidence in the API’s organization and in your product overall.

To do that, you first have to decide on the moment where a developer would consider their goal achieved and then shorten it as much as possible.

This could include:

The ability to test the product right from the website or documentation without having to create an account or instant sign-up with Github/GitLab SSO.
A free trial
Great “Get started” documentation
Accessible and free documentation and up-to-date SDKs.
Ability to copy/paste code snippets
Pre-filled API requests (or other low-code options)
Public API tokens for testing purposes only

Open Source specialist Red Hat suggests a framework to assess your developer experience:

Can you do an elevator pitch of your API?
What’s your TTFHW and your TTFPA(Time to first profitable app)? How can you reduce them?
What’s the developer onboarding process? Can you make it easier?
Do you provide enough flexibility to make developers successful when using your API?
What’s the support you provide to developers?
Can your API support multiple use cases?

Sell to developers with a clear roadmap

Developers are investing time and effort in your product, they would like to know where will it go and what future features they could wait for. Managing expectations with a concrete roadmap and clear targets is essential to engaging developers in your product.

Avoid overpromising and stay transparent in your planning by either providing a public roadmap or a space for users to see what you’re currently working on.

Developers know development is hard and can hold many obstacles, you don’t have to give an exact ETA but seeing you committed to your deadlines will convince any user to trust your product.

Sell to developers by having a product-led growth model

To circle back to this article’s opening, the product-led growth model is a perfect match for products whose target persona is developers. The model emphasizes what developers value most: not wasting time with sales and the ability to self-serve themselves in your product looks like the way to go.