AI-Assisted Product Discovery: When Code Is Cheap, Judgment Is the Job

TL; DR: Deciding What to Build Is the New Job, Now that Code Is No Longer a Constraint

Agentic coding has removed the cost gate that used to stop product teams from chasing every idea at once, and the constraint has moved to product judgment: the ability to tell what is worth building. AI-Assisted product discovery can prepare that judgment by reading far more customer evidence than any product person could. Such a discovery agent analyzes three families of sources, checks eight patterns, and argues both against and for your current direction.

The A3 Framework has a name for this work: Assist, the agent analyzes and prepares, and the humans decide. The framework also helps to define the agent limits with the A3 Handoff Canvas – what the agent does, what the human does, which data we use, etc. – and the AI Definition of Done – what a quality AI output “looks like” – before the first run.

Thesis: This article on AI-assisted product discovery explains how product teams can use AI agents to compare customer feedback, usage data, and stakeholder requests with their product vision, product goal, product roadmap, and past decisions, flagging drift, bias, and sunk costs, while humans keep the decision under the A3 Framework’s Assist category.

Disclaimer: I read Charniak/McDermott’s book on “Artificial Intelligence” decades ago; of course, I use AI for research, translations, proofreading, challenging story arcs and article structures, creating artifacts such as graphics, and summarization. It is a production tool, not a substitute for thinking.

---

🎓 🇬🇧 The AI4Agile Online Course v4 — November 27, 2026, at $149 — Join the Waitlist

Sooner or later, a CFO will ask what your AI use actually returns. “It saves me time” will not survive that meeting.

The first wave of AI adoption rewarded practitioners who learned to prompt. That skill still matters, and this course still teaches it. The second wave rewards something rarer: people who can turn individual AI use into knowledge that survives departures, spend that can be explained and steered, and output that organizations can trust. That work is process design and change management. You have been doing both for years, on harder problems than this.

EXCLUSIVE: The new A3 Delegation Lifecycle System with seven ready-to-use templates, from the AI Workflow Inventory to the AI Definition of Done to the AI Working Agreement, to make sense of delegating work to AI models.

The AI 4 Agile Online Course v4 is in English. 🇬🇧

What You Will Get:

✅ 20+ hours of self-paced video modules ✅ 4 Live onboarding session ✅ A cohort-hardened​, proven course design ✅ Learn to 10x your effectiveness with AI; your stakeholder will be grateful ✅ Apply AI to classic use cases of “Agile” ✅ The A3 Delegation System comprising seven ready-to-use templates ✅ All texts, slides, prompts, and graphics ✅ Access custom GPTs, including the “Scrum Anti-Patterns Guide GTP” ✅ Guaranteed: Lifetime access to v4 ✅ AI4Agile Foundation Certificate: 40 questions in 45 minutes.

👉 Please note: The course will be available for $149 from November 27-30, 2026! (After that, $249.) 👈

🎓 Join the Waitlist now and be the first to know: The AI4Agile Online Course v4 — November 27, 2026, at $149 — No Coding Required!

---

🇩🇪 Zur deutschsprachigen Version des Artikels: KI-unterstützte Product Discovery.

🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 35,000-plus subscribers.

🎓 Join Stefan in one of his upcoming training classes!

---

Both AI Product Camps Hand Off the Part That Just Became Scarce

Product people seem to be splitting into two camps over agentic coding. The first camp is celebrating: If a coding agent can build a working version of an idea in an afternoon, why argue about which of five ideas to pursue when you can build all five and let the market tell you which one sticks? (Yes, assuming you have the credits to keep feeding tokens into your coding agents.) The second camp has drawn the opposite conclusion. It expects the next agent to take over the choosing as well, preferably with a dashboard and a confidence score attached to each recommendation.

Both camps are wrong for the same reason: each hands off the one capability that has just become scarce. Throwing spaghetti at the wall has become affordable in tokens. Yet it remains as unaffordable as ever in focus, maintenance, and the attention of customers who have to make sense of five half-finished features. An agent that chooses for you, on the other hand, has taken over the part of product work that nobody can delegate without also delegating the accountability for the outcome, whatever the org chart says about who owns the product.

Coding Used to Be the Gate That Forced Us to Choose

