how we build · part one
The Pull
The Product Owner's walkthrough before a developer pulls a story. What the developer reads. The moment the witnessed understanding re-enters the team room — and the discipline of asking before building.
Events in this phase. PO walkthrough — ten to fifteen minutes, before the developer begins. Not a meeting — a conversation at the board. Daily over the board — right to left — stories closest to done first.
The walkthrough
Before a developer pulls a story into In progress, the Product Owner walks them through the witnessed moment. Not the feature. Not the acceptance criteria. The moment. "This is Gal. Wednesday afternoon. Twenty-eight submissions are waiting. She has forty minutes before she has to leave. The part that takes her the longest is the open-answer marking because she switches tabs twenty-eight times."
This is not ceremonial. It is the mechanism that ensures the developer begins with the person's situation in mind rather than the system's behaviour. A developer who pictures Gal's afternoon writes different code than a developer who pictures a data model. Both may produce working software. Only one produces software that changes the situation the brief described.
What the developer reads
After the walkthrough, the developer has five artifacts in front of them. Each one carries a different dimension of the understanding. Together, they are enough to build without inventing:
- The Epic card — the activity name, the person, why this Epic exists, what done means. The scope boundary.
- The story card — the specific scene within the activity. Person, moment, what done looks like, out of scope, links.
- The wireframe states — named frames in Figma showing what the person will experience. The prototype to click through.
- The technical artifacts — API contracts, schema additions, ADRs that constrain the implementation.
- The scenarios — named Gherkin scenarios from the amigos session. The specification the tests will verify.
When to ask vs when to decide
The developer will encounter ambiguity. Some ambiguity should be resolved by asking the Product Owner — anything that touches the person's experience, the scope boundary, or an architectural promise. Some ambiguity should be resolved by the developer — implementation details, internal naming, algorithm choice, anything that doesn't change what the person sees or what the system promises.
The line: does this decision affect the person's situation or the system's contracts? If yes, ask. If no, decide and move on.
Resolution gate — Pull to Code
Enough to begin without inventing.
The developer has walked through the moment with the PO. All five artifacts are read and understood. Questions that touch the person's experience have been asked. Implementation decisions that don't affect the person's experience have been made.