Why do businesses build digital tools for their employees, customers, and vendors? This isn’t a trick question.
Hint: This is kind of like asking “Who is buried in Grant’s tomb?”
Answer: So they will use them.
We have just completed a couple of blog posts on how to build the tools for your customers that they need and that are easy to use. To get caught up, you can review those posts here and here.
What we haven’t discussed is how to make them easy to adopt - for your intended audience. Not assuming this is obvious, but the reason to make them easy to adopt is so they can easily adopt them, adapt their practices to them and then exploit them to improve their intended outcomes. Adoption necessarily comes before outcomes, so we will start there.
The key to adoption of new software (or anything) is biological in nature. Everything we do or encounter triggers our nervous system and that ‘triggering’ and how we react to it will determine if we adopt the software or not. If our nervous system isn’t triggered, then we haven’t even noticed the new tool - which is a different problem all together - and not the topic of this blog post.
Fight or flight?
As humans, our nervous systems are different than the other animals on the planet. The main difference is that we have language and the other species on the planet don’t. Having language has made advances in our species possible that just weren’t before. Language enables us to coordinate, cooperate, plan, invent, learn, and explain - among other things. All of these skills that are enabled by our nervous system are used in various ways to exploit software to execute practices in our businesses (and personal lives).
What comes before this, though, is more primal. Some call it the “lizard brain”. This is when our nervous system notices something and is triggered based on the pattern of what is noticed and our prior interactions with similar patterns. It is at this point that many software projects / products make the adoption of the software difficult for users.
Pattern recognition
Our brains recognize patterns and store those patterns in our brain’s long-term memory - the region of the brain that houses these patterns is called our amygdala. These patterns are what has worked to keep our species alive in times when thinking about what to do would take too long and be too late - think lions stalking humans on the savanna. For those of us not prone to roaming savannas, think a bus baring down on you as you cross the street.
In each of the above situations, you don’t have time to think, your survival depends on your brain's ability to trigger the correct reaction. It does this by releasing chemicals into your blood stream that gets your attention and has you react to save your life. This is over simplified for our purposes here, but the same response happens when you encounter something new - like a new version of software that you are being told to use. Or when you walked into your 7th grade math class and the teacher surprised you with pop quiz.
When you are confronted with something new, like learning new software, your brain will trigger the chemicals that have you notice the situation. These chemicals make you feel uncomfortable - sick to your stomach, sweaty, etc. Then, in the background you are comparing the patterns you are seeing here with others you have encountered in your past. If you have had success in these situations in the past, you stay and fight (learn the software). If you have had unsuccessful encounters in the past, you are triggered to flee (go back to your old practices and ignore the software for as long as possible. If the first thing you do with your software is trigger your user’s flight mechanism, good luck having them adopt it. More likely they will flee to the old, familiar way of doing things.
If your practices for releasing software recurrently trigger this flight mechanism in your user community - you will never get them to really adopt your software - and they certainly won’t willingly adapt their practices to it. This resistance will cause delays, add unnecessary costs to your software development practices - and you won’t produce the outcomes that justified your investment in building that software.
So what to do?
Next week we will continue this discussion and share some practices for making your software more “adoptable”.
Follow us on Linked In (8PennyLabs) to be the first to learn when a new blog post drops.