Worked example: Relay — from product hypothesis to a controlled release

Everything in this example is fictional. Relay is an invented maintenance-request coordination product, not an actual Westforge case study. The market assumptions and feedback below are scenarios designed to illustrate decision-making; they do not claim real interviews, trials or market validation.

The point is to follow one continuous chain of reasoning, not nine unrelated sample problems. We start with product positioning, design only the engineering boundaries that are justified, implement one independently verifiable slice, challenge it, revise product scope and set release conditions.

Product in one paragraph

Relay is a proposed lightweight web product for small multi-site facilities teams. Staff submit maintenance requests; coordinators need to know which requests exist, who owns them and what state they are in. The initial idea also includes automatic urgency classification. The product hypothesis is that clear request ownership matters more to the initial audience than predictive sophistication.

The work-through

Step	Read	Decision/evidence produced
1. Product intent	Brief and hypotheses	Problem, users, hypotheses, provisional scope
2. Positioning and discovery	Positioning and research	Comparison categories and experiment plan
3. Ambiguity	Questions and decisions	Disputed meanings and escalation points
4. Architecture	Design	Mechanics, integrations, product orchestration
5. Contracts	Behavioural contracts	Invariants and explicit error semantics
6. Design decision	Decision record	Why the chosen boundary exists
7. Delivery	Phased plan	Bounded outcomes and gates
8. Agent execution	Work order	Allowed scope, stopping rules, evidence
9. Challenge	Escalation example	How to stop a plausible but wrong workaround
10. Reuse	Tool pipeline	Deterministic operations used by agents
11. Verification	Evidence matrix and review protocol	Mechanical checks, independent scrutiny
12. Decisions	Review record	How concerns are investigated, not voted away
13. Product learning	Scope change	Explicit example of removing a feature
14. Value	Outcome scorecard	Learning and costs, not code counts
15. Release	Release readiness	What evidence would be needed to ship
16. Continuity	Traceability	Connect intent through contracts and tests

A small executable slice

See the reference code for a working Python demonstration of request intake. It uses the standard library only and includes tests for duplicate delivery, contradictory duplicate payloads, validation and auditing. It deliberately does not claim to implement the whole product.

What to notice

1. Product discovery is not postponed until after the build. Each increment can test a product assumption.
2. Architecture is a design decision. The agent does not invent the layers while implementing a large ticket.
3. Contracts reduce context. The intake agent needs the store/audit contracts, not the internals of every consumer.
4. Errors are allowed to stop work. A conflict with a contract is not a prompt to build a shadow system.
5. Tests and review are complementary. Mechanical evidence answers specified questions; independent scrutiny looks for missing questions.
6. Less scope can mean more progress. The story ends by simplifying the product hypothesis, not celebrating feature count.

This is a practical illustration of the principles, not a prescribed process every organisation should follow.