What Your Discovery Phase Should Actually Deliver
Stop paying for decks. Start demanding decisions.
What You Need to Know
A discovery phase should produce a scoped backlog, a build-vs-buy recommendation, an agreed MVP definition, and a clear delivery plan — not a glossy deck. If your studio can't hand you those four artefacts, the engagement has produced theatre, not traction.
At a Glance
- Phase length
- 1–3 weeks (compressed) to 4–8 weeks (complex systems)
- Required outputs
- Backlog, build-vs-buy rec, MVP definition, delivery plan
- Biggest risk
- Discovery theatre — paid process with no actionable decisions
- When to skip full discovery
- Fewer than 3 user roles, no complex integrations, no compliance constraints
- Market
- UK and Australia — B2B software commissions
Best For
- ✓Founders and ops directors commissioning B2B software for the first time or after a failed previous engagement
- ✓UK and Australian operators evaluating whether a studio's discovery proposal represents genuine value
- ✓Product leads who want to hold a studio accountable for discovery outputs rather than just process
Not For
- ×Consumer app founders — the scope and process differ significantly
- ×Teams who have already completed discovery and are mid-build
- ×Enterprise procurement teams running formal RFP processes — this guide addresses smaller, direct engagements
Key Takeaways
- ✓ A discovery phase must produce four things: a scoped backlog, a build-vs-buy recommendation, an agreed MVP definition, and a delivery plan.
- ✓ Discovery theatre — workshops that end in slide decks with no decisions — is common and expensive. Define deliverables contractually before you sign.
- ✓ For straightforward B2B tools with fewer than three user roles and no complex integrations, a compressed scoping sprint is faster and cheaper than full discovery.
- ✓ The most valuable work in discovery is cutting scope from the MVP — not adding features. A studio that grows your MVP during discovery is not managing scope.
- ✓ AI-assisted product studios can compress discovery significantly by automating parts of backlog generation and brief analysis — without skipping rigorous scoping.
The Problem With Discovery as Usually Sold
You've seen the pitch. A software studio proposes a four-to-eight-week discovery phase before any code is written. You sign off £8,000–£25,000. Six weeks later, you receive a 60-slide deck, a journey-mapping workshop recap, and a vague "options paper". Nothing is decided. Nothing is scoped. The next proposal is another five-figure engagement to move into "alpha".
That pattern — call it discovery theatre — is widespread enough in UK and Australian B2B software markets that founders and operators have started treating discovery as a tax rather than a tool. That's a mistake in the other direction. Done properly, discovery is the most valuable money you spend on a product. Done poorly, it is money spent to produce more proposals.
This guide exists to help you tell the difference before you sign.
Four Things a Discovery Phase Must Produce
A rigorous discovery engagement ends with four concrete artefacts. If your studio cannot commit to delivering all four, renegotiate the scope or find a different partner.
1. A Scoped, Prioritised Backlog
Not a list of features someone brainstormed in a workshop. A genuine backlog: user stories written from operator workflows, acceptance criteria at least roughly sketched, and a rough-order-of-magnitude size on each ticket. The backlog should be prioritised — ideally using a framework the whole team has agreed to, such as MoSCoW or RICE — so that on day one of build, the team knows exactly what goes into the first sprint and why.
If you receive a feature list without sizing or priority, you have received a wish list, not a backlog.
2. A Build-vs-Buy Recommendation With Reasoning
Discovery should settle whether you're building, buying, or combining a commercial platform with custom extensions. This decision has enormous cost implications and should be documented explicitly, with the reasoning written down: which off-the-shelf tools were evaluated, why they fall short (or don't), and what the hybrid option looks like if that's the right path.
Many studios skip this step because the answer might be "buy, don't build" — which ends the engagement. That conflict of interest is real. A trustworthy studio will surface the recommendation anyway, because their reputation depends on it. For a structured view of that trade-off in practice, see our build-vs-buy exhibition platform guide, which applies the same logic to a concrete vertical.
3. An Agreed MVP Definition
The MVP — Minimum Viable Product — should be defined as the smallest deployable version of the system that delivers measurable operator value. Not a prototype, not a proof of concept: something real users can log into and use to do their job.
Critically, the MVP definition should include an explicit list of what is out of scope for the first release. Scope cuts are where most discovery phases do their most valuable work, and where most studios are least willing to push back on clients. A good discovery team will fight to remove features from the MVP — that is their job. If the MVP looks like a fully featured product, the scope hasn't been cut.
4. A Delivery Plan You Can Hold Someone To
A delivery plan is not a Gantt chart showing the next six months as a waterfall. It should cover: sprint cadence, milestone-linked review points, who owns what decisions on the client side, and the conditions under which scope can change. It should be short enough to fit on two pages and concrete enough that both parties know what "on track" looks like at week four.
Without this, discovery hands you a backlog that floats — no deadlines, no accountability, no mechanism for a founder or ops director to track progress.
What Discovery Does NOT Need to Produce
Knowing what to cut is equally important.
Brand and UX polish — Wireframes should be low-fidelity enough to be thrown away. If your studio has produced pixel-perfect mockups in Figma during discovery, they've spent time that should have gone into workflow analysis. Polish comes after validation.
Comprehensive technical architecture documents — A high-level architectural decision record is useful. A 40-page technical specification is not, unless you're procuring from a separate build vendor (in which case you have a different problem).
Stakeholder alignment decks — Discovery is not a change-management programme. If you need a slide deck to get internal sign-off, that's a governance challenge your studio should help you short-circuit, not produce collateral for.
When to Cut Discovery Short
For straightforward B2B tools — internal dashboards, lightweight portals, data pipeline fixes — a full discovery engagement is overkill. A well-run scoping call followed by a one-week structured brief can produce a backlog and MVP definition fast enough that you're into build within a fortnight.
AI-assisted product studios can compress discovery further still. When a studio uses AI tooling to generate first-draft user stories, draft acceptance criteria, and identify comparable prior patterns in their codebase, the manual effort in discovery drops substantially. That compression is one of the reasons some studios can now ship working B2B portals in weeks rather than months — discovery is tighter, not skipped.
The threshold for a full discovery engagement is roughly: more than three distinct user roles, more than one integration with an existing system, or meaningful regulatory or compliance constraints. Below that bar, a compressed scoping sprint is almost always the right call.
How to Brief Into Discovery Well
Discovery only produces useful outputs if you go in with the right inputs. Before you engage a studio, you should be able to articulate:
- The operational problem in one sentence (not the solution)
- The user roles who will touch the system and what they currently do manually
- The existing tools and data sources the new system must connect to
- Your non-negotiable constraints — timeline, compliance, geography
- What "success" looks like at six months post-launch
If you haven't written those down, start there. Our guide on how to brief an AI product studio walks through the full structure. The better your brief, the faster and cheaper your discovery.
Red Flags to Watch For
| Signal | What it usually means |
|---|---|
| Discovery deliverable is described as "a report" | You're buying a document, not a decision |
| Studio won't commit to a fixed scope for discovery | They're hedging against overrun at your expense |
| No build-vs-buy step in the discovery plan | Studio has already assumed you're building |
| MVP definition grows during discovery | Scope isn't being managed — it's being accommodated |
Comparing Discovery Approaches
Key Terms
Discovery theatre
A paid discovery engagement that produces presentation-layer outputs — slide decks, journey maps, options papers — without committing to a backlog, MVP scope, or delivery plan.
MVP (Minimum Viable Product)
The smallest deployable version of a system that delivers measurable value to real users. Defined by what is explicitly out of scope as much as what is in scope.
Scoping sprint
A compressed, time-boxed engagement (typically one to two weeks) that produces a prioritised backlog and MVP definition without the full ceremony of a multi-week discovery phase.
Quick Comparison
| Approach | Typical Output | Best For | Risk |
|---|---|---|---|
| Full Discovery (4–8 wks) | Backlog, architecture, MVP spec, delivery plan | Complex multi-role systems with integrations | Theatre if studio lacks discipline to cut scope |
| Compressed Scoping Sprint (1–2 wks) | Prioritised backlog, MVP definition, sprint plan | Focused B2B tools with clear workflows | May miss edge cases in complex regulatory environments |
| Brief-Only (Days) | Rough backlog, ballpark estimate | Simple internal tools or proof-of-concept | Scope drift likely without a formal backlog discipline |
| Discovery-as-Proposal (Common) | Slide deck, options paper, another proposal | No use case — avoid this pattern | No actionable output; money spent on more selling |
Frequently Asked Questions
How long should a software discovery phase take?
For most B2B operator tools, one to three weeks is sufficient if the studio is disciplined. Four to eight weeks is appropriate only when there are multiple user roles, complex integrations, or significant compliance constraints. Anything longer without a clear output commitment is a warning sign.
What is the difference between discovery and a scoping call?
A scoping call is a structured conversation — usually one to three hours — to establish brief, constraints, and rough scope. Discovery is a paid, multi-week engagement that produces a full backlog, MVP definition, and delivery plan. Both have their place; the right choice depends on project complexity.
Should I pay for discovery before committing to a build?
Usually yes, for anything beyond a simple internal tool. A proper discovery phase lets you validate assumptions cheaply before committing to build costs. The risk is paying for discovery that produces no actionable output — which is why you should define the deliverables contractually before you start.
How do I know if a discovery phase has produced useful outputs?
You can answer yes to four questions: Is there a sized, prioritised backlog? Has a build-vs-buy decision been made and documented? Is the MVP defined with explicit out-of-scope items? Is there a delivery plan with milestone dates? If any of those are missing, the discovery is incomplete.
Can AI tools shorten the discovery phase?
Yes. AI-assisted studios can use tooling to generate first-draft user stories, surface comparable system patterns, and automate parts of the brief analysis — compressing the manual effort in discovery without skipping the discipline of scoping. This is one reason AI product studios can sometimes move from brief to backlog in days rather than weeks.
How Samvara researches this guide
We write for exhibition organisers and import/export operators in the UK and Australia. Guides favour specific, verifiable operational advice over generic tips — grounded in systems we have shipped, client workflows, and current industry practice. We revisit articles as tooling and regulations change.
Sources
- UK Government Digital Service — Service Manual: Discovery — GDS definition of discovery outputs and phase gates, widely referenced in UK digital procurement.
Written by
Shreyansh Doshi, Founder of Samvara
Shreyansh Doshi is the founder of Samvara Technologies, a product studio building operator software and SaaS products for exhibition, import/export, travel and fitness businesses in the UK and Australia. He writes about product delivery, operations systems, and where AI does and does not belong in a real workflow.
Keep Reading
More in Build vs Buy
