Product discovery: a practical guide for AI and SaaS product teams

What are the stages of the product discovery process?

The process moves through five stages: frame the outcome, understand users, map opportunities, test the riskiest assumptions and decide.

The stages echo the Double Diamond, which the UK's Design Council launched in 2004 with 4 phases: discover, define, develop and deliver. Discovery work covers the first diamond and the early part of develop. The strip below shows where the work widens and narrows.

1. Frame the outcome

I start with the decision, not the research plan. The trio writes the desired outcome and a problem statement in plain words, such as "property managers sort maintenance requests by hand." The page keeps every later test aimed at one goal. In my two-week plan, framing gets 2 days.

2. Understand users

Customer interviews show how users handle the problem today, before anyone pitches a solution. I keep each interview to 45 minutes and ask about the last time the problem happened, because real events beat opinions. Listening gets 3 days and ends in interview notes and a journey map.

3. Map opportunities

Teresa Torres' opportunity solution tree organizes what you heard: the desired outcome at the top, then customer opportunities, then solutions, then assumption tests. The tree stops a team from jumping from one interview to one favorite feature. The output is an opportunity map with a few targets circled.

4. Test the riskiest assumptions

Assumption testing pays off when you test the assumption that would kill the idea first. A prototype test with real users checks value and usability, while a feasibility spike checks the build. The test block gets 2 days and ends in results marked passed, failed or unclear.

5. Decide

The trio writes a decision memo: build, change or stop, with the evidence behind each call. Validated ideas move into the product backlog, and failed ones go back to stage 3. The call takes 1 day, and a stopped idea counts as a result.

None of these stages waits for a sprint boundary, so the next question is how they sit inside agile.

How does product discovery work in agile?

The product discovery process in agile runs as a second track beside delivery: one team tests ideas while it ships, and only validated ideas enter the backlog.

Many agile teams call this dual-track agile. Jeff Patton, who credits Desirée Sy with an early version, titled his essay "Dual Track Development is not Duel Track": two kinds of work, done by one team. Discovery and delivery need the same people, or the learning stays with whoever ran the interviews.

Who does the work? Teresa Torres defines continuous discovery as, at a minimum, weekly touch points with customers by the team building the product, and a product trio leads it. The product manager, designer and tech lead work together rather than handing off.

The table below compares the two tracks by question, output, cadence, people and finish line.

For Scrum teams, I keep the discovery track on its own light board. A backlog item enters sprint planning only after its riskiest assumption has passed a test, which is my working agreement rather than a Scrum rule. A tool such as Jira Product Discovery can hold that board's ideas and scores, but the tool does not run the discovery. Before launch, there is no weekly customer habit to join yet, which is where a timeboxed phase comes in.

How long should a product discovery phase last?

A timeboxed discovery phase runs from a 5-day sprint on one question to several weeks for a whole product area, then hands over to continuous discovery.

A phase makes sense in three situations:

• New product or market: nobody has talked to these users yet, so a weekly habit has nothing to build on.
• First AI feature: data and model questions decide whether a design is even possible.
• A board or investor deadline: a date forces a decision, so a timebox protects it.

Continuous discovery alone fits a live product whose trio already spends 30 minutes with customers every week.

Length depends on the size of the question. A 5-day design sprint answers one question in 5 days. Our design sprint page puts a full discovery phase for a whole product area at 3–6 weeks, with 10–20 interviews plus a data review. Our AI discovery workshop runs 1 to 2 weeks.

A discovery phase that drags on delays development without improving the decision. Too long looks like research that continues to avoid a call, and too short looks like a phase where no user saw anything. Before the phase closes, I book a standing customer slot of 30 minutes every week, so discovery continues past the gate. Pick your length from the size of the question and put the end date in the calendar on day 1.

What changes in product discovery for AI features?

An AI feature adds five checks to the four risks: the right tool, data readiness, model feasibility, evaluation and the cost of a wrong answer.

On July 29, 2024, Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025. The causes it named were poor data quality, inadequate risk controls, escalating costs or unclear business value.

A 2024 RAND report lists 5 root causes of AI project failure, and the first is a problem that is misunderstood or miscommunicated. Several of those causes, such as unclear business value, a misunderstood problem and missing data, are questions discovery can answer before a build starts.

Is AI the right tool?

No, not by default. I start from the user task, not the model, because a rule, a filter or better search sometimes does the job with less risk. The Google People + AI Guidebook, from Google's People + AI Research (PAIR) team, starts in the same place: user needs first, then whether AI adds value.

Data readiness: can you use the data?

Data readiness asks four questions per AI use case. Does the data exist, can you access it, are you allowed to use it and is it labeled? Permission is a US legal question: the California Consumer Privacy Act (CCPA) as amended by the California Privacy Rights Act (CPRA), the Health Insurance Portability and Accountability Act (HIPAA) for health data, and your customer contracts.

In February 2025, Gartner predicted that through 2026, organizations would abandon 60% of AI projects unsupported by AI-ready data. PAIR advises teams to translate user needs into data needs, then judge the data on predictive power, relevance, fairness, privacy and security. I run this as a data audit, one row per use case.

Model feasibility: can a model do the task?

A feasibility spike puts real inputs through a candidate model before anyone designs a screen. Engineering owns the spike and reports answer quality, latency and cost per call. I give the spike 2 days in a two-week plan.

Evaluation: what counts as a good answer?

