The Perfect Quest

Act 1: The Knight Who Was Always Getting Ready

Don Quixote was exceptional at preparing for adventures. He restored his grandfather’s armor, piece by rusted piece. He named his horse—a scrawny nag rechristened “Rocinante,” because a great knight deserves a great-sounding steed. He designated a peasant woman as the noble lady Dulcinea, so he’d have someone to dedicate his conquests to. He rehearsed speeches, memorized the code of chivalry, and studied the protocols of knightly combat.

Weeks of this. Maybe months. All before a single step on the road.

Sancho Panza, meanwhile, stuffed some cheese and bread into a saddlebag, threw a blanket over his donkey, and said something to the effect of: “Alright, let’s see what happens.”

The contrast isn’t comedy. It’s a diagnosis. Quixote believed that sufficient preparation would make the quest go right. Sancho understood that you figure out the quest by going on it.

The planning trap in product management

This shows up in every product org I’ve worked in, wearing slightly different costumes each time.

The Perfect Spec. The PRD isn’t ready yet. It needs one more section on edge cases, one more competitive analysis, one more pass from legal. Three weeks later, the PRD is a 40-page artifact that engineering will blow past in the first sprint—because the real questions only surface when you start building.

The Research Phase. “We need more data before we decide.” Sometimes this is true, and the research genuinely changes the outcome. But more often, the team has enough signal to move and is using “more research” as a socially acceptable way to avoid making a bet.

The MVP Mirage. Someone says “let’s just add one more feature to the MVP”—and then someone else says it, and then someone else. Repeat until the product is neither minimum nor viable, just a bloated prototype that took four months instead of four weeks.

The Roadmap Ritual. Quarterly planning that becomes monthly planning that becomes weekly planning. Every iteration produces a more refined roadmap and zero shipped product. The map gets more detailed while the territory remains unexplored.

These all share a root cause: the belief that more preparation reduces risk. Past a certain point, it doesn’t. It just delays the moment when you find out what actually works.

Why we do this to ourselves

The uncomfortable truth is that over-planning often isn’t about rigor. It’s about fear. Starting means committing. Committing means you might be wrong. Staying in planning mode feels productive while keeping every option open.

Quixote could be the greatest knight in the world as long as he never actually fought anyone. The preparation was the safe part.

Sancho wasn’t braver—he just didn’t confuse motion with progress, or planning with doing. His preparation was ruthlessly practical: Do we have food? Do we have transport? Then we have enough. Let’s go learn the rest on the road.

The “ready” test

Before any project stalls in planning, try making the implicit explicit. Ask the team to write down, specifically, what conditions would make them ready to start. Not “when the spec is done”—that’s circular. Something concrete:

• We need sign-off from engineering on the data model.
• We need confirmation that the API partner can support our volume.
• We need a decision on pricing tier.

If the team can produce that list in five minutes, they probably have legitimate blockers. Work through them. But if the conversation devolves into vague concerns about “alignment” or “completeness,” you’re looking at preparation as procrastination. Name it and move.

Act 2: The Inn That Isn’t a Castle

So the quest finally starts. And throughout the novel, Quixote and Sancho arrive at roadside inns—modest, dirty, overcrowded places with bad food and worse wine.

Quixote, predictably, sees castles. He perceives drawbridges where there are broken fences, towers where there are chimneys, and noble lords where there are innkeepers trying to get through the dinner rush. He demands the treatment befitting a knight-errant and grows confused, then angry, when reality doesn’t cooperate.

Sancho sees the inn. It’s not great. The bed is lumpy, the stew is suspicious, and the other guests are loud. But it’s shelter, and there’s food, and the donkeys can rest. So he negotiates a room, finds the least terrible meal, secures the animals, and makes sure everyone is ready for tomorrow.

This is the second half of the shipping problem. The first act is about starting before you’re ready. The second is about working with what you actually have once you’ve started—rather than refusing to engage because conditions aren’t ideal.

Waiting for the castle

This version of the trap looks different from over-planning, but it comes from the same place: a conviction that the right conditions are a prerequisite for good work.

• “We’ll start when we hire that senior engineer.” The hire takes three months. Onboarding takes two more. Five months of stalled work for a capability that the current team could have approximated.
• “We need a proper analytics pipeline before we make this decision.” Meanwhile, ten user interviews this week would surface 80% of the same insights.
• “We need to migrate to the new platform first.” The migration becomes its own multi-quarter project. The actual product sits in a queue behind the infrastructure that was supposed to enable it.
• “Now isn’t a great time—too much in flight.” There will never be a great time. Every quarter has too much in flight. The perfect moment is a castle that doesn’t exist.

