Just Do It assumes you know what the “it” is. For a whole class of problems that is the exact piece you are missing, and the slogan tells you to skip the only step that would have found it.
I did not plan my way into code. In 2016, two years into 3D work, I started writing scripts to drive geometry in Rhino and Grasshopper, because I wanted forms faster and had no idea what that would turn into. I worked through tens of online courses with no plan for them. By the time I enrolled in a bootcamp it was easy, because I had already been inside the problem for years. Nothing about that sequence was a strategy. Starting was the thinking, and the plan appeared afterwards, once there was something to plan with.
Two kinds of problem, and the tell that separates them
Some problems are legible from outside. You can see the whole shape, list the options, weigh the trade-offs, and pick. Migrating a service to a new host. Adding a field to a form. Planning genuinely works on these, and starting without a plan there is impatience wearing a productivity hat.
Others are foggy. You can see clearly for a short distance and not at all beyond it. The options cannot be listed, because most of them are not visible yet. Most new products are here. So is most work in an unfamiliar domain, and almost every “we should probably look at X” that has sat on a roadmap for two quarters.
The failure is applying the first mode to the second. It looks responsible. It produces documents and comparison tables built on assumptions nobody has tested, and it absorbs weeks while the actual uncertainty sits exactly where it was on day one.
The tell is reliable: when you try to plan, you keep needing to assume something you have no basis for. If every branch of the plan rests on a guess, you are generating fiction in a confident format.
What starting actually gives you
Movement in fog buys resolution rather than distance. You can now see things that were invisible an hour ago.
How the options interact. On paper, choices look independent. In practice, choosing one changes what the others cost and often deletes several outright. That shows up in the first hour of contact and reorders everything.
Which constraints are real. Half the constraints in any plan are assumed rather than verified. Building the smallest version sorts the real ones from the imagined ones faster than any discussion, and it is usually a different half than everyone expected.
Whether you were solving the right problem. This is the most common outcome of starting and the most valuable. The problem turns out to be a different one, and that discovery never appears in a planning document, because the document was written by someone who had not had contact yet.
Whether to continue at all. Starting is how you get the information that tells you to stop, and stopping early is a win planning cannot deliver, because planning has no mechanism for finding out it was wrong.
Starting is not committing
The standard objection is that starting on the wrong thing wastes effort, and sometimes it does. Mostly the objection confuses starting with committing, and separating them is half the benefit.
Starting means building the smallest thing that produces real contact with the problem. It is designed to be thrown away. Its output is information, specifically the information that could not be obtained any other way.
The grand version is the prototype that saves the quarter. The ordinary version is three habits on a normal week:
- Fog check – Stop planning the moment every branch rests on a guess, because the planning felt productive and that is why the step gets skipped.
- Friday build – Build the version you would happily delete on Friday, because anything you would fight to keep has quietly become a commitment.
- Scary part – Point it straight at the thing you are least sure about, because a prototype that avoids the scary part is a demo.
The fear of starting is usually a fear of commitment in disguise. Separate them and the cost of starting collapses: a day, deliberately disposable, in exchange for resolving uncertainty that would otherwise sit there for weeks getting more expensive.
What AI actually changed here
This is the part I think is new, and the reason to write this now rather than a few years ago.
The cost of fog was always that you could not see far enough ahead to judge whether a direction was worth walking. You had to walk it. That is still true. What changed is how far you can see before you start.
Describe a direction and get back a reasonable account of where it leads: likely failure modes, what gets hard at scale, what usually goes wrong with this shape of approach. That is a synthesis of how similar things have gone, which is exactly the information you were missing, and which used to require finding someone who had done it and getting an hour of their time.
The smallest version of three approaches is now a day rather than three weeks. You can afford contact with several directions before committing to any of them.
And fog is often partly linguistic. You cannot plan because you cannot state the problem. Talking it through with something that reflects a structured version back is a fast way to find out whether the fog is in the problem or only in your description of it, and those need completely different responses.
To be fair to the other side: the projection is a synthesis of the typical case, and the interesting problems are precisely the ones where you are not in the typical case. It sees further into the fog. It does not remove it. Treating a projection as knowledge is how you walk confidently in a direction nobody checked, which is the general shape of how these tools quietly replace your judgment if you let them.
Why this is hard to do in an organisation
Starting without a plan feels unprofessional, and in a company it is harder to defend than a document. The document looks like work. The disposable prototype looks like fooling around, right up until it is the thing that saved the quarter, at which point nobody remembers being sceptical.
What makes it defensible: you are acquiring the inputs the analysis requires rather than skipping it. A plan built on assumptions is less rigorous than a prototype built to test them. It is only dressed better.
That loop is a specific case of a general rule about decisions under uncertainty: buy information before you buy the position. A disposable prototype is the cheapest information purchase available in technical work. The same test decides which repair to attempt once something is already broken, where the cheap option is worth reaching for only while failing it is free.
Years later, none of the scripts from 2016 survive, and the direction they revealed is the job I have now. The prototypes were disposable. What they showed me was not.
Some problems can only be seen from inside; for those, the professional move is to start. Which item on your roadmap has been planned for two quarters and touched for none?