We’re wired to hunt for complete answers. From the neat tick boxes of school exams to the glossy final slide of a business plan, the ideal is a polished solution with no dangling threads. But out in the thick of hard problems—rethinking a city’s bus network, untangling a legacy codebase, or just trying to map a week’s worth of dinners—that all-or-nothing instinct often leaves us stuck. Declan Mercier here. After watching how breakthroughs actually unfold over the years, I’ve landed on a quiet conviction: the engine of progress isn’t the perfect solution. It’s the partial solution. Not settling. Not lowering the bar. It’s a deliberate strategy of building incomplete but working stepping stones that let you feel your way toward a whole you can’t yet picture.
A partial solution is a deliberately unfinished answer—one that tackles a slice of the problem, lowers your uncertainty, or gives you a platform for the next move. It’s not a draft you stash in a drawer. It’s a probe, a prototype, a hunch turned into something you can bump against reality. Its value doesn’t live in being complete. It lives in the reaction it triggers: the fresh questions it kicks up, the constraints it finally makes visible, the oddball connections it lights up.
The Trap of the Monolithic Answer
Why do we keep reaching for the big, unified answer? Part of it is cultural. We celebrate the lone genius with the grand theory—not the team that ground through seventeen clunky mockups. There’s an aesthetic pull to completeness, a tidy package that explains everything. But that hunger for closure turns into a cognitive trap fast. When the problem is fuzzy, with requirements that shift and dependencies nobody spotted, waiting for the full picture guarantees paralysis. You wind up in analysis loops, hoarding more data, hoping the fog will burn off. It rarely does.
I saw this play out up close while watching a city council wrestle with a new public park. They wanted a master plan that would nail drainage, playground safety, native plantings, and event spaces in one grand vision. Years slid by in surveys and consultant reviews. Meanwhile, a neighboring district just fenced off an empty lot, dumped some wood chips, and bolted in a single swing set. That partial solution—rough as a cob—gave kids a place to play right then. It also coughed up real usage data: where people came in, where they sat, what broke first. That data became the bedrock for their later, more graceful design. The half-baked park was more useful than the flawless plan on paper.
Core Principles of the Partial-Solution Mindset
Shifting into this way of thinking takes a few deliberate mental habits. It’s not about a rigid playbook. It’s more about taking on a different relationship with things being incomplete.
1. Slice by Function, Not by Component
A common stumble is to break a problem into pieces that are individually useless. If you’re building a bike, you don’t start with the entire frame, then all the wheels, then the gears. You build a minimal rolling chassis: a frame, two wheels, a seat. It won’t win races, but you can coast down a hill and learn about balance and brake placement. That’s a functional slice—a vertical cut through the system that delivers a tiny sliver of end-to-end value. It forces integration snags into the open early. In any project, ask yourself: What’s the smallest slice that lets a real person do one useful thing? Ship that. The feedback you get will cut sharper than any theoretical review.
2. Invert the Question: What Can We Ignore?
Most planning kicks off with “What do we need?” A partial-solution frame starts with “What can we safely leave out for now?” This isn’t laziness. It’s constraint management. Every element you strip away sharpens your focus on what stays. When I’m writing a dense report, I often draft the conclusion first—a brutally short, one-paragraph version that states the core argument with zero supporting evidence. That partial solution makes me nail the spine. If the spine doesn’t convince, no amount of polish will save it. By explicitly listing what you’re ignoring, you also sketch a roadmap of future work grounded in real gaps, not imagined ones.
3. Treat Solutions as Questions
A finished answer says, “This is how it is.” A partial solution says, “What if we tried this?” The posture is entirely different. It invites pushback and tinkering. In a team, framing a prototype as a question—“What would happen if we removed the login step entirely?”—shifts the tone from defensive to curious. This is especially potent in fields where uncertainty sits thick. A quick, scrappy market test with a hand-built product can surface more truth than a year of market research. The partial solution is a tool for pulling information out of reality, not imposing a design onto it.
The Hidden Value: Exposing Real Constraints
The most underrated bit of partial solutions is how they turn invisible constraints solid. On paper, a problem can seem to have a clean, elegant answer. But try to implement even a sliver of it, and the real world shoves back in ways you never imagined. I once watched a software team set out to build an algorithm for optimizing delivery routes. In theory, it was a straightforward routing problem. They built a crude version that handled just three trucks in a single neighborhood—a partial solution so limited it was almost embarrassing. Within a week, they discovered the real bottleneck wasn’t route distance. It was driver familiarity with specific loading docks. The algorithm had to swallow “dock preference,” a variable nobody mentioned in months of planning. The partial solution didn’t just test the math. It surfaced a hidden human factor that ended up defining the project’s success.
This runs well beyond engineering. In personal finance, instead of constructing a grand budget, try tracking just your food spending for two weeks. That single, partial view often reveals patterns—the 4 p.m. snack, the subscription meal kit you never touch—that a full spreadsheet would bury. It’s a focused lens, bringing one corner into sharp relief so the next step becomes obvious.
Navigating the Discomfort of the Unfinished
This approach isn’t cozy. It asks for a tolerance of ambiguity and a readiness to show work that feels raw. A nagging voice whispers, “If it’s not complete, it’s not valid.” To push back on that, I’ve found it handy to slap an explicit label on any partial solution: a one-line statement of its scope and its known limits. This turns it from a flawed final product into a precise experimental tool. Something like: “This model predicts customer churn using only last month’s data; it doesn’t account for seasonal trends.” That framing guards you against over-reading the results and tells others you know exactly where the edges are.
Another trick is to define the next step before you let the current one loose. The moment you put a partial solution into the world, feedback floods in. Most of it will be noise—aesthetic gripes, scope creep dressed up as critique, praise that misses the point. If you’ve already decided what you need to learn next, you can filter that feedback without mercy. You’re not hunting for approval. You’re hunting for a specific scrap of information to build the next stepping stone.
From Partial to Whole: The Emergent Path
Let’s be clear: this isn’t an argument against finishing things. The goal isn’t to live forever in a swamp of half-done work. The goal is to reach a sturdier, reality-tested completeness than you could have dreamed up from the start. The sequence might go like this: a series of small, functional slices that gradually link up; a set of ignored elements that get tackled one by one as their importance proves itself; and a final integration phase where the lessons from each partial step get synthesized. The result is rarely the elegant vision you started with, but it’s almost always more useful, more resilient, and better tuned to the actual problem.
Think about how a long-form essay evolves. My own process is a cascade of partial solutions. It starts with a single, provocative sentence—a thesis that’s almost certainly wrong in its simplicity. That’s the first partial solution. Then I write a list of objections to that sentence. That’s the second. I freewrite a story that illustrates one of those objections. That’s the third. Only after several of these fragments are lying around do I start to glimpse the real structure. The final essay isn’t a linear stretch of that first sentence. It’s an emergent property of the collisions between those early, deliberately incomplete attempts. The first sentence wasn’t a false start. It was a scaffold I needed.
This framework shifts the yardstick of productivity from completion to learning velocity. A day spent producing a polished, 40-page document that nobody reads is less productive than a day spent crafting a one-page diagram that sparks a hard, course-correcting conversation. A partial solution is a unit of learning, not a unit of output. Adopting that metric changes everything—how you shape your day, how you collaborate, how you mark progress when you’re knee-deep in messy, real-world problems.
Frequently Asked Questions
How does this differ from simple prototyping or minimum viable products?
It’s a close cousin but wider in intent. Prototyping and MVPs usually live in product development. This framework applies to any complex cognitive or strategic task—writing a policy memo, planning a garden, picking up a new language. The emphasis sits on the mindset of actively using incompleteness as an investigative tool, not just a step in a build-measure-learn loop. It’s the deliberate practice of making your ignorance visible so you can chip away at it methodically.
What if stakeholders or clients only expect fully polished work?
That’s a real constraint. The trick is to reframe the partial solution not as a draft, but as an “interim decision tool” or a “focused experiment.” You’re not showing them an unfinished product. You’re presenting a specific, bounded result of a test designed to answer their most pressing risk. You say, “Before we sink resources into the full initiative, we ran a two-day trial on this one variable. Here’s what we learned.” You’re selling the value of reduced uncertainty, not the artifact itself. Over time, you can bring them along by showing how these small probes head off larger, costlier mistakes.
How do you prevent a culture of partial solutions from turning into a graveyard of half-done, abandoned work?
This is the discipline that makes it hold together. Every partial solution needs a clear owner and a defined “expiry” or follow-up trigger. It’s not a fire-and-forget artifact. When you create one, you also create a hypothesis: “We believe this slice will show X.” Schedule a review for when the data lands. If the hypothesis holds, you move to the next slice. If it falls apart, you explicitly kill that line of inquiry and document why. The aim isn’t to pile up partial solutions. It’s to use them as transient probes that get systematically resolved into knowledge—even if that knowledge is “this path is a dead end.”
Can you apply this to personal creative projects where there’s no external deadline?
Absolutely. In fact, it’s often most potent there, because the risk of perfectionism is sky-high. For a novel, instead of outlining all 30 chapters, write a single, emotionally charged scene that you know belongs somewhere in the middle. That scene—a partial solution—becomes a touchstone. It teaches you the tone, the voice, the rules of the world you’re building. From that one solid point, you can write forward and backward. The block often breaks not by planning more, but by producing a small, undeniable piece of the whole.