A post-mortem on commercial developer tools, their market, and software as a medium
I left the developer tools space last year and this is my brief post-mortem, an analysis and some of the conclusions I gathered after working on it for almost 4 years. Most of these conclusions are my take on unintuitive learnings and pieces of knowledge that seemed paradoxical, at first, but in hindsight make sense to me.
“We’re our own users” is not a product strategy
Well, the thing with developer tools is that they’re built by developers. It seems straight-forward and intuitive that this has to be a great advantage, right? Nothing better than the artisan making tools for artisans. Nothing better than a carpenter who can also work metal making tools tailored to carpenters.
It is an advantage, but don’t rely on it too much. Great developers are not necessarily great product people, and the other way around. Developers are parametric in nature and like customization, tinkering, and systems to adapt to their workflow, not the other way around. However, they’re also demanding, want a polished finished product, and simplicity.
If you’re embarking on the developer tools field, get a great product person. Someone who can distill decades of workflows and habits, find the right product market fit, and steer the direction of the product into market. Don’t dictate the strategy of the product based on your preferences as a developer, but use real market data.
Dogfooding is useless
Dogfooding: using a product or service developed by your own company so as to test it before it is made available to customers.
Dogfooding is useless. In a scale from 1 to 10 in how valuable is the data obtained in testing:
- 9: Public alpha/beta tests
- 7: Closed alpha/beta
- 4: User interviews, usability sessions
- 1: Dogfooding
Dogfooding is a waste of your time and your team’s time. Everyone in the team is on a different mindset, the mindset of someone who’s testing their own product. You’re not only biased, but also affected by internal ego, ownership, territory, and hierarchy. An external user doesn’t care who built what, since they treat the product like a black box. An external user is not afraid of hurting the CEO’s feelings, or the designer’s ego over a button that doesn’t look like one. Get some real users, get them early, get lots of them, get them quick. Test every single iteration. Release a closed alpha as soon as possible: make it weeks, not months.
Developer tools are *tools* and nothing else
People love calling their creations something that suggests aggregate, added value. It’s the sound of potential. In the developer tools space, we hear platform, community, environment. You can put whatever you want in your pitch deck, but your developer tool is just a tool, and nothing else.
There’s nothing to be ashamed of, though. The best developer tools do one thing and do it really well. The best developer tools focus on functionality, distill out everything else, have a clear purpose, and are utilitarian to the extreme. If vi/vim was a commercial product, it’d be worth billions of dollars.
Functionality is the first priority, not the underlying technology
As engineers, we’re often bewildered and excited at technology, the inner gears of a product. Truth is, without a product, technology is useless. There isn’t a single successful company on Earth that has built their little empire purely on a technology, with no use case, customer, or product at its core.
In developer tools, this isn’t uncommon. We’re often too focused on what can we accomplish before we focus on why. I’ll take also a step forward and suggest: before you spend money on technical R&D, talk to your users. Have them test functionally complete prototypes before you write a single line of code.
Developers are utilitarian but care about transparency
Don’t confuse developers’ pragmatism. They care about transparency. For any given tool they use, they want to know: who’s behind it, what’s the business model, and is it reliable. If they can’t answer one of these questions clearly, they won’t use your product.
If there’s no apparent business model, then there are only 2 choices as a developer/user: 1) I am the business model; me and my data, my code, my privacy, 2) They’re not making me pay for this now, but they will in the future somehow. Make sure point 1 never crosses through your users’ minds. Make sure they understand you’re not there to steal their data or make their lives complicated.
Be transparent and people will rally behind you, no matter how much you charge.
The WALL in developer tools: the difference between nice-to-have and essential
Last, and most important: the WALL. The WALL in the developer tools space is a 200 ft cement wall that separates products that are nice-to-have from essential products.
Non-commercial nice-to-have developer products have a future; they don’t have growth expectations and they can be slowly polished and developed through a collaborative effort.
Commercial nice-to-have products simply fail. Their growth demands are too high, their product market fit isn’t clear enough, and their value isn’t solid. If you’re working on a commercial developer tool, make it your goal for it to become an essential everyday tool. You do that by optimizing for product market fit, functionality, and usability. How do you do that? Talking to your users, prioritizing functionality over underlying technology, and releasing an alpha/beta early and often.
_____
All in all, I had fun designing and coding developer tools. It’s a fun space, with a lot of room for improvement, that can clearly impact software. I will say, though, I won’t be coming back anytime soon. To me, and a lot of people I’m sure disagree with me, software isn’t a goal, it’s just a medium. I understand a lot of people love coding and everything that comes with it, but to me it’s a very good tool, and nothing but a tool. I write code everyday, but I like writing it for a goal outside of software.
I plan to spend the next few years of my career coding and designing for automation, mobility, supply-chain, and agriculture. So many problems to solve and exciting solutions ahead.
It all started with this email from Google 6 years ago:
;)
