Mind Engineering

When out speaking with prospects and clients, I often see myself in them. I think this is a good thing as it allows me to empathise with them, and better understand the way they see the world. When doing this I often catch myself thinking "that was me 5 years ago" or "that was me 10 years ago", or sometimes "That is interesting! Wonder why she is doing it that way?"

Recently it occurred to me that we all seem to be on the same journey of maturation as product developers. Where we through time and experience move through different stages, where in particular the driving question underlying the product development process seems to change.

What can I build? I started out as a software developer. As a professional I took a lot of pride in my ability to efficiently deliver reliable products by the book, with all the whistles and bells I believed to be necessary.

I was particularly interested in the affordances found in the solution space, asking what can I build? It would be fair to say that I had a tendency to fall in love with the products - after all they were perfect if I may say so myself (no bias here)...

What do I think they want or need? Despite being a practitioner of Agile and thus (mostly) working by the book. I found that our users often did not seem even close to as enthusiastic about our products as I did.

This got me thinking that if the goal of Agile is to reduce waste of resource (efficiency). Is it not committing the ultimate sin by building ineffective solutions, that would just be thrown away by our users?

This made me realise the importance of empathising with the user. And I started to practice what I believed to be User-Centered Design (UCD). Asking what do I think our users want or need?

Can they use it? After a while UCD led me to start observing my users in action. This is when I noticed that they were struggling to use our products. Stupid users right?! However, after a while it occurred to me that the reason why they were struggling, was that they did not have the same knowledge about our product as I did.

Given that I myself was not the user of the product, the user interface should be adapted to the knowledge held by the first-time user (I know, who would have thought?). This new-found interest for usability, had me asking can they use it?

Do they need it? After investing a lot of time and resource into learning about usability. I noticed that despite being able to use our products, people were still choosing not to(!) Almost as if they didn't care about the problems our products were solving - and that was exactly it(!) This realisation had me asking do they need it?

Do they want it? Despite validating (proving) that our users had the problems the product were solving. I often found that what I believed to be relevant prospects (fancy word for potential customer) still did not want the products. Due to that the problems the product were solving was just not painful enough for the prospects to care.

Afterwards I learned that it has been found time and time again that if the problem being solved is painful enough, people will figure out how to use a product (almost) regardless of usability. This insight had me asking do they want it?

Will they use it? Confident that I had cracked it, I was completely blind-sided when users who had told us that they most definitely had a problem and wanted a solution for it. Still chose NOT to use it when we made a highly usable product and provided it to them.

Were they lying to us? Yes - kind of. It turns out that due to a range of different cognitive bias such as for example hyperbolic discounting, which is a fancy way of saying that humans are really bad at predicting their own future behaviour. As well social desirability bias, meaning that people tend to tell you what they think you want to hear - as they have nothing to win by upsetting you. There was a strong dissociation between what people were saying and actually doing.

This led me to start asking will they use it? And I find that ultimately all the other questions comes second or third to this. I'm not saying that market research, usability etc is irrelevant, but rather that they come second to the often ignored ‘willability’.

Why does the question matter? I have found that the questions I ask have a fundamental influence on the way I approach new product development. If you focus on usability, usability is what you get. If you focus on ‘willability’, ‘willability’ is what you get. - And I know which one I prefer(!)

The hard part of product development (most of the time) is not actually making the product, but rather making people use the product. This is what we are all about here at Mind Engineering. We help you find, understand and solve: the right problem, for the right user, in the right way.

Raise your hand if you have heard this story before...

An engineer has an idea and starts building a product. As a professional he or she takes pride in making the product by the book. Giving it all the bells and whistles he believes to be necessary.

He keeps on building until one day when he becomes aware that he is running out of money - and the product is not even finished yet(!) With the growing worry of imminent failure he starts making an effort to sell the product. He starts approaching prospects, which tells him that his product is interesting - but despite this they are still not buying it.

With time the passion for the project fades and it is eventually put on ice - indefinitely(!)

Sounds familiar?

As product developers our job is to develop products. Or is it?

It is said that if the only tool you have is a hammer, everything looks like a nail. As product developers we have a bias towards focusing upon building solutions.

But when you think about it, a technical solution is fundamentally the automated solving of a problem. It follows that for a solution to be effective and attractive it must be solving the right problem for the right user in the right way.

Thus what we primarily should be developing is our understanding of how our user experiences the problem and solution space.

We call this the problem-first approach.

People intrigued by our company name often ask: What is Mind Engineering? To be honest this is a question we struggled to answer for a long time, as Mind Engineering is more of a philosophy. But at the end of the day it boils down to the following…

When speaking with prospects or clients we often find it necessary to make them aware, that the hard part of product development (most of the time) is not actually making the product, but rather making people use the product. And make no mistake: users are what make products successful.

By incorporating this obvious yet often ignored notion into our practices, we find that it fundamentally changes the way we approach new product development. Where our focus shift from making ‘better’ products to making more successful users. Going from asking “What features can we build?” to “What problems can we solve?”

This means that the actual product is merely a byproduct of the new product development process. What we are really designing and engineering is human emotions, cognitions and behaviours. And we argue that our primary job as product developers is not to develop products, but rather to develop empathy or understanding of how the user experiences the problem and solution (space).

Some might call this User-Centered Design (UCD). However, unlike UCD we are not as interested in whether people can use a product, as opposed to whether people actually will use a product. This due to that it simply does not matter if people can use a product - if they actually choose not to!

Furthermore, it have been found time and time again that if the problem being solved is painful enough, people will figure out how to use a product (almost) regardless of usability. With this we are not saying that usability is irrelevant, but rather that it comes second to the often ignored ‘willability’.

These ideas and values inform our mission here at Mind Engineering. We help you find, understand and solve: the right problem, for the right user, in the right way.