Most people agree that developers of all job descriptions have tremendous technical power at their fingertips. However, particularly in large organizations, many software and programming tool developers have been focusing on the purchaser as the customer. More often than not, that is not the developer who will be implementing the tool purchased. The C-suite, project managers, or lead engineers may seem like the best target audience. But what about the developers they will delegate implementation to? How do developers influence tool purchases?

To understand this, Developer Media posed a very simple question on  

“How often do you shoot down product tool choices your manager/team lead presents to your team?”

Survey Says

OK, the best comment title kinda sums up the sentiment of the comments from several respondents: “Easier to let them shoot themselves.”

But seriously. We received 748 responses from 19 Nov 2018 to 26 Nov 2018 and quite a few additional comments delivered with searing wit. So, for those 748, how did the results break down?

Survey Results

Response# of Votes% of Total% Error*
Total Responses748100%
All the time. You’d think they’d just let us choose by now435.75%1.7%
Never - We are/I am presented with sensible choices618.16%2.0%
Never – we/I don’t have veto power and/or are never asked or presented with choice 9512.70%2.4%
Never – I/we choose our own tools and products22129.55%3.3%
*95% Confidence.

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 sale (and also, not damage your brand)?

Clearly, you need to win over the developer before you drive the purchaser to a decision. Which of course means you should have a robust campaign that markets to developers, particularly the developers who will use your product.

Common Objections

How do you do that? Let’s take a look at the comments from the developers who took this survey, and treat 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.” — CodeProject 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.’” — CodeProject 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.” — CodeProject 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 presale 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.” — CodeProject 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 freak out. Just because developers that you didn’t talk to are going to influence the decision doesn’t mean all is lost. Instead, create campaigns that speak to that developer. Design campaigns to overcome the objections a good developer will have by providing them with technical content such as documentation, use cases, tutorials, and free trials. Remember, skepticism is a sign that someone has a real problem. Developers will want to use your tool if they understand how it solves their problems. Give your users the technical information they need to make or influence the purchase decision. Developer marketing…it’s technical.