Developer Relations (DevRel) is commonly tasked to drive growth and success of developers using their company's product. Of course, coming up with reasons why developers should adopt their product is necessary to deliver an effective message. But wouldn't it also be healthy to put attention on why they may NOT adopt?
I am just brainstorming here, but the following list captures reasons I believe developers may not adopt a product.
Unaware
It is not possible for a developer to adopt or use a service if they have never even heard of the company or product.
Uninformed
Different from being unaware, this means the developer has only a vague or misinformed idea of company or product.
Unneeded
The developer does not perceive the relevance of company or product.
Untrusting
The developer's perception is that there is too much risk to engage with company or product. This could be due to not trusting the overall industry the company represents, or company/product too new in market.
Unhappy
The developer had (or heard of) a bad experience with product or company.
Uneasy
The developer may had initial interest, but the process to adopt or get engaged was too complex or confusing.
Uneconomical
The developer has interest but considers cost of product or investment in time/resources a barrier to continue. Competitors appear (or are) less expensive.
Underwhelmed
Despite possibly being the right fit for a developer, how the developer learns about the company or product did not impress enough to invoke active interest.
Unable
While the developer may personally like the company or product, the perception (or reality) is that no adoption could take place due to constraints/policies of organization developer works for.
I do not claim the above is an exhaustive list, but is it a good starting point for discussion? Imagine if each DevRel carefully considered each reason not to, and came up with a plan to turn things around?
If you have other reasons why developers may not adopt, please share!
Photo by Anna Shvets: https://www.pexels.com/photo/woman-with-hands-on-her-face-in-front-of-a-laptop-4226215/
Top comments (10)
Interesting viewpoint :)
I might add 'Unescapable', the company/product appears to lock developers into it's own ecosystem, making a later decision reversal or change of product much harder. This is often a major consideration from an architects point of view or an agile process view.
@phlash I love this perspective, thank you for sharing!
Undecided
The developer is currently weighing their options and looking at other alternatives which serve the same purpose.
@kaspera Although closely related to "underwhelmed" I will add "undecided" to the list because it captures a very critical moment - the decision is not made yet, whereas "underwhelmed" leans toward not using. Thank you for sharing!
Unethical
One more thing that I think that throws off developers is if a company is misleading the devs into believing they can do something with their product when they can’t right at that time. Even though uninformed in the post covers misinformed, I feel misinformed is unintentional and could be a result of improper documentation/explanation of something whereas misleading is intentional and hence falls into unethical.
@devocado Thanks for the add, I agree, but perhaps for different reasons. I like "Unethical" across the board. Perhaps the developer views the way the company operates in a negative way. Hopefully this is a rare problem!
From other discussions I have had, I would add "Unpopular" to the list. This is not about trust in product/company, so not "Untrusting." It is also not about a bad experience with product/company, so not "Unhappy". Unpopular could simply be vibe of a community, or negative press about some item at company. Perhaps the company took on a political view not popular by some. Whatever the case, it has been added, and I appreciate all the feedback I have received so far!
Unadaptable or Unapplicable
The product has the functionality that is desired, but it is not possible to apply it to the tech stack of the developer or is not suitable for the infrastructure that the developer needs to operate in.
Another example would be that the tool has the functionality but it cannot be applied because it isn't configurable to restrict it to the developer's privileges. IE: a tool to watch logging and/or values but it isn't retractable to the developers testdata only, creating a privacy issue when integrated.
@eekayonline Thanks for reply. How would you describe "Unadaptable/Unapplicable" as different than "Unable"?
From a comment on LinkedIn, "Unfunded" is a good addition. It differs from "Uneconomical" in that the focus is on lack of resources regarding the developer. So while the company/product may be very competitive on price, it is still out of reach for some... such as students, hobbyists, or low-funded startups.
Credit goes to Bill Sherman!