Only 11% of consumers would let an AI decide a purchase for them (Gartner, May 2026). Product discovery is the product managers' discipline: a discovery phase where the product team runs user research to understand user needs before building. Discovery has a lesser-known counterpart, the one the buyer lives through. This article sets out the product discovery process, the tools, then Kleio'sagentic discovery .
What is product discovery?
A definition of product discovery
Product discovery is the phase of product management where the product team identifies the right problem and the right solution before developing. Effective product discovery rests on three pillars: user research, user feedback and idea validation. The product designer explores the solution, the developer assesses the product and the product leads arbitrate. This way of organizing separates discovery from delivery. The product discovery process reduces project risk: the team tests a hypothesis before developing the feature. Every product builder gains a product vision grounded in customer needs.
Why is product discovery crucial?
The importance of product discovery comes down to a statistic every product lead knows: most ideas do not produce the expected impact. Without discovery, a company invests in a feature on the strength of an intuition, then sees the gap between what users expected and what was delivered. Discovery brings concrete added value: it defines the right problem, solves a real need and concentrates the development budget on what matters to the market. It also limits the time lost on projects launched from an internal point of view. For a company, it is a risk management objective as much as a creative one.
Who does product discovery in a product team?
The product manager leads discovery with a product designer and a developer, sometimes called product builders. The product designer turns research into mockups and testable journeys. The developer assesses what is feasible and what is not. The product leads then arbitrate between opportunities. The trio shares responsibility for the decisions: nobody receives a specification that is already fixed. Product design and agile product management meet here, because discovery feeds every iteration of the product. Discovery is a cross-cutting discipline of product management: it connects users, design and development. Companies that want to raise their maturity can use an internal guide describing each role.
Discovery and delivery: two parallel tracks
Discovery decides what to build. Delivery builds and ships. Many organizations split them into two tracks running in parallel: that is the dual trackprinciple. While developers ship the feature validated last month, the product team is already testing next month's ideas with users. This setup avoids the time lost on projects where you code first and ask questions afterwards. Product discovery feeds the roadmap with evidence rather than opinions. The discovery and delivery cycle repeats every quarter.
Marty Cagan's four risks
Marty Cagan, a reference author in product management, structures discovery around four risks to clear before development. Value risk: will customers buy or use the product? Usability risk: will users understand how to use it? Feasibility risk: can the team build it with its skills and its technology? Viability risk: does the solution work for the whole company, sales and legal included? Each risk has an owner: the product manager carries value and viability, the designer usability, the engineer feasibility (SVPG, Marty Cagan).
Teresa Torres's continuous discovery
Teresa Torres popularized continuous discovery : at least weekly contact with customers, run by the team building the product, through small research activities aimed at a target product outcome (Continuous Discovery Habits). Her central tool, theopportunity solution tree, connects a product outcome to opportunities drawn from interviews, then to solutions and experiments. The product team sees its assumptions laid out and chooses what to test. The approach installs discovery as a habit of the product organization rather than a one-off phase before a launch.
How to succeed at product discovery: steps, techniques and tools
The steps of effective product discovery
An effective product discovery process follows steps that every team adapts to its context:
- frame the problem and the expected outcome with stakeholders
- run user research through interviews and observation
- identify user needs, then write assumptions to validate
- imagine several solutions and prioritize them by value and effort
- build a prototype or a minimal test to get fast feedback
- decide to continue, adjust or drop the idea
Every step of product discovery produces a deliverable: a research summary, a ranked list of hypotheses, a tested prototype. The agile process loops several times before the delivery phase. Idea validation stays the goal: an idea only moves forward if it survives a test with real users. These product discovery steps appear in every method: succeeding at product discovery starts with accepting that your ideas will be questioned. To structure product creation, organizations can use an assumption roadmap and outside support, a coach or an internal reference person who guarantees the cadence.
How do you run user research well?
User research is the heart of discovery. To do it well, the product team interviews people who actually live the problem, not colleagues. An interview lasts half an hour and explores lived situations rather than opinions about a hypothetical product. Asking “what would you do if?” produces polite but false answers. Better to ask “tell me about the last time you”: the user then describes observable behavior. The summary groups the verbatims into opportunities, which the product manager ranks by frequency and impact.
The product discovery techniques that work
Product discovery techniques fall into two families. Qualitative research covers user interviews, field observation and usability tests. Quantitative research covers surveys, usage data and A/B tests. Design thinking and the double diamond structure the alternation between divergence (exploring the problem) and convergence (choosing the solution). The minimum viableproduct concept, a low-cost test, confronts an idea with real users in days rather than months. The choice of technique depends on the risk to clear and not on a methodological fashion.
Which tools for product discovery?
Product discovery tools cover four uses: centralizing user research, mapping opportunities, prototyping and prioritizing the roadmap. A product team uses a prototyping tool to test mockups, an interview tool to record and analyze the voice of the customer and a project management tool to track ideas, such as Jira Product Discovery. Organizations already relying on Jira for flexible project management often attach their idea backlog to it. Low-code platforms also allow prototyping without writing a line of code. Jira Service Management or another project management tool stays useful for tracking requests but it does not replace research. A test website or a demo application is often enough to validate an assumption. Product discovery tools should be chosen according to the stage and the risk to clear. The tool matters less than the discipline: a team that never talks to its users will gain nothing from better software.
Expert tip
before buying a tool, set your product team's cadence of user contact. One interview a week with a free tool beats a subscription with no interviews.
A step-by-step product discovery example
Take the example of a meeting room booking application. The product team writes a hypothesis: assistants book too late because they cannot see free rooms in real time. It runs five interviews, discovers that the real problem is uncertainty about the equipment, then builds a prototype that shows the equipment before booking. A test with eight users validates the assumption in two weeks. The team avoided developing an expensive real-time calendar. The example illustrates the principle: discovery turns a feature idea into a testable question.
Framing workshop: define the problem before the solution
A half-day framing workshop defines the problem space before designing a solution. The team lists what customers expect, drops every feature that answers none of it and aligns everyone on the same wording of the problem. The workshop is also a moment of product culture: it is a reminder that the value proposition is built starting from the user. Good framing leads to more targeted solutions, shared success criteria and alignment on the expected outcome. Among the keys to success: a solution tested early, explicit expectations and a team aligned on the value sought. What can be decisive is team culture: the most useful advice is to document every decision so the team can revisit it. You also need to be able to drop an attractive solution that does not answer what users expect, and to define in advance what would change your mind.
The English vocabulary of discovery: product team, tech lead, insights
French teams use English vocabulary that needs decoding. The product team brings together the product manager, the designer and the tech lead. A feature is a function, an insight is a lesson drawn from research and customer discovery is research run with customers. The framework is the shared way of working, the build is the construction and work in progress covers the ideas being tested. Decisions rest on data and on every piece of information coming back from the field. Understanding this vocabulary is a key to reading the reference books: it lets you follow the exchanges of an international team and see how work is prioritized in a discovery process. A product strategy that reads clearly across the whole cycle rests on these shared words.
How do you document and share a product discovery?
A good discovery leaves a readable trace. One summary sheet per cycle gathers the problem, the hypotheses, the test results and the decision taken. A simple template is enough: objective, users interviewed, lessons, next step. Reading those sheets lets newcomers understand the history of product choices. It also aligns stakeholders on the vision and the roadmap without going back through long meetings.
How do you learn product discovery?
Learning product discovery runs through three levers: reading the reference books, practice supervised by a product coach and team culture. A two-day course gives a methodological frame but only repeated interviews install the reflex. Most organizations that succeed appoint a pair in charge of building the practice, then extend the approach team by team. It also helps to frame executive expectations from the start: discovery produces decisions, not immediate shipments.
What place for artificial intelligence in discovery?
Artificial intelligence speeds up interview synthesis, the grouping of verbatims and the writing of assumptions. It does not replace contact with the user. A product team saves time on analysis but has to keep the human conversation to understand context. The same holds on the buyer's side, as the rest of this article shows.
Succeeding at product discovery: which support should you choose?
Succeeding at product discovery often calls for outside support during the first cycles. A coach helps structure product creation: how to sequence the product discovery steps, how to run an interview without bias and how to present the conclusions to executives. The most useful product courses mix theory and practice on a real company topic. A complete guide does not replace that work: the importance of product discovery becomes clear by practising it on your own product. Product discovery tools come afterwards, once the method is in place. In an organization, discovery is a discipline learned through repetition and discovery product management then becomes a team reflex. To follow progress, many teams use a Jira project management board adapted to ideas and assumptions. Measuring the impact of that work runs through a monthly review with the product leads, where the team measures the product impact of the decisions discovery made possible.
How do you avoid the pitfalls of product discovery?
Four pitfalls come back in most organizations. Confusing discovery with validation: the team seeks to confirm its idea instead of testing it. Interviewing the wrong users: a sample of friends or long-standing customers skews the assumptions. Staying on opinions: without real user feedback, the roadmap reflects whoever speaks loudest in the meeting. Finally, separating discovery from the development team: the product manager discovers alone and passes on the conclusions, which destroys the benefit of the trio. Avoiding the pitfalls of product discovery takes discipline of cadence more than of method.
How do you measure the impact of product discovery?
Measuring the impact of discovery means measuring the quality of product decisions. Useful indicators: the number of hypotheses tested per month, the share of shipped features that reach their usage objective, user satisfaction after launch and the time saved on abandoned developments. Effective discovery reduces the projects cancelled mid-course. Its impact on the product is therefore judged by the fall in risk before each release and not by the volume of documents produced. Measuring impact requires setting the indicators before the discovery rather than after: with no numeric objective at the start, no team can conclude anything. The importance of product discovery is then demonstrated by one simple figure, the cost avoided.
Product discovery on the buyer's side: the other half of the problem
Most product discovery guides stop at the product team. Yet the buyer lives through a discovery too: that of a product they do not know yet, inside a catalog they do not master. The table below compares the two.
What if the buyer does not know what they are looking for?
About 60 % of buyers do not know what they want at the start of a high-consideration journey (Kleio data). A traveler looking for “somewhere sunny with the family” or a household looking for “a flat near a school” is not writing a precise query. Their need takes shape by discovering offers, not before. The buying journey therefore works as a discovery where the buyer learns what they like by seeing what exists, in hospitality, real estate, travel or automotive retail.
Why filters and search engines are not enough
A faceted filter assumes the buyer already knows their criteria: budget, surface area, engine. A text search engine assumes they can name what they want. In a complex catalog, neither assumption holds. A mobile or web booking application poses the same problem as a dealership site or an estate agency: the customer has to be able to name their need to use the search engine. The buyer then drops out, picks at random or hands the question to an advisor who does not have time to handle everything. That loss is invisible in conversion statistics, which count the buyers who left and not those who never reached a preference. The usual advice, add more filters, does not solve the problem: the application richest in filters stays silent in front of a buyer who does not know what to ask for.
What Gartner says about AI and buying
According to Gartner (US surveys of 846 people in November and December 2025 and of 322 people in January 2026), only 11% of consumers would let an AI decide a purchase. On the other hand, 28% accept that it narrows the choice in personal electronics and 31% in household products. Among people using AI for shopping, 54% double-check everything it produces and 62% consider that the information those tools gave them wasted their time. The lesson is clear: the buyer wants help exploring, not a delegated decision.
Did you know?
Only 11% of consumers would let an AI decide a purchase but 28% to 31% accept that it narrows the choice (Gartner, May 2026).
Agentic discovery: external product discovery driven by AI agents
A definition of agentic discovery
L'Agentic discovery is a discovery run by AI agents that help the buyer build a preference by reacting to real products. It is not about exposing a catalog to external agents. The agent proposes a few real products, watches the buyer's reaction then revises its next proposal. The buyer refines their preference without having to state it upfront. Our dedicated page sets out this agentic discovery concept. It differs from a FAQ assistant: the agent reasons about attributes, prices, availability and relationships between products.
The loop: propose, react, revise
The diagram below shows theagentic discoveryloop. Every buyer reaction, a refusal included, becomes a signal: a refusal on price revises the estimated budget, a refusal on distance revises the area. The loop converges toward a preference clear enough to move to a booking, a quote or an appointment with an advisor.
The loop reuses the logic of product discovery : an assumption, a test, a lesson. Only the learner changes. In internal product discovery, the product team discovers what users want. In agentic discovery, the buyer discovers what they want, helped by the agent.
Diagnostic: does your buying journey have a discovery problem?
Does your site let the buyer discover what they want or does it require them to know already? Answer four questions to place your journey.
The result says whether your journey rests on filters, on text search or on guided discovery. It does not replace an audit but it puts words on the gap between what your catalog offers and what your buyers are able to express.
Agentic discovery or product recommendation?
A classic recommendation engine ranks products from behavioral history. It therefore assumes a history, which is missing for a buyer discovering a rare category. Agentic discovery works without history: it starts from the conversation and from live reactions. To go deeper into the difference, see our guide on product recommendation and our analysis of the difference between agentic discovery and agentic search. The two approaches complement each other: recommendation ranks, discovery guides the construction of the preference. In a sales application, web or mobile, recommendation serves the last step and discovery serves the first ones. An application built only on recommendation leaves the buyer without a guide at the start; an application that includes agentic discovery accompanies them from their first need.
Where discovery is decided: hospitality, real estate, automotive
Buyer-side discovery weighs most on high-consideration purchases, meaning a long decision, a large catalog and weak intent at the start. In hospitality and travel, the traveler discovers the destination at the same time as the offer. In real estate, the buyer revises their project with every virtual tour. In automotive retail, they move from a budget to a use case then to a model. Travel is not Automotive and Real Estate is not Wholesale: each industry has its own exploration logic.
Kleio, the agentic discovery platform for high-consideration purchases
The Knowledge Engine: a live catalog
Kleio's Knowledge Engine distributes our clients' catalog across three purpose-built stores: products, documents and memory. The agent therefore queries a live catalog, with up-to-date prices and availability rather than a frozen export. The Knowledge Engine reaches 99% precision on queries with answers in under 3 seconds and zero hallucination: the agent only answers from approved data. Our article on the Knowledge Engine sets out that architecture.
The Triple Business Ontology
Kleio's Triple Business Ontology layers three pre-built levels: function, industry and customer. It exists for 7 industries : Travel, Automotive, Real Estate, Wholesale, Manufacturing, Insurance, Energy & Utilities. Every business application inherits that ontology. An application has to be able to understand this vocabulary. Each industry therefore has its own exploration vocabulary: the agent knows what a decisive criterion is for a traveler or for a property buyer. We extend that ontology to the client's data model in weeks.
Orpi, Selectour, Havas Voyages, Altarea Cogedim
Orpi deployed the Kleio platform on Orpi.com and across its 1,250 agencies serving 8,000 advisors, in three months (see the Orpi case study). Selectour equips its travel advisors and its customers. Havas Voyages is growing its lead generation through a personalized conversational experience. Altarea Cogedim absorbs the complexity of its property offers and financing schemes while freeing its advisors for the high-value moments.
Deploying in 8 to 12 weeks
We deploy Kleio in 8 to 12 weeks from project kickoff to production, within a SOC 2 framework with tenant isolation. There is no plug-in to bolt onto your catalog: the implementation is supported, with your ecommerce team and your advisors.
