The first time I saw a jigsaw puzzle being solved from the middle outward, I felt a quiet disorientation. The solver ignored the edges entirely. No frame, no corners, just a dense cluster of colour taking shape in the centre of the table. It looked inefficient. It looked chaotic. But she finished faster than anyone else in the room.

I think about that puzzle often now, because it exposed something I had always done without questioning: I assumed you had to build the frame first. That you had to define the boundaries before you could make sense of the interior. But some problems don’t yield to boundaries. Some problems only reveal their structure once you start assembling the middle and let the edges emerge later.

This is an essay about thinking in partial solutions. Not half-finished work, not lazy shortcuts, but a deliberate cognitive stance that treats incomplete answers as legitimate tools rather than failures to be hidden. It’s a framework I’ve been piecing together across years of watching people solve hard problems—engineers debugging distributed systems, physicians narrowing differential diagnoses, writers wrestling with structure, even my neighbour rebuilding a motorcycle engine on his driveway over six months.

The common thread is this: they all got comfortable with intermediate states that looked wrong but carried useful information.

The Frame-First Fallacy

Most of us are taught to solve problems by starting with the big picture. Define the scope. Establish the constraints. Draw the box, then fill it in. This approach has obvious merits. It prevents drift. It gives you criteria for completion. It makes progress measurable.

But it also has a quiet cost. When you insist on framing a problem before you understand its texture, you often frame it wrongly. And once the frame is set, it becomes hard to see what doesn’t fit inside it.

I once watched a team spend three weeks defining the requirements for a software feature. They wrote documents. They drew diagrams. When they finally started building something small and concrete, they discovered within two days that their frame excluded the most important behaviour. The boundary they had drawn so carefully was in the wrong place. The time spent framing wasn’t wasted exactly—it generated clarity about what didn’t matter—but it delayed the moment when reality could push back.

Partial-solution thinking inverts this sequence. You build a small, incomplete thing first. Not a prototype in the polished sense, but a fragment. A piece of the middle. You work on it without knowing exactly how it connects to the whole. You watch what it does. Then you build another fragment nearby. Connections start to appear. The frame emerges from the fragments, not the other way around.

What Partial Solutions Actually Look Like

The phrase “partial solution” can sound like an excuse for unfinished work. But in practice, a partial solution is something more specific. It’s a deliberately bounded attempt that answers one narrow question while remaining consciously incomplete on other dimensions.

Consider how a physician approaches a patient with a confusing cluster of symptoms. The full solution would be a complete diagnosis with a treatment plan. But that’s not where they start. They run a single test. Not because they expect that test to solve the case, but because its result—positive or negative—will eliminate large branches of possibility. The test is a partial solution to the diagnostic problem. It doesn’t heal the patient. It doesn’t even name the disease. It just makes the problem space smaller.

This is different from guesswork. A guess tries to jump to the answer. A partial solution tries to make the problem more tractable. The distinction matters because partial solutions compound. Each one narrows the space you have to search. Each one reveals a little more structure.

I’ve started thinking of this as probe-based reasoning. You send out a small, low-cost probe into the problem space. The probe doesn’t need to be correct. It needs to be informative. It needs to return a signal that tells you where to probe next.

Why We Resist Incompleteness

If partial solutions are so useful, why don’t we default to them? The resistance runs deep.

One reason is social. Showing someone an incomplete piece of work feels exposing. It invites judgement on something you already know is flawed. Most workplaces reward finished outputs, not intermediate fragments. The person who presents a polished document gets more credit than the person who shares a messy halfway attempt—even if the halfway attempt was more generative.

Another reason is cognitive. The human mind craves closure. The Zeigarnik effect, studied extensively in psychology, shows that unfinished tasks occupy mental space until they’re resolved. Holding multiple partial solutions in mind simultaneously is genuinely taxing. It feels uncomfortable. The temptation to resolve the ambiguity prematurely is strong.

A third reason is that most education systems train us to value answers over questions, solutions over explorations. From early schooling, we learn that showing your work means showing the clean path to the right answer. The wrong turns, the dead ends, the provisional ideas—these get erased from the final submission. We learn to hide the parts of the process that look messy.

But messy is where the learning happens.

A Working Framework

Over time, I’ve distilled the practice of partial-solution thinking into a loose framework. It’s not a rigid method—more a set of habits that make it easier to stay in the incomplete space long enough for insight to arrive.

1. Name the Fragment

When you start working on a piece of a problem without knowing how it fits the whole, give it a name. Not a final name—a provisional label that says what question this fragment is trying to answer. “Testing whether the delay is in the database layer” is better than “investigating performance.” The name keeps the fragment bounded. It reminds you what this piece is for and, just as importantly, what it isn’t for.

