The Discovery Phase for SaaS Products: What Happens Before Anyone Opens Figma

A SaaS company spent eight months and $340,000 building a reporting module. It launched. Two percent of users opened it in the first month. Post-launch interviews revealed that the users the product was built for — operations managers — had their reporting needs fully covered by a spreadsheet export they’d set up two years ago. Nobody had asked them.

That is not a development failure. It is a discovery failure. The most expensive version of building the wrong thing is the one where you build it all the way to launch before you find out.

Discovery is not a slower start. It is the cheapest place to be wrong. A flow change in a Figma file costs hours. The same change in a shipped codebase costs weeks. This article covers what discovery actually produces, how long it takes, what it costs, and how to judge whether an agency’s discovery proposal is genuine or theater.

---

What a Discovery Phase Is (and What It Is Not)

Discovery vs Requirements Gathering

Requirements gathering is a documentation exercise. Someone describes what they want. The output is a specification. The specification is then built.

Discovery is an investigation. The starting question is not “what do you want to build?” but “what problem are you actually solving, for whom, and how do you know?” Requirements gathering assumes the problem is understood. Discovery tests that assumption before committing to a solution.

A requirements document says “users need a dashboard with five widgets.” A discovery process asks why those five widgets, whether users actually use dashboards, and what decision the dashboard is supposed to help users make. The answers are frequently different from the requirements.

Discovery vs a Design Sprint

A design sprint — the Google Ventures format — is a five-day intensive that produces a tested prototype of a specific solution. It is useful when the problem is understood and the goal is to prototype and test a solution quickly.

Discovery is broader and slower. It investigates whether the problem is real, who has it most acutely, and what constraints any solution must operate within. Running a design sprint in place of discovery assumes the problem definition is correct — which is exactly the assumption discovery is meant to test.

The Three Risks Discovery Is Meant to Reduce: Value, Usability, Feasibility

Every SaaS product fails for one of three reasons: it doesn’t solve a problem people have (value risk), it solves the problem but nobody can figure out how to use it (usability risk), or it can’t be built within available technology and resources (feasibility risk).

Discovery addresses all three before significant development investment is made. Week one typically addresses feasibility and constraints. Week two addresses value risk through user research. Week three addresses the competitive landscape. Week four produces the scoped, prioritized output that development can begin from.

The Discovery Process, Week by Week

Week 1 — Business Model, Constraints and Success Criteria

The first week is internal. The goal is to align on what success looks like before any research is conducted.

This includes: the business model and how the product makes money, the technical constraints (existing systems, APIs, infrastructure), the budget and timeline constraints, the regulatory context if relevant, and the definition of success — specifically, what metrics will be different in twelve months if the product works.

This week produces a constraints document and a success criteria framework. Without it, research and design are conducted without a filter for what actually matters to the business.

Week 2 — User Research and Jobs to Be Done

Week two involves talking to the people the product is being built for. Typically five to eight interviews with users or potential users in the target segment — enough to identify patterns without over-indexing on individual responses.

The framework that produces the most useful output for SaaS product design is Jobs to Be Done (JTBD): what job is the user trying to accomplish, what are they currently using to accomplish it, what is frustrating about the current solution, and under what circumstances would they switch.

This week produces user archetypes (behavior-based descriptions of how different user types approach the problem), a jobs-to-be-done map, and a documented set of unmet needs ranked by frequency and severity.

Week 3 — Competitive and Solution Landscape

Week three maps the existing solution landscape: what alternatives users currently use, what those alternatives do well and poorly, where the gap is, and what your product needs to do better to earn adoption.

This is not a feature comparison table. It is an analysis of how each alternative earns and loses users, and what the switching trigger is. A SaaS product entering a market where users are deeply embedded in an incumbent needs a different strategy than one entering a market served by spreadsheets and manual processes.

This week produces a competitive positioning map and a differentiation brief — a clear statement of what your product does better than the available alternatives for the specific user segment you’re targeting.

