What Is a Product Opportunity Sprint and When Is It Worth Paying For?

A Product Opportunity Sprint is a focused engagement for answering a question that should come before development:

Is this digital product opportunity worth pursuing, and what is the smartest next investment?

It is designed for organisations that have an idea, internal problem, customer opportunity or technology concept but do not yet have enough evidence to justify a full build.

The output should be a decision: build, buy, test further, redesign or stop.

When a Product Opportunity Sprint is useful

Typical situations include:

• a business wants to launch a new digital product;
• leadership has an app or platform idea but user evidence is weak;
• a manual internal workflow may justify custom software;
• an existing product needs a major new capability;
• a company is deciding between commercial software and a custom build;
• an AI product idea needs validation before engineering begins;
• multiple stakeholders disagree about scope;
• a vendor proposal exists, but the underlying problem has not been tested.

The sprint reduces uncertainty before the organisation commits larger budget.

What the sprint is not

It is not a compressed software-development project.

It is not a requirements workshop where every stakeholder request becomes a feature.

It is not a promise that the outcome will be an MVP.

Discovery is valuable precisely because “do not build this yet” can be the correct conclusion.

The Abrasim Product Opportunity Sprint

The sprint works through five decision stages:

Frame → Evidence → Options → Validate → Decide

The duration and depth vary with the problem. The important characteristic is focus: the work is bounded around a specific investment decision.

Stage 1: Frame the opportunity

Start by separating the problem from the proposed solution.

A stakeholder may say:

We need a customer app.

The sprint reframes this as questions such as:

• What customer problem are we solving?
• Who experiences it?
• How is it handled today?
• What does the current problem cost?
• Why does a dedicated app appear to be the answer?
• What other interventions could solve the same problem?

This creates an opportunity statement that can be tested.

A useful statement includes:

• target user;
• problem;
• current behaviour;
• desired outcome;
• business value;
• major assumptions.

Stage 2: Gather evidence

The sprint then looks for existing evidence before creating new research unnecessarily.

Sources can include:

• analytics;
• CRM data;
• customer-service records;
• sales feedback;
• search demand;
• employee interviews;
• customer interviews;
• competitor products;
• current workflow data;
• transaction volumes;
• operating cost.

For an internal product, the strongest evidence may come from cycle time, manual effort and error rates.

For an external product, demand, user behaviour, willingness to switch and commercial economics matter more.

Stage 3: Evaluate solution options

The team should deliberately consider more than one path.

Options might include:

• improve the existing process;
• use a commercial platform;
• configure an existing system;
• integrate two current systems;
• build a lightweight internal tool;
• build a custom customer product;
• use AI to augment part of the workflow;
• change policy or process instead of technology.

This prevents the sprint from becoming a justification exercise for a solution already chosen.

For major software choices, the Build vs Buy Software framework provides a structured comparison.

Stage 4: Validate the riskiest assumptions

Validation effort should focus where being wrong would be most expensive.

Common assumption categories include:

Desirability

Do users actually have the problem and care enough to change behaviour?

Viability

Can the product create enough business value to justify its cost?

Feasibility

Can it be built and integrated within realistic constraints?

Operability

Can the organisation support, govern and improve it after launch?

Risk

Are privacy, security, regulatory or reputational concerns manageable?

The method depends on the assumption.

Possible tests include:

• user interviews;
• workflow observation;
• clickable prototype;
• technical spike;
• manual concierge test;
• landing-page demand test;
• data analysis;
• commercial modelling.

See How to Validate a Digital Product Idea Before Spending on Development for the full evidence ladder.

Stage 5: Make the decision

The sprint should end with a recommendation and the evidence behind it.

Build

The problem and opportunity are strong enough to justify a defined next product phase.

Buy or configure

The capability is not sufficiently differentiating to justify custom development and an existing platform fits the need.

Integrate

The best value comes from connecting existing products and adding a smaller custom layer.

Test further

The opportunity remains promising, but one or two material assumptions are unresolved.

Stop

The evidence does not justify further investment.

Stopping can be an excellent return on a discovery engagement if it prevents a much larger failed build.

What should the sprint deliver?

A good Product Opportunity Sprint produces artefacts that help the next decision rather than a pile of workshop photographs.

Opportunity definition

The problem, target users, outcome and commercial rationale.

Evidence summary

What is known, what is assumed and how strong the evidence is.

User and workflow map

The important journey or operating process around the opportunity.

Option analysis

Build, buy, integrate and non-technology alternatives where relevant.

Validation findings

Results from prototype, technical, market or operational tests.

Risk and dependency map

What could block value or increase implementation cost.

Recommendation

Build, buy, test, redesign or stop.

Next-phase scope

If the opportunity proceeds, a bounded scope for what should happen next.

Should the sprint produce a feature list?

It may produce candidate capabilities, but a giant feature backlog is not the goal.

Features should follow evidence about the user problem and product outcome.

An early scope is better expressed as:

• core user outcome;
• critical workflow;
• assumptions to test;
• minimum required capabilities;
• non-goals;
• success measures.

This gives a product team room to learn without turning every workshop request into a contractual promise.

How is this different from an MVP?

An MVP is a product or service released with enough capability to test value under real conditions.

A Product Opportunity Sprint happens earlier.

It asks whether an MVP is even the right next investment.

Sometimes a prototype, technical spike or commercial platform pilot can answer the important question more cheaply than building an MVP.

How is it different from a strategy workshop?

A workshop is mainly a collaborative session.

A sprint combines workshops with evidence gathering, analysis and validation.

