The simple version
An unfinished document that you actively think through is doing more intellectual work than a polished one you ship and forget. Completion is not always the point.
What we think documents are for
Most people treat documentation like a product. You write it, you finish it, you publish it. Value delivered. This mental model comes from how we think about shipping software, where a feature that isn’t deployed is a feature that doesn’t exist. Applied to writing, it creates a straightforward anxiety: the draft sitting in your notes folder is a failure, a thing you started and didn’t finish.
But that model is wrong about what documents actually do.
A document is not just a container for information that gets emptied when someone reads it. It’s also a thinking tool. The act of writing something down forces a kind of precision that thinking-in-your-head doesn’t require. When you write “we should improve the onboarding flow,” you immediately have to confront what you mean by “improve,” which part of the flow, for which users, and by what measure. The unfinished draft is where that confrontation happens.
The draft as a working memory extension
There’s a useful concept in cognitive science called “extended cognition” (the idea that thinking isn’t just what happens inside your skull, it includes the tools and representations you use to think with). A whiteboard mid-session, a half-completed diagram, a document with bullet points and crossed-out paragraphs: these are all active parts of the thinking process, not just records of thoughts you already had.
When you keep a draft document open for days or weeks, returning to it, adding to it, revising a section when you learn something new, you’re using it as a kind of external working memory. The document holds context you can’t hold in your head. It lets you think in longer time scales than a single session. It captures the shape of a problem before you understand the solution.
The moment you “finish” that document and ship it, you often close this loop prematurely. You’ve converted a live thinking tool into a static artifact.
Why finishing can be the wrong move
Consider how senior engineers actually work through hard problems. The good ones don’t sit down, think a problem through, and then write a design doc. They write the doc as part of thinking the problem through. The doc has contradictions in it. It has a section that says “TODO: figure out what happens when the cache is cold.” It has three different approaches outlined, none chosen yet.
If you force that person to “finish” the doc before they’ve finished thinking, one of two things happens. Either they pretend to have answers they don’t have (which produces confident-sounding documents full of hidden assumptions), or they stall indefinitely because finishing feels like committing.
This is the trap that productivity systems often create. They treat every open item as a debt. The unfinished document appears on your list, nags at you, gets a due date. The pressure to close it out is real. But “closing it out” by writing a clean conclusion you don’t actually believe yet is worse than leaving it open.
The unfinished state is sometimes the correct state.
When to ship, when to keep the loop open
This is not an argument for never finishing anything. Some documents genuinely need to ship. A runbook that only exists as a draft helps no one when the service goes down at 2am. A product spec that never gets shared means the engineers are guessing. There’s a real cost to hoarding your work in perpetual draft state, and that cost is paid by the people who need the information.
The distinction worth making is between two types of documents.
The first type is a knowledge transfer artifact: something whose value is in moving information from your head to someone else’s. API documentation, a postmortem, a decision log, a tutorial. These have a clear audience and a clear moment of utility. For these, shipping matters. An unfinished postmortem is a missed organizational learning opportunity.
The second type is a thinking scaffold: something whose primary value is in organizing and extending your own cognition while you work through a problem. Strategy drafts, exploratory technical spikes written as prose, half-formed product ideas, anything that starts with “I keep going back and forth on this.” For these, shipping is often beside the point, and the impulse to clean them up can actually destroy their value.
The problem is that most productivity systems treat all documents as the first type. Everything gets a completion state. Everything is either done or not done.
The cost of premature closure
There’s a reason experienced people in most knowledge-work fields keep private notebooks that never get published. The notebook isn’t a failure to produce; it’s a different category of tool. Physicists keep lab notebooks that no one else reads. Architects keep sketch pads full of ideas that never become buildings. Writers keep journals they never intend to publish.
The same principle applies to your Notion workspace, your Obsidian vault, your Google Drive graveyard of unfinished documents. Some of those documents are genuinely stalled and should be deleted or archived. But some of them are doing active work just by existing as a place you return to when you’re thinking through something hard.
The failure mode isn’t the unfinished document. It’s not being able to tell the difference between the document that’s productively incomplete and the one that’s just avoiding closure out of perfectionism. If you haven’t opened a draft in three months and feel vaguely guilty every time you see it, that’s probably not a live thinking tool. If you’ve been actively working in a doc for two weeks and it still has unresolved questions, that might be exactly what good thinking looks like.
Shipping is sometimes the right answer. But “done” is not inherently better than “actively in use.”