Week 4 — Scope, Architecture Direction and Roadmap

Week four synthesizes the previous three weeks into actionable output: a validated problem statement, a prioritized feature scope, a technical architecture direction, an integration map (what third-party systems the product needs to connect to), and a costed roadmap.

The prioritized scope is organized by impact on the validated user jobs and constraints. Features that don’t map to a validated user job are deprioritized or cut. Features that map to the highest-frequency, highest-severity user needs are in scope for the first release.

How the Timeline Changes for a Complex Platform

A four-week discovery process is appropriate for a focused SaaS product with a reasonably understood user base. Multi-sided platforms require a longer process because each side has separate user research, separate jobs, and potentially separate technical architectures.

A marketplace discovery process typically runs six to eight weeks: two weeks per distinct user type plus synthesis and scoping. Compressing this produces a discovery output that has mapped one side of the market well and guessed at the other.

What You Actually Get at the End

Validated problem statement and success metrics. A one-page document describing the problem, who has it, how you know it’s real, and what measurable outcomes define success. This is the filter every subsequent product decision is evaluated against.

User flows and information architecture. How users move through the product to accomplish their primary jobs, and how information is organized. This is the foundation of UI/UX design for SaaS — not a wireframe, but the structure wireframes are built from.

Clickable prototype or lo-fi wireframes. A testable representation of the primary flows. Rough enough that users respond to the structure rather than the aesthetics. This is the artifact that gets tested with users before any production code is written.

Technical feasibility notes and integration map. A documented assessment of the technical approach, the third-party integrations required, and any constraints or risks in the proposed architecture. Specific enough to inform scoping without being a full technical specification.

Prioritized scope and a costed roadmap. A phased breakdown of what gets built, in what order, and at what approximate cost. Phase one is what’s needed to test the core value proposition with real users.

A slide deck with research themes and opportunity areas is not a discovery deliverable. It is research without synthesis that doesn’t unblock any specific design or engineering decision.

What Discovery Costs and How to Judge the Return

Typical Cost and Duration by Product Complexity

For a focused SaaS product with a defined user base: four weeks, $15,000–$30,000. This covers stakeholder alignment, five to eight user interviews, competitive analysis, lo-fi wireframes for primary flows, and a prioritized scope document.

For a multi-sided platform or a SaaS product with complex integrations: six to eight weeks, $30,000–$60,000. The additional cost reflects research across multiple user types and more complex technical feasibility assessment.

For an enterprise SaaS product with regulated use cases or significant compliance requirements: eight to twelve weeks, $50,000–$100,000+.

The Rework Arithmetic: Changing a Flow vs Changing a Codebase

The cost of changing a user flow in a Figma prototype is measured in hours. Moving a step in an onboarding sequence, adding a field to a form, removing a feature that turns out to be unnecessary — these are low-cost changes before development.

The same changes after development cost more by an order of magnitude. McKinsey research (2022) found that fixing defects after launch is five to ten times more expensive than fixing them during the design phase. Discovery makes the high-cost changes happen at the lowest-cost point in the project.

When Discovery Is Not Worth It

Discovery is not always the right investment. Three situations where it isn’t:

The problem is genuinely well understood. If you have already built version one, operated it with real users for six months, and have clear data on what’s not working, you need a product audit and a redesign brief — not a full discovery process.

The scope is deliberately narrow. If you are building a specific, well-defined feature for a user base you know well, a two-day workshop and a round of prototype testing may be sufficient.

Speed is the constraint and being wrong is recoverable. In some market contexts, getting something live quickly and learning from real usage is more valuable than a thorough pre-launch investigation. This requires that being wrong early is genuinely recoverable — which is rare in B2B SaaS where users have switching costs.

Running Discovery Well

Who Needs to Be in the Room