AI evaluation means writing down what a good answer looks like before design starts. PAIR asks teams to agree how they will measure whether the feature works, weigh second-order effects and choose the precision vs recall trade-off. Precision is the share of flagged items that truly belong in the category, and recall is the share of items in the category that the model flagged. In maintenance triage, missing an urgent leak hurts more than over-flagging a dripping tap, so the model evaluation favors recall.

Cost of a wrong answer

Map who a wrong answer harms and how the user catches and corrects it, because the harm map feeds the design guardrails. The National Institute of Standards and Technology (NIST) gives US teams a frame here. Its NIST AI Risk Management Framework (AI RMF) says that after completing the Map function, a team should have enough context about AI system impacts to inform an initial go/no-go decision. In maintenance triage, a missed urgent leak harms the tenant, so staff confirm or change every suggested urgency.

You can test value before any model exists. A Wizard of Oz prototype puts a person behind the interface to write the AI's answers, so 5 users can react to them before anyone builds a model. The grid below lists the evidence that passes each check and who answers it.

This is the part most teams skip. Our AI discovery workshop scores each AI use case on user value, data readiness, cost and risk of wrong answers, with your product lead, an engineering or data lead and a business owner.

How do you do product discovery in two weeks?

To do product discovery in two weeks, split 10 days of work into five blocks (frame, listen, check risks, test and decide) and close each with one written output.

If you're asking how to do product discovery with a small team, start with the decision you need, not the method. NN/g argues that two weeks is too short unless users are easy to access and the problem space is relatively small, so I use this timebox for a first round on one decision, not for a whole product area. Here's the plan I use, labeled by the question each block answers.

The room holds the product trio plus a business owner who can make the call. The range of 4 to 6 users and the 5-user test match how we run our own workshop, where participants give about 2 hours a day. If you want a facilitator for an AI feature, the in-house or partner section below covers when that makes sense.

Two mistakes break the plan. Teams recruit users on day 3, so the listening block starts empty, or they build the prototype before the spike and test a concept engineering cannot ship. Book your 4 to 6 users today.

Product discovery example: one AI idea, request to decision

The example below is hypothetical: one board request for AI, run through every check, so you can watch each check change the plan before a screen exists.

Take the property-management SaaS from the opening log. The grid below compares its three AI ideas across the four risks and five AI checks.

Auto-replies fail on the cost of a wrong answer, because a confident, wrong reply about a lease becomes a legal problem. Lease summaries pass on value, but the leases exist only as scanned images. Nobody has confirmed the team is allowed to process them, so the idea parks until a data audit. Triage passes, and the team builds a narrow version: the model suggests a category and urgency, and staff confirm each one.

None of the three failed on design. Each check removed scope before anyone drew a screen.

Two real projects show the same habit. Before designing the Digno performance platform, an AI-scored product, we collected requirements from stakeholders and end users to pin down the scoring formula. Digno's brief was to express performance as one plain score that makes sense to managers and staff alike. For Vocable, an AI content marketing platform, we ran stakeholder interviews and kept the scope tight around the jobs writers named most often.

Try the grid on your own shortlist, one column per AI idea.

What goes on a product discovery checklist?

A product discovery checklist is an exit gate: 8 yes/no checks grouped by risk, plus 4 for an AI feature, that must pass before an idea enters the delivery backlog.

Two rules make the gate work. An unknown counts as a no, and every unknown goes back to a test rather than to the trash. A check that a test failed sends the idea to change or stop, as the auto-replies showed. The AI lane applies only when the feature uses a model.

I check the quiet lines first. "Outcome metric written down" fails when the team agrees on a goal but never names the number that proves it. "Correction path" fails when the design shows an AI answer with no way to edit or reject it. Run the gate on your current top idea within 7 days and count the unknowns.

Should you run product discovery in-house or with a partner?

Keep discovery in-house when your product trio can meet customers weekly; use a design partner when you lack a designer, face a deadline or scope a first AI feature.

In-house fits these situations:

• A trio exists: a PM, a designer and a tech lead can each give the work about 2 hours a day, so learning stays in the team.
• Customers are reachable: you can book 5 users this week without a recruiter, so tests stay on schedule.
• The idea extends what you know: a new report in a familiar workflow needs less outside challenge.

A design partner fits these:

• No designer or researcher on staff: someone has to run interviews and build a testable prototype in days.
• A pet idea: an outside facilitator asks the kill question without office politics.
• A board wants AI by a date: you need a data audit, a tested concept and a scoped plan the board can read.

The cost of discovery differs by route. In-house, you pay in the trio's time away from delivery; with a partner, you pay a fee plus about 2 hours a day from your leads.

Our workshop runs 1 to 2 weeks with your product, engineering and business leads for about 2 hours a day. The team ranks use cases on those four criteria, then tests the top concept with 5 users. You get 5 deliverables: a task map, a ranked use case list, a tested concept, a risk register and a scoped plan. Here's what a facilitated AI discovery workshop costs: $8,000–$20,000.

You own the plan afterward, and some teams take it to their own team. When the decision is "build", the work moves into AI product design.

Bottom line

Product discovery buys a decision, and an AI feature needs five extra checks before anyone designs a screen. Run the four risks first, then the AI lane, inside one timeboxed phase.

Run the 8-check exit gate above on your next idea, and add the 4 AI checks when it uses a model. If the AI lane comes back mostly unknowns, that is what our AI discovery workshop is for.

Before your phase ends, I'd book a weekly customer slot of 30 minutes, so the gate opens onto a habit instead of a handoff.

FAQs