How to reach Developer Experience supreme level — Part Two — Suffering Because of Bad DX
Almost every product built for developers had the same problem in their start, building something good enough in the fastest way possible, it's the common MVP way to build something, or just the developers need to deliver, deliver and deliver…
Probably these products will have unfinished features, which is ok at this point because they need to validate their product-market fit.
So, the company accomplishes the market validation, they have tons of new customers, they start to scale their sales and marketing team, everything looks just fine… Or not.
This growth strategy has a downside, a lot of technical debts probably had been created, sooner or later, these debts come and start to slow down your growth, and then, you start to suffer from Bad DX!
"How do I identify if my product has bad DX?"
Identifying bad DX
First things first, you have a Dev-Tool as a product so you should know the Developer's General Journey, this will be your guide through your DX self-inspection.
Every Dev-Tool that I know works with at least four of these six pillars, so basically what you should do is split your product into these pillars and measure their effectiveness.
You can do that using DX Metrics as a framework, and a spreadsheet to track your points. You have to evaluate your features based on DX Metrics and put the results into the spreadsheet. Below I inserted an example to help you through this process, and you can download it here.
I recommend that you do this process at least every half year, this will give you a good perspective of which pillar you should be more focused on, and it will be a good retrospective tool, also, since it will enable you to analyze where your product needs attention.
After you complete this spreadsheet you will have a holistic view of your product in terms of Developer Experience, so all you will have to do is design a plan that will try to solve these problems.
Stop suffering from Bad DX
The first step for stopping suffering because of Bad DX after you had identified the pain points using the DX Self Inspection sheet, is to start a discovery process that will enable you to identify possible solutions for them.
Recently I found a great article explaining a continuous product discovery framework, and I believe if you don’t use any other framework this will be helpful.
I enjoy continuous discovery processes because I believe that products are like living beings, they never stop changing, so your product roadmap should follow the same rhythm, of course, having your business objectives well defined and aligned with an experimentation strategy like this one.
Once you have defined the main solutions and their key outcomes, it's time to implement them. For it, you can use the implementation process present in the article that I mentioned previously.
As a final step, release, track and analyze these new modifications, use tools like Mixpanel and Hotjar for it, if you achieve your outcomes, great, it's time to move forward, if not, repeat the process.
In the end, to stop suffering because of Bad DX you need to realize that you have Bad DX, you need to understand what's DX, and apply it to your product.
By the way, I will speak more about how to apply good DX to your product in the next article. :)
