He wasn’t pleased that the group didn’t know what the staff on the frontline did. So, he asked them to spend a day in the bank’s branch and observe what the staff did.
The group returned with their observations and admitted that their idea was faulty.
It seems that product and tech teams don’t invest enough time and effort in learning what their users do, or how they perform their jobs.
Asking users what they want isn’t a good approach:
Don’t ask users what they want. Users don’t know what they want, so they ‘dictate’ what they desire.
You should have heard the quote attributed to Henry Ford where he says, “If I had asked them what they want, they would have said a faster horse!”
Horse cart users would have desired for faster and healthier horses, and more comfortable carts.
So, Instead of asking users what they want and then jumping right on doing that, we should:
– ask them for their pain points
– get their insights and learn from those
– ‘explore’ rather than ‘gather’ requirements
So what do we do if not ask users?
It is true that often users are served features or products that aren’t useful for them. Possibly because people who build those products never find out how users do what they do. That’s another problem because of which we see so may rubbish products in the market.
A while ago, my doctor (GP) explained a similar situation to me. She was struggling to use the software that the health practice had recently bought from a software firm.
Her comment was, ”They built this software for doctors without understanding what doctors do and how they might use this software.” Fair enough!
Not engaging with potential customers or users is one of the biggest shortcomings of product development. An even bigger problem is not knowing what the users actually do.
Knowing what a user does provides deeper insights into their work. Those insights can significantly inform and influence the development work that the product teams undertake.
