Day one and two: the shape of the thing
We start with the workflow the product exists to change, described end to end by the person who knows it best. Not features, not screens: who does what today, in what order, and where it goes wrong.
By the end of the second day we can restate that workflow back in one page. If we cannot, we do not understand the product yet, and no amount of estimating will help.
Day three: a data model on paper
The entities and their relationships come before any interface discussion. Most disagreements about scope are actually disagreements about the data model, and they are far cheaper to resolve on paper.
This is also where domain expertise pays off fastest. A founder who knows the field will spot a wrong relationship immediately, even when they have never read a schema before.
Day four: something deployed
A running deployment on real infrastructure, with authentication, a database and a release pipeline, even if the application does almost nothing yet.
Deploying on day four makes every later week honest. There is no integration phase at the end, because integration was the first thing built.
Day five: the not-building list
We write down what v1 will not include, and why, and send it. Roadmaps get read as promises; a not-building list gets read as a decision, and it is the document that keeps the next three months calm.
Everything on it is dated rather than deleted. Nothing is refused forever, but nothing sneaks back in unnoticed either.