Starting a product
Start building after the product is clear — not before.
When code arrives while scope is still moving, make the product decision acceptably concrete before another role starts building.
01
The moment code gets ahead of the product
You are a founder looking at a convincing implementation while the customer promise, business rule, and acceptance condition are still being argued in chat. The code is real; the product decision is not.
02
Why a fast agent makes this worse
An individual coding agent can answer the prompt in front of it. It cannot make an unsettled decision durable for the Architect, Developer, and the person who must accept the result.
03
A flow that makes intent buildable
Start with the uncertain request. BA clarifies the business rule and acceptance, asks the owner to approve the scope, and creates the initial canonical WP. Architect opens that same package and adds the relevant technical design. Developer then implements one bounded increment and records the checks. One founder can work through these responsibilities in separate sessions.
04
The first package another role can accept
- 01
Accepted scope
The request, business rule and acceptance criteria are reviewable.
- 02
Initial canonical WP
BA supplies a stable identity and links for Architect.
- 03
Technical enrichment
Architect adds selected decisions and constraints to that package before Developer begins.
05
What remains visible
Architect can open what the founder approved rather than reconstructing intent from chat. A later Runtime execution package has a separate local identity, so record its mapping to the canonical WP when used.
Start with the requirement
Read the Business Analyst guide, then use one live product question as the first accepted package.