The meeting where I drew the system

Two engineers were arguing about a roadmap item. One thought the platform already supported it. The other thought it would take three sprints.

I went to the whiteboard and drew the actual system — eight boxes, four arrows, two states the team had forgotten existed.

Five minutes in, the argument was over. Both of them had been right. They had been arguing about two different versions of a system neither of them had drawn in eight months.

That is the underrated PM job. Not the roadmap. The diagram of what already exists.

Why legibility compounds

Most product debates are not disagreements about what to build. They are disagreements about what already exists.

Two people argue about a roadmap when they are really running with two different mental models of the system the roadmap would extend.

Illegible systems tax every conversation. Engineers re-explain architecture in meetings. Designers spec flows that violate invariants nobody remembered. PMs prioritize features that, on closer reading, are already half-built somewhere else.

A legible system — a single, current, accurate description that everybody points at — speeds up the conversations, sharpens the prioritization, and onboards new hires in days instead of quarters.

It does not show up on a quarterly OKR. It shows up in the ambient speed of the team six months later.

Three artifacts that earn their keep

The first is the platform map. A diagram of the major capabilities, what each does, what depends on what, kept on one wall in the team area and refreshed every quarter. People who walk past it understand the company in three minutes. The version I keep at eOS lives on a single sheet of paper, stapled to the inside of my notebook. Every quarter I redraw it, and most quarters one of the boxes I drew the previous time has changed shape. The act of redrawing makes me notice.

The second is the state machine. For any flow with more than two states, the explicit machine, including the dead-end states, the error states, and the transitions that are not allowed. The cheapest way to find a product hole is to draw the diagram. The absences become obvious. The first time I tried to draw the onboarding state machine for a new product, I found three states the team had been treating as the same state and one transition that no code path actually supported. The gap is always real. The gap is always something a customer is going to hit.

The third is the decision log. Not the meeting notes. The why-we-did-X log. One line per decision, dated, with the alternative that was rejected. Six months in, it is the most reread document on the team, because it answers why are we like this faster than anything else.

What the work asks of a PM

Patience for description. PMs are trained to point forward — what is next, what is the priority, what is the bet. Legibility points sideways. It describes what is.

That can feel like work that does not move the needle. It does. It just takes six months for the move to show.

And editorial discipline. The map that says everything says nothing. A good map is opinionated about what to omit, what is irrelevant to the present roadmap, what is temporary, what is decoupled and does not need to appear. Editing the map is harder than drawing it.

The objections that come up

Three, in roughly the order they appear.

"Our system is too complex to draw." It isn’t. The systems that "can’t be drawn" are the ones nobody has drawn. The act of drawing forces the simplifications you need. If the final diagram has 47 boxes, you drew the wrong diagram. Pick the eight that matter and add an annotation that says we deliberately omitted the rest.

"It’ll be wrong by next week." Drawings of moving systems are always wrong. They are still useful. A diagram that is 90% accurate, dated, and on the wall is enormously more useful than a diagram that is 100% accurate, in someone’s head, and never on the wall. Date the diagram. Redraw it next quarter. Do not pretend it is a permanent record.

"My team won’t use it." They will, the moment the first cross-team argument gets resolved by pointing at it. The diagram earns its keep the third or fourth time it answers a question. Until then, you are building credit. Build the credit.

How to start when you don’t have time

You do not need to do all three at once. You do not even need to do them well at first.

Start with the decision log. One line per decision, dated. Email yourself or use a single Notion page. Do not try to backfill the past. Start from now. Two weeks in, you will have a small archive that already pays back. Three months in, you will be the only person on the team who can answer why are we like this in less than five minutes.

Then add the state machine, when a debate about a flow gets stuck. The act of drawing it ends the debate. The drawing becomes the artifact that lasts.

The platform map last. It is the most useful of the three over time, but also the most expensive to draw correctly. Earn the time by having the decision log and the state machines already paying back.

And in the AI era

If this idea matters, the AI era makes it matter more.

An agent will produce a beautiful PRD for a feature that conflicts with three existing invariants. Unless someone has done the legibility work, no one will notice until production.

The PM who spent quarters making the system legible looks, in retrospect, like the one who set the team up to use AI well.

The PM who treated description as overhead set the team up to ship the wrong things faster.

Legibility isn’t where the glamour is. It is where the compounding is.