Main menu

Sub menu

Empathic innovation

Are you an innovator? Did you ever make a solution that no one wanted to use? Did you ever reflect on the reason why it happened? If you did, I bet one of the reasons was you lost contact with your users.

If you are–like me– a researcher whose job is to solve problems using innovative solutions, then you are probably caught between two apparently competing goals. On one side you want to show the world how good you are by making novel and advanced solutions. On the other side you want to make solutions that are actually used. Solutions that are actually used are seldom novel or advanced.

In this competition one thing is clear: You cannot create a solution that addresses a problem for your user– and that you are happy with– unless you put yourself in the user’s place and understand her problems. One trap that we researchers easily go into is letting our love for advanced solutions blind us to the needs of the users. We end up as salespeople for our solutions, or become enslaved to assumptions that we have developed during years of research. We don’t believe the user has anything to teach us. But this is wrong.

In order to avoid this dilemma in my own work I have tried to create a framework for myself which I call Framework for Empathic Innovation (FEI). FEI is meant to remind me that breakdowns can occur in any communication and that I as researcher need to actively work for repairing them. The framework also reminds me how important the mindset of the researcher is. FEI is based on a number of ideas from various thought leaders–a bibliography is given at the end. So there is no new stuff here. But putting these ideas into one framework has helped me a lot in my own work. I hope you too will find FEI useful.

The framework–shown in the figure– makes up a staircase. You cannot jump to the top without stepping on each step. Making that useful solution of yours is the last step in the journey. You also need an ongoing evaluation and validation activity that I will come back to at the end. Below I will briefly describe the steps.

The first step is the most important one. It is also the most difficult one to master because for many of us it requires us to become a new human being, to become a giver. Adam Grand, in his excellent book “Give and Take” [1] divides human being into three categories– givers, takers and matchers. Some of us are already so lucky to be givers. This first step in FEI is for those of us who are takers or matchers.

This step is where we need to take control of our reptile brain. We are often experts in our own field of research. Normally when we talk to a user we already have a solution in mind. Either we have developed a solution during years of laborious R&D, or we arrive at a solution in the course of minutes during a conversation with the user. So the rest of the conversation centers around us trying to sell a solution to the user–i.e. taking from the user, gaining advantage for us. The conversation becomes an argumentation instead of a learning process. The aim of this first step in the framework is to help develop a giver’s mindset. This turns the whole dialogue upside down. It encourages us to see ourselves as students who want to learn something, with no egoistic desire to gain anything else than learning from the conversation and giving our knowledge to the user on the user’s terms. We are now the servant of the user. We have no selfish agenda.

The second step is listening. There are dozens of books out there about how to listen well–which is also a symptom of how difficult it is to actually listen and not just hear noises. Most listening frameworks center around listening techniques–see for instance [2]. These techniques are useful in isolation, but they often don’t address the underlying problem: We are not able to listen genuinely when we think as takers. As soon as we hear something coming out of the mouth of a user we start thinking “what’s in it for me?”. The words from the user’s mouth become noise– or worse, they become supporting arguments that we use in order to take more from the user and gain advantage. But if we decide to be a giver– the first step in FEI– we don’t have a personal agenda and then we become curious about hearing what the user has to say. We are empty inside–we need the user to fill us with her wisdom.

The first two steps are crucial, and they have to do with our reptile brain. Thinking about our private agenda is a way of surviving for us that we learned millions of year ago. We need to train ourselves to understand and experience the fact that the user is not a predator. That the user actually has ideas and knowledge that can help us make even better solutions. And in most cases, the user also pays us.

After step 2 comes acquiring. Acquiring is about learning to know the user and her problems. Acquiring consists of skills that can be learned–see for instance [3]. But acquiring cannot be done well without steps 1 and 2. The idea behind acquiring is that the user–even if she has a lot of wisdom and experience– is not able to express herself and her problems without a facilitated process. Your job as a researcher at this step is to help her get the tacit knowledge out of her head and into words and artifacts that are visible and understandable to the outside world. What you need to use are tools such as interviews, observations, or co-design tools such as paper prototyping.

Step 4 is where you as a researcher-innovator complete the job by making the solution you were intending to make– this is normally where you contribute with your core competence. In many cases the final solution will be very different than what you were intending to make. Or so it might seem like. They say defining the problem is half of the solution. So chances are that when you arrive at this point the solution is so obvious that your user can solve the problem with existing technology. How good! Remember again, it is the user who pays. And normally the user pays us to save her money.

The challenge for a researcher is to manage expectations. No one will hire a researcher without core competences. Everyone expects a researcher to come and bring the perfect solution into the room and solve the problem with super magic researcher abilities. The whole world might seem to be designed to make us researchers become takers. Even our users sometimes expect us to jump to conclusions. I experience this all the time as an ICT researcher. People expect me to know everything about ICT solutions and just take the perfect solution out of my researcher bag. We need to educate our users.

Evaluation part in FEI is as important as the other steps. We often delay evaluating our solutions until we are done. But that is obviously too late– what do I do if I did it wrong? There are a number of good evaluation methods documented in numerous books and articles. No matter what method you use, what is important is to do it iteratively and often. I have found the verified learning process that Eric Ries lays out in his excellent book “Lean Startup” [4] to be most useful. You need to break down your process into cycles, with defined deliverable results from each cycle building on results from previous cycles. Practically this means you have to climb the staircase in FEI many times. In addition to many other benefits, this iterative method allows you and the user to look at the deliverable results and evaluate them for yourself.

Pitfalls

“I am already a giver. I give away everything I have made.” Most researchers are fond of open source and open access. Releasing your solutions to the public domain is something completely different than what I describe above. If those solutions are not made using FEI– or other similar approaches– you have failed. You have to actually make those solutions in a cooperative process with the user. What you do afterwards is not part of FEI.

“I listened carefully to the user and did everything you said, but the customer was not happy with the results.” Probably your users and your customers are different people with different needs and expectations. Probably you failed to do a proper stakeholder analysis– which is part of any sound project management method. Your user might need user friendly solutions. Your customer might need cheap solutions. Find out who they are do the FEI for each of them.

“I am cooperating with user representatives.” User representatives in many cases will only be the second best thing. It is quite common that expert users or advanced users or even bureaucrats and leaders are marketed as user representatives and sold as typical users. The results will suffer accordingly.