Smallest Fix That Could Work: Test It First

The smallest fix that could work is the cheapest change that would show, within days, whether you understand your problem. If you test it before the big one, you learn what is true before you spend weeks and money on a plan built on a guess.

Problem Graph is a journal that draws itself as a map: you write the problem in one line, attach each fix you try, and record whether it worked, partly worked or failed, so the small test and its result stay in front of you when you plan the big one.

The smallest fix that could work: test it before the big one

"Smallest" does not mean "weakest" or "lazy". It means the least you can change while still touching the cause you suspect. A new company-wide tool is large. A one-line checklist sent to one team is small. Both aim at the same problem, but only one can be undone by Friday.

Three traits make a fix small enough to test first:

• It is cheap to reverse. If it fails, you lose an afternoon, not a quarter.
• It is narrow. It covers one person, one team, one week or one case.
• It can show a result soon. You can tell within days whether anything moved.

The word "could" matters. You are not looking for a fix that is certain to work. You are looking for one that has a real chance and a clear way to be wrong.

Why big fixes fail more often than small ones

A big fix bundles many changes and one guess. You pick a cause, build a large answer to it, and only find out at the end if the cause was right. If it fails, you cannot tell which part broke. Maybe the cause was wrong. Maybe the rollout was bad. Maybe people just did not adopt it.

A small fix isolates the guess. If you change one thing and the problem moves, you learned something. If it does not move, you learned something else, and it cost you little. Either way the big plan, if you still need one, now sits on evidence instead of a hunch.

There is also a human cost. A big fix creates commitment. People have spent budget and told others about it, so they defend it even when signs say it is not working. A small test is easy to drop without losing face.

How to find the smallest fix in 5 steps

1. State the problem in one line. If you need a paragraph, you have more than one problem. Split them.
2. Name the suspected cause. Write it as a claim that could be false, such as "People miss the first step because nobody tells them it exists."
3. List the fixes, big to small. Write the large solution first, then keep asking "what is the cheapest version of this?" until you hit something you could do this week.
4. Pick the one that tests the cause. A small fix that does not touch your suspected cause tells you nothing about it.
5. Set the test before you start. Decide what result would count as worked, partly or failed. Do this first so you cannot bend the answer later.

Step 3 does most of the work. People usually write one solution and stop. Forcing a ladder of options, from heavy to light, is how the small one shows up.

Link the fix to a root cause first (5 whys or fishbone)

A small fix aimed at a symptom is just a small waste of time. Before you pick anything, get a better guess at the cause. Two methods help, and our guide on 5 whys or fishbone, and which one to use explains when each fits.

In short, 5 whys follows one chain of causes downward. Fishbone spreads out several possible causes side by side. Use 5 whys when you suspect a single path. Use fishbone when you do not yet know where to look.

Whichever you use, end with one cause you can name in a sentence. That sentence is what your small fix has to touch. If the fix and the cause do not connect, go back a step.

Design a test that can prove the fix wrong

A test that cannot fail is not a test. "We will try it and see how it feels" will always come back as "pretty good." Build the test so a bad outcome is possible and obvious.

• Pick one signal. Choose something you can observe without arguing about it, like whether a task was done by a set day.
• Write the failing result down. For example: "If it is still late in two of three cases, it failed."
• Keep the scope small on purpose. One team or one batch is enough.
• Set a short window. A week or two. Long tests drift.

When the window ends, record the outcome plainly: worked, partly, or failed. "Partly" is a real answer. It usually means you hit part of the cause, and the next small fix should aim at what is left.

Worked example: a late onboarding process

This is a made-up example to show the method, not a real result. Say you run a small team and new hires keep getting their accounts and equipment late, so they sit idle for their first days.

The problem, in one line: "New hires are not set up by their first morning."

The suspected cause (after a quick 5 whys): nobody owns the setup tasks, and the request only goes out after the hire arrives.

The fixes, big to small:

• Buy and roll out an onboarding platform for the whole company.
• Write a full onboarding process document and train every manager.
• Send a five-line checklist to one manager, one week before the next hire starts, with a named person for each line.

The third one touches the suspected cause directly: it gives the tasks an owner and moves the request earlier. It costs about an hour. Write the pass mark first: "If the new hire has accounts and equipment on day one, it worked. If one item is missing, partly. If most are missing, failed."

Run it for the next hire. Suppose the accounts are ready but the equipment is not. That is a "partly." You learned the owner idea and the early request helped, and the equipment step has a different cause, perhaps a longer lead time. Your next small fix is to order equipment as soon as the offer is accepted. You still have not bought a platform.

Our guide to how to test a solution before you commit to it goes deeper on setting the pass mark.

Keeping the record in Problem Graph

This is where a map beats a notes file. In Problem Graph you write the problem as one line and put it in a lane, such as work. You attach each solution as an idea, mark the one you are trying, and record how it went: worked, partly or failed. Then you link the equipment problem to the setup problem, even if they sit in different lanes.

The graph keeps a failed fix on the map as a failed fix. That matters when someone, maybe you in six months, proposes the same idea again. You can see it was tried and what happened.

When the small fix is not enough and you need the big one

Sometimes the small test comes back "failed" for good reasons, and the right move is the larger change. Look for these signs:

• The cause was confirmed, but the small fix could not reach it. The checklist worked every time it was followed, but it is clearly impossible to follow at your scale.
• Several small fixes each gave a "partly." Together they show a structural gap.
• The problem is built into the design. No patch changes it.

The difference now is that your big fix has evidence behind it. You know the cause, you know what did not work, and you can say exactly what the large change must do that the small ones could not. That is a much easier plan to defend and to scope.

If you are unsure what else might work, Problem Graph can show similar problems other people have shared, in any lane, and which of their solutions worked. You can borrow one into your own graph with one tap, and it keeps a link back to where it came from. You can also ask the AI for suggestions. Treat those as proposals to test, not answers. They are good candidates for your list of small fixes.

Frequently asked questions

What is the smallest fix that could work?

It is the cheapest, narrowest change that touches your suspected cause and shows a result soon. It should be easy to undo and have a clear pass or fail line.

How long should a small fix test run?

Long enough to see the signal once or twice, usually a week or two. If you need months to tell, the fix is not small or the signal is too vague.

What if the small fix only partly works?

Record it as partly and ask what part of the cause is left. Then pick another small fix aimed at that remainder instead of jumping to the big one.

Do I need a tool to do this?

No, a page of notes will do. A map helps once you have several linked problems and want to see which fixes worked, partly worked or failed in one place.

Get started with Problem Graph

Try Problem Graph: it is free, and you can look around the public network without an account. Write one problem down in a line and attach the first thing you will try.

Pick the smallest version of that fix, set the pass mark before you begin, and record what happens. The big plan can wait until the small test has told you something.