Putting the cart before the horse

Or the solution before we understand the problem

How often do you jump to a solution or search for a tool before you really truly understand the problem you are trying to solve?

I know I do this often …

I am trying to help a friend, colleague, or someone I lead, by telling them a solution to their problem before they have finished telling me what it is.

I have gone to a meeting convinced I know what we are going to talk about and the solution I will propose.

I have also searched for test tools that can help me test something, without having really defined clearly what or how I need to test.

Put simply, we need to fully and clearly understand the problem or problems we are seeking solutions for, because we cannot possibly evaluate any solution well without understanding the what, how, and why it will solve the problem or problems for us.

I can now realize and recognize when I am putting the cart before the horse, so, I can also see others do this.

I am often attending meetings where there are one or more participants who are eager to share the solution they have to a problem we are not all agreeing exists, or at least not all understanding the same way.

In addition, I am often asked what I think about tool X or solution Y without being asked if I have understood what problem needs to be solved by either.

Worse, I am being told a solution for a problem that I have not fully stated needs solving, or that I have fully understood myself.

Or, I am being recommended or told to use a tool when it is not clear what part of, (if indeed), any part of the solution the tool will address.

Ideally the horse should come before the cart. We should clearly and fully understand the problem or problems we need to solve before we seek solutions.

So, how can we do that effectively and consistently?

Here are some simple suggestions;

Meetings:

If the meeting has no agenda – ask what the agenda is, what do we want to get out of this meeting? What are the desired outcomes?

If the meeting seems to be going off course – bring it back by asking if we are still trying to solve the problem we agreed at the beginning or if we are now solving a different one? It may be that some feel the initial problem has been solved, and we are moving on to another. Others may feel that in trying to solve the first problem we identified a second and are now busy trying to solve that. Either way, calling this out will hopefully lead to a (re)statement of the problem that everyone should be currently seeking and evaluating solutions to.

Emails:

If you are sent an email asking you to use, take part in, or help with solving something, but the problem statement is missing or unclear, ask for clarity. I will often try to help the email sender by asking convergent questions, for example;    

I think you are asking me to solve either problem a) or problem b), but I may have misunderstood and you could be asking about c) which I am unclear about, please can you let me know which it is?

If I have guessed correctly and it is either a or b then they can simply reply with a or b and do not need to take the time to explain either fully, as I am letting them know I believe I understand both well enough to proceed with whatever was asked in the original email.


In-person:

Often this will be your boss or a colleague tapping you on the shoulder, catching you in the corridor, or by the water cooler. Asking what you think of tool X or somebody’s solution or idea. If you are not 100% sure of the context or problem that the tool, solution, or idea is in relation to, ask for clarity. For example;    

I am not sure which problem tool X, solution, or idea Y is trying to solve, can you please remind me before I can offer you an opinion?

In summary:

Make sure you clearly understand the problem before seeking or evaluating any solutions.

Wait for the person to finish explaining the problem they have, or how they see it from their perspective.

Ensure every meeting you attend has a clear agenda and desired outcomes. What are the problems we are trying to solve, what are the objectives – so that we can all understand if the meeting is on track and if we should even be there.

Don’t respond to questions about solutions or ideas unless you are sure you are clear on the problems they are addressing – you will not be able to provide good answers or evaluations if you are not clear.

Author: Stuart Ashman

I am currently working as the Director of QA at Vision Critical a market research software and services company. I have been working in a variety of roles involving testing and quality assurance for over 20 years. I started off testing flight deck instruments and progressed through GSM network operations software, Unix Operating Systems and Lights Out Management Firmware, into Anti Virus and Anti-Spam software and HW appliances, finally spending a short period of time testing cloud provisioning and control software before entering into my current position.