How we scope a discovery engagement
A look at the questions we ask before a single line of code is written.
May 9, 2026 · Zovelum Team
Every engagement we take on starts the same way: a discovery sprint before anything is built. It is the single highest-leverage investment a team can make, yet it is routinely skipped in favour of jumping straight to solutions. After running dozens of these across insurance, SaaS, fintech, and logistics, we have developed a consistent set of questions and outputs that make the rest of the project run measurably smoother.
Why discovery exists
Discovery is not a research exercise — it is a risk-reduction exercise. The goal is to surface the assumptions buried inside the project brief before they become surprises in production. Teams that skip it do not save the time; they spend it later debugging wrong decisions.
"The goal of discovery is not to answer questions — it is to find the right questions to answer."
A two-week discovery sprint typically costs 5–10% of a project budget and prevents decisions that would cost 40–60% to unwind later. That is not a consulting pitch; it is a pattern we have measured across our own engagements.
The five questions we always ask
We run stakeholder interviews, review existing systems, and work through a structured set of questions. These five appear in every discovery we run, regardless of industry or stack:
What does success look like in 12 months?
Business outcomes, not features. We push until we have a measurable definition — ticket volume reduced by X%, release cycle under Y days, revenue per user above Z. Vague success criteria produce vague products.
Who are the real users, and what do they actually do today?
Not personas from a deck — real people doing the job right now. We shadow users where possible, review support tickets, and map the actual workflow before designing anything new.
What are the sacred constraints?
Every project has constraints the team is embarrassed to mention — a vendor contract that cannot be broken, a data format that is impossible to change, a regulation that limits architecture choices. We surface these early.
What has already been tried?
Teams rarely start from zero. Understanding what was built and abandoned — and why — prevents repeating the same mistakes under a different name.
Who will own this after we leave?
Software that cannot be maintained by the people left holding it is a liability, not an asset. The answer to this question shapes every technology choice we make during the engagement.
What we produce
Discovery produces three things: a scope document, a risk register, and a prioritised backlog. The scope document captures what is in and what is out, with explicit reasoning for each. The risk register lists the assumptions we could not validate — not to paralyse the project, but to ensure those risks are consciously accepted. The backlog is sequenced by impact and learning value, not by feature size.
The deliverables in brief
- Scope document — what is included, what is explicitly excluded, and why
- Risk register — unvalidated assumptions with owners and mitigation plans
- Prioritised backlog — sequenced by impact × learning value, not by size
- Architecture decision records (ADRs) — the technology choices made and the reasoning
- Stakeholder map — who needs to be consulted vs. informed as the project progresses
How long does discovery take?
For most mid-size projects (3–9 months of build work), two weeks is the right investment. Larger enterprise programmes may need four to six weeks. We are wary of discovery sprints that stretch beyond that — they usually indicate the team is avoiding making decisions, not gathering more information.
The most common mistake
The most common failure mode is a discovery that produces a beautiful document nobody reads after it is written. Discovery outputs are living artefacts. The scope document should be on the project wiki, linked from every sprint planning session. The risk register should be reviewed monthly. If the outputs are not actively used to make decisions, the sprint was theatre, not process.
A note on timelines: Clients sometimes ask us to compress discovery because the deadline is immovable. We can run a lighter-weight version in one week, but we are honest about what that buys: a scope snapshot, not a full risk audit. That is sometimes the right trade-off — as long as everyone understands what is being skipped.
Questions we get asked
Do you run discovery for every project, even small ones?+
For projects under four weeks of build time, we usually compress discovery to two or three structured conversations rather than a dedicated sprint. The questions are the same; the formality is reduced.
What if the client already has a requirements document?+
We read it thoroughly before the first call. Requirements documents are useful for understanding what the stakeholders think they need. They are less useful for understanding what users actually need or what technical constraints exist. Discovery validates, challenges, and fills the gaps in that document.
Can discovery be done remotely?+
Yes — we have run effective remote discovery sprints across multiple time zones. The tooling (Miro, Notion, Loom for async walk-throughs) makes most of it straightforward. The one thing that is genuinely harder remotely is shadowing real users in their workflow. We compensate with recorded screen sessions and support-ticket analysis.