At Kormoan, Product Discovery conversations often begin when a team already feels ready to build. The idea has momentum, requirements have started taking shape, and there is pressure to move into design or engineering. At that point, spending another few weeks questioning the concept can feel like slowing down a project that finally has energy. Yet this is also the moment when some of the most expensive assumptions are still relatively cheap to challenge.
Working across discovery, product design, and engineering has shaped how we think about this stage. A requirement that looks reasonable in a roadmap can behave very differently once it becomes a user journey, and differently again once engineering constraints enter the conversation. This is why we do not see Product Discovery as a preliminary exercise before the “real” work. For us, it is where a team decides which assumptions are strong enough to deserve the cost of becoming software.
Product Discovery is not the phase before the real work
When organisations ask what is Product Discovery, the usual definition involves understanding users, defining problems, and validating ideas before development begins. That is accurate, but it makes discovery sound more procedural than it really is. Every new product starts with beliefs: that a particular customer has a problem, that the problem matters enough to change behaviour, and that a certain product or workflow can solve it within realistic business and technical constraints.
Some of those beliefs will survive contact with customers. Others will not, and no amount of discovery can remove that uncertainty completely. Interviews have limitations, prototypes cannot recreate every real-world condition, and markets continue changing after research ends. The purpose is not to create certainty. It is to identify the assumptions that would be particularly expensive to discover were wrong after months of Product Design and engineering.
This has led to a useful Kormoan POV: discovery should not leave a team with more ideas; it should leave them with fewer assumptions that are expensive to be wrong about. That distinction changes the role of research, workshops and prototypes. They are not activities to complete because a process requires them. They exist to improve the decisions that design and engineering will eventually have to commit to.
Expensive product decisions often look perfectly reasonable
Bad product decisions rarely look obviously bad when they are made. A large prospective customer asks for a feature, so it enters the roadmap. A competitor introduces a new capability, and suddenly an equivalent feature feels necessary. Leadership has spent months studying the opportunity and has developed a strong opinion about what customers will want. Each decision has logic behind it; trouble begins when assumptions start accumulating faster than evidence.
One of the hardest conversations during discovery is questioning an idea after people have already invested significant time in believing it. Progress is naturally associated with visible things: prototypes, interfaces, development sprints, and working features. Discovery can feel less satisfying because sometimes its most valuable outcome is deciding that something everyone expected to build does not deserve to be built yet.
Design can unintentionally make that problem harder. Once an assumption becomes a polished prototype, it starts feeling more certain simply because people can see and interact with it. This is why we rarely agree with moving every product immediately into a detailed UI. Sometimes, a rough prototype, a mapped workflow, and several carefully chosen customer conversations can reveal more than weeks spent making an uncertain idea look finished.
Discovery changes what an MVP is expected to do
Almost every early product team wants an MVP. Far fewer want to remove enough functionality to create one. Sales has features it needs for prospective customers, operations has administrative requirements, leadership sees strategic opportunities, and engineering understands foundations that may eventually become necessary. Everything appears important because, over the lifetime of the product, much of it probably will be.
Discovery forces a different conversation. Instead of asking what the team wants in version one, we prefer asking what version one needs to teach the team. If the largest uncertainty is whether customers will change an established behaviour because a new workflow saves significant time, the MVP should make that behaviour testable. It does not necessarily need every reporting, administration, or personalisation feature that the mature product may eventually contain.
This sounds straightforward until something has to be removed from the roadmap. That is where discovery becomes an exercise in judgment rather than documentation. A focused two-to-four-week process can turn those decisions into something operational: a validated concept, clearer requirements, a Product Requirements Document, an MVP roadmap, and an initial effort estimate. The artefacts matter because they preserve decisions; the thinking behind them matters more.
Skipping discovery does not mean discovery disappears
The cost of Product Discovery is visible. Two to four weeks of research, workshops, prototyping and planning appear clearly on a project timeline, while beginning development immediately appears faster. What is less visible is the discovery that still happens after launch, when actual customer behaviour starts challenging assumptions that were never investigated earlier.
Users misunderstand onboarding, so the journey is redesigned. A workflow does not match how customers actually work, so functionality changes. Adoption remains weak, prompting research that could have happened before development. The organisation eventually performs discovery anyway; it simply performs it through software that has already been designed, engineered, tested and integrated into the rest of the product.
This is another finding that has shaped how we approach product work at Kormoan: when discovery is skipped, uncertainty tends to move downstream rather than disappear. Once it reaches UX, engineering or production, the same question becomes more expensive to answer because more decisions now depend on it. A prototype can be discarded relatively easily. Production software carries technical dependencies, development cost and internal commitment.
AI has made discovery more important, not less
Artificial intelligence has dramatically expanded what product teams can imagine. Products can generate content, summarise complex information, recommend actions and automate workflows that previously required direct human involvement. As those capabilities become easier to prototype, the temptation is understandable: teams begin with the AI feature and work backwards toward the user problem.
We see a different question emerging through Design for AI and AI Product Strategy: where does intelligence genuinely improve the user’s ability to make progress? A conversational interface may look sophisticated while making a predictable task slower. Automation may eliminate several steps but remove human judgment at precisely the moment it matters. An AI recommendation can be technically accurate while remaining unused because customers do not understand why they should trust it.
For AI products, discovery therefore has another responsibility. Teams need to investigate not only whether a capability can be built, but whether people want it to behave that way, how much control they are willing to give it, and what happens when the system is uncertain. Model capability is a technical question. Whether that capability belongs in the experience is still a product question.
Product Discovery is where Product Design begins
It is convenient to imagine strategy deciding what should be built, and Product Design deciding how it should look and work. Real product development is rarely that orderly. A customer interview can change the strategy, a prototype can expose a weak business assumption, and an engineering constraint can reveal a simpler experience than the original requirement suggested.
At Kormoan, this is why Product Discovery is closely connected with the work that follows rather than being treated as an isolated stage. Decisions made here eventually influence UX, information architecture, design systems, engineering priorities and how the product will be measured after launch. The same thinking matters in SaaS Product Design and Website Design & Redesign, where what appears to be an interface problem can sometimes reveal a deeper issue with the underlying journey.
Working across those stages also makes the cost of unresolved assumptions easier to see. Early ambiguity is relatively flexible: a workflow can change, a prototype can be discarded, and a requirement can be rewritten. Once the same ambiguity becomes part of architecture and production software, changing it involves considerably more people, dependencies and investment.
Good discovery should still leave questions unanswered
A strong discovery process should not produce the illusion that every question has been resolved. Markets change, customers surprise us, technical possibilities evolve and products behave differently once real people begin using them at scale. Trying to predict everything in two or four weeks would simply replace uncertainty with overconfidence.
The judgement lies in deciding which questions need answers now and which can safely remain open. Some decisions are expensive to reverse and deserve investigation before development begins. Others can be learned through the product itself without creating significant risk. Research provides evidence, but evidence rarely arrives with priorities attached; someone still needs to interpret conflicting signals alongside business realities and technical constraints.
This is why the best outcome of Product Discovery is not a perfectly resolved roadmap. It is a team that understands where it is confident, where it is still making assumptions and which of those assumptions matter enough to test before committing further.
Final Thought
The value of Product Discovery can be difficult to demonstrate because some of its best outcomes leave almost nothing visible behind. A feature disappears before engineering starts. A workflow becomes simpler before UI is designed. An assumption is challenged before customers have to expose the mistake. There is no launch announcement for the development work that never needed to happen.
At Kormoan, working across discovery, design, and engineering has made that invisible work increasingly important to us. Discovery is not valuable because it guarantees that every product decision will be correct. It creates a small space where changing your mind is still relatively inexpensive, before ideas harden into interfaces, architecture, and commitments that become much more difficult to reverse.
Perhaps the question is not whether a team can afford a few weeks to understand what it should build. It is how much it is prepared to spend on discovering the same answer later.