For decades, writing software was expensive and slow, and that expense did a job nobody had assigned to it: It acted as a sanity check and a cost gate. When building a feature took a team several weeks, the product people had to decide which idea deserved those weeks, and a weak idea often died in a prioritization discussion before anyone wrote a line of code. The gate was crude, and plenty of bad ideas slipped through anyway (usually the ones with a senior sponsor with budget authority); nevertheless, it forced a choice.

Agentic coding has removed much of that gate, and the theory of constraints predicts what happens next. Eliyahu Goldratt’s five focusing steps end with a warning that is easy to skip: Once you elevate a constraint, “the weak link may not remain weakest,” as the Theory of Constraints Institute puts it, and the constraint moves somewhere else in the system. In product development, it moves to judgment: product taste, the ability to read customer evidence, and the discipline to say no to an idea that a coding agent could build by Friday. Andrew Ng made the same observation on the No Priors podcast in August 2025, as Business Insider reported: “The bottleneck is deciding what do we actually want to build.”

Photography went through a comparable shift. When every frame of film cost money and darkroom time, photographers composed carefully before they pressed the shutter, so the cost of a frame forced the judgment upfront. Digital cameras removed that cost and moved the work to selecting and editing, where shooting thousands of mediocre frames mostly buries the person who has to pick the few worth printing. Product teams now face that editor’s problem: A coding agent can produce a working version of almost any idea, and someone still has to decide which version deserves a customer’s attention. Not everyone is as gifted as Steve Jobs, even though plenty of people still try to be the product manager in charge.

Every Roadmap Is a Snapshot of What You Knew Last Month

If judgment is the new constraint, it helps to look at the system product teams use to exercise it. The sketch below comes from my Product Owner classes, where I use it to show the challenges product people face when they manage a product backlog. (This AI-assisted product discovery article covers its left half.)

The product vision sets the direction, backed by a product strategy that describes how the organization intends to turn that vision into reality. At the operational level, the strategy becomes something more tangible and nearer-term: a product roadmap or, if your team borrows from Scrum, a Product Goal. (Plenty of product teams use elements of Scrum and would deny practicing it, which is completely fine; we are not paid to practice Scrum but to solve our customers’ problems within the given constraints while contributing to the organization’s sustainability.) Together, these artifacts form the narrow neck of a funnel: Every idea, request, and data point pours into its wide mouth, and only what serves the vision and the goal passes the neck and earns a place in the work. Below the neck, the sketch shows where the surviving ideas go: into a hypotheses backlog for validation through experiments or, when an idea does not serve the goal right now, into an anti-product backlog; both destinations depend on a human decision.

Each of these artifacts is a snapshot. A product roadmap, a product goal, or a product backlog represents your understanding of your customers, the market, and your competitors at the moment you wrote it down. I like to put it this way: Based on what we know now, this is our best abstraction of how we can create customer value, and it may change as we learn more. Scrum makes the same point when it calls the Product Backlog “an emergent, ordered list” in the Scrum Guide: Its composition and order change as the team learns something, which also lets the team judge earlier decisions in hindsight and correct course.

A snapshot is only useful if someone compares it with what has happened since, which raises two practical questions: Where does the new information come from, and who has the time to read it?

Cannot see the form? Please click here.

What Pours Into the Funnel, and What the Agent Has to Remember

Information reaches a product team through two kinds of sources, and both have grown faster than any team can read.

Passive sources: Information arrives without the product team asking for it, for example:

• Messages from the contact form on your website
• Tickets in the customer care department’s system
• Daily traffic and user behavior data from your analytics platform
• Product requirements from internal stakeholders, which arrive unrequested and usually with political weight attached.

Active sources: The product team goes out and gets the information, for example:

• Notes from continuous user interviews
• Ideas from the product people themselves, who work with the product every day
• Observations of users in their natural habitat, solving the problems they chose your product to help with
• User research such as user story mapping sessions with internal and external stakeholders.

Nobody reads all of this every week, and that is the opening for an agent. Depending on the size of your organization, the agent runs daily or weekly, reads everything that comes in, and prepares what humans need for product decisions.

However, two families of sources are not enough, and in my observation, this is where the typical “AI analyzes your customer feedback” pitch stops. An agent that only reads external evidence can tell you that customers dislike a feature; it cannot tell you that you have kept funding that feature for three quarters because of what you already spent on it. For that, the agent needs a third family.

