The method, in two sections
The Method
One Product Builder carries one product from a folder of scattered documents to something running in production, front and back; Design, Frontend, Backend and API, Data, access, delivery and review are the shared services that make it possible.
Owning the outcome does not mean doing every specialist job or managing every contributor. The horizontal services are partners in delivery, not a queue of disconnected tickets.
The Principle
The two dimensions
Vertical
One product outcome
One Product Builder accountable for one product, front and back: the problem, the decisions, the design that was accepted, the code, the backend and the verification, from the first folder of documents through to production.
- Design OpsA design system that both the prototype and the front end draw on: the components and their states, the tokens, the rules for using them, what may be extended, and who maintains it.
- Frontend OpsAn approved starter repository at a named version, with its architecture, routing and component conventions, the API-client pattern, the checks required on a deployable branch, and a version an agent can re-read before every change.
- Backend and API OpsAn API catalog with real examples, authentication and permission rules, request, response and error shapes, a test environment with safe identities, and a written way to ask for an API that does not exist yet.
- Data OpsWhere the reference data lives, the business meaning of key fields and status values, a test dataset that is safe to use, and the rules on what may be exported, by whom and to where.
- Access, delivery and reviewA request route with an approver and a response target, a path from local to the repository to staging to production, a way to see which revision is live, and developers who read the generated code.
One product running in production
Vertical · Product Builder
Own one outcome, front and back.
Carry the problem, the decisions, the design that was accepted, the constraints and the verification, from the discovery through to production. You draw on the shared services and you keep the outcome.
Horizontal · Shared services
Make expertise reusable.
Supply a named owner, an approved pattern or contract and its limits, a response route, and evidence that the contribution works in the running product — to you, and to everyone else doing the same job.
A contract in both directions
The Product Builder provides
- The outcome, the users, and the context
- The contribution needed
- The constraints it has to sit inside
- An acceptance check
- A decision deadline
The Ops owner returns
- A named owner
- An approved pattern or contract, and its limits
- A response or delivery target
- A review path
- Evidence that it works in the running product
Example
On a sharing flow, the Product Builder owns the permissions the product intends and the behavior the people concerned accepted. Design Ops supplies the reviewed pattern and its states, Backend and API Ops the authorization contract, Frontend Ops the starter the front end is written inside, Data Ops the events that show how it is used. The Product Builder walks the flow end to end, with its empty, error and permission-denied states, and checks it as one product.
The Path
From a folder of scattered documents to something running in production, alone, with coding and design agents doing the work you brief them for: seven gates in one order, and two things that run across all of them.
Why the order matters
- A folder of documents is not a discovery.
- A discovery is not a PRD.
- A PRD is not a prototype the people concerned recognize as their tool.
- A front end you can click is not a product whose flows hold in depth.
The question. Which of those do you actually have in hand? Start where the answer stops being yes, and do not let a session walk through a gate you have not closed: ask it, at every gate, to state which gate it is at, what it has, what is missing, and what you must decide before it crosses. A session that cannot answer has left the method.
“The line that closes a gate is what you should be holding before you move on.”
The seven gates
Seven gates, numbered 0 to 6. Nothing above them, and no sub-phases. Each one says what you do, what you hold when it closes, and the prompts and templates it uses.
0 · Set up the project folder
What you do
Put every document the project needs into one folder made for it, and open the session on that folder. Create the memory and the journal before anything else runs, and the project channel with everyone concerned in it. The first prompt converts and indexes; it interprets nothing.
Project memory and journal
Why did the product move this way, and what happened when? Two files created before anything else: the memory holds the current position, the decisions and the trade-offs; the journal holds the dated record, never rewritten, including what turned out to be wrong.
1 · Gather the discovery
What you do
Take stock of whatever you are starting from, and go through the sources for contradictions, ownership gaps and the same name used for different surfaces rather than for a summary. Have an agent read what nobody has time to read; what comes back is input, never a decision.
Discovery notes
What did the sources actually say, and where do they disagree? The source list, the ambiguities, the questions for stakeholders, and a first hypothesis on the product boundary, written in the folder so the next gate can open it by name.
2 · Write the PRD
What you do
Run the analysis prompt on the folder, make it separate what is established from what contradicts and what is absent, and answer its alignment questions yourself. Then refine the PRD and align it with the business people, the technical parts included.
The PRD
What is being built, and what is not? One document whose first section is the strategic framing, every assumption marked as an assumption with the source it rests on or the person who has to decide it.
3 · Prototype the end-to-end flows
What you do
The coding agent takes the PM role for this step: it writes the prompt for the design tool and demands end-to-end flows, not just the major screens. Iterate in the design tool, show it to the people who will use it, and keep going until they say it is their tool.
The prototype people accepted
Is this the tool the people concerned need? The end-to-end flows, with their states and their failures, iterated in the design tool and shown to real users until they say it is theirs.
4 · Port the prototype into code
What you do
Start from the organization's approved frontend starter and its backend conventions, never from an empty folder or the design tool's export. Then do the back-and-forths: the running front beside the design, you name what is off, the agent fixes it, you look again.
The running front end
Can you walk the flows and click them? A front end built inside the organization's starter, walked flow by flow beside the design, with what was adapted and what was deliberately left different written down.
5 · Connect the backend
What you do
Swap the mock services for real ones, flow by flow, and go deep on each before the next: the empty state, the error, the slow response, the permission that says no. Roles and privacy are enforced at the read-model level, not in the component that displays the data.
The connected flows
Do the flows hold in depth, or only on the surface? Each flow against the real backend, with its empty, error, slow and permission-denied states, and the roles enforced where the data is read.
6 · Test, then ship
What you do
Give accounts to the people who should test while the connection work is still going on, share the life of the product in the channel, and fix what comes back as it comes back. Then take the go-ahead with the leads of the trades concerned, and ship.
The release record
What went out, verified how, and who gave the go-ahead? What is in the release flow by flow, what was tested and with which accounts, what is known to be broken, and which review did not take place if one could not.
Each gate ispassopen — a named owner is resolving itblocked — stops dependent work
What it takes. From a folder of gathered discovery material to a front end you can click: three to four hours at best and twenty-four at worst, when the discovery has already partly been gathered. About a month to connect the backend so the flows hold in depth, depending on the size of the application. And the code still goes to developers for review, and passes, because the agent works inside the organization's starter and conventions. These figures are the author's own practice, not a study.
The AI builds fast, so the checks that matter are human ones. The people concerned accept the prototype at gate 3, and convincing has one meaning here: they say this is the tool they need. The code goes to developers for review before production, and the leads of the trades concerned give the go-ahead. Neither check is a stage bolted on at the end.
Two things run across the gates rather than inside one. The control session is a second session whose only job is to challenge the first: it reads, checks and challenges, it changes no code and decides no scope, and it returns findings with their evidence for you to decide on. The standing guardrail sends the agent back to the organization's frontend starter and backend conventions before every change to the code — not once at the start, every time. Control session → · Standing constraint →
Continuity. The build does not stop at gate 6. The front stays demoable and keeps evolving: you go back into flows, deepen them, connect what was left, and show it again in the channel. One thing is deliberately frozen, and only one: an MVP that has to go to production, where what is in the release stops moving until it is out.
Scale it to the risk
Narrow fix · starts at gate 6
A misleading label, reported by a tester.
The product is already in real hands and the wording is the whole change. Fix it as it comes back, inside the starter's conventions, walk the flow again, and let it go down the delivery path. Nothing here reopens the PRD or the prototype.
New product · starts at gate 0
A tool that does not exist yet.
One folder with everything in it, the discovery gathered and its contradictions named, a PRD agreed with the business, a prototype the people concerned call their tool, then the port, the backend flow by flow, and accounts in real hands before production.
These two examples show how much of the path a given piece of work actually runs. They do not describe a client project.