One of the key challenges every new product (/startup) have, is gaining early users, usage and feedback. It takes a crafted introductory approach to get the attention of developers, get them to try your new tech, and then spread the goodness to their peers.
In his book Inspired, Marty Cagan, describes two types of innovations: True new markets opportunities, and new technology enabling better solutions to existing problems. The latter, naturally, is far more common than the former. New products commonly compete with current state: Not solve a new problem, rather solve the same problem better. In the developers world "current state" usually means a combination of open source technology and a good amount of do-it-yourself (DIY) stitching. Trying to drive change, replacing someone's investment in selecting open source and making it work, not easy. You are likely to encounter some emotional resistance on top of just trying to introduce your new approach.
Another factor impacting getting traction with developers is the realization that top-down approaches no longer work. Marketing to developers isn't very effective either. Developers have significant autonomy to design their toolchain: developers like to discover new technology themselves, try, qualify, and start using. Developers should to be the key persona to consider with early value arguments to be successful.
So how can you introduce and embed new technology to developers? Here are a few points to consider
- Short message, relevant & different, placed correctly: your marketing message needs to be short: people automatically detract from long text. It needs to show immediate relevance to a clear & relevant developer need. And it needs to immediately demonstrate differentiation. Lastly, it needs to be placed where developers in the specific area go to and read, whether it's stackoverflow, open source community etc.
- Credibility & empathy: Whether on the web, or in direct dialog, devs can immediately sniff you out. The context of the discussion needs to be informed and experienced at their level. Does that mean that a product manager needs to be a developer? Not sure. I think it's ok to have a dev lead with you that amplifies the value as a user. But speaking the same language is key.
- Listen to them articulating their challenges (with the current state): This is an important one. If you manage to get the dev to describe what doesn't work with their existing solution and why it matters, you've turned the corner. From now on, assuming your solution addresses the pains the user articulated, you can (and should) use their words in describing how your solution does the job and does it better. If you were to articulate your perspective of the pain point right upfront (when you get on the call and someone asks who you are and what you do, and you go on an extended monolog about your company and the solution), you probably will lose the audience attention.
- Get early wins: Keep in mind that your earlier users are worth so much more than their monetary value. It's ok to give the product away for a year, for example, in return for weekly collaboration and feedback, and if things go well, introducing you and the tool to more teams.
- "Champion" your user: An internal developers' opinion and success story are multiple times more credible and valuable than yours. Going back to the previous point, enabling, nurturing and working with your early power users would mean they could become your internal champions and drivers for usage and users across other teams. That's another reason why early users in any new logo are so important to nurture.
- Last but not least, ensure your progress includes a hint of reality. As producers of innovation, we love what we do. It's only natural to ask and hear what we want to hear. You can go very far with a user who, for many reasons, and good intent, does not represent a viable opportunity for you. Make sure you build in usage metrics, and if possible, gain the advice of your sales/presales people, who know how to poke at your thinking and ask you the right questions that would reveal the unpleasant reality you might miss.
Building solutions for the developer community is lucrative, but challenging. Definitely from the technological aspect of it, but there are many opportunities when large waves of innovation are considered (cloud native, cyber, healthcare, AgTech, Finops etc.). But a bigger challenge is getting the attention of developers, usage and feedback. It requires thoughtful and planned approach, iterative experimentation and correction, just like any product you build.
