The product discovery process with AI: what AI can and can't do before the spec
A step-by-step discovery process for teams using AI: where it speeds up research, and where judgment stays human.
Product discovery is the work a team does to decide what to build before building it: finding which customer problems are real, which are worth solving, and which solution to bet on. The output of the product discovery process is a recorded decision that people and agents can act on.
Your agents can build it by Friday. Whether anyone needs it is still unknown. Coding agents shortened the build, but discovery still runs at the speed of interviews, scheduling and debate. AI can make parts of discovery faster, mainly research and synthesis. It can't choose the bet for you, and it can't be held accountable for a wrong one.
The product discovery process, step by step
1. Frame the problem and the outcome
Write down the problem you think exists, who has it, and the outcome that would tell you it's solved. "Reduce failed deliveries for customers who aren't home" is a frame. "Build a rescheduling feature" is a solution in disguise.
- AI can help with: rewording a solution-shaped request into a problem statement, and listing the assumptions hidden in it.
- Humans decide: which outcome the team is accountable for, and whether this problem matters more than the others on the list.
2. Gather evidence
Pull together what you already have and fill the gaps: customer interviews, support tickets, usage data, sales call notes, churn reasons.
- AI can help with: transcribing and tagging interviews, searching ticket archives, pulling usage queries, drafting interview guides.
- Humans decide: who to talk to, which questions to ask, and which sources are trustworthy enough to count.
3. Synthesise and cluster
Group what you heard into themes and needs.
- AI can help with: a first pass at clustering, counting how often a theme appears, and linking every theme back to the raw notes.
- Humans decide: whether a cluster is real or an artefact of how the notes were written, and which outlier deserves more weight than the majority.
4. Generate and size opportunities
Turn themes into opportunities, then estimate how many customers each affects and how much it costs them.
- AI can help with: listing candidate solutions per opportunity, drafting sizing queries, and pointing out where evidence is thin.
- Humans decide: the sizing assumptions and which opportunities to pursue.
5. Test assumptions
Check the riskiest assumption before committing a build. Common product discovery techniques include clickable prototypes, fake-door tests (a button for a feature that doesn't exist yet, to measure interest), and concierge tests (delivering the service by hand to a few customers).
- AI can help with: building a prototype quickly, drafting test copy, and summarising results.
- Humans decide: which assumption is riskiest, what result would change the plan, and whether the test was fair.
6. Decide and record
Choose an approach, record what you rejected and why, set scope and non-goals, and define done.
- AI can help with: drafting the decision record from the team's notes and checking it for gaps.
- Humans decide: everything in it. This is the step AI can't take over.
7. Hand off to the build
Give the decision to the people and agents who will build it, with the evidence linked.
- AI can help with: turning the decision into a spec, acceptance criteria and tasks. See spec-driven development for product teams for that step.
- Humans decide: whether the spec still matches the decision, and who signs off on done.
Where AI helps and misleads in product discovery
Discovery task | Where AI helps | Where AI misleads | Human owner |
|---|---|---|---|
Interview prep | Drafts guides, lists assumptions to probe | Writes leading questions if not checked | PM or researcher |
Evidence gathering | Transcribes, tags, searches tickets and data | Treats whatever is easy to search as the whole picture | PM |
Synthesis | First-pass clustering, linking quotes to themes | Smooths over the dissenting customer | PM and designer |
Opportunity sizing | Drafts queries, lists candidate solutions | Produces precise-looking numbers from weak inputs | PM with data lead |
Assumption testing | Builds prototypes fast | A polished prototype gets mistaken for validation | Product trio |
Decision | Drafts the record, flags gaps | Can present a choice as if the evidence made it | PM |
AI failure modes in discovery, and safeguards
Four failures come up when teams lean on AI for discovery.
Confident synthesis of thin evidence. Six interviews summarised in fluent prose read like a finding. The summary doesn't show how little sits under it.
Dropped dissent. Summaries favour the common view. The one customer who explained why the feature would break their workflow can disappear from the output.
Fabricated quotes. A language model asked for "customer quotes about X" can produce plausible quotes nobody said.
Prototypes mistaken for validation. AI makes prototypes cheap, so teams show more of them. A customer saying "that looks nice" to a prototype tells you little about whether they'll change their behaviour.
The safeguards are plain habits. Link every theme to its raw sources. Keep the original quotes and recordings next to the summary. Mark confidence on each finding, and note how many people it rests on. Treat any quote without a source as illustrative until someone finds the transcript.
Continuous discovery and the product discovery process
The steps above can run as a project, or they can run every week. Teresa Torres's book Continuous Discovery Habits describes the second approach: a product trio starts from a clear outcome, interviews customers to discover opportunities, and uses assumption tests to evaluate solutions, with an opportunity solution tree to visualise the work. If agents can build every week, discovery that runs once a quarter leaves them waiting for decisions, which makes a continuous cadence more useful than before.
From discovery to a decision brief
Discovery's output should be a decision an agent can act on. Here is an illustrative example. The company, evidence and numbers in it are made up.
A logistics app lets customers pick a delivery window at checkout. Customers can't change it once the parcel is dispatched. The team has done discovery on whether to allow changes after dispatch.
Decision brief: change the delivery window after dispatch
Sample decision brief. Problem: Customers who become unavailable after dispatch can't move their window, so drivers make failed attempts. Evidence: linked interview notes, support tickets tagged "reschedule after dispatch", failed-attempt reports (illustrative). Decision: Allow one window change after dispatch, up to the evening before delivery day. Rejected: same-day changes (drivers' routes are locked by then), unlimited changes (route planning can't absorb them). Constraints: In scope: customer app and tracking page. Out of scope: driver app changes, business-account deliveries. Can't bend: a change never moves a parcel to a depot outside the customer's zone. Done when: A customer can move a dispatched delivery once, before the cutoff, and sees the new window confirmed; routes after the cutoff are unchanged; support can see the change history. Open questions: Do we charge for the change? If unresolved, the agent builds it as free and flags the pricing hook for review.
Illustrative example
- Problem
- Customers who become unavailable after dispatch can't move their window, so drivers make failed attempts. Evidence: linked interview notes, support tickets tagged "reschedule after dispatch", failed-attempt reports (illustrative).
- Decision
- Allow one window change after dispatch, up to the evening before delivery day. Rejected: same-day changes (drivers' routes are locked by then), unlimited changes (route planning can't absorb them).
- Constraints
- In scope: customer app and tracking page. Out of scope: driver app changes, business-account deliveries. Can't bend: a change never moves a parcel to a depot outside the customer's zone.
- Done when
- A customer can move a dispatched delivery once, before the cutoff, and sees the new window confirmed; routes after the cutoff are unchanged; support can see the change history.
- Open questions
- Do we charge for the change? If unresolved, the agent builds it as free and flags the pricing hook for review.
| Field | Text |
|---|---|
| Label | Illustrative example |
| Problem | Customers who become unavailable after dispatch can't move their window, so drivers make failed attempts. Evidence: linked interview notes, support tickets tagged "reschedule after dispatch", failed-attempt reports (illustrative). |
| Decision | Allow one window change after dispatch, up to the evening before delivery day. Rejected: same-day changes (drivers' routes are locked by then), unlimited changes (route planning can't absorb them). |
| Constraints | In scope: customer app and tracking page. Out of scope: driver app changes, business-account deliveries. Can't bend: a change never moves a parcel to a depot outside the customer's zone. |
| Done when | A customer can move a dispatched delivery once, before the cutoff, and sees the new window confirmed; routes after the cutoff are unchanged; support can see the change history. |
| Open questions | Do we charge for the change? If unresolved, the agent builds it as free and flags the pricing hook for review. |
A sample brief you can read and copy. It is not a live specification.
The brief carries what discovery learned, what it rejected, and the limits the build must respect. For how to put a record like this in front of a coding agent, see how to give AI coding agents product context.
Product discovery in the enterprise
In a large organisation, discovery spreads across many teams. Two teams interview the same customers in the same month. A research finding lives in one team's folder and never reaches the team building on it. A decision made in a steering meeting reaches engineering as a one-line ticket. These are versions of the problem we call the enterprise context gap: the distance between what the organisation knows and decided, and what each agent receives.
The pattern gets sharper with agentic build pipelines. Most software factory setups start at the build and assume discovery has already happened, as we describe in what is a software factory. When discovery is thin, the factory builds thin decisions quickly. The pillar post on why the AI SDLC is really a product lifecycle explains why discovery becomes the bottleneck once building is fast.
Where SteerFlow fits
Trace the path discovery's output takes: evidence → decision → spec → agent → code. Research tools and notes hold the evidence. Coding agents handle the spec-to-code end. The middle, where evidence becomes a decision with reasons attached, is the part that usually ends up as a slide deck or a meeting memory, with no form an agent can read.
SteerFlow is designed to capture evidence and decisions as records agents can act on. It is designed to keep each decision linked to the evidence behind it and to the constraints and done-checks that follow from it, so the agent building the feature reads the same reasoning the team agreed on.
If discovery is where your decisions lose their reasons, we're happy to talk it through. Get in touch.
FAQ
What is product discovery?
Product discovery is the work of deciding what to build before building it. A team finds which customer problems are real and worth solving, tests the riskiest assumptions, and records a decision about what to build and what not to.
What are the steps in the product discovery process?
A common sequence is: frame the problem and outcome, gather evidence, synthesise it, generate and size opportunities, test assumptions, decide and record, and hand off to the build. Teams often loop back through steps rather than running them once.
How can AI help with product discovery?
AI can transcribe and tag interviews, search support tickets and usage data, produce a first pass at clustering themes, draft interview guides, build quick prototypes, and draft the decision record. Each of those outputs needs a person to check it against the raw evidence.
Can AI do product discovery on its own?
No. AI can speed up research and synthesis, but choosing which problem to solve, weighing trade-offs and owning the outcome are human decisions. AI also makes specific mistakes in discovery, such as summarising away dissent or inventing quotes, which a person has to catch.
What is continuous discovery?
Continuous discovery is running discovery as a regular habit instead of a one-off project. Teresa Torres's Continuous Discovery Habits describes a product trio working from a clear outcome, interviewing customers, and testing assumptions on an ongoing basis.
What is the output of product discovery?
A recorded decision: the problem and its evidence, the chosen approach and rejected options, the scope and constraints, and the checks that define done. A deck of findings with no decision is an incomplete output.
How long should product discovery take?
It depends on the risk and cost of being wrong. A small, reversible change may need a few conversations and a quick test. A large bet that touches several teams needs more evidence. Match the depth of discovery to the cost of building the wrong thing.
