A discovery sprint should leave the team with decisions and evidence, not only a presentation. The useful outputs depend on what is uncertain: customer workflow, technical feasibility, integration access or delivery scope. Define the questions before choosing the workshops and artifacts.
The contract to define first
Produce a problem statement, representative workflow, constraints, risk register and acceptance sketch. Use prototypes or technical spikes only where they answer a named uncertainty. Record what was learned, what remains unresolved and who owns the next decision. A sprint does not need to pretend every requirement is settled to be valuable.
A worked scenario
A hypothetical founder is unsure whether coaches need a native app or a responsive portal. Discovery can observe the actual review task, test a small prototype and identify device constraints. The result should explain the platform decision and its assumptions rather than simply delivering both options as polished mockups.
An implementation and review sequence
- Name the decisions the sprint must support
- Choose evidence-gathering tasks for each uncertainty
- Deliver assumptions unresolved risks and next owners
Failure cases worth testing
| Condition or input | Expected behavior |
|---|---|
| A prototype answers no stated question | Reconsider its purpose |
| A provider dependency is unresolved | It stays visible in the scope |
| The sprint ends | The team can identify the next decision and evidence needed |
Download the illustrative acceptance checklist (JSON)
Tradeoffs and limits
Discovery can become endless if every question creates another workshop. Timebox investigations and distinguish a decision-blocking uncertainty from a detail that can be resolved during implementation.
Use the result to make a decision
The practical output is straightforward: define decisions prototypes risks and acceptance outputs for discovery. Keep the assumptions with the artifact so a product owner, implementer or prospective partner can review the same decision. A useful handoff states the supported scope, the evidence collected and the remaining dependency instead of treating a successful demonstration as proof of every operating condition.
Continue with related implementation detail
Related guide: Scope an MVP around one complete customer workflow.
Fitness app feature prioritization
AI feature readiness assessment
References and current platform requirements
thoughtbot: customer discovery
The linked references provide platform or process context. The worked scenario and acceptance matrix are original examples; adapt them to the actual product, supported environment and documented responsibilities.
Discuss the workflow
Bring one customer workflow and its constraints to define a reviewable discovery scope.
Explore the relevant AptixLabs service
What decisions should a discovery sprint produce?
A discovery sprint should leave the team with decisions and evidence, not only a presentation. Discovery can become endless if every question creates another workshop.
Which failure cases should be included in the review?
Include these explicit cases: A prototype answers no stated question: reconsider its purpose; A provider dependency is unresolved: it stays visible in the scope; The sprint ends: the team can identify the next decision and evidence needed.