Product Discovery: What Should You Know Before You Start Designing?

Most digital products don't fail because a team couldn't build them. They fail much earlier. Someone assumed they understood the customer. Someone interpreted a business problem as a feature request. Someone designed the solution before validating the problem. Someone asked users whether they liked an idea and mistook polite enthusiasm for evidence. Someone spent six months building exactly what the client requested, only to discover the real problem was somewhere else. The development team did its job. The designers did their job. The project launched. And the product was still wrong.

This is the problem Product Discovery exists to address. Not to make a team absolutely certain about everything, that's impossible. Not to produce another large document nobody reads. And not to postpone development indefinitely. The purpose is much more practical: reduce the most dangerous uncertainty before it becomes expensive to change. A digital product should not begin with a screen. It should begin with evidence.

A workshop can be part of discovery. A workshop is not discovery.

NOT A MEETING

Discovery Is Not a Meeting

One of the most common misconceptions is that discovery is a workshop, a room, a Miro board, a few sticky notes, a handful of stakeholders, and two hours later someone produces a customer journey and calls the project "discovered." That isn't discovery. A workshop can be part of it. So can an interview, research, or a prototype. But discovery itself is a process of reducing uncertainty and changing decisions based on what you learn.

That last part matters. If research produces twenty pages of findings and nothing about the product changes, the team may have conducted research. It hasn't necessarily conducted meaningful discovery. A useful way to think about it: question, evidence, interpretation, decision. Something is discovered when the evidence changes what the team believes it should do. A feature gets removed, a target audience shifts, a workflow simplifies, an assumption gets rejected. Occasionally the most valuable discovery is simply: we should not build this. That isn't a failed project. It may be the most successful outcome of the entire process.

PROBLEM FIRST

The Problem Before the Solution

Most projects arrive with a solution already attached. "We need a new website." "We need a mobile app." "We need a CRM." "We need AI." Those statements may be correct. They may also be completely wrong. A business rarely describes its situation in pure problem language, people naturally describe what they think the answer should be. A sales team doesn't usually say "we have an information flow problem between lead qualification and account ownership," they say "we need a better CRM." A customer doesn't say "our information architecture creates unnecessary cognitive load," they say "I can't find what I'm looking for."

If you accept the proposed solution too early, discovery becomes a search for evidence that justifies the solution you already decided to build. That's backwards. The first question is what is actually happening. Only then, why is it happening. And only after that, what might be worth changing.

The Medpresso medical education platform began exactly this way, as a website redesign for a diagnostic center. The doctors were exceptional, their reputation was growing, and they believed they needed a better website. They were partly right. What they actually needed was a better way to communicate who they already were. That distinction, uncovered before any design work started, is what eventually let the relationship grow into a full educational platform used by thousands of doctors, not just a nicer version of the original request.

WHAT IT FINDS

What Discovery Is Actually Trying to Find

A useful discovery process doesn't try to learn everything, that's impossible. It looks for information that can materially change the product's direction, usually across several categories. The people: who actually experiences the problem, who decides, who uses it, who pays, who operates the system internally, sometimes five different groups. The problem: what happens today, what makes it difficult, how often, who's affected, what it costs. The context: when the problem appears, what surrounds it. The current workaround, particularly important, since a spreadsheet, an email chain, or a WhatsApp conversation that looks ridiculous from the outside may exist because it solves something the proposed product hasn't understood yet. The business impact: why solving this actually matters. And the assumptions, possibly the most important category, since discovery isn't about proving the team is right, it's about finding where the team might be wrong.

START WITH ASSUMPTIONS

Start With Assumptions, Not Questions

Before conducting interviews, a strong team writes down what it currently believes: customers abandon checkout because the process is too long, dealers need a mobile inventory interface, enterprise buyers need individual pricing, users want AI recommendations. These are hypotheses, not facts, and that distinction matters. Once assumptions are explicit, they can be ranked by importance, uncertainty, and cost of being wrong. A minor assumption with low impact doesn't deserve a two-week research project. A fundamental assumption about who will use the product may deserve the very first conversation. This is one of the ways discovery stays practical instead of becoming research for its own sake.

INTERVIEWS

Interviews Are Powerful, and Easy to Get Wrong

The biggest mistake is asking people to predict the future. "Would you use this?" "Would you pay for this?" These questions produce optimistic answers, because people are generally polite, want to be helpful, and may genuinely believe they'd use something without that proving they will. A much better starting point is the past: tell me about the last time this happened, what were you trying to do, what did you do next, what was frustrating. Past behavior is evidence. Future intention is a hypothesis.

The people interviewed matter just as much as the questions. Interviewing only executives, friends, or people who already like the concept is a common failure, those conversations are useful but not automatically representative. A customer has one perspective, a salesperson another, an operations manager a third, and an administrator dealing with exceptions nobody else sees may hold the most important information of all. For B2B products this gets more interesting still, the person buying the system may not be the person using it, and the person approving the purchase may not be the person suffering from the current process. Stakeholder conversations reveal something different again, organizational reality: which teams are involved, where handoffs happen, which decisions are political rather than technical. A technically elegant product can fail because the organization can't adopt it, so discovery has to understand the organization around the product, not only the end user.

