The developer experience (DX) formula

Originally published here.

It took a long time to shift the mindset of the software industry to be user-first. The rise of a product-focused mentality and product management best practices helped a great deal in pushing this forward.

But when the users are developers, all these decades of established processes are suddenly thrown out of the window. Why?

Good developer experience isn’t a luxury; it’s a necessity.

It should be easy

All you have to do is put yourself in the shoes of your users, aka fellow developers. How hard can it be, right? You’re working in the same industry after all; it's not like you have to start roleplaying as a marketing executive or a medical professional.

It turns out it's not that straightforward. Not every developer's needs are the same, and not every developer requires the same amount of guidance.

You don't want to overload your users by throwing every possible resource about your product at them all at once. Think of their use case as a journey. A journey usually has a beginning and an end. The start is probably more interesting for you, so it takes some time to think about it. Where does your user's journey start?

Most developers have problems they need to solve, and they usually want to use the best existing tool for such issues instead of rolling out their self-baked solution (hopefully — right, folks?).

How can you find developers struggling with a problem that your tool solves?
Why is your tool the best solution for such a problem?
How do you get the potential user to try out your tool?

By answering some of these questions — and coming up with more — you’ll already start seeing the mistakes you’re currently making. If not, let me introduce you to a few common ones.

Common mistakes

No free trial

One of the core motivators of software engineers is exploration, which often includes playing around with new tech. For most of us, it's what sparked that initial interest when we started hacking on things.

Suppose you think your amazing sales team will be able to influence the “decision-maker,” who in your eyes isn’t part of the group of developers that’ll use your product. In that case, you underestimate engineers' power in modern product teams.

Bad documentation

In the age of many excellent frameworks that help you write (or generate!) documentation for your product, if you lack in this, your product won’t even get considered when evaluating solutions for a technical problem.

As you well know, developer time is one of the most expensive resources for a company. If the team has to spend most of it on figuring out how to use a product and navigate the edge cases (there are always edge cases) they bought or want to buy, you’re in great danger.

Also, if your business model revolves around providing “enterprise-level support” in lieu of proper documentation, you can forget it.

No community support

This might be a little more controversial when talking about tech products — especially if you still have the image of an antisocial hermit when you think about developers — but community is always at the core of software engineering.

Think mailing lists, demogroups, and hackathons. And realize that the whole idea behind the internet is to make it easier for people to connect and share information.

You don't have to create a community, but make sure you do your best to enable the creation of one and support and nurture it to your best abilities — the members will be your best friends in business development.

These circles are excellent for business referrals, technical support, etc. You can get all these benefits just by showing up.

Not preparing for software engineering practices

Software engineers have decades of battle-tested, proven practices like testing, version control, etc.

Suppose you fail to accommodate your product into these processes. In that case, your tool is destined for replacement as soon as another comes along that does the same on a technical level (or maybe even less) but has a built-in mechanism that enables developers to use their existing, comfortable git workflow properly.

What problems does good developer experience solve?

Business 🤝 Tech

There are a lot of business cultural issues that can be mitigated by implementing good developer experience, like the age-old disconnect between technology and business departments — a buy-in from management combined with a product that’s horrible to use will only contribute to this.

On the other hand, if both departments are happy, that accelerates collaboration and productivity even more! If your product can enable this in an organization, you can claim this as a win for yourself.

Tangential opportunities like this make focusing on developer experience worth it, but arguably harder to reason for as it can be complicated to quantify the return on investment.

Product-market fit

You are the product; developers are the market. Do you really fit together if they hate you? How long will you be able to satisfy your users if all they think about is how great their life would be if they went with a competitor product instead of you?

You’re probably not IBM; you won’t lock in corporations for hundreds of years. You’re more like a library in a programming language that’ll get swapped out for the next one if the developer gets annoyed enough, or the competition catches up in features (it will happen!) while providing a smoother user experience.

Unbundled architectures

Modern systems are comprised of many components, which are usually provided by tools/services such as your product.

Software teams nowadays keep component exchangeability in mind when they architect new systems because the ecosystem changes so fast that they don't want to get stuck with something that’ll be deprecated before they make it to release day.

Think of it as future-proofing; instead of paying for professional support in the following years, it's easier to find a compatible, better alternative and make the switch.

You might not like this, but it’s an opportunity for you to position your product as the best alternative to something that has become slow/unsupported, or simply new tech built on modern foundations has left it in the dust.

Software only grows. It's the nature of the industry that systems become uncontrollable behemoths.

If you can convince the developers that if they change one piece of their architecture to use your product because it's not just compatible, it's easier to use and better in every way, you're in!

Exercise for the reader

As a thought experiment, try to come up with two lists; one with tools/APIs/websites/whatever you distinctly remember having fun using and one with products that resulted in the opposite.

Think about the exact things that made you have a specific reaction when using those tools and after collecting a few, see if your product has or misses these.

Join our Slack community to get the freshest content straightaway, network with your peers, stay on top of the latest job opportunities, and more.