Most people approach a problem by staring at it. Something is broken, something isn’t working, and you try to reason forward from the current state toward a fix. Sometimes that works fine. But there’s a class of problems — usually the messier, more ambiguous ones — where staring at the problem just produces more confusion.
The approach that’s changed how I think about these: don’t start at the problem. Start at the solution.
What does the end result actually look like?
Before doing anything else, describe the finished state as concretely as you can. Not “it works” — what does working mean, exactly? What does a user see? What does the output look like? What can you do at the end that you can’t do now?
This sounds trivial but it’s often where the real clarity comes from. A lot of problems feel unsolvable because the goal is vague. “The performance is bad” is not a destination. “The page loads in under one second on a mobile connection” is. “Users are churning” is not. “Users who complete onboarding retain at 80%; currently it’s 40%” is.
Once you have a concrete picture of the end state, you can work backwards from it.
Work backwards from the solution
Trace the chain in reverse. Given that the end state looks like X, what would have to be true one step before X? And one step before that?
This is how detectives work. You don’t start at the beginning of the crime — you start at the evidence, and you reconstruct the chain of events that could have produced it. It’s also how mathematicians approach proofs: assume the thing you want to be true, then figure out what it would require.
Working backwards has a useful property: it forces you to be specific about preconditions. At each step you have to ask “what would have to be true for this step to work?” — which is often exactly the question you were struggling to ask while staring at the problem from the front.
Work forwards from where you are
At the same time, trace forward from where you actually are. What do you have? What can you do from here? What does the next step look like?
This half of the process is more familiar. It’s the normal direction of problem-solving. But doing it after you’ve already sketched the backwards path means you’re not just wandering forward hoping to end up somewhere useful — you know where you’re headed.
Find the intersection
You’re now running two paths: one backwards from the solution, one forwards from the current state. At some point they should meet. The gap between them — the place where the backwards path and the forwards path don’t connect — is the actual problem.
This is what makes it feel like solving a maze. If you’ve ever tried to solve a maze by only starting from the entrance, you know how easy it is to go deep down a wrong path before realising it’s a dead end. But if you work from both ends simultaneously — tracing inward from the entrance and inward from the exit — you find the connection point much faster. The maze is the same. The strategy changes how much of it you have to explore.
The intersection is where the question becomes concrete: why can’t I get from here to there? Usually by this point you already know. You’ve been forced to be specific about both ends, and the gap between them is obvious in a way it wasn’t when you were staring at the problem from one direction.
When this is most useful
Not every problem needs this. If the fix is obvious, just fix it.
But this approach earns its keep when:
- The problem is vague or hard to articulate
- You’ve been going in circles without making progress
- There are multiple moving parts and you’re not sure which one is actually broken
- The “obvious” fix keeps not working and you’re not sure why
The last one in particular. If you’ve tried the obvious thing twice and it hasn’t worked, the usual cause is that the obvious thing is fixing the symptom while the actual problem is somewhere else in the chain. Working backwards from the desired state often surfaces where the chain actually breaks.
A quick example
Say a form submission isn’t saving to the database.
Working forward from the current state: the user fills in the form, hits submit, the request goes out… and then what? You follow the request. Does it reach the server? Does validation pass? Does the database call happen?
Working backwards from the end state: what does a successful save look like? A row in the database. What would produce that row? A successful query. What would produce that query? A valid payload arriving at the right handler. What would produce that payload? A correctly structured request from the frontend.
Now trace both paths until they stop connecting. Maybe the forward path shows the request reaching the server correctly. Maybe the backwards path shows the handler expects a field that the frontend isn’t sending. The gap is obvious once both paths are on the table — but from either direction alone, it’s easy to look in the wrong place.
It works outside of code too
The example above is software because that’s my day job, but the method isn’t specific to debugging. I’ve used it on completely physical problems with no prior knowledge, and it holds up just as well.
While I was in Thailand I picked up a couple of camera lenses at a market for almost nothing. The price made sense — they were broken. I’d been doing photography for about two days at that point. I had no idea how a lens worked mechanically, no repair experience, and no particular reason to think I could fix them. I just knew they weren’t behaving the way a working lens should.
So I started at the end: what does a functioning lens actually do? Light enters, elements focus it, the aperture controls how much gets through, the autofocus motor moves the glass. Work backwards — if the focus isn’t locking, what in that chain could fail? Motor? Sensor? Mechanical obstruction? The glass itself?
Fortunately in Thailand you can order lens spanner wrenches, rubber friction tools, and a full disassembly kit from Shopee or Lazada and have them the next day for almost nothing. So I ordered the tools and opened the lenses. Working backwards from “what should be happening” gave me a map of what to look for even though I didn’t know the territory. One had a bent aperture blade. The other had a detached autofocus ribbon. Both fixable.
I’ve always enjoyed fixing things — broken tech, household items, whatever needs attention. There’s a saying in Afrikaans: ‘n boer maak ‘n plan — roughly, a farmer finds a way. No specialist, no manual, no formal training required. You just reason from what the thing is supposed to do, work backwards to what might be preventing it, and figure it out from there.
The backwards method is just that instinct, made deliberate.
It sounds almost too simple. Work from both ends, find the gap. But the act of describing the end state concretely, before you’ve started solving, changes the quality of everything that follows. You stop exploring in the dark and start navigating toward something specific. The problem usually turns out to be smaller and more locatable than it looked when you were just staring at it.