Discovery requires three types of involvement from the client side: a decision-maker who can approve scope changes without escalating, a domain expert who understands the industry context and can evaluate whether research findings are real, and someone who talks to customers weekly and can validate or challenge what research surfaces.

Discoveries that involve only founders or only engineers routinely miss significant user context. Discoveries that involve only users miss significant business and technical constraints.

How Many Interviews Are Enough

Five to eight interviews with users in the same segment will surface the majority of patterns. Nielsen Norman Group research (2000, updated 2023) established that five users identify approximately 85% of usability problems in a given interface. Diminishing returns set in quickly after the first five to seven interviews.

If your product serves multiple distinct user types, you need five to eight interviews per segment — not per product.

Killing Your Own Idea: Making ‘Stop’ an Acceptable Outcome

Discovery should be capable of producing a “stop” recommendation — a finding that the problem isn’t real enough, the market is too small, or the technical constraints make the product unviable.

Most discovery processes are commissioned with an implicit assumption that they will produce a “build” recommendation. A genuine discovery process includes the explicit agreement, upfront, that a “stop” finding is a legitimate outcome — it is far cheaper than building the wrong product.

Red Flags in an Agency’s Discovery Proposal

• No user interviews in the proposed scope
• Deliverables described as “insights deck” or “research report” without specified design artifacts
• Timeline shorter than two weeks for any product with external users
• No mention of success metrics or how the discovery output connects to investment decisions
• Discovery scope doesn’t include any technical feasibility assessment
• No explicit process for incorporating findings that contradict the client’s assumptions

Conclusion

Discovery is the cheapest place to be wrong about what to build. The deliverables it produces — validated problem statement, user flows, clickable prototype, integration map, costed roadmap — are the foundation that every subsequent design and engineering decision builds from.

The arithmetic is straightforward: a $20,000 discovery process that prevents a $150,000 rebuild is a return that no other investment in your product cycle can match.

If you’re commissioning SaaS UI/UX design or a product build and want to understand what a genuine discovery process looks like for your specific product, book a scoping call. We’ll tell you whether discovery is the right investment for where you are. Learn more about us and how we approach product discovery.

FAQ

• What is a product discovery phase?

  A product discovery phase is a structured investigation before design or development begins. It reduces three risks: value risk (building something nobody needs), usability risk (building something nobody can use), and feasibility risk (building something that can’t be built within constraints). It produces validated problem statements, user flows, wireframes, and a prioritized scope.

• How long does a discovery phase take?

  For a focused SaaS product: four weeks. For a multi-sided platform with multiple user types: six to eight weeks. For enterprise SaaS with regulatory requirements: eight to twelve weeks. What drives the difference is the number of distinct user segments requiring separate research and the complexity of the technical integration landscape.

   

• How much does a discovery phase cost?

  Focused SaaS: $15,000–$30,000. Multi-sided platform: $30,000–$60,000. Enterprise SaaS: $50,000–$100,000+. Evaluate this against the cost of building the wrong thing. McKinsey research (2022) found that fixing defects after launch is five to ten times more expensive than fixing them during design. Discovery makes the expensive changes happen at the cheapest point.

• Can we skip discovery if we already have a spec?

  A spec answers what to build. Discovery answers why this, for whom, and whether the assumptions behind the spec are correct. Skipping is reasonable in one case: you have already built and operated version one and are redesigning based on observed behavior — not assumptions. In that case, a product audit is the more appropriate investment.

• What deliverables should a discovery phase produce?

  A validated problem statement, user flows and information architecture, clickable prototype or lo-fi wireframes, technical feasibility notes and an integration map, and a prioritized scope with a costed roadmap. A slide deck of research themes is not a discovery deliverable — it doesn’t unblock any specific design or engineering decision.

• Who should be involved from our side?

  Three roles: a decision-maker who can approve scope changes without escalating, a domain expert who understands the industry context, and someone who talks to customers weekly and can validate or challenge what research surfaces. Discovery conducted with only founders or only engineers routinely misses significant context that changes the output.