A problem well articulated is half solved

A problem well stated is half solved

Sounds like an aphorism, a pretty statement, but I've seen from experience how much depth this has. We tend to underestimate the significance of the need, and the difficulty in clearly articulating the problem. And this can apply at an individual level or at a collaborative level, at work or in personal equations. 

At an individual level. When upset or angry for instance, we clearly know we're upset or angry with some event or behavior, ours or others, but only know the actual cause at a vague level.  So our normal reaction of the situation is to handle it at the symptom level.

A project is veering off course. Milestones are not being met. There's a sense of urgency and lots of meetings. Urgent takes precedence over Important. But until we spend the time identifying and understanding the root cause, there's not much real progress we're going to make with the solutions.

Articulating is to figure out the what of it down to a single or more, clear statement level. It in essence means digging deeper to understand the crux of the issue. Once there, getting to the how of it becomes so much more efficient.

Lets do this through examples, one from a work experience and one from a personal one:

Work:

This is a case of multiple stakeholders collaborating on a business need. 

To get real value from working together, we need the problem well articulated and clearly aligned to the interests of all parties.

                              

Here's a sanitized story of one such initiative at a company. 

Let's call it White Co, a parts supplier for the white goods industry (the durable consumer appliances that tend to have a white finish — air conditioners, refrigerators, and so on).

It had taken a long time to organize the workshop. White Co had put huge efforts in convincing a key customer to participate and had done its best to set up the event well. They had picked a location designed to spark people’s imagination, and both parties had sent representatives from multiple functions that included experts and key executives from both companies. Commitment and expectations were high.

But the workshop flopped. The issue, it turned out, was that the problem they were trying to solve through the exercise was relevant only to White Co and not its customer, so the customer’s people soon disengaged. In an attempt to salvage things, White Co switched to a problem that was important to its customer, but it soon became apparent that this didn't work either, because it really wasn't relevant to the White Co people. Both sides ended up disappointed and will be unlikely to want to repeat the experiment.

                                                

This happens more often than you might think. In businesses, managers all too often treat such ”co-creation” as an event rather than a process and therefore focus almost exclusively on the workshop. But the workshop is only a point in a process that starts with the careful, collaborative design of a problem statement. Here are some tips on how to write a winning problem statement:

Brainstorm and iterate: Analyze needs and priorities to identify problems that could be relevant for both sides.

Select several problem statements: Don’t go into the workshop with just one problem statement.

Rank-order the list: Agree with your customer on shared criteria and then score each of the listed problems accordingly. 

Such collaboration can be difficult, but focusing your initial effort on jointly defining a clear problem will make it more likely that you will achieve real, sustainable value in the long term.

The Personal example in a separate post..... to work around risk of tl..rl :)