We recently posed the question to the CodeProject.com audience: “How often do you shoot down product tool choices your manager / team lead presents to your team?”. From this, we learned that 34.5% of the developers who responded very often, often, or occasionally reject the choices the purchaser has already made. In addition, approximately 30% never have to reject a product from on high because they choose their own tools!
However, this first survey did not dig into the reasons why developers had rejected or disliked tool selections made by their manager, team lead, or other leaders in their organization. So, to better understand why developers might reject tool recommendations from someone they report to, Developer Media posed a very simple question on CodeProject.com:
“If you have rejected tools or products recommended by your team lead or manager, what were the reasons?”
Most surprising reason: “Open source code was in French”.
Yep, that was unexpected. One commenter mentioned that they felt like the code could have been great! But he and his team couldn’t read it since, as they shared in their comment, the “open source code was in French”.
Meanwhile, poor documentation is definitely an issue that prompts some developers to reject a tool recommendation. Out of the 656 responses submitted between 26 Nov 2018 and 3 Dec 2018, 19% cited “The documentation was awful (or possibly non-existent)” as a reason for rejecting a tool recommendation. Woe unto those who had a terrible API – the reason given by another 15% of developers responding. However, the biggest reason given for saying no to a tool recommendation was simply that there was a better alternative out there (39%). Another 37% felt the tool they had rejected would have neither solved their problem, nor provided any benefits.
Survey Results
| Response | # of Votes | % of Total* | % Error** |
|---|---|---|---|
| It didn’t actually solve any problems we had, nor provide any benefits | 246 | 37.50 | 3.7 |
| It was pushed on us without anyone asking us what we actually wanted | 174 | 26.52 | 3.4 |
| It was too complicated or time consuming to implement | 177 | 26.98 | 3.4 |
| It was slow, buggy, a resource hog, or just plain sucked | 183 | 27.90 | 3.4 |
| There were better alternatives available | 257 | 39.18 | 3.7 |
| The API was terrible | 97 | 14.79 | 2.7 |
| The documentation was awful (or possibly non-existent) | 125 | 19.05 | 3.0 |
| The marketing material used to explain the product put us off | 28 | 4.27 | 1.6 |
| I don’t like the company who makes the product | 26 | 3.96 | 1.5 |
| I don’t get to, or never have, rejected tools or products | 143 | 21.80 | 3.2 |
| Responses | 656 |
What does this all point to? Aside from clear technical problems with a tool, to us it sounds a bit like marketing malpractice. When an overall poor job is done communicating a tool’s strengths and applications to the needs of the developer market, frustration and rejection often ensues.26% of the developers said that they simply hadn’t been asked what they wanted. Another 26% found that the tool was too difficult to implement, while 27% gave up on a recommendation because it was too buggy.
Overcoming Objections
Of course, providing a functional product is Step 1, but then making sure the public documentation is truly helpful is Step 2. It’s important to develop the public documentation as marketing material for developers. It should be highly technical and help developers evaluate the tool’s usability in their hands for their use cases. Simply focusing more on creating well-written public documentation could solve many of the other problems that lead to tool rejection. A well-documented product means your company has thought through the use cases that are most important to your customers.
There are a couple of other strategies worth employing. Bear in mind two very important aspects of marketing to developers:
- Appeal to sandbox thinking
“But then we have a management that loves shiny. Part of our mandate is to piss about with the latest tech so lots of it is recommended by various sources and the team gets to play with the new toys. The majority get rejected as for most of the reasons in the survey.” – CodeProject survey comment
Remember, sometimes your customers get to play with lots of technology. That means they are constantly evaluating products. Offering tutorials and well-documented free trials are the best way to appeal to developers who have the opportunity to “piss about” with your tools.
- Lead with developer empathy
If you prioritize developer empathy for your product marketing, then you will find that you prioritize identifying the best problem-solution fit for your product. Once you do this, you can write about it. Create thought leadership pieces highlighting the problem, ideally written by practitioners outside your company (since the developer empathy will be baked right in). Follow with education pieces that highlight the attributes of the best solution. With any skill, it will lead your developer prospect right to your product.
That’s a Wrap
Developers seek solutions to specific problems they encounter in their work. Creating developer marketing that focuses on helping them see the problem-solution fit of your product is the best way to keep your tool off the rejection chopping block. By focusing on your customer’s problems, you can avoid having your product cast aside. Harness practitioner-created content (with developer empathy built in!) that is technically valuable to prospects. Marketing campaigns should include everything from the public documentation to thought leadership blogs, educational components, how-to white papers, and tutorials in order to help your customers identify themselves. Remember, you don’t have to piss a developer off. You just have to think like one.
