Planning feels good. You're mapping out the work. Thinking through dependencies. Anticipating edge cases. Being thorough and strategic.
You're doing something. You're making progress.
Except... you're not actually building anything. You're planning to build. And there's a big difference.
When Planning Becomes Stalling
Here's the thing about planning: it's comfortable. The risks are hypothetical. The problems are theoretical. Nothing's on the line yet.
Building is scary. You make real decisions. You face real constraints. You ship something that people can judge.
So when we're anxious about building, we retreat into planning. We tell ourselves we need more clarity, more detail, more certainty before we start.
But perfect plans don't exist. And waiting for perfect clarity means never starting.
The Planning Theater
You know you're over planning when:
- You've spent more time planning than it would take to build
- The plan has more detail than you could possibly need
- You keep finding "one more thing" to think through before starting
- The team feels ready to build, but leadership wants more planning
- You're planning how to plan (meta meetings about process)
At that point, planning isn't reducing risk. It's just deferring the discomfort of actually shipping.
The Paradox
Here's the uncomfortable truth: you learn more from building than from planning.
No matter how thoroughly you plan, reality will surprise you. Requirements will shift. Technical constraints will emerge. Users will want something different than you expected.
The plan doesn't survive contact with reality. So making the plan incredibly detailed doesn't actually help. It just delays the moment when you discover what you got wrong.
When Planning Actually Helps
To be clear: planning isn't inherently bad. It's useful when:
You're coordinating across teams: If five teams need to integrate, some upfront alignment helps.
There are expensive one way doors: If the decision is hard to reverse (like database schema migrations), think it through first.
You're in a regulated environment: Sometimes you need documentation and approvals before you can act.
You're clarifying the goal: If the team isn't aligned on what you're building or why, that's worth resolving upfront.
But notice: these are specific, narrow cases. Most day to day work doesn't need extensive planning.
The Lean Approach
The best planning is just enough to start, and no more.
Sketch the outline: What are we building? Why? What does success look like?
Identify big unknowns: Are there technical risks or dependencies we should validate early?
Start building: Make the plan more detailed as you learn, not before.
This is the "thin slice" approach. Build the smallest useful version, learn from it, then decide what's next.
You plan iteratively, not exhaustively.
The Bias Toward Action
Great teams have a bias toward action. When in doubt, they start building.
Not recklessly. Not without thought. But they recognize that doing reveals information that thinking cannot.
You think the API will work a certain way? Try it and see.
You think users want feature X? Ship a prototype and validate.
You think the architecture should be Y? Build the first version and refactor if needed.
Ship, learn, adjust. That's faster than plan, refine, perfect, ship.
The Courage Test
Here's the real question: are you planning because it helps, or because you're avoiding the risk of shipping?
If the plan genuinely reduces costly mistakes, great. But if you're just gathering more requirements, refining the design one more time, adding more detail to the spec, that's delay.
At some point, you have to build. The plan will never be perfect. You'll never have complete information. Start anyway.
Because the only thing worse than building the wrong thing is spending six months planning to build the wrong thing.
Plan enough to be thoughtful. Then ship. Adjust as you learn. That's how you win.