What is the Real Problem?

September 12, 2009

My life as a manager involves me with a variety of meetings and conversations every day. I hold regular one-on-ones with my direct reports, attend project meetings, management meetings, customer calls, along with engaging in conversations or meetings that are geared towards moving something forward on some front. Someone always wants to know when something will be done, who is available to work on a critical problem or new project, or to discuss overcoming an obstacle.

A major part of defining direction is to understand the problem at hand, and sometimes this means probing a little, even if the problem appears to be obvious. One example that I was faced with recently was a customer request for a report. The customer presented a 30+ page document that described the data required and the format that the data needed to be in to allow it to be sent electronically to another party, among other things.

The document was presented to me at a meeting – which started late due to other pressing issues – along with the following statement: “The customer needs this to run automatically. I know that everyone is already booked, but is this something that you can do, and if so, how quickly can you do this?”

I looked through the first few pages of the document while I asked for the background on the request. I then began poking at the particulars.

“What do they mean by automated?” I asked.

“I’m not sure,” was the response.

"Is the database configured to hold the 18 fields that are being asked for in the output?”


“Well,” I said, “this seems like a simple request and a slam-dunk.”

But the fact that it seemed so easy also bothered me. I knew that the customer had in-house database personnel, so I really was curious as to why they were asking us to perform this seemingly simple task, especially since we would charge them for our time.

“Are they generating this report today?” I asked, immediately following with, “And why are they asking us to do this? Does their request have something to do with their desire for this to be automated?”

Our customer liaison indicated that the customer was in fact generating the report already through a third-party reporting tool.

My response was that while this seemed simple enough, we needed to clarify just what the customer specifically desired before providing a cost estimate. I could easily see how we could accomplish the request, but we would likely be providing the customer a solution that was “the same thing, only different” from what they already possessed – as a billable exercise. I was sure that this would not please the customer.

We had two valuable clues that pointed towards a clarifying conversation with the customer:
  • We didn’t understand the “automation” portion of the request.

  • We understood that the customer was generating this report today, but we didn’t understand what was inadequate about it. Perhaps all that we needed to do was assist them in automating what they already had available.
In this case, the quality of the solution – from the customer’s perspective – would be directly proportional to the quality of the description of the problem. The key to getting at the real crux of the customer’s desire was to keep asking why, and not stopping until the customer’s perspective – and true goal – was articulated. We needed to dig deeper, moving past the literal wording of the request to gain an understanding just what the customer wanted to accomplish.

For a quick guide to problem-solving, have a look at How to Define a Problem, an article that I found on wikiHow. As the article points out, the most important step in solving a problem is clearly defining the problem in the first place.