Critical Thinking: Step 2 – Define and Refine an Approach

Or suffer the consequences…You don’t want to find yourself trying to untangle a huge ball of string at the end of your project.

Recently we talked about the importance of writing down your perception of any problem you are trying to solve. This time, I’ll focus on taking that problem and building out an analytical framework.

When I teach this material in my Critical Thinking class, I emphasize the efficiency and clarity you gain from a structured approach to problem solving. If writing the problem down (and gaining buy-in) is the first step, then defining (and refining) an approach is the second.

So why should I care about building an “Approach”?

Last time I emphasized the importance of defining “what is the problem/where are we going” by defining your problem and showing it to others to test and refine that definition. It’s critical, but not sufficient.

Next we need to take a well thought out, but rapid, stab at “how are we going to get there?” Think of this step as building a draft roadmap. Without a map, you may know where you are trying to get but good luck finding your way there. (Michele can tell you about my stereo-typical male problems with this!)

Laying out a clear representation of your analytical framework has a number of subtle benefits beyond the obvious ones.

Obvious Benefits

Putting a more detailed view of the problem in print has all of the benefits we discussed regarding problem definition including clarifying your own thinking, exposing it to others for feedback etc.

Because this step involves drilling deeper into the problem and identifying specific questions and research to conduct it also forces you to confront inter-relationships between parts of the problem.

It also allows you to decompose the problem into more discreet bits to work on.

Subtle Benefits

Stakeholder buy in – I feel like I’ve become “Mr. Stakeholder” for the amount of time I talk about it. But without it you are sunk in any group-based decision making process. Sharing and iterating your framework with others accomplishes a few key things:

–       Gives those who agree with you the confidence to support you.

–       Highlights who disagrees with you or is resistant and more importantly forces them to articulate why. This allows you to understand what evidence is required to either persuade or mitigate risk.

–       Generally improves the clarity and focus of the framework when multiple perspectives are included.

Better intuitive understanding of the problem / continual learning – It’s my observation that we only really learn when we get to a point where we have a framework to hang new facts or observations on. My academic colleagues would call this having a “theory base”. Does new data or evidence confirm or challenge your view of the problem? To answer this you have to have a view, but be willing to let it evolve. Without a “theory” you’re just collecting facts…and they may not even be relevant.

Evolving your story – As your understanding evolves, so does your story. My students find that their final presentation is MUCH easier when they are disciplined throughout the process because you have been refining, tuning and clarifying continuously. You can’t get to the end and say “now what do I think?” if you’ve been structured all along.

If it’s so important, why don’t we do it already?

I won’t repeat the past posts observations about time, pressure and misjudging our prior knowledge, but there are a few additional things at this stage worth highlighting.

Difficulty with “unstructured” or “ill-defined” problems – Not all problems are created equal. Some are “well-defined” (limited scope, within the solver’s experience and can be approached with their existing knowledge and skills). Unstructured problems are complex, can appear impossible to resolve and force the solver to move beyond their experience and skills.

What I propose in terms of problem formulation, research design etc. becomes more important the bigger and messier the problem is for all the reasons I’ve mentioned. The margin of error becomes huge the more ill-defined it is and the more continuous course correction needs to be.

Bias towards “having the answer” – I see a bias towards having the answer in many academic and business settings. (We could dub this “assertiveness bias”.) Case discussions in business school can become more about argumentation and winning than they are about discovery. Staff meetings can be about positioning and power. But frankly, it’s not reasonable to look at something briefly and have “THE” answer. Genuine problem solving in a complex environment requires broad thinking and openness to non-obvious answers. Always ask someone to “prove-it”. Facts are friendly, but can take time and effort to build.

Impatience – This is related to “answer bias”. As Veruca Salt yelled at her father, “I want it and I want it now Daddy!” (Charlie and the Chocolate Factory for those who might miss the reference.) The boss needs an answer now. The Professor just called on me. To be clear, I am NOT urging you to dither or be indecisive. But where you have the latitude or influence, push for analytical clarity and to “go slow to go fast”. Better process leads to more enduring and insightful answers.

So what do I do?

I propose a simple excel based template that many call an “issue tree”. Working from left to right, it typically will have 4-5 columns depending on the scale of the problem you are working on.

You can tackle the template in any order you choose. Most will start left to right, working from higher level questions into more detailed ones. But if you are getting stuck or lost, try right to left or bounce around. It’s intended to be a tool to capture your thinking and help structure it, not a restrain to it. (So don’t “check your brain at the door”.)

I will assume you are doing this on a project that is reasonably challenging and involves multiple stakeholders. It is still a powerful personal tool, but I’m choosing the more difficult environment to illustrate a few more concepts.

