The Stack Overflow Survey is so good that I just can’t stop writing about it!
72% of 68k developers responded that starting a free trial is the most common way they evaluate new tools. Notice the next big categories: asking developers and visiting communities are the only other responses > 60% before a steep drop off. The last and smallest response is “companies that emailed me.”
I’m not sure we can get any better data on how to reach developers. Of course satisfying the above 3 major categories is not an easy task! In fact, this is where developer first startups need to spend many cycles focused on.
Start a Free Trial - Developers will not put in a real email into the free trial signup form unless they have been convinced before getting there that there’s a strong likelihood the product will solve their problems. This means content, documentation, maybe even a sandbox to play with the product before the ROI on the sign up flow generates any value.
Ask Developers I Know/Work With - Once word of mouth spread occurs, a company can grow like wildfire. However, getting there is no walk in the park. It requires conference talks, meetups, and figuring out exactly which developer personas have the pain point the product is solving. “Our product solves the problem for backend engineers” is useless vs “Our product solves the problem for backend developers experimenting with using Wasm server side”. Go deeper into a niche to enable word of mouth to flow.
Visit Developer Communities Like Stack Overflow - This one takes the most time out of all the 3 categories. It’s not as simple as putting a post in a discord group and expecting people to reach out. First, a founder needs to spend time regularly contributing to discussions in the community before the trust is built. Just like SEO it requires time, consistency, and a delivering good content to eventually start surfacing enough engagement. Ever wonder why Hacker News has those karma points, the above is exactly why.
Finally, once you’ve convinced a developer of the value the product brings. Now, they just buy it right? Wrong, mainly because unless it truly is something small that a developer can put a credit card down on, most will require approval from a budget owner. The good news here is that out of 51k devs surveyed, 66% responded that they have influencer over the decision.
Developers have a lot of power to help push products that they love forward. Which is why the focus on developer experience and meeting devs where they are (both in their workflows and communities) is worth the time and effort from day one. It’s not a short or easy task, but the payoff of focusing on it is having fervent user love that leads to multiple opportunities to serve those same users and the users they tell in the future!
What I’ve enjoyed this week:
Loved this example by Doordash of how they applied ML to solve a real business need
How Platform Engineering Teams themselves are like startups needing to find distribution through their orgs from DevOps Weekly by Gareth
The right abstractions can also be found in commercial solutions. In fact, this is the ideal default to maximize the percentage of engineering cycles on the product. Build vs buy decisions are usually made by comparing costs of internal efforts with total cost of ownership. But what’s just as important is the specific abstractions provided by the vendor. If the product does not look like what you’d build for yourself internally, the delta in developer productivity needs to be considered. That’s why the most informed buyers are those that have built their own version of a product or have at least scoped the effort against a design. Only those teams will have fully considered which abstractions will be most effective to solve the problems at hand.
I’m a sucker for a good podcast talking through the basics of health and this podcast by Dave and Ben was exactly that on nutrition & macros
Better DevEx is a moat!
Another simple reminder of what we need to do to maintain good health