The challenge of selling developer productivity tools often lies in accurately measuring their impact. Many teams don’t measure developer KPIs at all, and those who do find that these metrics are highly variable. This is especially true for smaller teams with lower task flow, resulting in smaller sample sizes.
Some reasons for varying development times might include:
- Incomplete or unclear specifications – bad product specifications require the engineer to complete them himself.
- Scope creep – adding more features to a project while building it.
- Technical debt – different parts of the codebase can have different amounts of tech debt.
- Code quality requirements (such as tests or code aesthetics) – can vary between teams and code reviewers.
- External dependencies – waiting for help or action from someone with a different set of priorities.
- Interruptions – employees may experience different amounts of interruptions during their work.
When selling a new developer productivity tool, it is crucial to provide a low-friction path to a significant “aha” moment. This allows you to target software developers directly (bottom-up) and make them fall in love with your product. If your product is good, they will advocate it strongly enough that management will buy it, despite being unable to measure its impact. Popular examples of such products include GitHub Copilot, GitHub, Slack, and JetBrains products.
If there is no easy way to try your product, it will be difficult to sell it as a developer productivity tool. It will be much harder to convince developers to try it, so bottom-up is less likely to succeed. If you go top-down, you will need to add features that affect the customer’s business in some other measurable way.
What has been your experience in selling developer productivity tools? Have you found other effective ways to sell them? As always, I’m eager to hear your insights and experiences on Twitter.