Ask anyone what their problem is and they will tell you exactly how they want to solve it and make it go away.
I could easily come up with a few of my own problems and solutions to them, but their wrong. It’s not that I don’t trust myself,
It’s not that I don’t trust myself, it’s that they are framed by own view as to how I perceive the problem. In that frame, whether I want to accept it or not, I have already inferred a number of assumptions important to me, but perhaps not relevant to the problem at hand – either based on my own perceptions, personal
In that frame, whether I want to accept it or not, I have already inferred a number of assumptions important to me, but perhaps not relevant to the problem at hand – either based on my own perceptions, personal decision-making framework, and/or environment.
That’s why when working with a customer, it’s important to dig deep to understand the problem they are trying to solve before suggesting solutions and platforms that could fix their problem.
Customers don’t always want to hear this because they “know best” for the very same reason that I know the answers to all of my own problems – by the framework and worldview that surrounds me. Sure there will always be some aspects of alignment but it’s important to not take this at face value.
So how do you get a customer to buy into seeing the demo they need?
- Show them what they believe their problem to be, get them to agree to what has been discussed with their team during a requirements session.
- Show them what their problem really is and watch.
Did you get it right? Did you get it wrong?
Perhaps – but did you start the conversation to go deeper?
That’s the goal.
In the end, it’s about starting that conversation of what they need vs what they think they want and moving forward to solve the real problem.
And it’s not solely for customers either – take the word customer and replace it with “team”, “colleague”, “project”, etc.