The output is therefore not simply stakeholder alignment. It is a recommendation grounded in observed users, operating data, market evidence or technical testing.

Who should participate?

Depending on the opportunity, the core group may include:

• executive sponsor;
• product lead;
• subject-matter expert;
• user researcher or strategist;
• designer;
• technical lead;
• data specialist;
• operational owner.

The team should be small enough to move quickly but broad enough to test the opportunity from business, user and delivery perspectives.

What evidence should exist before development begins?

The exact threshold depends on the size of the investment.

For a substantial custom build, leadership should usually know:

• the problem is real;
• priority users are understood;
• current alternatives are known;
• the commercial or operating value is plausible;
• the riskiest technical dependency has been explored;
• ownership exists;
• success can be measured;
• build vs buy has been considered.

If those questions are unanswered, engineering will end up discovering them at a much higher cost.

When is a sprint not worthwhile?

It may not be necessary when:

• the requirement is genuinely commodity and an obvious product already fits;
• the change is extremely small and reversible;
• strong evidence already exists and the next decision is clear;
• leadership has no intention of acting on the findings.

Discovery should be proportionate to uncertainty and investment size.

Example: internal operations platform

Imagine a company wants to replace a spreadsheet-heavy workflow with custom software.

The sprint might discover that:

• the process handles high transaction volume;
• 30% of staff time is spent reconciling information;
• most errors arise from duplicate data entry;
• an existing SaaS product covers the core workflow;
• one proprietary pricing process is genuinely unique;
• the SaaS product exposes an API.

The best recommendation may therefore be:

Buy the commodity workflow platform and build only the proprietary pricing integration.

Without discovery, the company might have commissioned a full custom system.

What makes the sprint valuable?

The value is not the number of documents produced.

It is the amount of expensive uncertainty removed.

A useful sprint should make the next investment smaller, clearer or easier to stop.

The decision principle

Do not ask “what should we build?” until you have asked “what is worth changing?”

That principle keeps product development connected to business value and makes discovery part of investment discipline rather than an optional design exercise.

How to run the sprint step by step

Step 1: Approve the investment question

Name the sponsor, decision owner, decision date and investment that may follow. Convert “we need an app”, “we need a platform” or “we should add AI” into a question about a user, problem, behaviour, outcome and commercial or operating value.

Output: a bounded opportunity statement and a record of the proposed solution assumptions.

Step 2: Map stakeholders and decision rights

Identify users, customers, process owners, technology and data owners, finance, risk, procurement and the people who will operate the result. Clarify who can recommend, approve, block and accept evidence. Avoid a committee in which nobody owns the decision.

Output: a responsibility map and escalation route.

Step 3: Build the evidence and assumptions register

Gather existing research, analytics, sales and support evidence, workflow data, transaction volumes, cost, current alternatives, market evidence, contracts and architecture. Classify what is known, inferred, assumed and missing. Rank assumptions by the cost of being wrong.

Output: a prioritised assumptions register, not an unqualified requirements list.

Step 4: Research the problem in context

Observe representative users completing the current task or journey. Interview them about actual behaviour and recent examples. Review exceptions, workarounds, switching barriers and who bears the cost. For an external product, test demand and willingness to change; for an internal product, test volume, delay, error, effort and control.

Output: problem evidence and a current journey or workflow map.

Step 5: Define the outcome and success evidence

State the user outcome, business outcome and operating outcome separately. Define the baseline, leading learning measure, outcome measure and guardrail. Avoid a success definition limited to launch, usage or stakeholder satisfaction.

Output: an outcome model that can govern option selection and later product measurement.

Step 6: Generate competing options

Compare policy or process changes, service redesign, an existing product, configuration, integration, a lightweight tool and custom development. Include retaining or stopping the current idea. Assess differentiation, control, fit, total operating burden, reversibility and dependency alongside the initial build cost.

Output: an option matrix with non-technology and buy routes represented fairly.

Step 7: Select the riskiest assumptions

Score desirability, viability, feasibility, operability and risk assumptions by uncertainty and consequence. Choose the smallest set that could change the investment decision. Do not prototype comfortable interface details while the commercial or integration assumption remains untested.

Output: a validation plan ordered by decision risk.

Step 8: Run the cheapest credible tests

Choose the method that produces relevant evidence: interviews, observation, service prototype, clickable prototype, concierge test, landing-page test, commercial experiment, data analysis, supplier proof or technical spike. Define sample, success signal, limitation and stop condition before running it.

Output: test results that can support, weaken or invalidate the opportunity.

Step 9: Define the first-version boundary

If evidence supports progression, define the core user outcome, critical workflow, minimum capabilities, essential controls, integration boundary, non-goals, operating owner and questions the first version must prove. Keep future ideas outside the funded boundary.

Output: an evidence-led product boundary rather than a giant feature backlog.

Step 10: Make and document the decision

Recommend build, buy, configure, integrate, validate further, redesign or stop. Show the evidence, unresolved assumptions, cost and dependency ranges, risks, owners and the next gate. Record why rejected routes were not selected.

Expected result: leadership can approve a limited investment with a clear learning objective or avoid a build that is not justified. The sprint supports that decision. Demand, adoption, delivery cost and market success still need evidence.

For the governance shared by all audit types, use How to Choose and Run the Right Business Audit.

Use the copy-ready governance and decision templates in the Leadership Audit Working Pack.

Sources and further reading

• GOV.UK Service Manual: How the discovery phase works
• GOV.UK Service Manual: Measuring service benefits
• Atlassian: Product discovery
• GOV.UK Service Manual: Commercial off-the-shelf products and services