Evidence-Sequenced Roadmap
What do we build next? Whatever teaches you the most important thing you don't know yet. Order the roadmap by what you need to learn, not by what's on the wish list, and give every item the evidence it has to produce.
Build what you need to learn next.
What moves it to the next step
A wish list grows every week, and the loudest request usually wins. An evidence-sequenced roadmap gives every item a job: to settle one question.
List the unknowns
Write down what you don't know that could sink the product: whether people use it without being asked, whether they'll pay, whether the model holds up on real data, whether one channel can reach them.
A short list of unknowns, each one a question with a yes or no answer.
Order by learning
Put first the unknown that blocks the others. There's no point tuning onboarding for users who won't come back, or pricing a feature nobody uses.
A reason, in one line, for why each item sits where it does.
Name the evidence
Every item on the roadmap states what it will prove or disprove, and how you'll see it. An item that can't name its evidence goes back to the wish list.
For each item: the question, the signal, and where you'll read it.
Re-sequence
When the evidence comes in, the order changes. A yes unblocks the next item; a no can move the whole roadmap, which is the point of having built the cheap thing first.
The roadmap changed because of what you learned, not because of who asked loudest.
The clinic assistant after its first release.
Illustrative example The clinic from Cut It, sequenced the way we'd sequence a real product. Not client work.
First: booking and payment
The question: will patients pay when they book, in the chat they already use? Everything else depends on the answer.
Then: reminders in the chat
The question: do reminders cut the front desk's calls the day before? The evidence is the call log.
Then: no-show prediction
Only now, because it needs the booking data the first two items collect. The question: does it beat the reminder alone?
Waiting: the voice assistant
On the wish list, not the roadmap, until the chat flow is proven and a question needs it.
Where it goes wrong
- Misread
Dates first, evidence later
Why A roadmap of dates promises output. A roadmap of evidence promises learning, and the dates follow from it.
- Misread
Ordering by effort
Why The easiest item first feels like progress, and often teaches nothing. Order by what you need to know.
- Misread
Never re-sequencing
Why If the order survives every result, the evidence isn't being read. The roadmap should change when you learn something.
In the Journal: Build: does it exist, and does it work? and PMF: do they keep using it?
Published 28 September 2026. Graylemon original, from our engagement method.