Most planning advice assumes a stable future.
Make a plan. Stick to it. Measure against the plan. Success means execution matched the forecast.
That works until the future shifts in ways you didn’t predict. Then the plan becomes a liability.
The journey from no plan to too much plan
I learned this through a fairly predictable cycle.
When I started building, there was no plan. Just an idea and willingness to see what happened. Build something, see if it works, adjust. Repeat. It was chaotic, but it was also the phase where I learned fastest. Every mistake taught something immediately because there was no plan insulating me from the result.
Then I learned planning frameworks. Scrum, Kanban, agile techniques. Suddenly there were ways to be systematic about direction. It felt like progress. If chaos was learning by accident, this was learning by design.
So I tried to apply it rigorously. Detailed sprints. Careful estimation. Plans refined before execution. For a while it worked. Things felt controlled and intentional.
But at some point the cost showed up. The plans became brittle. A change in requirements meant restructuring everything. A discovery mid-sprint meant the whole framework felt wrong. I found myself spending more time maintaining the plan than building the thing. And the more I tried to perfect the plan upfront, the more I resisted changes that didn’t fit the structure.
That’s when it became clear. I had overcorrected.
Constraints force clarity, but only if you let them
The problem with too much planning is that it tries to optimize for a future you can’t actually see. More options, more contingencies, more flexibility in the plan. But actually, constraints are what make planning work.
When I worked on that first paid freelance project, the product direction kept shifting. The client had a vision, but as we explored what was actually feasible, what the market differentiation could actually be, things changed. Early on, we had a broad pet platform idea. Then we narrowed it.
That narrowing didn’t happen because we suddenly had perfect clarity. It happened because we hit real constraints. Technical feasibility. What we could actually build and defend in a limited timeframe. What differentiation looked like when you removed the fantasy of building everything.
The constraint forced a choice. Without it, we’d still be trying to plan for a version that didn’t fit reality.
Same thing with my thesis. Early on, I had a much broader model. Six check types. Three provenance domains. It sounded comprehensive on paper. Infeasible in practice. Feedback pushed toward declared variation instead of trying to capture everything the system could possibly do.
Again, a constraint. What I could actually implement. What I could defend. The constraint forced me to narrow and strengthen instead of broaden.
This is where people usually get planning wrong. They see constraints as obstacles to work around. Actually, constraints are the thing that makes planning stop being fantasy and start being real.
Uncertainty requires slack, not precision
But here’s the other side. Once you’re in the work, tight planning becomes a trap.
I’ve learned this cycling through diet, language learning, and building apps. When I tried to plan everything perfectly beforehand. the exact routine, the exact structure, the exact milestones. it held until something broke. And something always breaks. Life gets busier. Priorities shift. You discover you were wrong about something fundamental.
Tight plans don’t survive contact with that uncertainty.
What actually works is building slack into the system. Not slack as in wasted time. Slack as in intentional flexibility.
With Finnish, I stopped trying to optimize the perfect learning routine and started building a small daily minimum that could survive disruption. Reviews, exposure, some real output. Nothing fancy. But flexible enough to keep working even when other things demanded attention.
With building, I stopped trying to perfect the plan and started thinking in smaller increments. Limited scope per iteration. Build something small. See what works. Adjust. The vision stays, but how you pursue it stays flexible.
With diet, I stopped trying to nail every meal and set one anchor. One solid meal per day that covers what matters. Everything else is flexible. The constraint (one meal) gives structure. The flexibility everywhere else makes it survivable.
In each case, the pattern is the same. you can’t predict what will break, so you don’t plan for precision. You plan for recovery. You make it easy to iterate without everything falling apart.
The paradox
Here’s what I missed for a long time. constraints actually enable better planning than freedom does.
More options paralyze. Real limits force decisions. And in execution, trying to plan for certainty fails. But planning for uncertainty, building in the ability to be wrong without catastrophe, that works.
Planning doesn’t mean predicting accurately. It means accepting you’ll be wrong and structuring so wrong isn’t fatal.
That’s the difference between a plan that gets abandoned when reality shifts and a plan that bends.
What this looks like
I still think about product vision. I still consider direction carefully. But I’ve stopped trying to achieve perfection in the first iteration.
Build incrementally. Limit how much each problem can break. Keep the ability to change course. That’s where the work actually happens. The plan guides. But it doesn’t constrain the learning.
Constraints force you to make hard choices upfront. Uncertainty forces you to leave room for being wrong. Together, they’re what makes planning under real conditions actually work.
The future will surprise you. Plan for that. Not by predicting more accurately. By building in the slack to survive being surprised.