The ongoing Schoeffel digital transformation, a century-old luxury pearl jewelry house, shows how far this can extend. The stakeholders span brand leadership, a regional business partner, and an international team, across different disciplines and time zones, each holding a different piece of what the business actually needs. Discovery there isn't a phase that finished before design started, it's continued alongside the work, because a transformation at that scale keeps surfacing organizational reality nobody could have mapped in a single workshop.

WATCH THE WORK

Watch the Work, Don't Just Ask About It

There's a real difference between "how do you process a lead" and "show me what you did with the last lead that came in." The first produces a description. The second produces evidence, because people forget, simplify, and normalize inefficient behavior they've lived with for years.

We saw this exact gap firsthand with a retail client, Sport Discount. The team described their site as working well, engagement looked fine, nothing seemed urgently broken. Layering in heatmap data from Yandex Webvisor and Plerdy alongside Google Analytics behavior flows told a different story, most header links were barely getting clicked at all, and visitors were stalling in places nobody expected. Nobody had misled anyone in conversation, the team simply hadn't seen what the recordings showed, because they had stopped noticing the friction years earlier. Observation is where discovery earns its value in operational software and any project involving an existing, lived-in workflow.

Existing data belongs in discovery too, not just interviews: analytics, CRM records, support tickets, abandoned carts, call transcripts. If customers say a process is simple but analytics show a steep drop-off at that exact step, that tension is worth investigating. Contradictions are often where the most valuable discoveries are hiding.

WORKSHOPS

Workshops Have a Purpose, Not a Monopoly on Truth

Workshops help a team make sense of information collectively, mapping processes, stakeholders, journeys, business rules, and priorities. But a workshop shouldn't become a competition of opinions, "the CEO thinks," "marketing thinks," "sales wants," these are inputs, not conclusions. A strong workshop turns different perspectives into explicit questions: what do we know, what do we believe, what conflicts, what evidence exists, what still needs testing. That distinction turns a workshop from a brainstorming session into an actual decision-making instrument.

A related discipline matters just as much: classifying what you're looking at. Evidence is something supported by observed behavior or reliable data. An assumption is something believed but not yet demonstrated. An interpretation is a conclusion drawn from evidence. A hypothesis still needs testing. This sounds formal, but it becomes genuinely useful the moment a project involves multiple stakeholders, it stops a passing comment in a meeting from quietly becoming "a requirement" three months later.

A statement made once in a meeting can quietly become a requirement three months later, unless someone is disciplined about labeling it correctly.

VALIDATION THEATRE

Validation Theatre, and What Real Validation Looks Like

This is where discovery often turns performative. A team builds a prototype, shows it to five people, everyone says "looks great," and the project moves forward with the concept called validated. It usually isn't. Validation requires a proposition that can actually fail. If an experiment is designed so almost any positive reaction counts as success, nothing has been validated. "Would you use an app that makes this easier" produces polite enthusiasm. "Walk me through the last three times you solved this problem, now try completing the same task with this prototype" creates an opportunity to observe real behavior, which is much harder to fake.

A useful validation loop runs claim, evidence, experiment, result, decision. Customers abandon configuration because there are too many decisions, that's the claim. Analytics show a drop at a specific step, interviews describe confusion, that's the evidence. Build an alternative simplified flow, that's the experiment. Observe task completion, that's the result. Simplify the flow, change the hierarchy, or reject the hypothesis, that's the decision. The final step is what actually matters, if nothing changes because of what was learned, the experiment produced information but not necessarily product progress.

NOT EVERY HYPOTHESIS

Not Every Hypothesis Needs a Prototype

One of the biggest inefficiencies in discovery is jumping into design too quickly. Sometimes the fastest way to test an assumption is a customer interview, a spreadsheet, a fake door, a landing page, a pricing conversation, or a concierge process where a human manually performs what the future software is supposed to automate. This matters especially for startups, building software to test whether people want software can be an unnecessarily expensive experiment. Sometimes the best prototype is a person pretending to be the product.

The goal isn't the most impressive artifact, it's learning something important as cheaply as possible. A good discovery team keeps asking what the smallest experiment is that can meaningfully reduce a specific uncertainty, since if the real question is whether customers will pay, you probably don't need the complete product; if the question is whether staff will actually use a workflow, a realistic simulation often teaches more than polished UI. That question alone can save months.

TECHNICAL DISCOVERY

Technical Discovery Has to Happen Too

A product can be validated with users and still be extremely difficult to build. Technical discovery exists to prevent that surprise: what systems already exist, where is the data, which system is the source of truth, what APIs are available and what are their limits, what can be built, bought, or integrated. This is exactly where Product Discovery starts connecting directly to digital architecture.