The pattern is always the same: real constraints get reframed as absolute blockers, and the team waits for conditions to improve instead of building within the conditions they have.

Constraints as creative force

Sancho’s genius wasn’t optimism—he didn’t pretend the inn was wonderful. His genius was treating constraints as the shape of the solution rather than obstacles to it.

Limited food at the inn? He made a simpler meal, which meant less time cooking and more time resting. Shared room with strangers? He slept in shifts and kept watch on their belongings. No stable? He tied the donkeys under an overhang and improvised.

Every constraint narrowed the options, which made the decision faster, which meant he spent less energy deliberating and more energy executing. The constraint was doing half the work for him.

This translates directly. A small team can’t build a sprawling feature—so it builds a focused one, which is usually better anyway. No budget for formal research? Five hallway conversations with users and a Google Form will teach you something. Legacy system that can’t be replaced? Build a thin layer on top of it. You’ll ship in weeks instead of quarters, and you’ll learn whether the idea is worth a bigger investment before you make one.

The teams that ship aren’t the teams with the most resources. They’re the teams that treat their constraints as boundaries of the playing field rather than reasons not to play.

Ship today, upgrade tomorrow

Sancho didn’t refuse to sleep at the inn while waiting for a castle. He used what was available tonight and looked for something better tomorrow. And here’s the part that’s easy to miss: every night at an inn taught him what actually mattered. A safe place for the animals. A dry bed. Food that wouldn’t make them sick. If he ever got a castle, he’d know exactly what to build in it.

Your scrappy v1 teaches you what the full product should be. Not in theory—in practice, through the reactions of real users touching real software. The team that ships an imperfect version and iterates will always understand their problem space better than the team that plans the perfect version in a vacuum.

This isn’t an argument against quality. It’s an argument about sequence. Ship, learn, then invest in quality where it matters most. The alternative—investing in quality everywhere before you know what matters—is how you build a beautiful product that solves the wrong problem.

Recognizing Both Traps

These two failure modes—planning forever and waiting for ideal conditions—often show up together, feeding each other. The team that over-plans in Act 1 is the same team that, once finally moving, refuses to ship until conditions are perfect in Act 2. The underlying belief is identical: if we just get things right enough before we act, we can avoid failure.

You can’t. Failure is information. The goal is to fail cheaply, learn fast, and redirect.

Watch for these signals:

• Scope that only grows. Every review adds requirements; none removes them.
• Sentences that start with “We’ll start when…” or “We just need one more…”
• Spending more energy on tooling, process, or infrastructure than on the actual product.
• A team that can describe the ideal state in vivid detail but hasn’t shipped anything in weeks.
• Recurring debates about the same decision—a sign that the team needs data it can only get by shipping.

If more than two of these are present, you’re probably stuck in one of the traps—or cycling between them.

The Monday Morning Checklist

Instead of more questions to discuss, here’s a checklist. Print it. Tape it to your monitor. Run through it before your next planning session.

• We have written down, specifically, what “ready” means for this project. Not “when the spec is done.” Concrete conditions with dates.
• Our MVP is defined by what we’re cutting, not what we’re including. If everything made the cut, it’s not an MVP.
• We can name the constraints we’re working within—team size, timeline, tech debt, budget—and we’ve designed the solution around them, not despite them.
• We have identified one thing we could ship this week with what we currently have. Not next month. This week.
• We’ve distinguished between blockers and discomforts. A blocker is “the API doesn’t exist yet.” A discomfort is “the API isn’t as clean as we’d like.”
• We know what we’ll learn from shipping that we can’t learn from planning. If the answer is “nothing,” more planning might be warranted. Usually, the answer is “a lot.”

The Squire’s Advantage

Don Quixote prepared for the perfect quest and then demanded castles along the way. He got knocked off his horse a lot.

Sancho packed some cheese, rode a donkey, and slept at inns. He made it to the end of the novel. He solved problems with whatever was at hand. And when he was eventually given a real governorship—actual responsibility over an actual place—he governed well, because he’d spent years learning what mattered through experience rather than theory.

Your product lives in a world of limited budgets, small teams, legacy systems, and imperfect data. The quest will never begin under ideal conditions, and the inns along the way will never be castles. The PMs who thrive are the ones who pack the cheese, get on the road, and make the inn work.

Stop preparing. Start shipping. Work with what you have. Upgrade when you’ve earned the knowledge to do it well.

Put this into practice

Stop preparing, start shipping. The 1-Page PRD forces clarity and gets you moving. The Launch Checklist helps you define “good enough” and get out the door.

Get the Templates →