Before you begin
Set the operating boundary first.
- Access to at least three representative users or realistic task examples.
- One accountable builder who can complete the full input-to-output path.
- A fixed time and spend limit for the seven-session experiment.
- Non-sensitive test data and a written list of unacceptable failure modes.
Step by step
Move from scope to a checked artifact.
Session 1 — choose one user decision
Name one user, one recurring task, the current workaround, and the decision or action your product should make easier. Write the smallest observable success signal and the conditions that would make the idea not worth building.
- Checkpoint
- The problem can be tested with real examples and does not depend on serving everyone.
- Artifact
- One-page problem and stop-rule brief
Session 2 — define one complete flow
Map the minimum path from input to useful output, including empty, loading, error, refusal, and retry states. Separate the required workflow from features that can wait. Identify where a human must review or approve the result.
- Checkpoint
- The first release has one end-to-end outcome and no orphan feature list.
- Artifact
- Flow map and acceptance checklist
Session 3 — prepare the task packet
Collect representative inputs, expected output structure, evidence needs, privacy constraints, and failure examples. Version prompts, model identifiers, parameters, tools, and contextual files so observed behavior can be explained later.
- Checkpoint
- The builder can distinguish a model failure from an unclear task or missing context.
- Artifact
- Versioned task and evaluation packet
Session 4 — choose the smallest operating stack
Select tools, model access, storage, hosting, and analytics according to the flow’s constraints. Prefer reversible choices and existing infrastructure. Record why each component is present, what it costs, what data it receives, and when it should be replaced.
- Checkpoint
- Every component supports the first flow rather than a hypothetical future platform.
- Artifact
- Stack decision record
Session 5 — build and verify the usable path
Implement the complete flow and test it with the task packet. Check content safety, authorization, data handling, timeouts, model failures, rate limits, accessibility, and mobile behavior in proportion to the release risk.
- Checkpoint
- The path produces a useful result or a clear safe failure for every representative example.
- Artifact
- Tested release candidate and defect list
Session 6 — release to a bounded audience
Deploy a traceable version, verify the public path, and invite the smallest useful group. Tell users what the product does, what it does not do, how their data is handled, and where human judgment remains necessary.
- Checkpoint
- The release can be identified, monitored, and rolled back without guessing.
- Artifact
- Release record and user test script
Session 7 — decide from observed work
Review completed tasks, failure patterns, abandonment, support questions, cost, and qualitative feedback. Decide whether to improve the flow, package it for repeat use, run a new experiment, or stop. Preserve the evidence and the reason for the decision.
- Checkpoint
- The next action follows observed behavior and predefined constraints, not launch-day enthusiasm.
- Artifact
- Decision record and next experiment
Deliverables
Keep the work reusable and inspectable.
- Problem brief and explicit stop rules
- End-to-end flow and acceptance checklist
- Versioned task and evaluation packet
- Stack decision record
- Verified release candidate
- Production release and user test record
- Evidence-based next decision
Decision boundaries
What this tutorial does not prove.
- Seven sessions constrain the experiment; they do not guarantee product-market fit, revenue, or a production-grade system.
- High-impact decisions need qualified review, stronger evaluation, and governance outside this launch cadence.
- Do not collect personal or confidential data merely to make the prototype feel realistic.
- Early user interest is directional evidence, not proof that a larger market or repeatable business exists.
Source ledger
Check the current primary guidance.
- NIST AI 600-1: Generative AI Profile
Risk-management reference for defining scope, controls, ownership, and evaluation according to context.
- RichBay: How to judge an AI answer
The review method used to separate task fit, evidence, uncertainty, and usability.
- RichBay: Reviewed output comparison
The repeatable method for versioning tasks, capturing outputs, and publishing a bounded decision record.