Thinking · June 2026
What “thinking it through” actually is
Most of the work in an idea comes before the building: finding the one problem hidden under the answer.
An idea arrives as an answer — something to build, already half-drawn. An app that does this. A site with that. The shape shows up first. What the shape is actually for, in plain words, nobody has said yet.
That gap is the whole job. Not the building — the gap.
When you first hear an idea, it’s usually a solution wrapped tight around a problem nobody has named. The solution is the loud part — specific, exciting, you can almost see it. The problem underneath is quieter, and a little dull. Most of the time the person holding the idea has never said it out loud. They didn’t have to. They jumped straight to the answer. Everyone does. That’s just how ideas feel.
So the first real work is to pull the two apart. Put the solution down. Ask the boring question: what is this actually for? If it didn’t exist, what would go wrong for an actual person?
You keep asking until the answer fits in one plain sentence — one a stranger could repeat back to you. Not a paragraph. Not “it’s like X but for Y.” One sentence. Until you have that, all you’re holding is the idea’s costume.
“Notifications”, for example
Say the idea is notifications. The product should send notifications. But “notifications” is already an answer. The real question underneath: what is this person afraid of missing? Maybe nothing. Maybe the actual problem is that the important thing sits buried three taps deep — and the fix is a different first screen, not a notification at all. The word you were handed pointed at a solution. The problem was a layer down, wanting something else entirely.
The wrong clock
This sounds slow. It is, a little — but only if you’re watching the wrong clock. That sentence is the cheapest thing in the whole project to change. You can rewrite it over an afternoon. Find the same decision three months later, inside something already built, and it costs weeks to undo, because by then the sentence has turned into code and screens, with habits already formed around it. Blur doesn’t burn off once you start building. It gets poured into the foundation, and it sets.
There’s a reason this step gets skipped, and it isn’t laziness. Naming the problem plainly is dangerous — to the solution. Say it clearly enough and half the features you were excited about quietly stop making sense. They were answering a problem nobody had checked was real. Easier to leave the answer alone and start building. Building feels like progress. Questioning doesn’t.
Clarity, early
Done right, the problem gets sharp enough that the rest stops being an argument. You don’t debate whether to add a feature. You hold it up against the sentence, and it either belongs or it doesn’t. The plan is just the shape of the problem, traced out. People mistake this for taste, or experience. Usually it’s just clarity that showed up early, before there was anything built to be precious about.
This is patience more than cleverness. Just refusing to move yet. An idea comes in blurry — every real one does — and the urge is to fix the blur by adding. More features. More screens. But you can’t add your way to focus. It’s what’s left when the wrong things fall away and the one real thing is finally sitting there in front of you.
That’s the hour before anything gets built — the one where nothing visible happens, where there’s nothing to show anyone. It’s the most useful hour in the whole project. Everything after it is just sticking to a sentence you took the time to get right.