Most of my big mistakes came from skipping the planning phase. Not from laziness. From eagerness. Bias for action feels productive. It is not always.
Working hard on the wrong plan is not an execution problem. It is a planning problem.
I put in the work but was not always good at sequence. I would start a new initiative with energy, encounter problems, and spend days firefighting. When it failed, I blamed poor execution. The real failure was right at the beginning.
Bent Flyvbjerg studied thousands of large projects. In his book “How Big Things Get Done”, the data is clear: 8.5% of projects finish within cost and time targets. Only 0.5% meet cost, time, and the desired outcome. His data comes from large infrastructure projects. Mine does not. But I have seen the same loop in my own business. I cannot prove the data transfers, but the mechanism feels identical: commitment without a real plan creates a break-fix loop, not delivery.
The model he offers is simple: Think Slow, Act Fast. Plan long, deliver fast. In an operations-heavy business, planning is cheap because you are not spending money yet. Every delay in delivery costs money. The same problem caught in planning costs you time. Caught in delivery, it costs you money you are already spending.
I did the opposite. I planned fast: gut calls, aggressive targets, optimism. Then delivered slowly, trapped in a break-fix loop I built myself. The fix is not more effort. It is better sequence.
Start with the smallest unit you can test.
Before building O9X , I spent money learning this the hard way. I tested Airtable first. Then the system became brittle. One process change required reworking multiple automations. Costs scaled faster than the problems it solved. I moved to ERPNext. I hired external developers to customise it. That was the failure point. No outside team understood the business well enough to build for it. Whether that was their limitation or mine in briefing them, the result was the same. By the time I stopped, I had spent ₹3 lakhs in software costs and months in lost time before writing a single line of O9X code.
What I should have done earlier: ask what is the smallest piece I can build and test. That is what Flyvbjerg calls the Lego block. My first real Lego block for O9X was mapping how the business actually ran. Not how I assumed it ran. That mapping took three weeks. The only cost was my attention. It stopped me from building a system that executed the wrong process with confidence.
Build the block. Test it. If it works, build the next one. If it does not, you have lost weeks, not months. The failure is cheap. This is not moving slowly forever. It is front-loading learning while the cost of being wrong is still low.
The planning phase ends when the goal becomes specific enough to write down. For O9X, I started with a vague aim: improve operations and compliance. As I mapped the business, small errors and gaps surfaced. Each one sharpened the goal. Planning ended when I could write down every change the system needed. That clarity was the signal to move.
A practical test before starting any new initiative:
- Can you write the goal in one paragraph?
- Can you name two real alternatives that meet the same goal?
- Can you say what would make you stop?
If you cannot answer these, you are not ready to commit. Staying in planning is not weakness. It is the job.
The tendency to commit early is the real enemy.
I committed early because it felt like progress. But early commitment on a thin plan does not speed up delivery. It speeds up the break-fix loop. Once work begins, you have already spent money. Stopping feels like waste. It feels like admitting the money already spent is gone. So you continue, even when the plan was never real.
When I am genuinely clueless now, I write down the project goal and the specific feature or workflow I am considering. Then I debate it with AI. I keep the project goal fixed. Everything else is open to change. The goal sharpens. The scope shrinks. Two or three I abandoned entirely. The debate showed they were not worth building. This is a working hypothesis, not a proven system. But it has been the most useful check I have found so far.
If the plan survives that debate, I commit to one Lego block.
Before your next initiative, ask yourself one question:
Am I thinking slow because it is strategic, or because I am afraid to commit?
I have learned to tell the difference by asking one smaller question first:
What is the cheapest test I can run this week?
If I can name it, I am thinking slow for the right reason. If I cannot, I am stalling.