How Do You Change Someone’s Mind?
Yesterday, and again this morning, I spent a good chunk of my day changing someone’s mind.
Well, that’s not fair. I spent a good part of my morning convincing someone that the train I was suggesting they take, not the train they were convinced that they needed, was the best way to get to their destination.
One of the hardest parts of working with customers - internal or external - comes when the customer has decided that they not only know the problem, but they also know the right solution. Let’s face it: we all do it. “When all you have is an Agile hammer, everything looks like a nail.”
Walking into the discussion, I’d talked about the customer’s stated goals with our team: what they wanted, and more importantly, the timeframe we had to make it happen. In short, I described the ideal end-game, and then proceeded to define realistic things we could do by the end of the year. At the end of the team’s brainstorming, we’d come up with a fairly elegant solution that, most importantly, was deliverable by this year and…
To co-opt a phrase from Obi-Wan, it met the customer’s goals, from a certain point of view.
Armed with the knowledge that we had an elegant technical solution that met the customer’s goals, I set off to discuss the solution with the customer.
“No, that’s not right.”
“Why not,” I asked.
“Because if you do that, we don’t copy the data.”
Well, there it was. The goal was to display the data from a partner’s site on our site, as stated, so that the third-parties were happier with prominent placement on our site, and so that the end-users who had to keep data up-to-date only had to keep one copy up-to-date.
My team’s solution did that, exactly, and did it in the time we had to develop a solution. But, it didn’t copy data from database A over to a similar looking form in database B.
“Why do we need to do that?”
“Because that’s what we said we’d do.”
Looking over the contract, talking to the third-parties whose problems we were trying to solve, that’s nothing like what they said we needed to do. Their goal is to have their data displayed on our site, and give their customers one place to update our data.
“We didn’t say we’d copy it, we said we’d display it. Our solution does that, and gives their customers one place to update their data. Why do we need to copy it to our database?”
“Because we need to be able to incorporate their data into our backend systems.”
Looking over our solution, I realized that we needed to incorporate the third-party data into our backend business rules. We could do that, using our solution, with minimal additional effort.
“We can do that by modifying our business rules to include the new data source without creating or changing records in our database. Why do we need to copy their data into our database, and overwrite our records?”
“Because we need to increase our numbers in our program for…”
I anticipated this need as well. We could easily count the distinct new records between the two databases, and provide a unified number of clients using our two systems.
I explained this, and then our CEO joined in the ad-hoc solution discussion in the kitchen. Note to self: if you want to have an opportunity to win over converts one at a time, avoid having those conversations in the kitchen.
Luckily for me, one of our other senior managers joined the discussion, and we continued down the same track. At the end of the discussion, after feeling I’d made great headway toward explaining that we both wanted to get to the same destination, but that we had a much faster, nicer train to get there, it was time for the customer and our CEO to go off to a meeting.
As he walked out of the kitchen, his parting comment was, “Well, I think we’re all of the opinion that I’m right.”
If I hadn’t noticed the sarcastic grin when he said it, I’d have given up hope.
As it is, we’re well on the way to getting a strong technical solution in place now, that’s a good step toward the final corporate goals.
When I’m faced with a customer who both knows their problem and thinks that they know the solution, it can be very difficult to examine their solution, together, with an objective mind. The customer knows enough to be dangerously entrenched with both their problem and the Rightness of their perceived solution.
In this case, I used a modified version of the Five Whys to get to the root problems, and helped dissect the reasons that the customer’s solution was an incomplete solution: there were serious data synchronization problems in integrating the two sources that the customer had just accepted as “intractable”, and hand-waved off the table.
There are countless other methods and means to get to the root issues a customer solution is trying to solve. Sometimes, the customer is right, and sometimes, they’re wrong. But in either case, questioning the underlying assumptions and validating any solution is essential to a successful project and a happy customer.
How do you work with your customer, especially those that have a solution already in mind, to uncover their assumptions gently and cooperatively, to build the best solution you can?
