As dev first companies proliferate the public SaaS world, “Developer Experience” has become a new term that I now hear CNBC even talking about. But what does it mean? In this post, I’ll explain a little more about it and follow up in the future with more detailed posts. I also recommend watching some of the videos from DevXConf if you’d like to learn more.
Developer Experience can broadly be bucketed into the following categories:
Ease of use
Technical advancement
Efficiency
Cost
Durability and Stability
This is a Snack Bites newsletter so you can see how all of this can and will be covered more deeply in future posts. For now though, I will explain each of the above categories in a bit more detail.
Ease of Use - This is one of the hardest ones to get right. True ease of use can mean entirely different things to different people. However, when I think of it, I consider the following areas. 1) Detailed documentation that allows developers to easily understand how and why to use the product. 2) A frictionless way to try the product. This can span everything from a free trial and freemium product to authentication with Github. 3) Integrations into a developer’s native workflow (i.e. what if they use CircleCI or Github Actions, can the product work with that).
It is a difficult thing to balance though as making something “too easy” for developers takes away from the problem solving and dopamine hit of accomplishing a hard task. That’s why I focus more on “frictionless” trials while still having good documentation to let devs figure out how to use the product by themselves.
Technical Advancement - If the product enables a new task to be accomplished faster, more efficiently, or perhaps even enables a completely novel task, that could be an impressive product but not necessarily a good DevEx. However, if the product also helps a developer advance their knowledge and skillset, that is magic. Engineers like to improve their skills so they can create new features and solve problem areas. A product that is able to help a developer learn is augmenting the DevEx in that product. Which is why things like Mongo University are such a hit. Notice that this is sometimes outside of the product but still part of the product experience broadly.
Efficiency - There are two high level ways to look at efficiency. 1) The product should help developers accomplish a common task more quickly than before. 2) The product enables less resources and complexity in the system to be required than before. “Complexity” is a loaded term that requires more nuance but this is a Snack Bite after all.
Cost - Self-explanatory. Reducing costs is important for products to help end users and customers. However, costs could mean the actual cost of the product ($100k to use the product) or the amount of human capital that the product helps alleviate. Replicated, a boldstart portfolio company, has been quoted by Hashicorp to free up the time of a team of 4-8 developers that used to manage multi-prem software delivery to focus on more beneficial company areas. The cost savings there can be quite significant as it compounds over time.
Durability & Stability - Finally, good DevEx is a product that embodies durability and stability. We all know inherently what that means: high availability, the ability to scale with usage over time, good alerting and communication if the service is down. But another area of good DevEx is characterized by the tweet below.
Twilio supported an API for 13 years and when they finally decided to degrade it, they told customers that they would at least need to migrate to the API that had been for around for 11 years. That is a long time to support an API that presumably half the customer base or more is not using as the company has grown and newer customers are using more recent APIs.
There’s a lot more to dive into in each of these categories but I hope as you look at dev first companies, you start to think about their products in the categories described above to understand why developers continue to use that product.