The Product Discovery Sprint: A Practical Guide for UK Teams

A discovery sprint should not begin with the assumption that the requested solution is already correct.

If someone says, “We need an app for this process”, reframe the request:

• What problem is the app expected to solve?
• Who experiences the problem?
• What happens today?
• Why is the current process insufficient?
• What other solutions could address the problem?
• What would make the proposed app unnecessary?

This prevents the team from treating a technology request as a product conclusion.

Inputs Required Before the Sprint

A sprint becomes inefficient when participants spend the first day searching for basic context that should have been prepared beforehand.

Collect the available inputs:

• Business objectives
• Existing product or service information
• Previous research
• Analytics and support evidence
• Existing process maps
• Customer or user feedback
• Current technical architecture
• Known integrations
• Security and privacy considerations
• Commercial constraints
• Delivery constraints
• Relevant stakeholders
• Decision owner
• Existing ideas or proposed features

The GOV.UK guidance on planning user research recommends defining research objectives, user groups and research activities around the questions the team needs to answer.

Prepare a short briefing document with:

The team should know what success looks like before the sprint begins.

Day 1: Outcomes, Users and Constraints

The first day creates a shared understanding.

Morning: Align on the outcome

Turn broad objectives into specific outcomes.

Instead of:

Build a customer portal.

Use:

Help existing customers complete the most important account task without contacting support.

The second statement is easier to research, prototype and measure.

Midday: Understand users and context

Map:

• Primary users
• Secondary users
• Buyers or approvers
• People who provide support
• The user’s trigger
• Current workflow
• Offline steps
• Existing tools
• Failure points
• Accessibility needs
• Organisational dependencies

The GOV.UK guidance on user research in discovery recommends considering the full experience, including tools, transactions, support and offline steps.

Afternoon: Record constraints

Constraints are not only technical.

Day 1 output: A shared outcome statement, user and stakeholder map, current-state journey, constraint register and initial research questions.

Day 2: Journeys, Risks and Assumptions

The second day turns context into testable decisions.

Map the core journey

Map the journey from trigger to outcome:

1. What starts the task?
2. What does the user need to understand?
3. What action do they take?
4. What information or permission is required?
5. What decision occurs?
6. What happens when the action succeeds?
7. What happens when it fails?
8. What support or follow-up is required?

Do not map only the ideal path. Include the points where users pause, make a mistake, lose access or need another person.

Create an assumption register

Prioritise assumptions by consequence, not by how easy they are to discuss.

Identify the riskiest question

A useful risk question is specific:

• Can users complete the main task without assistance?
• Can an external system provide the required information?
• Can the product meet the required response time?
• Will a buyer accept the proposed operating model?
• Can the team support the service after launch?

Day 2 output: Core journey map, assumption register, risk ranking and priority research questions.

Day 3: Solution Options and Technical Feasibility

The third day explores more than one possible response.

Avoid jumping straight from problem to one preferred feature set. Compare options such as:

• Improve the existing process
• Add a responsive web journey
• Build a focused mobile experience
• Integrate an existing product
• Use a manual or concierge service initially
• Purchase a commercial platform
• Build a custom capability
• Combine an existing tool with a small custom component
• Defer the problem until stronger evidence exists

Technical feasibility should answer questions, not become premature production engineering.

Investigate:

• Data sources
• Authentication and authorisation
• Integration dependencies
• Offline or poor-connectivity needs
• Performance constraints
• Device features
• Security boundaries
• Deployment environments
• Monitoring and support
• Data retention and deletion
• Accessibility testing
• Ownership after delivery

Day 3 output: Options comparison, feasibility findings, technical risks and a recommended direction with stated assumptions.

Day 4: Prototype and Test Plan

The fourth day makes the riskiest user-facing assumptions tangible.

The GOV.UK prototyping guidance recommends using prototypes to explore and test approaches before committing to production code.

Choose the lowest fidelity that can answer the question:

Prepare a test plan with:

• Research objective
• Participant profile
• Access requirements
• Task scenario
• Prototype or test environment
• Questions to ask
• Behaviour to observe
• Consent and privacy approach
• Evidence to capture
• Decision the findings will inform

The GOV.UK guidance on planning a research round recommends clear objectives, relevant participants, informed consent, preparation and time for analysis.

Do not coach participants through the task too quickly. If the prototype is confusing, record that as evidence.

Day 4 output: Tested prototype or proof of concept, research plan, findings template and an agreed definition of useful evidence.

Day 5: Evidence Review, Scope and Decision

The final day turns findings into a delivery decision.

Review:

• What was confirmed?
• What was contradicted?
• What remains unknown?
• Which user needs are strongest?
• Which assumptions remain risky?
• What did the prototype reveal?
• What did the technical investigation reveal?
• What should the first release include?
• What should be deferred?
• What must be measured after launch?

Create a scope boundary.

Then choose one of four outcomes:

A stop decision can be a successful discovery outcome. It may protect users, budget and team capacity.

Day 5 output: Discovery summary, product scope, decision log, risk register, roadmap options and proceed/change/pause/stop recommendation.

Minimum Outputs Before Engineering Begins

Before development starts, the team should have:

1. A clear problem and outcome statement.
2. A defined first user group.
3. A mapped core journey.
4. A list of assumptions and risks.
5. Evidence from relevant users or stakeholders.
6. A tested prototype or technical proof of concept where needed.
7. A documented first-release scope.
8. A deferred-work list.
9. A technical and operational constraint summary.
10. A measurement and learning plan.
11. Named decision owners.
12. A clear next-step decision.

These outputs do not guarantee that delivery will be easy. They make the remaining uncertainty visible and manageable.

Common Discovery Sprint Mistakes

Avoid:

• Treating a requested feature as the confirmed solution
• Inviting stakeholders without a decision owner
• Running workshops without user evidence
• Confusing internal preference with user need
• Designing every possible journey
• Building production code before testing the riskiest assumption
• Producing a roadmap without a scope boundary
• Ignoring operations, support or accessibility
• Collecting research that the team cannot act on
• Declaring success because the workshop finished
• Hiding contradictory evidence
• Treating a five-day sprint as a substitute for all future research

Discovery should create momentum through clarity, not momentum through premature commitment.

Conclusion

A product discovery sprint is a decision-making process.

Start with the outcome and problem. Understand users and context. Map the journey. Rank assumptions. Compare solution options. Test the riskiest questions. Investigate feasibility. Finish with a scope boundary and a clear decision.

For help planning discovery, product strategy, UX or delivery, explore FlutterCraft services or contact the FlutterCraft team.

Sources

• How the discovery phase works, GOV.UK
• User research in discovery, GOV.UK
• Plan user research for your service, GOV.UK
• Plan a round of user research, GOV.UK
• Making prototypes, GOV.UK
• Measuring the benefits of your service, GOV.UK
• The Double Diamond, Design Council