From an idea to a build-ready plan

Positioning: one sentence you can build against

Before anything else, one line that says what the product does and who for. Not a tagline — a constraint.

The test is not whether it sounds good. It is whether it can reject a feature. If a proposed feature does not obviously serve that sentence, the sentence is doing its job. If every feature seems to fit, the sentence is too vague to plan with, and every later decision inherits that vagueness.

• The one line. What it does, for whom, instead of what.
• The target user, narrowly. Not “coaches” — “independent coaches with 5–30 active clients, currently juggling four tools.”
• The one problem v1 must solve. Singular. Not a list.

That last one is the load-bearing part. A product with one problem has a boundary. A product with four has none.

A positioning line that cannot turn a feature down is not positioning. It is decoration.

The MVP boundary: what is out, and why

Most MVP definitions list what is in. The useful half is the other one.

An MVP is not a small version of the product. It is the smallest complete outcome for one user — the whole promise delivered once, rather than every feature delivered halfway. A product with all its buttons and none of them finished is not an MVP; it is a demo that cannot be used. That argument is the whole of what actually deserves to ship.

So write two lists. The first is what ships. The second is what is explicitly cut — with the reason next to each cut.

This is also the step that keeps the product from growing sideways instead of forward — the failure described in why more features create less clarity.

Features, named by the job they do

Now the features — but not as a list of nouns.

Each one gets a sentence saying what job it does in the product. “Public booking page” is a noun. “The client-facing core — replaces the tool they use today” is a job. The second version tells you what breaks if you cut it.

Two things fall out of this immediately.

• Features that cannot be given a job are not features. They are habits copied from another product.
• Features whose jobs overlap are one feature described twice.

Order them by the job, not by effort. Effort belongs in the build plan, several decisions from now — putting it here is what produces plans full of easy work that does not add up to an outcome.

Pages and flows: one system, not three lists

Features, pages and user flows are usually written as three separate documents, and that is exactly where products start to drift apart.

They are one system. A feature exists on a page. A page sits in a flow. A flow crosses several features. Written separately, they disagree within a week — the feature list gains something the pages never got, the flows describe a screen that no longer exists.

• Pages — the screens that must exist. Name them as routes.
• Flows — the two or three paths that actually matter, written as a sequence a real person takes, end to end, including where they arrive from.

Write the flows as prose, not diagrams, at this stage. Prose forces you to name the moment where a flow crosses a system boundary — the payment, the email, the policy check — and those crossings are where the next decision lives.

This step expands more than it looks like it will: one feature routinely becomes six pages and four failure screens. Deriving them properly, including the empty and partial states nobody lists, is worth its own pass.

Dependencies: the decisions that touch everything else

This is the step most plans skip, and the one that costs the most when skipped.

Some decisions are local. Most are not. A handful of them touch every other part of the product, and if they are made late — or made implicitly — the cost is not a change, it is a rewrite.

Timezone storage is the classic. Decide it on day one and it is a data model. Decide it in month three and it is booking, reminders, rescheduling and calendar files, all at once.

The pattern to look for: a decision that more than two features read from. A cancellation policy that lives inside each flow means every policy change touches four features. The same policy as one object means it changes in one place.

That is not an argument against the feature. It is the argument for knowing the cost before agreeing to it, which is the whole point of doing this step before the build order rather than during it — and it is the same habit as seeing what breaks before you build.

Build order: dependencies decide, not priority

Only now does the build order get written — because only now is there enough information to write it honestly.

The order is not “most important first.” It is riskiest data model first, then whatever unblocks the most work. Priority tells you what matters. Dependencies tell you what is possible. Building in priority order is how things get built twice.

• Foundation.The model everything else reads from. Auth, and whatever the dependency step flagged as touching everything.
• The core loop.The one path that delivers the promise, end to end, with the expensive parts stubbed behind a flag so it is testable early and free.
• The parts that carry risk.Money, third parties, anything with a refund path or a compliance surface.
• Everything built on top.Flows that read from the objects that now exist.
• The parts that can run in parallel.Anything with no hard dependency left.
• Polish and launch.Empty states, reminders, onboarding.

Two rules make it hold. Each stage must ship something testable, or it is not a stage. And a stage that depends on a decision not yet made is not scheduled — the decision gets made first. This is the difference between a plan and a list, which is why a backlog is not a build plan.

Open decisions, written down as open

The last section is the one that keeps the plan honest: the decisions that are not made yet, listed as such.

Every plan has them. The failure is leaving them implicit, where they get decided by accident — by whoever writes that part of the code first, in whatever way is convenient that afternoon.

Written down, an open decision does three things: it stops being rediscovered, it can be scheduled before the work that depends on it, and it makes clear which parts of the plan are still soft. Keeping that record in public is most of what makes a build log more useful than a roadmap.

This list is also the plan's first job after v1 ships: shipping is what supplies the evidence these decisions were waiting for, which is the work that keeps a plan from being abandoned the week the build starts.

Why the order is the method

Read back, each step exists to protect the next one.

Run in this order, each decision is made once. Run in any other order, some of them get made twice — and the second time is the expensive one, because there is code attached.

What this gives an AI coding agent 🤖

One more reason the order matters, specific to how most people build now. An agent given a ticket has the ticket. An agent given this has the product: the boundary, the invariants, the non-goals, and what a change is allowed to touch.

The difference shows up exactly where you would expect — not in whether the agent writes the feature, but in whether it quietly breaks three others while doing it. That is also why an agent should stop and ask rather than guess at a decision the plan never made.

Seven decisions. Most of the cost of a build is set before the first one is written down, and almost all of it is set by the order.

If you would rather see the finished thing than the argument for it, the same seven sections are filled in end to end for a sample product — the format to copy, at the depth a real one is written.