You are not your users, and that's great
For devtools founders, the developers who are the most fun to talk to and build for are not the ones you’ll need to power the next phase of growth.
This is frustrating. It’s also an opportunity.
Developers are not a monolith. As our field has grown, there are more different specializations, stacks, and paths into the industry than ever.
If you’ve founded a devtools company, you’re walking around with deep insight into some part of how software gets made. That insight comes from experience. You’ve seen things break more times than you can remember, acting as the keeper of institutional knowledge on several teams. You’ve made meaningful contributions to open source projects. Given how long you’ve spent building this expertise, you’ve developed a great network of peers and fellow experts. When you talk with them about your tool, it’s so easy to see new possibilities.
But you’re all in the minority.
The vast majority of developers know less than you do. Otherwise someone else would have crafted your tool instead.
So figuring out where your product experience is expecting vast quantities of knowledge 99% of developers just don’t have is an important job. From there it’s essential to experiment with how to fill in gaps, iterating on the results. This is what’s missing to drive the adoption your investors are looking for.
A bit of deliberate user research is a great start. We’re not talking about off-the-cuff interactions in Discord or at conferences—although those are great too. We’re talking about a handful of structured conversations with a diverse cross-section of users who can tell you how they came into this field, what they want for their futures, what role your tool is playing in their journey, and how it can better help them get where their going.
Speaking of Discord, your support community is also a great way to learn about the pitfalls in your adoption funnel. Don’t send your support engineers in there all alone. Everyone building your product should have regular contact with the people most willing to speak up and ask for help.
Do these things and you’re guaranteed to perceive a variety of jumping off points for improving your error messages, your docs, and the product itself.
Once you get to know your users, you can start building advantages into your product that make them into more advanced, successful customers.
