I’ve done the rounds through a number of SaaS companies – Twilio, Okta, ngrok, and now Pangea – where we were selling to developers and the same first question comes up every time: How do we get developers started with our product?
Throughout the years, I’ve explored lots of answers to this question:
- Make it easy, compelling, or exciting
- Write great docs, examples, and sdks
- Get celebrity developers to talk about it
- Conference presentations
- Peer pressure
- Outright bribery
Some of those answers are more useful than others but only addressed the HOW and never explored the underlying and fundamentally more important WHY question: Why would developers want to use our product?
Why do developers choose a tool?
Every developer company says “because our tool is better” but that’s answering “why would they choose us” and assuming developers have the problems we imagine.
While at Okta, a better answer struck me: Developers hate wasting their time. At first glance, it feels like a useful answer but has some gaps. After all, if we really hated wasting our time, we’d probably buy more off the shelf systems instead of rolling our own or choosing open source. The actual answer is a deeper truth:
Developers have two goals in life: build something useful and go home.
Everything boils down to one or the other:
- Why do we pick that IDE? Because it lets us write better code faster.
- Why do we pick up that framework? Because we think it solves our problem easier.
- Why do we choose that deployment model? Because we think our system will be more stable so we won’t get angry 3am calls.
Then we have two additional truths linked to this one:
Developers are generally disconnected from revenue. They know their Sales team makes money but generally find the practice distasteful and irrelevant to their day to day tasks. Therefore, developers define “useful” as “how many people are using my software?” We want to know more people are using our software this week than there were last week. After all, as it grows and does more, we get to solve better and more interesting problems.
So what should we do?
When we put these ideas together, we can derive two imperatives for companies selling to developers:
- Anything that accelerates a developer building something useful or going home, we should do more.
- Anything that slows those down, we should stop.
Therefore, our original question – How do we get developers started with the product? – really breaks into two more specific questions:
- How does our tool help developers build something useful or go home?
- How do we demonstrate that and speed them along?
If we can’t speak to and demonstrate both, we have a toy, not a tool.
There’s another darker corollary from this reasoning: The fastest way to demoralize a team is for them to build something that gets shelved and never used. The longer they work on it only multiplies how demoralized they’ll be.