How to ensure a good developer experience

Before a developer starts using a new tool, they go through a process of trying to answer four questions:

1. What is this product?

2. Do I need it?

3. Can I trust this vendor?

4. Is it fast to implement?

All the answers to these questions need to be extremely easy to be found, preferably on your homepage. If developers can't tell what your product is and if the answer to any of the other questions is 'no', then no matter how good your product is, you'll end up losing a significant portion of your hard-to-earn developers.

A good first impression

Here are a few tips on how to answer these questions properly:

1. "What is this product?": Explicitly share what your tool is and how it can help. This is the first thing developers must see when opening your website. Don't try to get too creative here.

2. "Do I need it?": Share customer feedback or a way to quantify how this tool can help you save time, money, or effort. Make sure the user knows that you're solving a real problem that they may have and if you don't use the tool, you'll need to figure that problem out yourself. As a good example, I like to refer to the landing page of Comet ML, specifically at the section "Move ML Forward—Your Way", where you can see the "Before Comet" and "After Comet" visuals.

3. "Can I trust this vendor?": Make sure to share other companies or organizations which are using or involved with your tool and address any concerns users may have regarding using your product. You'll get a lot of extra points on this one if you have a strong active community backing you up.

4. "Is it fast to implement?": How long till I get going with this? minutes? hours? days? Do I need to book a demo or talk to a sales person? Do I need to setup multiple different things to get started? Are the docs helpful? The faster you can get the user to start building with your product the better.

BUT, the first impression is just one of many things you need to get right. To go deeper into how to make developers happy with your product, we need to cover the entire developer experience.

What is 'experience'?

Experience is everything that comes after the developer decides to know more about you. It happens after the awareness phase, where you've piqued their interest through social media, events, word of mouth, or whatever.

The important thing is: now they want to know more about you to see if you can help them in some way.

After you gave a good first impression following the steps I shared above, it's time for the next goal: have them build something with your tool - fast.

Now you need to make sure you remove as much friction as you can at these 4 areas:

1. TTHW. Your documentation should be 1: easy to find, 2: easy to read. Try to track how long it takes for the average developer to achieve the TTHW assuming they start from scratch. It depends a lot on the technology in place but I'd say 5 minutes is incredible, 10 minutes is great, over 30 minutes is considerably bad.

Time to Hello World (TTHW) is the amount of time it takes a developer to achieve a minimal tangible result with a new piece of technology

1. Resources. Please don't have the developer jumping between dozens of pages within your website - or worse, Google - to find the things they need to build a simple application with your tool. Everything must be intuitively accessible: documentation, use cases, blogs, videos, case studies, and frequently asked questions.

2. Documentation. A good technical writer makes all the difference. Your docs need to be clear, clean, and intuitive. Make sure you're answering all the questions the user may have when following those steps and try to get feedback from the community on what could be improved.

3. Questions. It needs to be easy for them to get in touch with your team and ask questions. It can be on a forum, Discord, or Slack. Try to answer these as fast as possible. If you feel like you're getting a lot of the same question, it's time to add it to the docs.

Accepting defeat

The developer signed up for your product but stopped using it? Don't flood them with pointless emails trying to get them back - they'll probably just send you to the junk.

Instead, try setting up a system of discovery into where that user got stuck and send a few resources their way that may help!

Why should I care?

Notice that no matter how good your product is, the developers will only reach that level of getting to know more about it if you're able to deliver all the steps that come before that, if you haven't, then they'll give up on you without ever being able to try it out.

---

Thanks for reading and let us know in the comments if you found those tips helpful!