Why a failed solution is worth keeping
Knowing how to learn from failed solutions starts with not forgetting them. The attempt fails, the problem stays, and a month later the same idea comes back as if it were new. A failed solution holds real information: it says that this action, in this situation, did not move the problem. That is useful only if it is written down.
A journal built for this exists. Problem Graph records a problem in one line, attaches each solution that was tried, and marks the outcome as worked, partly or failed. A solution that failed stays on the map as a failed solution instead of being deleted. The rest of this piece applies the same habit with any notebook, so the method is what matters.
The aim is plain. Make every failure leave behind a short record that your next attempt can read.
What forgetting costs
When a solution fails and nothing is written down, three things tend to happen. You repeat it, because it still looks sensible. You blame the wrong cause, because you remember the mood of the attempt and not its details. Or you give up on the whole problem, because the failure is taken as a fact about you and not about one idea.
The Wikipedia entry on problem solving describes the process as achieving a goal by overcoming obstacles. It also lists mental obstacles that keep people from finding solutions, among them confirmation bias, mental set and functional fixedness. A written record cannot remove those, but it gives you something outside your head to check them against.
How to learn from failed solutions: four lines per attempt
You do not need a long entry. For each solution you try, four lines are enough:
- The idea. What you did, in a sentence that a stranger could follow.
- The situation. What was true at the time: who was involved, what was limited, what had changed.
- What happened. The facts, not the feeling. Dates, numbers and who said what.
- The outcome. One of three words: worked, partly or failed.
The journal uses the same shape. A solution is added as an idea, marked when it is being tried, and given its outcome afterwards. Keeping the outcome to three words matters, because it stops a failure from turning into a long story that you never read again.
Find the cause before you drop the idea
The failed solution is not always the bad idea. Sometimes a good idea failed because of one condition that can be changed. To tell the two apart, look for the cause.
The method used in engineering and medicine for this is root-cause analysis. The Wikipedia page lists four steps: describe the problem clearly, set out a timeline from the normal situation to the moment the problem appeared, tell the root cause apart from other causal factors, and draw a causal graph between the root cause and the problem. You can do a small version of each step on one page of a notebook.
The page also says that this analysis generally feeds a remediation process, where corrective actions are taken to prevent the problem from recurring. That is the point of recording a failure: the next action is different because the cause is known.
A worked example: the deposit that failed
Take a freelancer with a problem: clients settle late. Call it "Late invoices" and put it in the work lane. Three ideas go on the list: automatic reminders, a deposit upfront, and late fees.
The first month, the freelancer tries a deposit upfront. Two of four clients refuse and one goes elsewhere. The entry reads:
- Idea: ask for 30 percent upfront on every new job.
- Situation: new clients, no contract template, fee already agreed on a call.
- What happened: asked after the fee was agreed. Two refused, one left, one agreed.
- Outcome: failed.
A weak note would stop there and the freelancer would never try a deposit again. Now look for the cause. Was the idea wrong, or the timing? The deposit came as a surprise, after the fee was settled. That is a condition that can change. The freelancer adds a line: "failed because it was raised after the fee was agreed, not because deposits are refused."
The next attempt puts the deposit in the first quote, before the fee is settled. That is a new entry, linked to the first. If it fails too, the record shows two attempts and two causes, and the freelancer can see that the deposit was never the real problem. The journal's home page uses this same problem as its example, with reminders marked as settling invoices 9 days sooner, and a deposit upfront and late fees listed beside them.
Read the record before you try again
A record only helps if you read it. Before any new attempt, open the problem and read every entry under it. Ask three questions:
- Has this idea been tried before, and what happened?
- Is a past failure caused by something that is different now?
- Which causes keep showing up in more than one failure?
The third question is where a record pays back most. One failure is an event. Three failures with the same cause are a finding.
Watch for the habit of reading failures your way
The same Wikipedia page defines confirmation bias as an unintentional tendency to collect and use data that favors preconceived notions. It shows up in failure notes in a quiet way: you blame the cause you already believed in. If you thought the client was careless, every late payment becomes proof of it.
Write the facts first and the cause second, and keep them in separate lines. Then ask what you would see if your favoured cause were wrong. If you cannot name anything, the cause is a belief and not a finding.
Link problems that belong together
Causes often cross problems. A freelancer who finds that "raised too late" explains the failed deposit may find the same pattern in a failed rate rise. On the site, problems that belong together can be linked, even across its four lanes (personal, work, expert and scientific), so a pattern shows on the map that a list would hide. On paper, you can get the same effect with a shared tag.
The site also shows similar problems other people have shared and which of their solutions worked. A borrowed solution keeps a link back to where it came from, and the graph records outcomes only; it does not promise that a borrowed idea will work for you. That boundary is worth copying in your own notes. Treat another person's success as a lead to try, and record your own result next to it.
Frequently asked questions
Should a failed solution be deleted from a problem journal?
No. Keep it with its outcome and its reason. A deleted failure is the one most likely to be tried again.
How much detail does a failed solution need?
Four short lines: the idea, the situation, what happened and the outcome. Add the cause once you have looked for it.
What if a solution only partly worked?
Record it as partly, and write which part helped and which did not. A partial result is often the best clue to what to change next.
How do you tell a bad idea from a good idea that failed?
Look for the cause. If a condition that can change explains the failure, such as timing, wording or who was involved, the idea may deserve a second attempt. If not, move on.
How many failures should you collect before changing approach?
There is no fixed number. Change approach when two or more failures share a cause that your current idea cannot avoid.