I learned this from watching a researcher I worked with years ago. She kept a whiteboard divided into columns, each labelled with a specific sub-question. Under each column, she’d tape index cards with findings, hypotheses, and dead ends. None of the columns contained a complete answer. But together, they formed a map of what she knew and what she still needed to learn. The structure made the incompleteness visible and manageable.

2. Lower the Cost of Being Wrong

Partial solutions only work if you can afford to discard them. If every attempt carries high stakes—reputational, financial, emotional—you’ll naturally avoid producing anything that might be wrong. So you need to engineer environments where wrong fragments are cheap.

This might mean sharing ideas verbally before writing them down formally. It might mean sketching on paper instead of building polished slides. It might mean setting explicit expectations with collaborators: “This is a probe, not a proposal.” The phrase itself acts as a permission slip. It signals that you’re exploring, not committing.

3. Watch for Emergent Structure

After you’ve generated several fragments, step back and look for patterns. Do two partial solutions point toward the same gap? Does a fragment from one area unexpectedly resolve a question in another? This is the stage where the frame starts to build itself.

There’s a particular pleasure in this moment. It feels like watching a photograph develop in a darkroom—shapes emerging from chemical fog, relationships becoming visible that you couldn’t have predicted. The key is not to rush it. The structure that emerges slowly is usually more trustworthy than the structure you impose quickly.

4. Know When to Commit

Partial-solution thinking has a shadow side: it can become a way to avoid finishing. At some point, you have to close the loop. You have to say, “I know enough now to act.” The skill is in recognising that moment, which rarely announces itself clearly.

One heuristic I use: when new fragments start confirming what you already suspect rather than surprising you, you’re probably ready to commit. The probes are returning diminishing information. The problem space has been narrowed enough that further exploration costs more than it’s worth.

The Deeper Shift

Learning to think in partial solutions has changed more than my approach to problems. It has changed my relationship with uncertainty.

I used to experience uncertainty as a problem to be solved—an uncomfortable gap between not-knowing and knowing that needed to be closed as quickly as possible. Now I experience it more as a terrain to be explored. The gap contains information. The discomfort is data. It tells you where the problem is still opaque, where your mental models are still too coarse.

This doesn’t mean wallowing in indecision. It means treating the period of not-knowing as productive rather than pathological. Some problems genuinely need to be sat with before they yield. The person assembling the puzzle from the centre wasn’t being chaotic; she was letting the image tell her where the edges belonged.

There’s a phrase I’ve come back to many times, from the mathematician and philosopher Alfred North Whitehead: “The art of progress is to preserve order amid change and to preserve change amid order.” Partial solutions are a way of preserving change amid order. They let you act before you understand fully. They let you build before you have a blueprint. They keep the process alive while the shape of the answer is still forming.

Frequently Asked Questions

How is this different from agile development or iterative design?

There’s overlap, but partial-solution thinking is a cognitive stance rather than a project methodology. Agile and iterative approaches apply to teams and timelines. This framework applies to how an individual holds a problem in their mind—whether they’re writing alone, debugging a system, or trying to understand a complex situation. You can use partial-solution thinking even when no formal process requires it.

Won’t this approach waste time on fragments that lead nowhere?

Some fragments will lead nowhere. That’s built into the approach. The question is whether the cost of those dead ends is higher than the cost of framing the problem incorrectly and having to redo everything later. In my experience, dead-end fragments are usually cheap—a few hours of thinking or tinkering—while a wrong frame can cost weeks or months. The math often favours exploring first.

How do you explain partial-solution thinking to colleagues who expect finished deliverables?

This is the social challenge. One practical approach is to label partial work explicitly and pair it with a clear question. Instead of presenting a half-finished document as if it were complete, say: “I’ve worked on one piece to test an assumption. Here’s what I found. Does this change how we think about the rest?” When you frame the fragment as an information-gathering step rather than a failed deliverable, it becomes easier for others to engage with it on those terms.

Is there a risk of never feeling ready to finish?

Yes. The framework requires a counterbalancing instinct for closure. Not every problem benefits from extended exploration. The skill is in distinguishing between problems that are genuinely emergent—where the structure isn’t visible yet—and problems where you’re simply avoiding the discomfort of committing. If you notice you’ve been probing the same territory for a while without new insights, it’s probably time to act on what you already know.

In the end, partial-solution thinking isn’t really about solving problems faster. It’s about solving them with more fidelity to what’s actually there. It’s about letting the problem teach you its shape instead of forcing it into a shape you brought with you. That takes patience. It takes tolerance for mess. But the alternative—building careful frames around problems you don’t yet understand—is often just a more elaborate way of being wrong.