Imagine a concept where a customer configures a complex product and receives an instant personalized price. The UX can be designed and prototyped, but where does the price actually come from, what happens when the pricing engine is unavailable, can the CRM store the configuration, can the ERP understand it, does the customer see the same price everywhere. These aren't later implementation details, they affect whether the product concept is viable at all, which is why technical discovery shouldn't begin after Product Design is "finished." It needs to inform it from the start, the same discipline covered from the product side in Product Design vs UX/UI.

HOW LONG

How Long Should It Take, and When Should It Stop

There's no universal answer, a focused feature might need days, a complex B2B system involving multiple departments and existing infrastructure might need considerably longer. But discovery shouldn't become an endless research project, the goal was never to know everything, it's to know enough to make the next expensive decision intelligently. That gives it a natural stopping condition: can the team answer, with reasonable confidence, what problem it's solving, for whom, how it's solved today, what the major constraints are, which assumptions remain risky, and what the first version should explicitly not do. Reasonable confidence, not certainty. Waiting for certainty can become its own form of avoidance.

One of the best outcomes of discovery is usually a smaller scope, not a larger one. An MVP shouldn't be everything the team might eventually want, released badly, it should be the smallest product that tests the critical assumptions and delivers meaningful value. This matters more, not less, as AI makes implementation cheaper, because "we can build it" is not the same claim as "we should build it now."

Discovery Decision Checklist

DELIVERABLES

The Deliverables Should Change Decisions, Not Just Exist

A professional discovery process can produce problem framing, research synthesis, an assumption map, an opportunity map, current and future-state workflows, prioritized requirements, an MVP definition, technical constraints, and a risk map. But none of these documents is the real deliverable. The real deliverable is better decisions with less uncertainty.

There's one failure worse than skipping discovery entirely: doing it and then ignoring it. Three weeks of interviews reveal that customers don't need the requested dashboard, they need a faster way to complete one specific task. Everyone agrees. The dashboard gets built anyway because "it's already in the scope." At that point discovery has become theatre, since the entire point of the process is that new information is allowed to change the plan. Otherwise the team isn't discovering, it's documenting a decision that was already made.

Sometimes the most valuable outcome isn't a smaller version of the requested solution, it's a completely different one. The business really does have a sales problem, but the fix isn't a CRM replacement. There really is a conversion problem, but the fix isn't a full redesign. This is where discovery earns its value, separating the problem worth solving from the solution someone happened to request first.

A team can feel extremely confident after a workshop and still be completely wrong. Confidence was never the goal.

From Discovery to Product Design

Once the critical uncertainty has been reduced, the question changes. Discovery asks what have we learned. Product Design asks what should the product become because of it, the exact boundary and handoff we cover directly in Product Design vs UX/UI. The two disciplines overlap but aren't the same, discovery creates evidence and reduces uncertainty, Product Design turns that knowledge into a product model, UX/UI turns the model into an experience, digital architecture determines how the system needs to work, development turns the system into reality. The sequence is rarely perfectly linear, and at every stage new information can move the process backward. That isn't inefficiency. That's learning.

This applies just as much to a straightforward corporate website as it does to a complex platform. The SV Group corporate site, a custom furniture and woodworking manufacturer, started with business discovery before a single wireframe existed, mapping how the company actually wanted to communicate its expertise, its products, and its philosophy, not just organizing pages. The client's own words afterward summed up why that sequence matters: "the company doesn't sell websites, they sell a new understanding of business." Discovery is what makes that understanding possible, regardless of how simple the final deliverable looks.

Discovery adds real work before development starts, that's true, and it sounds like a cost. But the honest comparison was never discovery cost against no discovery cost, it's discovery cost against the cost of discovering the same truth after implementation. Finding out during an interview that customers don't want a feature is cheap. Finding out after three months of development is expensive. The point was never to eliminate uncertainty entirely, it's to move the cheap kind of uncertainty earlier, before it becomes an expensive one. A good product doesn't begin the moment someone opens Figma. It begins when a team can say, with reasonable confidence, here is the problem, here is who it affects, here is why it matters, and here is the decision we're prepared to make because of what we learned. Only then does the next real question become what to design at all.

How is Product Discovery different from a kickoff call or requirements gathering?

Requirements gathering usually documents what a client believes it needs. Discovery tests whether that belief is correct, using interviews, observation, and existing data, before committing meaningful time and budget to building it.

Does every project need a full discovery phase?

No. A small, well-understood feature with low uncertainty might need a short conversation, not weeks of research. The depth of discovery should match the size of the risk and the cost of being wrong, not a fixed template.

What's the biggest sign a discovery process failed?

The findings changed nothing. If interviews, data, and workshops produced a report that sits in a folder while the original plan proceeds unchanged, the team did research, not discovery.

Can discovery happen after a project has already started?

Yes, and it often should. New information rarely arrives on a convenient schedule. A team that treats a new finding as a reason to reconsider the plan, even mid-project, is still doing discovery correctly.