Organizational memory: The record of what the organization committed to and spent, for example:

• Current and previous product goals and product roadmap versions
• Notes from past stakeholder reviews, and release notes
• The anti-product backlog, including the reason for each rejected idea
• Past stakeholder decisions, and the effort and money already spent on initiatives.

The agent’s job, then, is to compare external evidence (what customers, users, and stakeholders say and do) with internal commitments (what the organization decided and spent). In most organizations, this memory lives in people’s heads, Slack threads, and Jira comments rather than in a tidy decision log, so start with what exists, for example, the current and previous product goals or product roadmaps and the raw notes of your last stakeholder reviews. Questions the agent cannot answer because records are missing are a finding in themselves, because they show where your organization doesn’t document knowledge or decisions about why it said no.

Another boundary is the first question the A3 Framework asks of any task: Should AI touch it at all? Counting tickets, computing the revenue at risk from billing and CRM data, and drawing the dashboard are deterministic jobs that a BI tool or a spreadsheet already handles reliably. The agent reads those computed figures next to the unstructured text and connects the two, while the tools built for arithmetic stay with the arithmetic.

Eight Questions for a Weekly AI-Assisted Product Discovery Check

The agent works through eight questions in three groups, and each group needs different inputs.

Drift, or has the world moved since we last looked: These questions need all three families, because drift only shows when you hold today’s evidence against yesterday’s commitments:

1. Where does the data point to a change in customer perception or needs?
2. Does our product roadmap or our product goal still align with what real customers say and do?
3. Have we started moving in the wrong direction because we ignored earlier feedback from the market? (The agent can only answer this one if the organizational memory shows what the team saw at the time and decided to set aside.)

Gaps and pain, or what customers keep telling us: These questions run on passive and active sources plus the figures your BI tool already computes:

4. Which functional areas do customers bring up again and again that the product does not address?
5. Which critical usability issues do customers complain about?
6. Which customers threaten to cancel their subscriptions or purchases because the product disappoints them, and what is our risk exposure? (The exposure figure comes from billing data; the agent links it to what those customers wrote.)

Self-deception, or whether we are fooling ourselves: These questions depend on organizational memory above all:

7. Are the product strategy, the product roadmap, or the product goal biased, built to confirm a belief about the product’s future while the market moves in a different direction?
8. Have we fallen victim to the sunk cost fallacy?

In the self-deception group, an agent does better than a tired human reader. People usually struggle to spot bias in their own plans, and what they’ve already spent tends to argue louder than evidence of what customers want. Both patterns are old acquaintances; I described them, together with the persona-driven self-fulfilling prophecy and the habit of ignoring sales and customer support, in Product Discovery Anti-Patterns Leading to Failure. The exciting new part is that an agent can check for them every week, across every source, without getting tired or diplomatic.

In AI-Assisted Product Discovery, the Agent Prepares the Decision, and the Product Team Makes It

In terms of the A3 Framework, everything so far is Assist, which the original A3 Framework article sums up as “AI expands options. You own the outcome.” The agent reads the sources and prepares the briefs, and the product team decides. The moment the agent moves an idea into the hypotheses backlog, kills a roadmap item, or reorders the product backlog on its own, the work has crossed into Automate, which is the wrong category for a decision that depends on product judgment, which is the capability the shifted constraint now demands from humans.

However, the preparation itself has a catch. Language models tend to agree with the person asking. Recent research suggests the problem has not gone away: Seo, Atanasova, and Augenstein tested 14 models on 42K questions and found that “all models are susceptible to user opinions regardless of size,” with models “most influenced by how confidently an opinion is stated, whom it is attributed to” (Claim Framing as a Driver of LLM Sycophancy, October 2026). A product goal handed to an agent is exactly that: a confidently stated position backed by the organization’s authority.

So, I suggest running the analysis as two briefs. The first brief collects the evidence for the current direction, while the second brief starts from the assumption that the product goal is wrong and builds the strongest case against it from the same data, citing every source. The humans then read both side by side. (The study documents the agreeable behavior; the two briefs are my countermeasure, and they apply an old rule of mine: Never accept a model’s first answer.)

