Why Market to Developers?
Maybe your product’s customer is actually a CIO. Maybe the purchasing team sits on the business side of the house. Maybe developers aren’t even really your customer, you just need to convince their company’s C-suite to build a product with your API and put that on their product development map.
So, why should you pay attention to developers? It turns out that they are often part of the decision making unit. Our survey of a developer community results showed that 60% of developers have the ability to approve or reject a tool purchase. We asked a very simple question on CodeProject.com:
“How often do you shoot down product tool choices your manager / team lead presents to your team?”
|Response||# of Votes||% of Total||% Error*|
|All the time. You’d think they’d just let us choose by now||43||5.75%||1.70%|
|Never - We are/I am presented with sensible choices||61||8.16%||2.00%|
|Never – we/I don’t have veto power and/or are never asked or presented with choice||95||12.70%||2.40%|
|Never – I/we choose our own tools and products||221||29.55%||3.30%|
The survey answers reveal that 34.5% of responders very often, often, or occasionally put the kibosh on choices the purchaser has already made. Approximately 30% never have to reject a product from on high, because they choose their own tools!
With roughly one-third of respondents indicating that your sale could become a no-go and another 30% of developers independently choosing their own tools and products, what does that mean for you to have a secure developer enthusiasm (and also, not damage your brand)?
Clearly, you need to win over the developer before you drive a purchaser or company leader to a decision. Which of course means you should have a robust campaign that talks to developers, particularly the developers who you want to use your product.
We reviewed the comments from the developers who took this survey, and treated them as the objections your developer marketing campaigns will need to overcome.
- The product is not supported for current implementation environments or standards.
“It’s just a non-coding colleague and myself here, but she keeps on buying these dashboard/reporting tools…you know the ones…you just give it a database connection and you can produce pretty charts and graphs in 10 minutes. One of them was a total dead end as they decided to abandon the promise of export to HTML5, instead only supporting Flash. After a few dead ends now, I think I’m finally getting respect for what can be done with jQuery or even native .Net charting components.” — survey comment
Solution: Make sure you support current common standards and provide content that includes tutorials and documentation that developers can find BEFORE a purchase is made.
- The developer is responsible for purchase and implementation.
“I cannot be the last programmer out there working that is not part of a “team.’” — survey comment
“Missing option—it doesn’t work that way in our shop. If the technical team needs a tool, we ask our manager about it. If he approves it, we buy it. He’s never proposed a tool to us.” — survey comment
Solution: Provide blog content that is technically rich so the developer who is the decider can make an informed decision. This means creating technically compelling awareness campaigns, free tutorials, and good public-facing documentation for the developer journey.
- Poor use-case fit.
“…there are idiots ‘up top’ constantly telling us what’s best and making us switch to it. It’s ridiculous, they have no clue what we actually need and that one tool does not fit all situations.” — survey comment
Solution: Use cases, use cases, use cases. Provide as many as you think are relevant. Better yet, have a practitioner help you determine what is relevant, and let them write it.
That’s a Wrap
Don’t panic. Just because developers that you didn’t talk to are going to influence the decision doesn’t mean all is lost. Proactively overcome their objections with content marketing campaigns that actually help the developer. Win over developers with technical content such as use cases (case studies) and tutorials. Remember, skepticism is a sign that someone has a real problem. Developers will support your company’s tool, platform, or API if it helps them make something innovative or makes their lives easier. Give developers the technical information they need to support the acquisition decision.