A key part of developer marketing is to understand how decisions are made around the adoption of tools or resources. Often times we think it’s a coder sitting in a room on their own, simply saying “I’ll use… this API,” but that is not usually the case. Developer organizations come in a variety of sizes and shapes, and so a variety of people make decisions on which tools and resources to adopt. Once we understand who the key decision maker is, we can begin to understand their needs, and then message the benefits of our API or other tool(s) to those needs.
Who Makes the Decision? Who Are the Stakeholders?
We can use the concept of a “decision-making unit” (DMU) to help us down this path. First, consider the structure and context of the developer organization: is it a one-man shop, is it a small agency, is it a large enterprise? Second, consider the context of your API or tool: how widely will it impact the organization and the apps/services they are developing? Is it tool an individual would choose to use (say, a certain text editor), or is it something more wide-reaching (an API that provides a key feature, for instance)?
With these in mind, we can begin to understand the makeup of the DMU and the stakeholders it represents. These could include:
An initiator – the person who begins the process by raising awareness internally.
A commercial decision maker - who evaluates the commercial aspects of a resource, such as pricing or business model.
A technical decision maker - who evaluates a resource’s technical aspects, such as programming language, compatibility with existing resources, and so on.
Influencers - who may not have explicit decision-making ability, but can influence the overall decision.
An approver - the person who makes a final yes/no decision.
Keep in mind that this is a model, and that the DMU will vary across organizations. In some cases, a single person will play multiple roles; in other cases, certain roles may not exist. But using the DMU model will help you to understand the different stakeholders and values that contribute to the decision to adopt a developer resource. Furthermore, the DMU is fluid, meaning it can change depending on the situation or product, and can also be very informal.
All of these variables depend on understanding your target developers and the organizations in which they reside. Think back to your segmentation – and review our article about it – for help.
Developer Decision Criteria
Once we understand who is making the decisions, we can explore the criteria they use to make them. We can make a general distinction between technical criteria and business criteria.
Technical decision criteria, and how they might be expressed by developers, can include:
Product features and functionality that answer a need – “Does it do X?”
Level and quality of technical support – “Do they make it easy to use?”
Stability of the resource and its provider – “Will the resource stay up, and will the provider be around?”
Compatibility – “Is it in a language we use? Does it work with the rest of our toolset?”
Technical switching costs – “What will it take to start using this, and is that worth the new benefits?”
Business decision criteria, and related questions, can include:
Costs for integration and running – “What will it cost to start, and what will it cost to keep using?”
Time and/or money savings over the long run – “What will we save by using this, and can we quantify it?”
Additional revenue/profit – “Can we quantify the monetary benefit?”
Overall ROI case – “What’s the benefit and ROI when we combine all this?”
With a good understanding of the decision makers, and what’s important to them, we can then focus our marketing and messaging on the right targets, and the factors that are most important to them.
Matching Communications To Decision Makers
Using the above questions, and our earlier understanding of who the decision makers are, we can then shape our communications and messaging to best match their needs and interests. You can work through this step by asking a series of questions about your product and target developers.
Who has the need our product answers, or gets its benefits? Is it the coder, is it the product manager responsible for monetization, or someone else? Make a clear technical or business case to this group, based on the situation, and communicate through fact-driven methods such as: feature lists, blog posts, FAQs, case studies, and example apps.
Who will implement our product? This could be a coder, a QA specialist, data analyst or someone else. To this group, emphasize ease of use and implementation through: documentation, forum support, quick-start guides, and example code.
Who is the ultimate decision maker? Is it the individual developer, is it a team manager, is it a CTO? This group needs to see the sum and outcome of the business and tech cases – the combination of the why and the how. Here, the most persuasive tools can be testimonials, case studies, cost-benefit analysis, and quantified ROIs.