The Ultimate Guide to Developer Marketing | Lee Robinson (Vercel)
Insider tips from a 10+ year veteran on how to build and market to developers
Dear subscribers,
Today, I want to share a new episode with Lee Robinson, VP of Product at Vercel.
Lee helped scale Vercel to 1M monthly active developers and $100M in annual revenue. He’s spent 10+ years building great developer products and has some of the clearest thinking on developer marketing that I’ve ever read.
We had a great chat about the developer’s mindset, what a great developer product looks like, and how to market to skeptical developers.
Watch now on YouTube, Apple, and Spotify.
Lee and I talked about:
(00:00) Steps to guarantee developers love your product
(01:15) How developers decide whether to use a new tool
(03:45) 3 pillars of a great developer experience
(08:34) Trust in open vs. closed source AI models
(10:52) Why most developer documentation sucks
(23:25) Developer marketing tactics that actually work
(27:30) How to balance hype and reality
(32:06) How to recover from losing developer trust
Read on for the interview takeaways.
The developer’s mindset
Welcome, Lee! So, let's put ourselves in the developer’s mindset. How do developers decide whether to use a new product?
First and foremost, developers love tools that have a free tier because:
They’re skeptical of new tools. They want to try it out and get firsthand experience before adopting it.
Non-US developers can’t afford to pay right away. A product priced at $20, $40, or $100 USD can be a steep starting point.
They also have a low tolerance for marketing pages. Instead:
Developers go straight to the documentation and code samples.
They’re trying to finish the job quickly and don’t want to deal with BS.
So, what are the core components of a great developer experience?
When building for developers, the experience is the whole product. Some specific tips:
Onboard as fast as possible. Optimize for letting developers get started quickly.
Make upgrades easy: Limit the blast radius of major version changes. Ideally, changes should start opt-in with many months of lead time.
Helpful error messages: When applicable, include hyperlinks in error messages to provide more context on how to solve the error. Provide feedback as you type — don’t make developers think.
Strong defaults and conventions: Have an opinion about “the right way” to build software. For example, don't make me think about setting up routing; just use the file-system-based routing with Next.js.
Provide escape hatches: When the developer wants to depart from the standard configuration, providing escape hatches can counter strong defaults.
You also need to exceed documentation and API design expectations — we can talk about those later.
Let's talk about AI. There's a debate about closed-source vs. open-source models. As a developer, which do you prefer? How do you think this will evolve?