DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 966,155 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Cover image for Reasons NOT to...
Michael Palermo
Michael Palermo

Posted on

Reasons NOT to...

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 (11)

Collapse
 
jarrodhroberson profile image
Jarrod Roberson • Edited on

Unpossible

The main reason to not use something is very simple; but extremely hard to know.

It if very easy to find out what something can do, there are usually more people marketing the technical products than the team that actually creates the product, dedicated to telling you what it can do.

What is most important is what it can NOT do.

This is very hard and very expensive until you get the experience needed to be able to figure that part out quickly.

Very few products list out what their product can not do at all. They might give you a list of what the product is not, but rarely a list of what is impossible to accomplish with their product.

When you know what something can not do, and I mean is functionally impossible in time or space. There are plenty of things that "can do that", but the effort involved in twisting the product in knots to get there makes it a complete waste of time.

Once you know what something can not do, everything else is possible.

Collapse
 
phlash profile image
Phil Ashby

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.

Collapse
 
palermo4 profile image
Michael Palermo Author

@phlash I love this perspective, thank you for sharing!

Collapse
 
kaspera profile image
Kasper Andreassen

Undecided

The developer is currently weighing their options and looking at other alternatives which serve the same purpose.

Collapse
 
palermo4 profile image
Michael Palermo Author

@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!

Collapse
 
devocado profile image
Vishal Pallerla

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.

Collapse
 
palermo4 profile image
Michael Palermo Author

@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!

Collapse
 
palermo4 profile image
Michael Palermo Author

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!

Collapse
 
eekayonline profile image
Edwin Klesman • Edited on

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.

Collapse
 
palermo4 profile image
Michael Palermo Author

@eekayonline Thanks for reply. How would you describe "Unadaptable/Unapplicable" as different than "Unable"?

Collapse
 
palermo4 profile image
Michael Palermo Author

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!

Take a look at this:

Settings

Go to your customization settings to nudge your home feed to show content more relevant to your developer experience level. πŸ›