Method

Map the product

One page covering what the product remembers, and what stops being true when something changes.

What goes on the page

Who is using it, what they are trying to get done, and what should be true when they finish. Everything else in the map exists to serve that.

Underneath the journey:

  • the records the product stores
  • the states those records move through
  • the rules that move them
  • what depends on what

For a small product this fits on one page. When it does not, the product is usually bigger than I had admitted to myself.

The question that pays for itself

If this changes, what becomes wrong?

I started asking it while untangling a content pipeline where editing one script invalidated a recording, then a summary, then a printed booklet, then a web page. Some of those relationships ran one way and some ran both ways. Writing the staleness down as a graph turned something I had been tracking in my head into something I could hand to somebody else.

Most features look local until you ask that question.

This is also where I put the AI to work against my own map, asking for missing states, words that could mean two things, and assumptions that will force a decision later. The goal is better understanding. If the map grew by two thousand words and taught me nothing, that round went badly.

How much to decide now

Long-term plans can shape cheap choices now. Stable identifiers and honest timestamps cost nothing today and keep a later sync feature possible. That is a different thing from building accounts and a backend for a product with no users.

Record the direction, make the smallest foundation decision that respects it, and leave the infrastructure alone.

The map is ready when it can support one slice end to end, and the questions still open would not change that slice. It will be wrong in places. Building the slice is what tells you where.

Further reading