All opinions and analysis in this post reflect my experience and opinion, not those of current or previous employers. They did not review or approve of this in any form.

For years I’ve advised everyone from solo developers to Fortune 50 companies on the best approaches to designing and building APIs in addition to numerous things to avoid.

Ten years ago, it was impossible to convince anyone that great documentation was possible, let alone a requirement. Terse dictionary-like documentation was normal. If it had examples, you were lucky. If there were SDKs, you were blessed. But regardless, odds are they were community efforts and not led by the company.

Now an API company won’t launch without documentation under version control, SDKs for their favorite languages, and demo code.

What Changed?

Twilio changed everyhing.. but not for the reason you think.

Yes, Twilio taught the industry how to do developer evangelism. Good technical demonstrations, blogging, and speaking at conferences are great but the landscape is littered with the corpses of failures that tried evangelism.

The problem is the sheer numbers involved. For example in Twilio’s 2017 Q3 report, they note 46,489 customers out of 1.9 million developer accounts or a ~2.45% conversion rate. That means if 1% of those customers are going to be the next Uber or Snapshot, you’ll need over 4000 users before you find one.

Yes, Twilio taught the industry how to onboard people quickly. When a developer evaluates a tools, they only get brief window to try it out before they get interrupted again. But lots of companies onboard quickly, so that’s not it alone.

Twilio taught us that developer experience is vital.

When a solo developer is playing with a side idea, he only has nights and weekends to dedicate to it. If he hopes to ship, he has to figure out which ideas to expand on and which to kill as quickly as possible. Alternatively, a Fortune 500 developer can’t ship quickly. They’re buried in structured development sprints and saddled by a procurement process which requires evaluation periods or a dreaded RFP.

great developer experience levels the playing field. It lets that Fortune 500 developer start quickly, evaluate quickly, and include or dismiss it quickly. Think of the last time you walked into a meeting and already knew you had a tool to get your job done easier and faster.

Who does Developer Experience help?

A great developer experience – including but not limited to great documentation, simple SDKs, and relevant examples – lets all developers move quickly:

  • A solo developer can evaluate an idea in an evening;
  • A Fortune 500 developer can play with that idea between sprints;
  • A prospect can try your product on their own and sell themselves on the solution;
  • A sales engineer can demonstrate a concept in a demo and hand it to a prospect;
  • A savvy product manger can explore that idea before it becomes a requirement.

From a business perspective, a great developer experience serves two purposes:

  • It places a long bet that there are future-whales looking for your service that you can catch early.
  • It solves a problem today by getting existing/potential customers started, prototyped, and deployed as quickly and painlessly as possible.

A great developer experience is vital because real-live production systems are built by busy people who want to do useful work and go home.

If you can make either easier, you win because they’ve won.

Write a Reply or Comment

Your email address will not be published.