The New Default. Your hub for building smart, fast, and sustainable AI software

See now
Beyond Guesswork: The Imperative of Scientific AI-Driven Product Discovery

Do You Need AI Product Discovery?

Michał Nowakowski
|   Updated Oct 11, 2026

AI product discovery uses AI agents to help product and business leaders move from a customer pain point to a scored use case and a working prototype, with people making every decision along the way.

It matters now because engineering got fast, but we're no better at deciding what deserves to be built. In July 2026, AWS published a case in which Henry Schein One's leadership team built four working prototypes in under 24 hours, a level of fidelity that the company estimates would normally take 8 to 12 weeks. Below is how the process worked, the mechanism behind it, and the places where it can mislead you.

Executive Summary

AI product discovery moves the evidence for a product decision from documents to working prototypes, which makes discovery behave more like an experiment than a debate.

Once AI coding has made building cheap, the expensive mistake is building the wrong thing quickly, so the bottleneck shifts upstream to the people who decide what gets built.

Henry Schein One's pilot shows how much that cycle can be compressed: 17 senior leaders, four prototypes in under a day, and two moving toward production. The gains are real, but a prototype that impresses a leadership room is still a hypothesis until customers have used it.

Why Is Product Discovery the New Bottleneck for AI-Native Teams?

Product discovery has become the bottleneck because AI sped up delivery but left the decision about what to deliver largely unchanged. AWS's AI-Driven Development Lifecycle (AI-DLC) replaces sprints with "bolts," work cycles measured in hours or days.

Upstream, little has changed. A product leader spends weeks gathering feedback, building a business case and writing requirements. Then the vision reaches engineering as a slide deck or a spec. Henry Schein One described the result plainly: the nuance was gone, the "why" had to be re-explained in meetings, and leadership couldn't judge whether an idea had merit until it was already being built.

Put that next to a fast delivery team and the economics flip. When building takes days, the costliest error becomes a fast, confident build of something nobody needed, and every speedup in engineering raises the price of a weak discovery process.

What Did Henry Schein One Change in Its Product Discovery Process?

Henry Schein One serves more than 100,000 dental practices, and its developers were already working with AI coding assistants. The leadership team wanted the same kind of help for the people deciding what to build, so they worked with AWS on a method called AI Product Discovery and Strategy (AI-PDS). It applies AI-DLC's core rule, "AI proposes, humans decide," upstream of development.

The engagement had two parts. First came a facilitated "Mob Discovery" session in which all 17 senior leaders defined the business context, named pain points and prioritized use cases, with AI structuring the discussion. Then small teams of four or five each took one prioritized use case and built a prototype. AI helped them articulate the problem, score opportunities against weighted criteria and generate the prototype specification. The leaders didn't write code. They debated priorities and made the calls.

According to AWS, the session produced four working prototypes in under 24 hours, and two are now advancing toward production. Because AI-PDS feeds directly into the Inception phase of AI-DLC, the development teams started with the full reasoning behind each priority instead of a handoff document.

The most telling detail is how the conversation in the room changed. Leaders stopped describing what they imagined and started saying "let me show you."

How Does AI Product Discovery Work in Practice?

AI product discovery works by turning each product idea into a cheap, testable artifact and recording why it was kept or killed. That's what makes it "scientific": a hypothesis becomes a prototype, the prototype produces evidence, and the evidence drives a decision someone has to sign.

AI-PDS covers six stages: envisioning (pain points and voice of the customer), use case intake, prioritization, prototyping, product strategy and go-to-market. AWS's open-source sample implementation, AI-PLC on GitHub, runs this as a guided workflow in Claude Code or Kiro. Three of its mechanisms are worth borrowing even if you never touch the repo.

The first is approval gates: the agent drafts and asks clarifying questions, and a person answers and signs off before the next stage, so judgment stays with whoever is accountable for the outcome. The workflow also writes every decision and input to an audit file. Six months later, you can check why use case B beat use case A and whether that reasoning held up. Finally, each prototype ships with a portable markdown spec that any delivery team can pick up, which is how context survives the handoff.

The difference from a conventional process is mostly about what counts as evidence and how long it takes to get it:

Traditional discovery

AI product discovery

Main artifact

Slide deck, PRD

Working prototype + portable spec

Time to a testable concept

