Product Opportunity Sprint

Is this need worth investing in, and what must the first useful version prove?

A discovery engagement that tests the need and defines a useful first version, including whether it can be built, adopted and supported before you commit to delivery.

Tell us what is not working

Who this is for: Founders, product teams and internal innovation leaders considering a new digital product, platform or automation tool.
When this helps: A product idea has support, but the user need, first-version scope or feasibility is not clear enough to commission delivery.
Decision at the end: A decision to build, buy, change, test or stop, with a defined minimum viable product (MVP), open questions and requirements for the next phase.

Value path

Market need and investment → a useful, supportable product

The problem: An idea may gain support before anyone has established who needs it, what the first version should do or how people will use and support it.
Evidence we need: The problem, intended users and result you want, available research and commercial or technical information, known constraints and the people responsible for the product and its operation.

Assess → Transform → Operate → Scale

Understand the problem before deciding what to change.

This engagement covers Assess. Transform, Operate and Scale each need a separate scope and approval. An assessment recommendation does not commit you to later work.

Assess
Understand the problem
Check the evidence and how the work happens. Decide which problem needs attention first.
Transform
Put the change into practice
Agree the scope, responsibilities and success measures, then implement the chosen changes.
Operate
Make the change hold
Support the change in day-to-day use and review whether it is delivering the intended result.
Scale
Repeat what works
Use results from day-to-day work to decide what to improve or extend, retaining the conditions that made it work.

Best for

Founders, product teams and internal innovation leaders considering a new digital product, platform or automation tool.

Boundaries and responsibilities

When this helps: A product idea has support, but the user need, first-version scope or feasibility is not clear enough to commission delivery.
Why it matters: Testing the need and first version early gives you a chance to change direction before delivery costs make that decision harder.
What you can decide: A decision to build, buy, change, test or stop, with a defined minimum viable product (MVP), open questions and requirements for the next phase.
What is included: Agree the problem, intended users, affected process and decision to be made.
Review evidence of user need, commercial opportunity, alternatives and constraints.
Define the MVP scope and assess what delivery and operation would require.
Recommend whether to build, buy, change, test or stop, with a separately scoped next step.
What we need from you: A concise brief on the idea or problem, intended result and decision to be made.
Available user research, market, commercial and technical evidence, including current process and product information.
Working sessions with the relevant product, commercial, technical and delivery people to review constraints and dependencies.
Your responsibilities: Provide the problem brief, intended users, desired result and available commercial, user and technical evidence.
Make the relevant product, commercial, technical and delivery people available to test assumptions.
Decide whether to proceed and agree the responsible person and evidence required for the next phase.
Decision criteria: Need: does the opportunity solve a defined problem for identifiable users?
Investment case: does the evidence support investment, with assumptions and gaps stated?
First version: does the MVP focus on the most important user and business needs, with lower priorities excluded?
Feasibility: are the delivery, technical and operating requirements, risks and dependencies understood?
Before you commit further: Proceed to definition or delivery when the evidence supports the need, first-version scope and feasibility.
Validate when a user, market, commercial or technical assumption needs testing.
Defer when dependencies or responsibilities remain unresolved.
Stop when the need, business case or practical route does not support proceeding.
What is not included: Product design, software development, integrations, hosting, production implementation and ongoing product operations.
A full technical specification, production architecture or delivery execution beyond the agreed architecture considerations and roadmap.
Unagreed research, evidence collection or stakeholder participation; any follow-on product leadership, architecture, prototyping or implementation is separately scoped.
How this differs: Tests the need, commercial case, first version and feasibility before build investment.
Focuses on a defined product or platform opportunity, unlike the broader Business Growth & Technology Opportunity Assessment.
Produces the evidence and scope needed for a delivery decision. It does not implement the product.

What we examine

01Problem and user need
02Commercial opportunity
03Market and alternatives
04MVP scope
05Technical feasibility
06Delivery and operating considerations

What you receive

01
A decision brief covering the problem, users, intended result, evidence and assumptions
02
An opportunity assessment covering the market, commercial case, alternatives and evidence gaps
03
A user and use-case model with an MVP scope and reasons for including or excluding features
04
An option assessment recommending whether to build, buy, change, test or stop
05
Technical, delivery and support requirements with important risks and dependencies
06
A roadmap identifying next-stage priorities and work needing a separate scope

How it works

01
Agree the problem, users, intended result and decision to be made.
02
Review available research and commercial and technical evidence, recording assumptions and gaps.
03
Assess the opportunity and alternatives, then define priority users and uses.
04
Set the MVP scope and compare options against value, feasibility, risk and support requirements.
05
Present the recommendation and roadmap, separating any product leadership, architecture, prototype or implementation work for its own scope.

What happens next

Decide what to do next.

You receive the evidence, MVP scope, recommendation and roadmap needed to decide whether to build, buy, change, test or stop. If you proceed, product leadership, architecture, prototyping or implementation is scoped separately.

Tell us about the problem