How to Get Developers to Adopt Your Product

Posted on July 3, 2017 Updated on July 3, 2017

Recently, I participated in a focus group where developers were asked to discuss how they make technology adoption decisions. Even “the big guys” seem unsure of how to get developers to notice and adopt their products. So, in this post, I’m going to try to reduce our learning and adoption process down to some concrete steps.

The truth is, we don’t just pick up tools, components, libraries, or languages just to complete a particular task or project. In truth, any technology we adopt has to help us do one or more of three important jobs. The more of these jobs your product can do, the more likely developers will pick it up and stick with it.

Job #1. Staying ahead of the curve.

As developers, we’re constantly navigating through a meteor shower of new frameworks, platforms, and libraries being hurtled at us at blinding speed. Somehow, we are driven and expected to possess a “technology radar,” a sense of what the next big platform or paradigm is. When the business need for a new technology arises, we must be ready to leverage that new technology or fall behind other developers who are.

So, does a developer sense which way the technological winds are blowing? We are ordinary mortals (however reluctant we may be to admit it), and the mechanisms by which we perceive “the next big thing” are often products of habit and evolution rather than conscious choice. Here are a few:

Influencers. Everyone is promoting something, but we are most likely to listen to those who have already earned our trust or gained our rapport. These can be highly esteemed thought leaders (e.g. Martin Fowler) or senior colleagues and friends.

Social Proof. Humans are wired to emulate the behavior of their surrounding society. Sometimes this means facing the wrong way in an elevator when everyone else is facing the wrong way. And sometimes it means getting excited about technologies that those around us are excited. For those of us who, at one time, were invested in bloated J2EE and WS-* Web Service, this can be a source of some comfort.

The Availability Heuristic. We tend to accept the familiar thing as the truth. So when we seek to read up on some hot new web framework or programming language, we may well choose to catch up on the first one that comes to mind.

These processes can lead us to determine which platform, language or tool to get to know in order to “stay up to date.” It’s important to note here that the desired outcome of “staying up to date” is not mastery of the tool being studied. Rather, the desired outcome is an assessment of the features and developer experience of the software, as well as its fitness for any potential development uses.

Thus, for staying up to date, a developer need not even employ the technology itself. Rather, he or she may most immediately rely on the tool’s website, documentation, tutorials, and examples. Therefore, it is crucial for technology products to reveal their value up front. An application example showing a real-world scenario reveals the value of a programming language much more quickly than a lengthy tutorial that goes through a high-level overview, installation instructions, and a contrived “hello world”-like the program.

Once we’ve assessed the value proposition of the tool, we may become curious enough to investigate it more extensively or file it away what we’ve learned until it’s time for job #2.

Read more on… How to Get Developers to Adopt Your Product

Author: Yev Bronshteyn