Discovery saves building the wrong thing.
A structured sprint that turns an idea into an evidence-backed decision: validated problem, tested concept, costed plan — or a documented reason to stop.
- Frame
- Research
- Prototype & test
- Decide
“Stop” is a success outcome.
The most expensive software is the software nobody needed. Discovery de-risks the decision: real users interviewed, the concept prototyped and tested, feasibility and cost estimated by the engineers who would build it — all before a build budget is committed.
Most failed builds were approved on a business case nobody could falsify. The problem was described from memory in a meeting, the users were represented by the person who complained most recently, and the estimate came from a template rather than from anyone who would have to live with it. Structured work replaces all three: the problem as observed rather than remembered, a concept in front of the people who would use it, and a cost band produced by the engineers who would own delivery. The output is a decision you can defend to a board — including the decision not to proceed.
A validated no costs a discovery sprint; an unvalidated yes costs a whole build.
Four workstreams, one decision.
They run in parallel rather than in sequence — research is still going when the prototype is being tested, and feasibility work starts at the outset because the hardest constraints are usually technical ones nobody has checked.
Problem validation
Structured interviews and workflow observation — does the problem exist, who has it, what’s it worth to solve? We speak to the people who do the work, using the same question set so the answers can be compared rather than anecdotally quoted. Where we can, we watch the task happen and count the steps, because the gap between how a process is described and how it is performed is where most product opportunities live.
Concept prototyping
Clickable prototypes tested with real users — evidence before engineering. The prototype is deliberately narrow: the two or three moments that decide whether the concept is worth anything, built well enough that a participant reacts to the idea rather than to the fidelity. Each round is watched by someone from your side, because a stakeholder who sees one session argues differently afterwards.
Feasibility & architecture
AI-native engineers assess integration, data and risk — the estimate comes from people who would own delivery. They read the API documentation, look at the data you actually hold, and run timeboxed spikes against the systems the product would depend on. The architecture sketch that comes out is deliberately rough on the parts that do not matter and specific on the parts that carry risk.
Decision package
Scope, cost band, timeline, risks and success metrics — everything a funding decision needs on paper. It is written to be read by someone who was not in the room: the evidence, the recommendation, the alternatives considered and what would have to be true for the recommendation to be wrong. It is portable to any vendor, including none.
How the work runs, day to day.
Time-boxed, with the date agreed with you.
Discovery expands to fill whatever time it is given, so we do not give it any. The sprint is time-boxed, with its length and price agreed with you up front and the decision session booked before the work starts. That constraint does more work than it looks: it forces the research to target the assumptions that actually change the decision, keeps the prototype to the moments that matter, and gives your stakeholders a date rather than a standing item on the agenda. From your side we need a decision-maker, access to users, and a technical contact.
- Duration, price and defined outputs, agreed before we start
- The decision session scheduled at the outset, with the attendees named
- 01Frame
- 02Research
- 03Prototype & test
- 04Decide
Four stages
Many conversations beat one confident opinion.
The research plan is written at the start and names who we need to speak to and why: the people who do the work, the people who supervise it, the person who inherits the exceptions, and at least one who solved the problem another way. Interviews follow the same structure so the findings can be counted, not just quoted. Every claim in the final package is traceable to a session, and where the sessions disagreed we say so rather than averaging them into a comfortable middle.
- A recruitment plan agreed up front — segments, roles and the reason each one is on the list
- Structured interviews, with workflow observation wherever the work can be watched
- Findings written with the evidence attached, including the ones that contradict the hypothesis
The estimate comes from the people who would build it.
An estimate produced by someone who will not deliver the work is a forecast of optimism. Ours is made by the engineers who would own the build, and it is made after they have touched the systems involved. That usually means timeboxed spikes: can we get the data out of the system of record at all, what does the partner API actually return, how much of the history is usable, what does the peak load look like. The architecture sketch names the two or three decisions that would dominate cost, and what we would need to learn to settle them.
- Timeboxed spikes against the real systems, not a review of their documentation
- Integration and data risks stated plainly, with the cost of each unknown
- A cost band with the assumptions that set its floor and its ceiling written next to it
A package that survives the meeting it was written for.
The decision package is written to be read months later by someone deciding whether the plan still holds. It contains the problem as evidenced, the concept and how it tested, the feasibility findings, a costed plan with a team shape and a timeline, the risks with owners, the success metrics that would tell you it worked, and a written recommendation. Where the recommendation is to build, it is scoped so the first release produces evidence — which is exactly where our MVP service picks it up.
- Options priced as bands, with what is in and deliberately out of each
- Risks with an owner and a mitigation, not a colour-coded grid
- Success metrics defined before the build, so the result can be judged rather than described
Three endings, and all of them are useful.
Build it — and here is the first slice.
The problem is real, the concept tested well and the feasibility work found nothing that changes the shape of the plan. The package hands over a scoped first release, a team shape, a timeline and the metrics that will tell you whether it worked. Because the same engineers did the feasibility assessment, delivery starts without a rediscovery phase — the spikes, the architecture sketch and the risks are already written down.
- A first release scoped around the riskiest remaining assumption
- Team shape and timeline, costed by the people who would deliver
- Success metrics and a measurement plan agreed before code starts
The problem is real; this was not the answer.
A sprint can also end in neither a clean yes nor a clean no. The research confirms a problem worth solving but the concept tested badly, or the feasibility work finds that the expensive part of the idea is the part users cared least about. The package says what the evidence supports instead — often a smaller build, a process change, or a different first user group — with the same costing discipline applied to the revised scope.
- The revised concept, and the specific evidence that redirected it
- What was dropped and why, so the decision is not quietly reopened later
- A re-costed plan against the new scope, not a discount on the old one
A documented reason not to build.
Some discoveries end here, and it can be the outcome with the best return. The problem turns out to be rare, or already solved by something the organisation owns, or worth less than the cost of solving it, or blocked by a constraint no software removes. The package records the evidence and the reasoning so the idea can be reconsidered when a condition changes — rather than reappearing later with the same assumptions and no memory of this work.
- The evidence for stopping, stated plainly and attributable to sessions
- The condition that would make it worth revisiting
- Any smaller, cheaper action the research did support
A discovery sprint, or straight into the build.
Four stages, with the decision session already booked.
Frame
Stakeholder alignment: the problem hypothesis, the users, and what evidence would change minds. We write the hypothesis down in a form that can be proved wrong, name the participants for research, and agree the decision criteria with the person who will make the call. Feasibility spikes start in parallel, because technical unknowns take the longest to resolve.
Research
User interviews and system review — the problem as it actually is, not as remembered in meetings. Interview sessions, workflow observation where the work can be watched, and a read of the systems and data the product would depend on. Findings are shared as they arrive rather than saved for the report, so the concept can start moving early.
Prototype & test
Concept built and put in front of users; feasibility assessed in parallel. The prototype covers the moments that decide the concept’s value, and each session is watched by someone from your side. Engineers finish the spikes and turn them into an architecture sketch, a risk list and the assumptions behind the cost band.
Decide
Findings, prototype results and the costed plan — presented for a go / pivot / stop decision. The session is a working meeting, not a presentation: the recommendation is on the table with the evidence behind it and the alternatives that were considered. You leave with the written package, whatever the decision is.
What you keep, whatever the decision.
- Research findings with interview evidence
- Tested prototype and usability results
- Technical feasibility assessment and architecture sketch
- Costed delivery plan with team shape and timeline
- Go / pivot / stop recommendation — in writing
- The risk list with owners and the assumptions behind every number
- Success metrics and how they would be measured after launch
When this is the right call.
Choose discovery when a significant budget is about to be committed on an assumption nobody has tested, when two internal camps disagree about what to build and need evidence rather than another workshop, or when the idea depends on systems and data whose real condition is unknown. It is also a way to compare building against buying, because the same sprint prices both. It runs naturally ahead of an MVP or a custom build, and pairs with UX / UI design when the concept survives testing.
It is not the right call when the decision has already been made and funded and the organisation only wants confirmation — that is a review, not a discovery sprint, and we will offer that instead. It is not the right call for a compliance-driven build whose scope is set by regulation rather than by user need. And it will not work if we cannot reach real users: without access to the people who do the work, the sprint produces opinion with better formatting.
Frequently asked questions
Where this service usually leads.
Tell us what you’re building.
Describe what exists today and what you need. An engineer reads it and replies in writing with how we would approach it.