look before you leap.

My jaw rarely drops when I happen upon another web professional’s blog. This article entitled “the problem vs the answer” made my jaw drop because it is something I have been ranting about for the past two weeks. I have been stumbling over the explanation; I couldn’t have said it better than Tom Knoll did:

Why is everyone more interested in the answer than the question?

When you have a problem that needs to be solved, you should be more interested in the questions than the answers. Solutions come from good questions, not prepackaged answers. I know you are pressed on every side and feel like you do not have enough time to worry about good questions. But good questions now, will save you exponential time in the future. If you allow many small under-pressure-solutions to stack up, you end up with a building that cannot be repaired, but can only be torn down and rebuilt.

There is a tendency in my field to provide a set number of answers, rather than taking time to consider the questions with people. I look forward to the day when we feel like we have time to ask the best questions and consider the best answers.

My jaw rarely drops when I happen upon another web professional’s blog. This article entitled “the problem vs the answer” made my jaw drop because it is something I have been ranting about for the past two weeks. I have been stumbling over the explanation; I couldn’t have said it better than Tom Knoll did:

Why is everyone more interested in the answer than the question?

When you have a problem that needs to be solved, you should be more interested in the questions than the answers. Solutions come from good questions, not prepackaged answers. I know you are pressed on every side and feel like you do not have enough time to worry about good questions. But good questions now, will save you exponential time in the future. If you allow many small under-pressure-solutions to stack up, you end up with a building that cannot be repaired, but can only be torn down and rebuilt.

There is a tendency in my field to provide a set number of answers, rather than taking time to consider the questions with people. I look forward to the day when we feel like we have time to ask the best questions and consider the best answers.


Blame Darwin

Humans solve problems naturally to survive. We get a buzz from talking about solutions. The solution is viewed as “taking action”, and we like to feel like we are making progress. But if we do not pause and ask specific and thoughtful questions about the problems we are facing, we have no way to judge what is an important problem and what is just small potatoes. Without a defined problem, we’re depending on trial-and-error and can only learn in hindsight. When it comes to survival of the fittest, and you are the one attempting to solve the problem of the saber-toothed tiger in front of you and you can only grab a rock if one is fortunately nearby, hindsight is usually moot after about 3 seconds.

Problem definition questions are specifically built to get us to be less dependent on hindsight (and beat evolution!). Not only do they help us select the best solution, they get clients to focus on defining the problem instead of the solution. I have had many projects begin with a client coming to me with a pre-selected solution that they want me to implement. As a solution-builder, that pretty much ties my hands and prevents me from using all of my experience and training. It seems just as ludicrous for me to tell someone else what their problems are; why should my client tell me which solution I should implement? The roles are crossed. The client is the expert (whether they know it or not) in defining the problem. I’m the solution expert. I’m not doing anyone any favors by taking the first solution presented without asking questions designed to better define the problem.

One hat, two hat, green hat, blue hat

Edward de Bono’s Six Thinking Hats talks about the importance of questions as an initiation to any problem-solving exercise. I’ve paraphrased a few of his questions into a list that usually helps jump-start a problem discussion:

  • What is the current state of affairs, and what problems does this current state cause?
  • Who is affected by those problems?
  • What are we trying to ultimately change or achieve?
  • If we solved all those problems, how would the world be different?
  • Who controls the systems affected by these problems?
  • What is the risk involved in attempting to solve these problems?

By answering these questions, we both comprehensively define the specific problems we’re trying to solve and set ourselves up with a way to check for success. Without investigating the problem, we have no way to do a good job of measuring our level of success. We just implement things without any metric that tells us if it was a good idea after all.

Talk to the hand

The challenge I see is not getting people to read this blog and think it is a good idea. The challenge arises the next time someone comes to me with a solution they need me to implement. I have to convince them it is a good idea to pause, backtrack, and define the problem when all they want to do is just get a solution in place. People tend to sing a different song when it’s their problem that needs to be solved.

1 thought on “look before you leap.”

  1. Being in the same field and essentially dealing with same issues, I completly understand your point of view. Awsome entry. Keep it up. I might recognize you in the bar sometime.

Comments are closed.