Draw First, Write Second

When most people sit down to plan a feature, they open a document. They start writing. They describe the problem, then the solution, then the open questions, and somewhere in the middle of that they realise they don’t actually know how the pieces fit together. So the document gets longer, the structure gets messier, and by the time they share it, it’s doing too many jobs at once.

There’s a better starting point: the canvas.

Structure before prose

A canvas forces a different kind of thinking. You’re not writing sentences — you’re placing things. You have to decide what the discrete pieces are before you decide what to say about any of them. That’s a harder question, and it’s the right one to answer first.

When you map a feature on a canvas — break it into components, draw the dependencies between them, assign statuses — you end up with a structure. Not a final structure, necessarily, but something concrete enough to argue about. Does this arrow go both ways? Why is this component upstream of that one? What happens if this piece is late? These are planning questions, and the canvas is where they surface.

The document, when you write it, is filling in the reasoning on top of a structure you already understand. That’s an easier writing task. And a much more useful document.

The two jobs of a plan

A plan has to do two things: communicate structure and communicate reasoning.

Structure is what you’re building and how the pieces relate. Reasoning is why — why this approach, why this scope, why this order. Both matter, but they’re not the same thing, and tools designed for prose are bad at the first one.

A list communicates order. A document communicates narrative. Neither one is good at showing that Component A has to finish before Component B can start, and that both depend on a third party delivering an API that’s currently blocked.

A canvas is good at that. Lines, directions, spatial arrangement — these carry structural meaning that words have to work hard to convey and that readers have to work hard to reconstruct.

The feedback problem

When someone reviews a document, their feedback is usually about the prose. They suggest different wording. They ask clarifying questions about specific sentences. They lose the thread in the middle.

When someone reviews a canvas, their feedback is structural. This dependency seems wrong. Why is this separate from that? What’s inside this node? Those are the conversations that actually improve a plan.

Starting with the canvas sets the terms of the review. Reviewers engage with structure first, which is where most planning mistakes live, rather than with prose first, which is where most planning mistakes get buried.

What this looks like in practice

Before writing the spec, spend fifteen minutes on the canvas. Map the pieces of the feature. Draw what connects to what. Give each piece a status that reflects where it starts: most things start as Scope (under consideration) or Backlog (not yet started).

Now look at the canvas. Are there surprises? Dependencies you hadn’t made explicit? Components that are actually two things pretending to be one? If yes — good. You found them before you wrote a thousand words of prose that assumed the wrong structure.

Then write the spec. Attach it to the canvas. The document explains the reasoning; the canvas shows the structure. Together they’re complete. Separately, both are missing something.

The shift

The mental model shift is from “planning as writing” to “planning as mapping, then writing.”

It’s a small change in sequence. The output is similar — you still end up with a canvas and a document. But the order matters because structure constrains reasoning. When you draw first, you’re making structural commitments that keep the prose honest. When you write first, the prose can go anywhere, which is usually somewhere vague.

Draw first. Write second. The spec will be shorter, clearer, and more likely to reflect what you’re actually building.