Primary Question (column 1) – What is the highest level/main question you are trying to answer? See a more detailed discussion here.

It seems so obvious. So clear. OK, then try to write it down and get 5 people to agree. My experience and the consistent feedback I get from students and executives is that it is much harder than it seems.

You have to be clear in your own mind and then come to common terms and understanding with others. It can be surprisingly hard, particularly on cross-disciplinary/functional problems.

Sub Questions (columns 2 & 3) – What is the sub-set of underlying questions that if answered will answer the primary question?

Deconstruct the big question/issue into its constituent parts. In consulting, they’ll talk about being “MECE” (mutually exclusive and collectively exhaustive). You want to make sure you have laid out ALL the questions and made them as distinct and non-overlapping as possible (i.e. don’t have 4 questions all asking essentially the same thing).

This is where things get messy. You have to really work through the relationship between questions, issues and data. You have to wrangle with different levels of detail and aggregation. This is where the bulk of the challenge and heavy thinking lays. You’ll have to debate what questions are most important, what data would be required and how hard is it to get etc. This is the beginning of analytical clarity and the prioritization that has to come. Because you can’t do everything and you won’t have perfect evidence. Ever. (Sorry, but it’s true.)

Analysis (column 4) – What specific sets of analyses and data sources are required to adequately answer the given question?

You aren’t done until you have articulated with (reasonable) specificity where and how you plan to get the evidence required to answer your questions. Will it be surveys? Do we already have the data or do we need to build and launch a survey? Do we have time and can we get approval? You get the idea…

Some evidence takes a significant investment of time and energy to get. This framework helps evaluate whether it’s worth it (and sometimes it isn’t). If it is, it lays out a clear framework for why and helps the justification. Much better to say “we need to launch a survey to answer these xx questions” than it is to basically answer “because we’re not sure what we think and want to go fishing to see if we catch anything good”.

Responsibility (optional column) – Who’s going to do it and by when?

Some project are straightforward enough that this simple template can become the planning document as well. So feel free to add detail as appropriate. If you are working on a complex and large problem, you’ll probably need a more detailed work plan. You can be the judge.

Here’s a very simple generic example of how you might start on a business strategy problem.

 Primary Question  Sub Questions  Analysis
How can we grow a new opportunity to $XX of revenue and XX% operating margin in 20xx? Is the market attractive? How large is it? Analysis required and target source(s) – for EACH significant subquestion
How fast is it growing?
What is the competitive environment?
Are there unmet consumer needs?
What is the current state of our related business? What existing relationships can we leverage?
Can any current products be effective in this market?
Other relevant internal factors…
What is our strategic intent? What is company or BU strategy?
Does opportunity fit into overarching strategy?
What is our best strategy for scaling up growth? Where can we best compete?
How can we best compete?
Can we win? Taken together, can above analysis yield a practical path to profitable growth?

Some thoughts about the process:

I still agree with all my points in “Write the Problem Down”, so won’t restate them here. Here are a few more specific to this step.

Go slow to go fast…

In my opinion, this tool is really the linchpin of the overall process. If you get this right, it tends to force you to handle other things well. You could come into this with a weak problem statement, but do a good job here and recover because you have really drilled into core issues. Those might force you to consider scope, stakeholders and other things you had glossed over before.

But if you get this step “wrong” (and by that I mostly mean you don’t drill in seriously) you’ll be without a rudder until you circle back and get squared away. A friend of mine at McKinsey likes to tell students that “your life at the end of the project is largely determined by how well you spend the first week.” Problem and approach definition is what he is talking about.

You won’t be right… first.

In the beginning you may not even know what you don’t know. But this tool can become a tracking document for where your thinking is. Again, it will help you in developing a “theory base” and subsequently a “fact base’ for your problem. So don’t get hung up on perfection at the beginning. You won’t be “right”, nor should you be.

This process isn’t sterile, pristine or sacrosanct so don’t get hung up on the process

It’s easy to become a tool junky and get persnickety about process, sometime to the detriment of progress. What matters is that you do the conceptual pieces. If you prefer Mind Manager software, or some other visualization tool, Great! Go for it. The initial pass at this shouldn’t take weeks (or even a week). It should take a few good hours and then begin to iterate it.

You may need to go do some initial work to build this out. It can be in parallel with other work, so long as you are clarifying analytical priorities along the way.

Be sensible

Use a little judgment. The amount of planning and thinking that goes into projects varies based on their scope and risk. So don’t check your brain at the door.


Leave a Reply

Your email address will not be published. Required fields are marked *