July 2, 2026
The Problem Framework
A problem is not a thing. It is a position: your distance from an unknown. The deep-dive on the framework I derived at 18, drowning in chaos, that turns problem-solving into one repeatable move.
This essay has an interactive module: The Problem Framework. Run it →This is the reading version of the Problem Framework module. The module is fast and interactive. This is the slow, deep version, for when you want to actually sit with the idea.
Where this came from
At 18 I was head of marketing at Adagio, living away from home for the first time, running a team of ten. Some of them had masters degrees, and they reported to a kid who had not finished his undergrad. Laundry, groceries, payroll, branding calls, family fights, money on the line. Stress was arriving from every direction at once, all day, every day.
Somewhere in that mess, my brain, which likes patterns more than it likes comfort, noticed something odd. I was not facing one big problem. I was facing problems as a category. Payroll, the family fight, the branding decision: one word stretching across situations that had nothing in common. When a single word stretches that far, it is usually hiding something.
Here is what it was hiding. Most people treat problem-ness as a fixed property of a situation, something that lives inside the thing itself, like mass or colour. But if that were true, nothing you could ever do to yourself would change it. You would be a prisoner of every difficult situation forever. That is plainly false, and one thought experiment shows why.
The bomb in the stadium
Picture a live bomb planted in the middle of a packed stadium. Same bomb, same timer, two observers. Observer A is sitting in row 12, close enough that the blast would reach them. Observer B is watching from a hill three kilometres away, completely out of range.
Is the bomb a problem for both of them?
Intuition says yes: a bomb among people is a problem, full stop, and B's distance changes urgency, not status. But look closely at B's next sixty seconds. Nothing in them is unresolved. For him the bomb is terrible news, not a problem. For A, everything is unresolved. Will it go off? Can I get out in time? Which exit? A is standing inside a cloud of unknowns, and B is standing outside it.
The sharper objection says B has a moral problem: should he warn people, call someone, help? Notice the move that objection makes. It hands B a decision with something unresolved inside it, and the moment it does, B genuinely has a problem. But it is a new problem, and it is his. The bomb itself is still only A's. The objection proves the point: problems attach to whatever is unresolved inside a person's situation, never to objects.
Same bomb. A live problem for one, a headline for the other. What differs is not the bomb. It is each person's relationship to the unknown around it. This is the thought experiment that cracked the whole thing open for me.
A problem is a state, not a thing
So here is the framework, the realization that finally made the word make sense to me.
A problem is not a thing. It is a state. Specifically, it is the state of facing the unknown. The moment your familiar mental map runs out and you are standing on a frontier with no instructions, that is a problem. Not the bomb. Not the payroll. The unknown wrapped around it. Take the costume off the word and underneath there is always exactly one thing: something you do not yet know.
This sounds abstract until you notice what it does to the sentence "I have a problem." Under the old view, that sentence describes the world. Under this view, it describes you: your position, your distance from an unknown. The world is mostly outside your control. Your position is not. You cannot always move the bomb. You can almost always move yourself along the axis.
Problem, challenge, asset: three distances
Once a problem is a position on an unknown axis rather than a property, you can slide a situation along that axis and watch its name change.
Unknown to you: it is a problem. You do not know how to face it or how to escape it. Known to you: it is a challenge. You know exactly what it is and what to do, you simply have to execute. Mastered by you: it is an asset. It is not just painless. It is a thing you can now point at others and use.
Same situation, three different words, and the only variable that moved is how much of the unknown you have eaten.
Fire is the cleanest proof. To an early human, fire was a calamity. It ate the forest, it killed, it was a thing you ran from screaming. Today the exact same chemical reaction cooks your food, smelts your metal, sterilises wounds, and runs the engine that got you to work. Nothing about fire changed. We changed position: fire went from a thing we did not understand, to a thing we knew, to a thing we command.
Two tempting wrong answers deserve a burial here. The first says our tools did it: hearths, engines, extinguishers. But tools are the receipts of understanding. You cannot build an engine around a reaction whose behaviour is still a mystery to you. Mastery came first; the equipment is what it left behind. The second says familiarity did it, that a million years of living near fire dulled the fear. But familiarity without knowledge just breeds casualties. Standing near a thing does not convert what you do not understand about it.
The encouraging consequence: whatever is stressing you today is a candidate for the exact same journey. It was a problem before it was a tool, just like fire.
The only move, and the two ways to make it
If every problem is an unknown wearing a costume, then solving any problem is one move repeated: convert unknown to known. That is it. That is the whole game.
Here is what surprised me when I derived this in my Adagio chaos: there are not a hundred ways to make that conversion. There are exactly two. Everything you have ever called problem-solving is one of these, or a mix.
Go wide: ask people who have done it, copy a pattern that already exists, borrow a solution from the system around you. Wide is fast and cheap, and it circumvents the problem. You get past it, and you are exactly as capable as you were before.
Go deep: sit with the problem yourself, alone, long enough to derive its structure from scratch. Deep is slow and it hurts, and it converts the problem into an asset, because now you own its structure.
I compress it into one line: you can solve a problem two ways, ask around or sit with it. The first frees you. The second makes you rich.
Two schools get this wrong in opposite directions. One says deep should always be your default, because borrowed answers build dependence. Seductive, and wrong, because depth is expensive: spending deep work on unknowns that never compound is how thorough people stay stuck. The other says the methods are interchangeable, so pick whichever is cheaper. Also wrong, because the end states are not identical. Wide leaves you unchanged. Deep leaves you owning something. They exit in different places, and knowing which exit a situation deserves is half of being good at this.
But some problems are just problems, no?
Let me steelman the resistance, because this framework can sound like positive thinking in a lab coat.
Objection one: this is just reframing. The payroll is still due, the bomb still explodes. True, and the framework never denies it. It claims the workable part of the situation is the unknown, and it points you at that part with precision. Denial looks away from a situation. This looks at it harder than panic ever does.
Objection two: some situations are objectively terrible, a diagnosis, a business collapsing, and calling them positions on an axis feels cold. Fair. But separate the pain from the problem. The pain is real and deserves its own time. The problem, the part that responds to effort, is still a stack of specific unknowns: what are the options, what do I do first. The framework does not eat your grief. It isolates the workable part so the grief and the work stop contaminating each other.
Objection three: this makes everything my fault, since the problem lives in my position. No. It makes everything your move. Fault is about the past. Position is about the next step. Those are different games, and only one of them pays.
Under stress, point at the unknown
Here is where the framework stops being philosophy and starts paying rent. Any time you are anxious, stuck, spiralling, do one thing before anything else. Pause and ask: what exactly is unknown to me here? Strip the emotional label off. Do not say this is a disaster. Just point at the unknown. Nine times out of ten the stress was downstream of one specific thing you did not know, and the moment you name it, it shrinks from a fog into a target. The fog was never the problem. The unknown inside it was.
Then comes the humbling part. Audit your stress map on paper. Write out everything you currently call a problem: the client conversation you are dreading, the tax filing, the pitch you keep not making, the workout you keep skipping. Tag each one honestly as unknown, known, or mastered. Most of your so-called problems will turn out to be knowns. The dreaded client call has zero missing information inside it. There is no mystery left, just discomfort and avoidance. And the fix for a known is not more thinking. It is execution.
A real problem has an unknown in it. Most of yours do not. Do not dignify procrastination by calling it a problem. This is why more planning rarely helps a chronic staller: he keeps running problem-solving machinery on things that are already solved.
Someone else's problem is your asset
Now the part that turns a calm-down tool into a money tool.
Because problem-ness sits on a personal axis, the very same situation can be a screaming problem to one person and a quiet asset to you, simply because you have already eaten that unknown. This is the entire structure of a business. A dentist is not paying you for a website. He is paying you to delete an unknown he has no intention of ever mastering.
So the leverage move is this: find a problem that is unknown to most people but knowable by you, because of your background, your network, or your skill, and you are sitting on the highest-leverage asset there is. I did exactly this. I narrowed my agency down to surgeons of a particular kind, a market whose unknowns I had already converted, where almost nobody else had. Low competition is just other people's unmastered unknown. That is all a niche is: a patch of unknowns you got to first.
Pricing follows the same logic. The freelancer charging twenty thousand rupees and the one charging five lakhs are often doing similar hours. They are not removing similar unknowns. You are paid in proportion to the size and scariness of the unknown you delete.
Two ways to waste the framework
Two failure modes will quietly eat you if you let them.
Wide forever: asking around becomes a substitute for ever understanding anything. You bypass every problem and convert none, so you stay shallow and replaceable.
Deep with no end: sitting with a problem curdles into wallowing and rumination, depth with no checkpoint and no exit. It feels like work because it is heavy, but work moves your position on the axis. Rumination just circles it.
The discipline is matching the method to the stakes. Bypass wide by default. Save the slow, painful deep work for the handful of problems whose mastery actually compounds into an asset. Spend depth like money, because it is.
Run it this week
Do this with a pen, not in your head.
Write down the five things weighing on you most right now, the ones you would call problems. Next to each, write exactly one of three words: unknown, known, or mastered. Be brutally honest about the knowns.
Then, for every item you tagged unknown, write a single letter. W if you should go wide, borrow a solution, and bypass it. D if this unknown is worth converting into an asset you will own for life.
You will usually find one D in the pile and a stack of knowns you have been calling problems to avoid doing them. The knowns need execution. The Ws need one message, one search, one call to someone who has already done it. And that single D is where your real work is. It is the unknown that, once eaten, stops being your problem and starts being your edge.
A problem is not a thing. It is a position. Move.
Want the fast, interactive version instead? Run the Problem Framework module, or explore the whole codex.