The A3 Handoff Canvas is where the team writes this down before the first run: The inputs name the three families of sources, the outputs name the two briefs, and the stop rules say what the agent must never do, namely rank ideas, recommend a decision, or move anything. The AI Definition of Done then states what each brief must contain before anyone discusses it, and the difference is easiest to see with question 8, applied to a hypothetical custom reporting module that has been on the roadmap for a while.

An Automate verdict, which is what you do not want:

• “The custom reporting module shows sunk cost characteristics. Recommendation: stop development.”

What the product team reads instead, assembled from both briefs, which is what the AI Definition of Done asks for:

• Commitment: “The module has been on the product roadmap since the start of the year and received development time in every release cycle since.” (Source: roadmap versions)
• Spending: “Most of the recent iterations went into report templates and export filters.” (Source: release notes)
• Customer evidence: “Requests for the module come from long-standing accounts that want custom CSV formats; recent onboarding interviews do not mention it.” (Sources: support tickets, interview notes)
• Case for continuing (first brief): “Enterprise accounts up for renewal list custom reporting as an open requirement.” (Source: stakeholder review notes)
• Case for stopping (second brief): “Customers who canceled during the period cited friction in the core workflow, and observed users export raw data to spreadsheets instead of using the in-app reports.” (Sources: cancellation tickets, observation notes)
• Open question for the product team: “Can scheduled exports cover the enterprise renewals without funding another cycle of module development?”

What happens next is a human call, and the options sit on the left side of the sketch: A finding can become a hypothesis in the hypotheses backlog and go to validation through an experiment; it can land in the anti-product backlog together with the reason why it does not serve the product vision or the product goal right now; it can trigger a change of the product goal itself; or the product team can dismiss it. Each of these destinations is a decision that the people accountable for the product make, preferably together.

Five Ways AI-Assisted Product Discovery Goes Wrong

A rule I apply to every AI initiative holds here as well: Do not apply AI on top of dysfunctional systems or processes. If a product team has no hypotheses backlog, runs no experiments, and keeps no anti-product backlog, the agent’s briefs land on nothing, and the following failure modes show what that looks like in practice:

1. The loud-customer bias: Passive sources over-represent vocal customers, while customers who quietly cancel rarely fill out a contact form first. An agent reading tickets will give the most weight to whoever writes the most tickets, unless the product team tells it to also look at who stopped writing, for example, in usage data from accounts that stopped logging in.
2. Sanitized records: When the notes of a stakeholder review say “stakeholders loved the demo” because nobody wanted to write down the objections, the organizational memory the agent reads has already been edited for comfort. The opposing brief can only argue from the records it receives, so a sanitized record produces a convincing case for the wrong conclusion. (Anyone who has watched a review turn into a performance knows how often this happens, or, to use a German proverb: Wer schreibt, der bleibt.)
3. Report theater: The briefs look polished, people read the summary, and nobody opens the evidence. Polished AI artifacts quickly fool people into believing that the AI is doing the real job, and a discovery check that nobody questions may be worse than none, because it lends a bad decision the authority of data.
4. The HiPPO override: The agent flags a misalignment, a stakeholder requirement with enough political weight wins anyway, and three weeks later, nobody reads the briefs anymore.
5. The authority mismatch: When an agent holds customer evidence against commitments, drift at the operational level often points to a flawed assumption at the strategic level, in the product vision or the strategy. A product manager who can change the product goal but not the strategy then receives a finding without the authority to act on it, and the brief travels from inbox to inbox until it is out of date. So decide before the first run who receives which kind of finding and who takes a strategic finding to the people who own the product strategy; the task split of the A3 Handoff Canvas is the place to write that down.

Amazon’s Fire Phone shows how expensive this gets when the highest-paid person is the CEO: Fast Company’s Austin Carr interviewed more than three dozen current and former employees, and a former engineering head said of the phone’s Dynamic Perspective feature, “We poured surreal amounts of money into it, yet we all thought it had no value for the customer,” adding, “Whenever anyone asked why we were doing this, the answer was, ‘Because Jeff wants it.'” (GeekWire’s summary of the Fast Company report, January 2015). Three months after launch, Amazon CFO Tom Szkutak disclosed a $170 million write-down, “primarily related to Fire Phone inventory valuation and supplier commitment costs” (GeekWire, October 2014). (The price did its share, too; Amazon’s devices chief, David Limp, later told Fortune, “We didn’t get the price right.”)

AI-Assisted Product Discovery – Conclusion: Run One Discovery Check Before Your Next Stakeholder Review

