Why More Planning Won't Get You Unstuck

Some decisions aren’t really about what to add. They’re about what you can’t change.

I keep seeing the same thing with clients. They’ve done all the right things - weeks of planning, long requirement docs, stakeholder sign-off. Somehow they still end up building the wrong thing, or the right thing too late.

It’s not incompetence. The planning just keeps solving the wrong problem. More analysis, better models, longer roadmaps. As if the answer is always in the next round of information. It usually isn’t.

Some of the better decisions I’ve made came out of constraints, not options. A hard deadline forced a simpler approach. A tight budget cut out everything I was unsure about anyway. A small team meant we couldn’t afford to work on the wrong thing. None of those were comfortable situations. But they were clarifying.

The Creative Force

“We cannot solve our problems with the same kind of thinking we used when we created them.”

— Albert Einstein

I don’t think constraints are just limitations, often they are what actually gets work done. Sometimes there is an unclear constraint that is driving decisions, other times the constraint is clear to everyone involved but no one will name it outright.

There is something genuinely practical about working under pressure, even if it doesn’t feel that way. When you can’t do everything, you end up doing the right thing, not because you became more strategic, but because you had no choice.

I see this in client engagements all the time. Someone comes in with a big vision, real budget, ambitious timelines. But the project that actually ships is almost always the one where, at some point, someone said: here’s what we have, here’s what we can’t move, let’s figure out what’s possible within that. That conversation is usually where the real work starts.

The constraint forces the question of what actually matters. And that’s usually harder to answer than people expect. I took part in projects where the problem wasn’t a lack of options. It was having too many. The approach I’m describing here is what helped me get unstuck, by forcing me to look at what was actually fixed before anything else.

Asking Questions

This isn’t a formal framework so much as a set of questions I’ve found useful, in roughly this order:

• What is actually fixed? Not what feels uncomfortable to change, but what genuinely doesn’t move. Budget, timeline, a hard technical constraint. Be specific.
• What can I actually control? Not what you’d like to control. What you have real influence over right now.
• What’s the smallest path that gets this done? Not the best path. The one with the fewest new variables.
• What happens if I wait? Sometimes constraints shift. Sometimes waiting a week changes the whole picture. Worth asking before committing.

The important thing is to answer these before you start building the plan, not after you’ve already committed to an approach. It’s easy to identify constraints that support a direction you’ve already chosen. That’s not the same thing.

Most people skip this because naming a constraint feels like giving up. Accepting that something can’t change feels like admitting defeat. I’ve come to think it’s the opposite. It’s just working with reality rather than spending energy trying to renegotiate it.

Removing Requirements

“If you are not occasionally adding things back in, you are not deleting enough.”

— Elon Musk

There’s another side to this that I think gets underplayed. It’s not just about accepting what you can’t do. It’s about actively cutting what isn’t necessary.

Most teams I’ve worked with have the opposite instinct. When something feels uncertain, add more. More features, more processes, more tooling. Every addition feels like reducing risk. But it accumulates, and accumulated complexity is what actually slows most projects down, not lack of resources.

The instinct worth building is toward deletion. Not cutting randomly, but deliberately. If something doesn’t clearly serve the core goal, it’s probably worth removing. And if you’re genuinely unsure, cutting and adding back later is usually safer than keeping it and losing clarity. The work of figuring out what actually needs to exist is often harder than building it.

The same instinct shows up at a different scale in how Elon Musk approaches manufacturing, walking thorugh it in the following video. The second rule, delete the process or step, outlines that you shouldn’t optimize what shouldn’t be there in the first place. Musk walks through it directly, referring to an engineering process rather than a product decision.

Most of the slowdowns I’ve seen come from this. Not from not having enough, but from carrying too much. Features that seemed small individually. Processes added to manage other processes. Each one defensible on its own, but together they create a kind of drag that’s hard to reverse once it sets in.

Something I ask more often now: what could we remove and still ship what matters? The answer is usually more than people expect.

What This Looks Like In Practice

A client came to me wanting to fully redesign their e-commerce platform. Two developers, tight budget, even tighter deadline. Their original plan had custom checkout, a loyalty program, blog integration, multi-currency support. Realistically? months of work including business operations involved.

I asked: what’s the actual minimum you need to start selling? After some back and forth: product catalog, cart, checkout, payments. That’s it.

We cut everything else. Shipped the core in six weeks. The rest came in later, once they had revenue and a clearer picture of what customers actually wanted. The things we cut would’ve taken months and probably would’ve been the wrong version anyway.

A founder I know was in a similar kind of stuck. Choosing between two markets, both looked good, endless pros/cons lists. He’d burned two months analyzing and wasn’t any closer.

I asked what his actual constraint was.

“Three months of runway.”

“Which market can you get real signal on for under $5k in a month?”

That was the question that changed it. Instead of trying to figure out which market was better in the abstract, he had a concrete test he could run now. He picked one, ran it, got data. The decision that had felt impossible turned out to just need a different frame.

Constraints don’t make decisions for you. But they shape decisions a lot clearer.

Caveats

Worth being honest about where this falls apart.

The whole thing assumes you’re working with accurate constraints. And sometimes you aren’t. Budget gets described as fixed when it’s actually negotiable. Timelines get presented as hard when there’s room. That’s not always intentional beacuse sometimes people genuinely don’t know what’s movable until they push on it. But working from false constraints produces confused output, and the inconsistency tends to be more visible to everyone else than the person doing it realizes.

The other thing to watch for is self-imposed constraints. “We’ve always done it this way.” That’s not a constraint. It’s a habit that’s been mistaken for one. The framework only works if you can tell the difference.

Getting Unstuck

The pattern I see most often isn’t people ignoring constraints. It’s people building more elaborate analysis to avoid confronting them.

More research, another workshop, a better spreadsheet. Some of it is useful. But a fair amount of it is just a way to stay in planning mode for longer periods, because planning feels safer than deciding. Sometimes people get into a game of who will be the one that takes responsibility so others don’t have to.

The actual move is usually pretty unglamorous. Figure out what’s fixed. Accept it. Ask what the best next step is given what is actually real, and remove what doens’t need to be there.

Most of the time, that’s enough to get moving.