Weeks (8–12 at Henry Schein One's fidelity)

Hours to days

What stakeholders react to

A description of an idea

Something they can click

Decision record

Meeting notes, if any

Logged rationale behind each choice

Handoff to engineering

Re-explained in meetings

Spec and reasoning carried forward

What Does AI Product Discovery Look Like Outside a Large Enterprise?

The same pattern works for a first-time founder without a 17-person leadership team. Monterail worked with a UK construction-industry founder on an AI cost-intelligence platform for construction finance, a product that had to win the trust of CFOs and boards.

Discovery started with hypothesis-first workshops. Each hypothesis about how construction cost management should work became a prototype feature, and each prototype became a proof point the founder could put in front of stakeholders. An interactive, AI-powered prototype was ready two weeks after kickoff. The MVP followed in three months on a 500-hour budget, with no rework after delivery, and passed its initial pilot review at the CFO and board level.

The more instructive moment came later. While preparing the pilot, the team found that the first client's accounting data was too incomplete and inconsistent to power the AI layer reliably. The team paused the AI rollout rather than ship outputs that could have misled a board. Fast prototyping got the product into the right shape, and holding the AI back until the data could support it protected the platform's credibility with the board.

What Are the Risks and Limits of AI Product Discovery?

The main risk is mistaking speed for validation. A prototype built in a day shows that an idea can be made concrete. It doesn't show that customers will pay for it, and Henry Schein One's published results measure prototypes and production candidates, not market outcomes.

Polish creates its own problem. A working app persuades far more than a slide does, which is exactly why it can push a room into consensus too early. Teams also get attached to things they've built, even in a day. Decide the kill criteria before the prototype exists, and get it in front of real users before anyone commits budget.

In regulated industries like dentistry, data and compliance set hard limits. AWS's sample states plainly that it is for experimental and educational use and that generated apps run on localhost with no authentication layer. That's fine for a workshop and not fine for real patient or financial data. If your prototypes need production data to be convincing, you need de-identified datasets, a HIPAA- or GDPR-aware environment and someone who owns that decision. As the construction-finance pilot showed, poor data can make an AI feature look worse than it is, or better.

Henry Schein One's session was also facilitated with AWS, and a one-off workshop is easier than a habit. The harder part is making evidence-first discovery how roadmap decisions get made every quarter, with a decision log people actually read and a delivery team that can take a prototype spec and run with it.

How Can Product Teams Start With AI Product Discovery?

Start small, with one decision you already have to make. Pick a single pain point your leadership keeps debating and run it through the full loop:

  1. Write down the hypothesis, the people it serves and the metric that would prove it wrong.

  2. Let an agent draft use cases and score them against criteria your team agrees on, then argue with the scores.

  3. Prototype the top one or two in days, not weeks, with synthetic or de-identified data.

  4. Put them in front of real users before any build commitment.

  5. Log the decision and its rationale, and give engineering the full spec rather than a summary.

The open-source AI-PLC workflow is a reasonable starting template because it's plain markdown you can adapt to your own prioritization framework. Treat it as a scaffold and build your production tooling separately.

Key Takeaways

  • AI made delivery fast, so the bottleneck moved upstream to deciding what to build.

  • Working prototypes replace slide decks as the main evidence in discovery. Henry Schein One built four in under 24 hours.

  • "AI proposes, humans decide" only works with explicit approval gates and a logged rationale behind every choice.

  • A prototype that wins over leadership is still a hypothesis. Set kill criteria first and test with real users.

  • Data readiness and compliance decide whether AI prototypes can go anywhere near production.

What Does It Take to Make AI Product Discovery Stick?

AI product discovery pays off when it changes how roadmap decisions get made. Faster prototypes are only the visible part. It needs leaders who are willing to be proven wrong by a prototype, data clean enough to make AI features credible, and a delivery team that can pick up a spec on Monday and keep the reasoning intact.

Monterail runs discovery workshops and rapid AI prototyping for teams that want to test ideas before committing a full build, and then takes the validated ones into production. If there's a product decision your team keeps circling, let's talk about turning it into something you can test.

AI Product Discovery FAQ

Michał Nowakowski
Michał Nowakowski
Solution Architect and AI Expert at Monterail
Linkedin
Michał Nowakowski is a Solution Architect and AI Expert at Monterail. His strong data and automation foundation and background in operational business units give him a real-world understanding of company challenges. Michał leads feature discovery and business process design to surface hidden value and identify new verticals. He also advocates for AI-assisted development, skillfully integrating strict conditional logic with open-weight machine learning capabilities to build systems that reduce manual effort and unlock overlooked opportunities.