Written by:
Last Published:
5 November 2026
•
The product discovery process is the short, structured phase before development in which you and your agency decide what to build, in what order and at what cost. Is that a polite way of billing before building? No. Done properly, it is a modest early cost set against the much larger cost of building the wrong thing.
Think of surveying the ground before pouring foundations. Nobody enjoys paying for a survey. Everybody enjoys it more than finding a spring under the kitchen floor. Product discovery does the same job for software: it surfaces the hidden problems while they still cost a conversation, not a rebuild.
This guide is written for the person buying the work: the founder, product owner or executive who signs off on scope and budget, rather than the people building it. It explains the process in practice, not in theory. The version we describe is Imaginary Cloud's own Scoping Session, so you are looking at a real process, not a generic one.
Product discovery turns an idea into decisions before money goes into code. In a Scoping Session, project managers, developers and designers work with your team through three phases (the business case, the user and the technical plan), and you leave with a scope, prioritised features, personas, a high-level architecture, named dependencies, a project plan and a cost estimate. Its value lies in what it prevents: scope drift, unreliable estimates and late surprises. The best test of a good discovery is whether another team could build from its output.
Product discovery is the work of deciding what to build, and whether to build it at all, before development starts. With an agency, it is a short, structured collaboration that turns an idea into a scope, a prioritised feature list, a technical approach and a cost estimate.
So, what is product discovery in plain terms? It is the decision-making half of product work. Teresa Torres of Product Talk describes it as a decision-making process, separate from delivery, which is the building, shipping and maintaining. Marty Cagan, writing for SVPG, frames its goals as finding out whether real users want the product and whether you can build something usable, useful and feasible.
Plus, what it is not. It is not design (though design feeds into it). It is not a quote (though a cost estimate comes out of it). And it is not a guarantee that the idea is a good one.
Sometimes the most valuable outcome is a clear "not yet". That is a result, not a failure.
You do not need a polished brief. You need honest answers to a handful of questions: what problem you are solving, for whom, under which constraints, and who decides. The more of this you can discuss in the first session, the fewer assumptions end up inside the scope.
None of this is a formal entry requirement. It is simply the material the conversation runs on. Bring what you have, and say plainly what you do not know.
One more thing to prepare, and it is not a document. Prepare to be challenged. A good discovery session questions the idea, and an organisation that is open to that gets far more from it.
Imaginary Cloud's Scoping Session has three phases: Analysis, Discovery and Planning. It brings together project managers, developers and designers, and it moves from the business case, to the user, to the technical plan.
The session is built around a user-centred approach, combining project management planning with developer and designer expertise. Here is what each phase involves, what you do, and what you take away.
The team starts with the idea itself. Together you clarify the business requirements, set the project timeline, list the main competitors, sketch high-level personas (fictional but evidence-based profiles of your typical users) and define the main objectives. This is where the questions in your preparation list get used.
What you do: explain the idea, the goals and the constraints, and answer the awkward questions about the business case.
What it sets up: the business case and objectives that frame the next two phases.
Now the focus moves from the business to the people using the product. Your team and ours build user personas together, to understand how those users will interact with the product. We then list and prioritise user stories, which are short descriptions of what a user needs to do and why. The ranking is based on the product's lifecycle stage and on user and product goals, and the output becomes the basis for the development plan.
What you do: contribute what you know about your users, and take part in the prioritisation. This is where you decide what matters most, and what waits.
What it produces: user personas, and prioritised user stories and features.
The last phase turns priorities into a technical approach. The team identifies and prioritises the main features, designs a technical solution that balances complexity against reach, and maps the external dependencies on third-party providers, such as payments, social login and cloud services.
What you do: confirm priorities, flag constraints on tools and infrastructure, and react to the proposed approach.
What it produces: a high-level architecture, a list of third-party dependencies and a project plan with time planning and a cost estimate.
Imaginary Cloud does not publish a fixed length for the Scoping Session, and that is sensible, because it depends on how clear your idea is and how complex the product is. For context, the UK Government's Service Manual says that a discovery phase typically lasts around four to eight weeks, shorter for familiar problems and longer for new ones. That guidance is written for public services, so treat it as a reference point, not a promise. Ask your agency for a timeline specific to your project.
A good product discovery process ends with documents you could build from, or take to another team. You should receive a project scope and roadmap, prioritised features and user stories, personas, a high-level architecture, a list of dependencies, a project plan and a cost estimate.
That list matches what Imaginary Cloud's Scoping Session delivers. To judge the quality, use what we call the hand-over test: could a different, competent team read these documents and price and build the product without a single clarifying call? If the answer is no, something is missing or vague. Run these four checks before you accept the output as done:
A good discovery also leaves your own side aligned. Look for outputs that stakeholders can sign off, such as an agreed priority order and a shared definition of the first release. If the people who fund the project and the people who use the product disagree about what "done" means, discovery is the cheapest place to find out.
Then discovery has done its job. A discovery that ends in "not as planned" or "not yet" saves you the cost of finding that out in development. Your options are to change the scope, test a smaller version first, or stop.
The UK Government's guidance makes the same point: discovery ends with a decision about whether to move forward, and stopping at that point is a legitimate outcome. What you keep matters too. The research, personas, priorities and technical findings stay with you, and they usually shorten the next attempt.
Agree this in advance. Ask your agency what happens if discovery changes the direction of the project, and how the next step is scoped and priced.
Discovery protects your budget by turning unknowns into decisions before development spend starts. Scope, priorities and technical dependencies are settled on paper, where changing your mind is cheap, rather than in code, where it is not.
Here is the mechanism, in three parts.
First, scope stops drifting. When features are listed and prioritised against user and product goals, "while we are at it" additions have to justify themselves. Effort goes where it matters most.
Second, the estimate rests on something. A cost estimate built from prioritised features and a defined architecture is a more reliable business forecast than a guess from a one-paragraph brief. Imaginary Cloud's own page describes early planning as a way to identify focus areas and avoid extra costs and delays.
Third, risks surface early. A payment provider that does not support your market, a login method your users do not have, a feature that is far harder to build than it looks: all of these are cheaper to find in Planning than in sprint nine.
We cannot give you a percentage saving, and we would be wary of anyone who does. The saving depends on how many wrong turns discovery prevents, and you only see those in hindsight.
What we can say is that the logic is long established. The Design Council's Double Diamond, a design framework with four stages (discover, define, develop and deliver), puts the first two ahead of the last two, in that order. Jakob Nielsen's research on usability argues for several small rounds of testing with redesign in between, instead of one big study.
Two public Imaginary Cloud case studies show the method at work, without claiming numbers their pages do not give. On Aurora Analytica, a clinical trial analytics platform, product owners, developers and designers agreed features and priorities within an MVP approach (a minimum viable product, the smallest version that lets you test an idea with real users), and design choices were checked against technical feasibility. On VestaConnect, a care coordination platform, an MVP was tested with beta users, their feedback informed the roadmap, and the product later moved from beta to a paid model. You can browse more in our case studies, and read about our MVP approach.
For an executive, discovery is a way to commit capital in stages. You pay a modest amount for better information, then decide whether to fund the full build. That lowers risk, improves the reliability of the forecast and can shorten the time to first value.
Here is how that maps onto the concerns a board or a finance lead will have.
To make the case in your own organisation, use your own numbers. What did the last project that changed direction mid-build cost? What does a missed sprint cost in team time and delayed revenue? Discovery will not remove those risks, but it moves the biggest questions to the point where answering them is cheapest.
Judge it on what you will hold in your hands and how the agency works with you, not on the sales presentation. Ask for the deliverables in writing, find out who will be in the room, and check what happens if discovery changes the plan.
Whatever agency you shortlist, these questions separate a real discovery from a long sales call:
Imaginary Cloud's Scoping Session is staffed by project managers and developers, with designers on the UX and interface work. It includes a cost estimate and a project plan. Imaginary Cloud then works in two models: team extension and managed projects.
Not every project needs the full product discovery process. A small, well-understood change to an existing product may need a conversation, not three phases. The risk is at the other end: a fuzzy idea that skips discovery and learns its lessons in development.
A lighter approach makes sense when the problem is well understood, the users are known, the technology is familiar and the change is contained. If you are unsure, ask the agency to say which phases you can shorten, and what risk that leaves open.
The most common mistakes are skipping discovery because the idea feels clear, treating the estimate as a fixed price, leaving decision-makers out and holding back constraints. All four are avoidable with a little preparation.
Product discovery is the work of deciding what to build, and whether to build it, before development starts. With an agency, it combines business analysis, user research and technical planning into a scope, a prioritised feature list and a cost estimate you can act on.
It is the stage at the start of a project, before development, in which you test your assumptions about the problem, the users and the technical approach. It ends with a decision to proceed, adjust or stop, and with the documents needed to plan the build.
A Scoping Session covers three phases: Analysis of the business case, Discovery of users and priorities, and Planning of the architecture and project. It produces a scope and roadmap, prioritised features and user stories, personas, a high-level architecture, a list of dependencies, a project plan and a cost estimate.
Agencies use different names for the same idea: discovery sprint, workshop, phase or scoping session. What matters is the output. Ask for the deliverables in writing, and check them against the list above: scope, priorities, personas, architecture, dependencies, plan and estimate.
It depends on the complexity of your product and how clear your idea is. Imaginary Cloud does not publish a fixed duration. UK Government guidance for public services suggests around four to eight weeks as a typical range. Ask your agency for a timeline for your project.
Imaginary Cloud does not publish a price. The session includes a time plan and cost estimate for your project, and you can request a quote through the business development team. Costs vary with the scope of the product, so the quote is the reliable answer.
Apply the hand-over test: could another competent team build from the documents without asking questions? Check that features are prioritised, dependencies are named, the estimate states its assumptions, and the session ends with a clear decision to proceed, adjust or pause.
Ask what you will receive and in what format, who will attend, how the session is run, what the estimate assumes, who owns the output and what happens if the plan changes. Also ask to speak to a client who has been through the same process.
Often, yes. Designs show what the product looks like, not whether the scope is prioritised, the architecture is sound or the third-party dependencies are mapped. The Planning phase covers those. If your designs are solid, discovery can be lighter, not skipped.
You decide whether to proceed. If you do, the scope, roadmap and project plan become the basis for development. Imaginary Cloud works in two models: team extension, where developers join your team, and managed projects, where we build it in-house with our own processes.
The product discovery process is a low-risk way to find out what your idea really needs, and what it will take. If you have a product in mind and want to see what a Scoping Session would look like for it, you can read about the Scoping Session or talk to our team. Bring the idea, the constraints and the awkward questions. We will bring the plan.
Alexandra Mendes is a Senior Growth Specialist at Imaginary Cloud with 3+ years of experience writing about software development, AI, and digital transformation. After completing a frontend development course, Alexandra picked up some hands-on coding skills and now works closely with technical teams. Passionate about how new technologies shape business and society, Alexandra enjoys turning complex topics into clear, helpful content for decision-makers.
People who read this post, also found these interesting:
.webp)
