Humans are creatures of habit. We prefer to stick to the things we know, and only switch to new solutions if our current solution is really inadequate, or the new solution offers very exciting new possibilities. But in any case, there’s always something that has to push us to change our behaviour.
To make a product that people will start using you have to take this into account. You have to learn about the current habits of your users, and work with them rather than against them.
I was made aware of this once again when doing interviews at one of our big customers. “We tried new tools, but people just wouldn’t check their notifications. So instead, we resorted to Whatsapp again.” Good that we heard this, because were just about to start building this nice discussion & notification system into our experimentation tool Dispatch! But apparently others before us thought of that as well, and failed miserably.
There are two reasons why it’s so important to pay attention to context when designing your products:
As mentioned, it’s too easy to stick to habits you already know. Adopting new habits costs time and effort, and a new solution has to (clearly) be worth it to motivate someone to take that time and effort.
This is very well explained by one of my favourite concepts from Jobs to be Done, the Progress Making Forces diagram. Here the “habit of the present” is explained as one of the forces keeping people from even considering new solutions. In order for them to start looking for something their current solution must be inadequate enough.
And the more time & energy it will take to switch to using your solution by having to change habits (either in individuals, groups or organisations), the more pain your (potential) customer will need to feel in order to make that switch.
So unless you have a product that is meeting a need better than any other solution out there and you can communicate that clearly from the get-go, it’s wise to put some effort into finding out about your user’s current habits, and adapt your product to that as much as you can to make it as easy as possible for them to switch.
What I experienced is that it’s very easy to start prioritising features based on ‘hidden’ assumptions which are derived from your own experiences.
We for example initially prioritised discussion and notification features in Dispatch, as we use those features extensively in Basecamp and Github. But we are a partially remote team, which makes these features crucial. However, just a few interviews out in the field already made clear that innovation team members, one of our main user segments, often do not work remote at all. Instead, they discuss everything in-person.
This completely shifted our perspective on what’s critical to develop first. We went from prioritising in-tool discussions and notifications to emphasising features like full-screen and easy drag & drop, optimised for in-person use on a big screen.
Doesn’t mean you cannot become successful scratching your own itch. Many successful companies started out scratching their own itch, and it’s an advice given to many budding entrepreneurs.
But if you have a specific target group in mind, you have to make sure that you get an in-depth understanding of their context, so you don’t start filling in the blanks with your own experiences, and end up making something that doesn’t fit into their (working) lives.
In a B2B setting this effect often gets amplified as multiple parties have to change their habits to make the new solution work. Often, if one party doesn’t make the shift, the solution is bound to fail.
For example: one of the innovation coaches we talked to mentioned he had tried out a new tool with one of the teams he coached. But because they barely checked it, he resorted back to WhatsApp whenever he wanted to make sure his messages were read. Of course, this led to the teams never developing the habit of checking the new tool. As a result it failed to take off.
Interviewing as a form of qualitative research is starting to become a mainstay in product research, which is great! But this experience made me realise again the importance of observation.
Go to the place where people will likely be using your product, ask them to walk you through a typical (working) day, ask them to show you the tools they use and the way they set up their environment, join along for a while if possible. Yes, it’s an investment, but totally worth it.
Note: also shows why it’s such a good idea to start working on an idea in a space you’re already familiar with (known as having a good idea-founder fit): you already have experience with the context and might be naturally involved in it. (a great example is Bob and Robbert here at Firmhouse doing lots of workshops and coaching with innovation teams!)
Even when you adapt your solution to your user’s existing lives as much as possible, they will (almost) always needs to change their habits in some way. And for some products even the minimum amount of investment needed is quite big.
So show empathy with your user, understand the struggle they go through when trying to decide what’s worth their time & effort and what’s not, and make the benefits of your product very very clear up-front.
This may seem self-evident, but realise that if your product needs a lot of investment this is something you really need to test well. Do users understand your proposition? Is the onboarding and troubleshooting smooth? Should you consider in-person onboarding?
Work with your customer and user’s habits, not *against *them. Because unless you can provide a very VERY clear benefit, and their current solution is way too inadequate, the barriers will prove too high to change their behaviour.
