What it means to track what you tried
Most people who solve a hard problem keep the plan in their head and lose the attempts. The short answer to how to track what you tried to solve a problem is one written line per attempt: what you did, how it ended and why. Anything shorter is memory, and memory drops the failures first.
A tool built for this is Problem Graph, a journal that draws itself: a problem goes down in one line, the solutions tried and what happened are attached, and links between problems appear on a graph. A notebook or a spreadsheet can hold the same record. What matters is that every attempt has a place to land.
Why memory is a poor tracker
Trying things until one works is the oldest way to solve a problem. Trial and error is described as repeated, varied attempts that are continued until success, or until the person stops trying. The second half of that sentence is the risk. People stop when they run out of patience, and patience runs out faster when they cannot see what they have already covered.
The same page says the approach works best on simple problems and is often the last resort when no apparent rule applies. It also says it is not careless by nature: a person can be methodical in the way they change the variables. Tracking is what makes the method methodical. Without a record, attempt six is often attempt two again, with a new name.
The record also helps the person who made it. A problem that drags on for weeks gets many half-remembered fixes. Some were tried properly. Some were tried for an afternoon. Some were only talked about. Only a note can tell those three apart.
How to track what you tried to solve a problem: four fields per attempt
Give every attempt the same four fields. Keep each one to a line.
- The attempt. What you did, in words another person could repeat. "Sent a reminder three days before the due date" is repeatable. "Chased people" is not.
- The state. Where it stands: an idea, being tried, or finished. Keeping ideas apart from tried attempts stops you from counting a plan as a result.
- The outcome. Worked, partly or failed. Add the thing you measured, if there was one, such as days saved or complaints received.
- The reason. Your best explanation for the outcome, and how sure you are. A guess marked as a guess is still better than no entry.
That journal uses the same shape. A solution is added as an idea, marked when it is being tried, and given an outcome of worked, partly or failed. A solution that failed stays on the map as a failed solution, so the failure is still there to read later.
Write the entry on the day the attempt ends. Two weeks later you will remember the result but not the conditions, and the conditions are what let you decide whether the same idea could work again.
A worked example: late invoices
The example follows the one on the project's home page, filled out with an invented freelancer. The problem, in one line: clients settle invoices too slowly. The freelancer records three attempts.
- Automatic reminders. State: tried. Outcome: worked; invoices were settled 9 days sooner. Reason: the clients did not refuse to settle, they forgot, and a reminder removed the forgetting.
- A deposit upfront. State: tried. Outcome: partly. Reason: clients who agreed did settle sooner, but two new clients walked away before signing, so the deposit helped one part of the problem and cost something elsewhere.
- Late fees. State: idea, not yet tried. Outcome: blank. Reason: the freelancer fears it will strain good relationships and wants to read the other two entries first.
Three things stand out once the entries exist. The freelancer can see that reminders solved the main cause, so the other two ideas are now optional. The partial result on the deposit is specific enough to act on: a smaller deposit, or one only for new work, is a different attempt, and it can be logged as one. And the idea that has not been tried is honestly marked, so nobody mistakes it for a failure.
Write the problem down before the attempts
Attempts need something to be attempts at. Problem solving is often split into well-defined problems, which have specific obstacles and goals, and ill-defined problems, in which the situation is troublesome but it is not clear what kind of resolution to aim for. A tracking log helps both, but in different ways.
With a well-defined problem, the one-line statement is easy and the log counts what has been covered. With an ill-defined one, the log is where the problem gets sharper. Early outcomes tell you what the real obstacle is, and you can rewrite the problem line as you learn. Keep the old wording in the entry, so the history of the problem stays readable.
The same page separates simple problem solving, which addresses one issue, from complex problem solving, which has several interrelated obstacles. If a problem has several, give each obstacle its own line and its own attempts. The journal lets problems that belong together be linked, even across its four lanes of personal, work, expert and scientific, so a shared cause shows up on the map.
Read the log before every new attempt
A log that is never read is only a diary. Make one habit around it: before you try something new, read the entries for that problem and ask three questions.
- Has this exact idea been tried? If so, what was different then?
- Has a close relative of this idea failed? If so, did the reason apply here too?
- Which entries have an outcome but no reason? Fill those in first, while you still can.
The first question is the one that saves the most time. Recording trials is not a new idea. In his puzzle-box experiments, Edward Lee Thorndike plotted learning curves that recorded the timing for each trial, so progress could be read from the curve and not from impression. A written line per attempt does the same job for a problem in daily life: it shows whether the attempts are getting anywhere.
Keep the failed attempts, and mark partial ones as partial
The urge is to tidy the log by deleting what did not work. Resist it. A failed attempt with its reason is the entry most likely to stop someone repeating it, and that someone is often you in a month. The home page puts it this way: a solution that failed three times stays on the map as a failed solution, and that is what the next person needs to know.
Partial outcomes need the same care. "Partly" with no detail is a shrug. "Partly: helped for existing clients, hurt with new ones" is a lead. Write which part helped and which did not, and the next attempt often suggests itself.
Frequently asked questions
How detailed should each entry be?
Detailed enough that someone else could repeat the attempt and understand its result. Four short lines usually do it: what, state, outcome and reason.
Should ideas that were never tried go in the log?
Yes, marked as ideas. They keep your list of options in one place, and the mark stops an untried idea from being read later as a failed one.
What if the reason for a failure is unclear?
Write that you do not know, and what you would need to see to find out. An honest gap is more useful than a confident guess.
Is a spreadsheet enough?
For a single problem, yes. A spreadsheet or notebook with the four fields works. A graph starts to help when several problems share causes and you want to see the links.
When is it time to change the approach?
When the log shows two or more attempts failing for the same reason and your next idea does not get around that reason, the approach itself needs to change.
What a record of attempts can and cannot tell you
A log of attempts shows what happened, in the order it happened, with the reasons you gave at the time. It does not prove that a reason was right, and it cannot say that an attempt that worked once will work again in different conditions. A reminder that settled invoices sooner for one freelancer says nothing certain about another person's clients.
What the record does give is a firmer base for the next decision. Each entry turns an unsure memory into a statement that can be checked, disputed or reversed, and a problem that has a written history of attempts is easier to hand to a colleague, a friend or an expert, who can start from what was done and not from a vague account of it.