You do not need an elaborate setup to try this. Take the sources you already have, for example, last month’s support tickets and contact form messages, the notes from your last ten user interviews, and last quarter’s product roadmap, and run questions 2 and 7 as two briefs against your current product goal. Then check the evidence inside the product team first, in your next refinement session or a dedicated discovery check, before anyone outside the team sees it: Open the sources, look for what the agent misread, and decide which findings you are willing to defend. Only once the team owns the argument does it go to the next stakeholder review, as a token for discussion, never as a decision.

If you want to practice this before you try it on your own product, the AI4Agile Online Course v4, which launches on November 27, 2026, includes an exercise in which you build this discovery agent with the data of MegaBrain.io, the course’s fictional startup.

And when your agent’s second brief makes a convincing case next month that customers have stopped caring about the feature your product roadmap is built around, who in your organization has the authority to act?

Questions This Article on AI-Assisted Product Discovery Answers

Why Does Product Judgment Become the Bottleneck When AI Agents Write Code?

Agentic coding removed the cost gate that once forced product teams to choose between ideas. When building a feature took weeks, weak ideas often died in a prioritization discussion; now a coding agent can build a working version of an idea in an afternoon. As Goldratt’s theory of constraints predicts, the constraint moves elsewhere, to product judgment: deciding which idea deserves customers’ attention.

Should an AI Agent Make Product Decisions?

No. Under the A3 Framework, product discovery analysis belongs in the Assist category: the agent reads customer feedback, usage data, stakeholder requests, and the organization’s past decisions and prepares the evidence, while the product team decides. The A3 Handoff Canvas records the agent’s stop rules before the first run: no ranking of ideas, no recommendations, and no moving items in the product backlog.

What Data Should a Product Discovery Agent Analyze?

A product discovery agent needs three families of sources. Passive sources arrive unasked: contact form messages, support tickets, analytics data, and stakeholder requirements. Active sources come from the product team’s own work, such as user interviews, observations, and user story mapping. Organizational memory covers past product goals, roadmap versions, rejected ideas with reasons, and money already spent; without it, the agent cannot detect sunk costs.

How Do You Stop an AI Agent From Confirming Your Roadmap?

Run the analysis as two briefs. The first brief collects the evidence for the current product goal; the second assumes the goal is wrong and builds the strongest case against it from the same data, citing every source. Language models tend to agree with the person asking: Seo, Atanasova, and Augenstein (2026) found all 14 models they tested susceptible to user opinions, regardless of size.

How Does AI-Assisted Product Discovery Fail?

They fail in five recurring ways: they overweight vocal customers, read meeting notes sanitized for comfort, produce polished briefs nobody checks, lose to the highest-paid person’s opinion, and deliver strategic findings to people without strategic authority. Amazon’s Fire Phone shows the HiPPO override at the top: engineers kept building a feature they believed had “no value for the customer” because Jeff Bezos wanted it.

AI-Assisted Product Discovery — Related Posts

AI Transformations And Agile Transformations Rhyme

You Already Have an AI Working Agreement. Write It Down.

If You Can Facilitate a Retrospective, You Can Audit Your AI

The AI Definition of Done: Human in the Loop Is Not a Quality Standard

The AI Delegation Lifecycle: Your Team Has AI Outputs. Where Are the Decisions?

Assist, Automate, Avoid: How Agile Practitioners Stay Irreplaceable with the A3 Framework

The A3 Handoff Canvas: Six Questions That Turn AI Delegation Into a Repeatable Workflow

The A3 Framework: Assist, Automate, Avoid — A Decision System for AI Delegation

👆 Stefan Wolpers: The Scrum Anti-Patterns Guide (Amazon advertisement.)

📅 Training Classes, Workshops, and Events

Learn more about AI-assisted product discovery with our AI and Scrum training classes, workshops, and events. You can secure your seat directly by following the corresponding link in the table below:

See all upcoming classes here.

You can book your seat for the training directly by following the corresponding links to the ticket shop. If your organization’s procurement process requires a different purchasing approach, please contact Berlin Product People GmbH directly.

✋ Do Not Miss Out and Learn More about AI-Assisted Product Discovery — Join the 20,000-plus Strong ‘Hands-on Agile’ Slack Community

I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you would like to join, all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.