Every project at inviqon begins the same way: a discovery sprint before any design or development work starts. This is not a formality — it's the most high-leverage work we do. The decisions made in a discovery sprint shape every design and engineering decision that follows.
This post explains exactly what happens in a discovery sprint, why we do each step the way we do, and what clients walk away with at the end.
Why we insist on discovery
The most common objection to a discovery sprint is that clients already know what they want to build. "We have a clear brief, we've been thinking about this for a year, we just need execution."
We've never worked on a project where discovery didn't change something material. Not because our clients don't know their business — they almost always do — but because the discovery process surfaces specific things that a brief can't:
- How real users currently solve the problem (which is often different from how stakeholders assume they do it).
- Technical constraints that affect what's feasible in the proposed timeline and budget.
- Conflicting stakeholder assumptions that aren't visible until they're explicitly surfaced.
- The feature that everyone assumed was simple but is actually complex.
Discovery costs 1–2 weeks. The cost of discovering these things in week 10 of a 12-week build is much higher.
Day 1–2: Stakeholder alignment workshop
The first activity is a structured workshop with the project's key stakeholders — typically 3–6 people from the client side.
The workshop covers:
Vision and success criteria. What does the product need to do? What does success look like in 3 months, 6 months, 12 months? What metrics will we track? This surfaces assumptions and, often, disagreements that need to be resolved before development begins.
User definition. Who specifically is this product for? We push for specificity: not "operations teams" but "operations managers at companies with 20–100 employees who are currently using spreadsheets and get paid to reduce errors." The more specific the user definition, the more useful everything that follows.
Constraints. Timeline, budget, technical environment (what systems must integrate?), regulatory requirements, team availability. Constraints are not problems — they're data that shapes the solution.
Assumptions and risks. What do we believe that, if wrong, would change the plan? Surfacing assumptions explicitly lets us design validation steps around the riskiest ones.
The output: a shared understanding document that everyone has reviewed and agreed on. This becomes the reference point for all subsequent decisions.
Day 2–5: User research
We run 5–8 interviews with real users or potential users of the product. Not surveys — 45-minute video conversations.
The goal is not to validate the proposed solution. It's to understand the current state: what users do today, how they do it, where they struggle, and what they would need for a new solution to be worth switching to.
What we listen for:
Workarounds. When someone says "I export it to a spreadsheet and then..." or "I have to manually check this every morning..." — these are gold. Workarounds reveal where existing tools are failing and where new software can create real value.
The job-to-be-done. Not "I need a dashboard" but "I need to know by 8am if any shipments are late so I can deal with them before customers call." The job-to-be-done tells you what success looks like from the user's perspective.
Decision triggers. What information does a user need to make a decision, and when do they need it? B2B software often fails because it provides the right information at the wrong moment in the workflow.
After the interviews, we run a synthesis session: sorting insights by theme, identifying patterns, and translating raw interview notes into actionable implications for the product.
Day 3–6 (parallel): Technical discovery
While user research is happening, we run a parallel technical investigation:
- Architecture assessment of any existing systems that need to integrate.
- Data model sketch based on what we've learned from stakeholders.
- Technology selection rationale.
- Infrastructure and deployment requirements.
- Identification of technical risks and unknowns.
The technical discovery informs timeline accuracy and flags anything that might affect scope — for example, a legacy API that doesn't support the integration approach assumed in the brief.
Day 5–8: Solution design
With user research synthesized and technical constraints mapped, we move into solution design. This is not UI design — it's information architecture and workflow design.
User journey maps for the 2–3 core workflows the product must support. These show the steps from trigger to completion, where information is needed, and where decisions happen.
Wireframes or sketches of the key screens. Not polished, but clear enough to test the structural assumptions.
Feature prioritization. Using the Now/Next/Later framework: what's in for launch, what comes in the next iteration, and what's explicitly deferred?
The goal is to have a proposed product structure that's specific enough to estimate and validate before we design high-fidelity UI or write production code.
Day 7–10: Prototype and validation (when appropriate)
For new products or significantly redesigned features, we build a clickable prototype in Figma and test it with 3–5 users before finalising the scope.
This step sounds like it adds time. It saves it. A prototype test takes 2 hours of user time and 1 day of design time. It routinely reveals assumptions that would have required 2–3 weeks of engineering rework to fix post-build.
What we test in a prototype session:
- Can users navigate the proposed structure without guidance?
- Do users understand what each screen is for?
- Do users know what to do when they encounter the core use case?
We're not looking for polish feedback. We're looking for structural problems.
The discovery deliverables
At the end of a discovery sprint, clients receive:
Problem definition. A clear, specific statement of the problem the product is solving, validated against user research.
User personas. 2–3 specific user archetypes with their jobs-to-be-done, current workflows, and pain points.
Product scope. What will be built in version one, with acceptance criteria. Explicit out-of-scope decisions with rationale.
Prioritised roadmap. What's in Now, Next, and Later, with the reasoning for each decision.
Technical architecture proposal. Tech stack, data model sketch, infrastructure approach.
Success metrics. How we'll know this worked. Specific, measurable, owned by specific people.
Timeline and cost estimate. With confidence intervals — not a single number, but a range that reflects known unknowns.
This document is the foundation of the build. When a scope question comes up in week 6, we reference the discovery document. When a stakeholder asks why we made a particular decision, the answer is in the discovery document.
Discovery is not overhead. It's the work that makes everything else faster.
inviqon runs discovery sprints for B2B startups and scale-ups. See our product strategy service.
