While anyone can certainly benefit from this post, its primary focus is on early-stage founders of developer tooling companies.

Selling developer tools to developers is like selling paintbrushes to artists. Just as an artist needs quality tools to create their masterpiece, a developer needs quality tools to build their software. Both require specialized tools that are designed to enhance their craft and help them achieve their goals. Just as an artist needs to choose the right brush for a specific stroke, a developer needs to choose the right tool for a specific task. And just as an artist’s brush can make the difference between a good painting and a great one, a developer’s tool can make the difference between functional software and exceptional software.

It’s common for developers to overestimate their abilities and underestimate the complexity of the challenges they face. For example, Abhinav Asthana, the founder of Postman, once remarked that many people believed they could create Postman in a single weekend. However, what they typically have in mind is a simplified version of Postman based on their understanding. However, as they delve deeper into the development process, they discover that the reality is far more intricate than they had initially envisioned, and unexpected complexities inevitably arise.

As for any other company, your top priority is communicating your value proposition in a way that resonates with your target audience. While developers may be impressed by your product’s technical prowess, highlighting its tangible benefits and how it can significantly improve their workflow is essential.

With that in mind, there’s a particular micro-framework that I refer to as a litmus test for developer tools. You can employ this framework to inform various aspects of your product, such as packaging, sales pitch, website design, and product onboarding, among others.

The number of touchpoints required for adoption/evaluation should be as low as possible, ideally one

If you are building a tool similar to NewRelic, an infrastructure monitoring tool widely used by companies, the primary stakeholders for selling your product are likely the engineering teams and SREs. These individuals will benefit most directly from your tool’s value proposition. Additionally, the security team will play a critical role in evaluating the tool’s security features and ensuring compliance with relevant laws regarding data tenancy. Integrating or evaluating a tool like this can be time-consuming and costly, involving DevOps and engineering work. This makes the evaluation process longer and more difficult for both sides.

On the other hand, anyone from any team can adopt VSCode Editor editor without breaking anyone else’s workflow. Once they find it useful, they start advocating it within the team, and that’s how bottom-up adoption starts. Hence it’s easier for your customer to evaluate something like VSCode.

Understanding these touchpoints and personas can help guide your growth strategy. For example, if your product requires a high degree of customization and support, you may need a sales-driven approach. In contrast, if your product is easy to use and requires little setup, a self-serve/product-led approach may be more appropriate.

Identifying the target customer persona through these touchpoints is also essential, as different individuals within an organization may have different priorities and concerns. For example, a CTO may prioritize security and scalability, while a Head of Product may prioritize ease of use and feature sets. Knowing your target customer persona can help you tailor your product and messaging to meet their specific needs.

Prioritizing product development efforts is another critical aspect of understanding touchpoints and personas. For example, suppose your target customer persona is a security head; in that case, prioritizing security certifications and integrations with existing tooling ecosystems may be more important than adding new features.

Understanding touchpoints and personas can inform your pricing strategy. For example, if your target customer persona is engineers, offering a freemium model that allows them to try your product before committing to a paid plan may be more effective than requiring payment upfront.

By identifying and understanding the various touchpoints and personas involved in product adoption, you can optimize your growth strategy, target the right customers, prioritize development efforts, and design a pricing strategy that appeals to your target audience.

Another essential aspect is how well your product integrates with the existing ecosystem. If your product expects too many behavior adoptions (i.e. higher time-to-adopt), there is a high chance of failure. This includes time-to-value returns as well.

Let’s take the example of “co-pilot” for VSCode. The time required to try it out is almost negligible, just by installing the extension. The time to value is also immediate since it starts working as soon as you start typing. Moreover, you don’t need to alter your current ecosystem unless you are using a different editor.

However, if a user is not using VSCode, the journey to use “co-pilot” becomes a bit complex.

They would first need to download and set up VSCode and install any relevant extensions, which can be time-consuming and can result in a higher drop-off rate. Only after completing these steps can they join the same journey.

It’s not necessarily a problem, as every tool will have early adopters willing to put in a significant effort to adopt it. However, if the time to value is high, along with a lengthy adoption process, there is a greater risk of slow or no growth.

Developing developer tools is a challenging task. The rules that apply to other industries or sectors may not always translate well into the world of developer tools. However, these unique challenges make it an exciting and intriguing space.

As a part of Sifar Ventures, I advise and invest in early-stage companies. Feel free to send me your ideas/products at [email protected].