Hi there,

Have you ever been stuck on a problem that keeps coming back, no matter how many times you think you have fixed it? Or found yourself about to make a big call and realized you are not fully sure your reasoning holds up?

Both situations share the same root cause: the thinking behind the decision was not clear before the action was taken. These two tools from Untools help with that, at different stages of the process.

Check your reasoning with the Ladder of Inference

Developed by former Harvard professor Chris Argyris, the Ladder of Inference is a tool that helps you fill the gaps in your thinking and make decisions based on reality rather than assumptions you have not examined.

The ladder has seven rungs that represent our mental processes. At the bottom: available data, what is actually observable. At the top: actions, what you do as a result. In between: selected data, interpretations, assumptions, conclusions, and beliefs.

These processes usually happen unconsciously and very quickly. Problems arise when we skip rungs, failing to acknowledge how a conclusion was formed before we act on it.

How to use it

Whenever you are about to make a decision or take action, stop and identify which rung of the ladder you are currently on. Then work your way back down, questioning each step:

• Why am I concluding this? What assumptions am I making?

• Are those assumptions valid? What else could the data mean?

• What did I ignore or not pay attention to? Are there other sources of data I did not consider?

Then rebuild your reasoning back up, this time more consciously and deliberately. You will often reach the same conclusion but with far more confidence.

Example

You are managing a team of developers. One of them has been missing deadlines and several projects have slipped as a result. You conclude he is not right for the job and decide to let him go.

But before you act, you pause and apply the ladder. You work back down:

• Why do I believe this is the right call? Because he clearly is not performing.

• What is that based on? The conclusion that he is not a good developer.

• What am I assuming? That his recent results reflect his overall ability.

• What else could the data mean? The deadlines may be unrealistic. He may be taking extra care to deliver quality work.

• What have I not looked at? I have not spoken to him directly. If I do, I might find the real reason.

The chain of flawed reasoning was: missed deadlines, inefficient, not a good developer, should be fired. By stepping back, you approach the situation more objectively. You might find the deadlines are too tight, or that he is dealing with something personal. Neither of which justify the decision you were about to make.

The ladder did not tell you to keep him. It told you the case was not ready to make yet.

Map the causes before you pick one with the Ishikawa Diagram

When a problem keeps coming back despite fixes, it usually means the fix addressed a symptom rather than a root cause. The Ishikawa Diagram, also called the fishbone or cause-and-effect diagram, is a structured way to map all the possible causes of a problem before deciding which one to act on.

Created by Japanese professor Kaoru Ishikawa, it is particularly useful for problems that have multiple potential causes across different areas. Exactly the kind of problem where intuition alone tends to miss things.

How to use it

1. Define the problem. Write it clearly at the head of the diagram. Specificity matters: "declining customer retention" is better than "things are not working."

2. Identify contributing categories. Draw branches for each category of factors that could be contributing. The classic set is People, Methods, Equipment, Materials, Measurement, Environment. Use your own if they fit better.

3. Find possible root causes under each category. For each category, ask "why is this happening?" and write down every possible cause, even partial ones. Do not filter at this stage. You are building a map, not reaching a verdict.

4. Analyze the diagram. Step back and look at the full picture. Which causes appear across multiple categories? Which can you test quickly? Where is the most likely leverage point?

Example

Say you are a product manager and sign-ups have been declining steadily over the past quarter. You start with that problem at the head of the diagram and begin identifying contributing factors. In this case you land on three: landing page issues, competition, and marketing.
Now you dig into possible root causes under each:

• Landing page: slow load time, unclear value proposition, sign-up flow has too many steps

• Competition: a competitor launched a cheaper alternative, their onboarding is simpler

• Marketing: ad spend was reduced last month, messaging has not been updated in six months, targeting the wrong audience segment

With all of these written down, you can begin to analyze where the problem actually originates. You might first check whether conversion rate has stayed steady despite lower traffic, which would point to a marketing issue rather than a product one. Or you might audit the sign-up flow directly to find where people are dropping off.

The diagram stops you from jumping straight to "we need to spend more on ads" before you know whether the problem is traffic, conversion, or something else entirely.

Common mistake to avoid

Jumping straight from "what is the problem?" to "what is the fix?" The diagram forces a step in between: understanding the full landscape of causes before committing to one. A solution that looks obvious from the outside often turns out to be addressing only one branch of a much wider picture.

When to use it

• Recurring problems that keep coming back despite previous fixes

• Post-mortems and team retrospectives

• Any situation where you want to understand causes before committing to a solution

Vault members get the full thinking toolkit with practical templates for every tool covered in this newsletter and more, designed to help you communicate and think more clearly. $99 one-time for lifetime access.

Get Untools Vault

These two tools work well together. Before you reach for a fix, use the Ishikawa Diagram to map what is actually causing the problem. Before you act on a conclusion, use the Ladder of Inference to check your reasoning holds up. Both take less than ten minutes and will save you from solving the wrong thing.

Until next time,

Tobe