It's always tempting to jump to solutions, but sometimes it helps to listen first.
"Solutioning" is the process of creating solutions. Contrary to what the name might suggest, that process actually begins with Listening. Unfortunately those of us who are solution-oriented tend to skip the entire process and go straight to solving problems, sometimes before we even know what the problem is. I know I do, because I'm intuitive. I'm ahead of the pack. They'll catch up.
Throughout my 16 years of software design - and in a lifetime of problem solving - I have been guilty of jumping to solutions. And I've also made the assumption that if I alone understand the problem, then my colleagues must see it the same way. They might even be thankful that I am so magically clairvoyant. "Good for him! Not only does it get it, he's fixing it!"
Umm, that's not how its works - especially in a group. What works is this: Listen, Discuss, Agree, Define, Solve.
How many times have you listened to someone complain and, by the time s/he finished unloading, the complaint had somehow gone away?
My cousin George was one of the original designers of Adobe Lightroom and then became a senior evangelist for the product. Seems there were some disgruntled members of a Windows user group up in Seattle who were upset because the Windows version of Lightroom had less functionality compared to the Mac OS version. He travelled up to Seattle with a knapsack stuffed full of Lighroom t-shirts and hats, booked two tables at a restaurant with a nice view overlooking the Sound, and listened to them for two hours. By the end of the meeting, everyone was happy and felt listened to. And, as it turns out, they were happy with the overall user experience of the app.
This is not always the case, but it does helps to listen first.
Customer A says "It's really hard to use this text messaging application because it doesn't connect to my contacts list."
Customer B says "I don't want any messaging app intruding on the privacy of my contacts list."
Developer C says "Customer B is right and our app cannot access the user's contacts list because that's not secure."
Marketing Guy D says "I think most of our potential customers will be type A."
Big Boss E said "We are in the business of providing secure connections for our customers. I'm with type B."
So, what did you hear? Is there a problem? Very much so. Sounds like we may need five different solutions. Or maybe five different apps!
It might be tempting to start solving the problem by saying "we need multiple solutions". It might also be tempting to say "This problem can't be solved until we make a business or technical decision." But in both cases, we're getting ahead of the game. Let's try to define the problem first, so that people who are entrusted with solving the problem - typically the Design, Development, and R&D teams - can begin solving objectively.
After one day in a locked meeting room, A, B, C, D, and E came up with this definition of the issue:
"As a user, I need quick and easy access to a selected set of contacts while making secure calls and texts, without exposing my phone's address list to hackers."
They also clarified using a negative:
"As a user, I do not need to have my address book open when making secure calls."
With the problem - or the user need - whittled down to one succinct statement that everyone can agree with, it's much easier for the solutioners to swoop in and work their magic. They may still have to consider multiple approaches because of technical limitations, business limitations, and balancing user needs. But by framing the issue in relatively dispassionate, objective terms, all of the stakeholders will have moved closer together and will be that much more likely to accept the proposed solution.
Listen to the problem.
Discuss it with everyone else.
Agree that there is a problem.
Define the problem dispassionately and objectively
Solve
