AI Product Discovery & AI product development: the right problem first

What separates AI product discovery from classic discovery

Classic software is deterministic: same input, same output, and every defect traces back to a line of code. AI systems are probabilistic – they weigh probabilities, and their behaviour depends on training data, system settings and context. Discovery therefore has to answer one question more than it used to: can this problem tolerate a solution that is sometimes wrong?

The answer decides the product architecture. Fraud detection at a bank needs explainability and human control; a phrasing suggestion in an editor tolerates errors because the user corrects them in seconds. The deep dive “AI product discovery: finding problems AI should actually solve” provides the framework of four core questions for this – problem proven, AI justified, error tolerance defined, data legal.

The table below shows the shift at a glance. It also explains why discovery becomes more important in the AI era, not less: the less the system's behaviour is fixed in code, the more depends on a clean understanding of the problem.

The hype trap: technology is not an end in itself

The most common mental traps at the start of an AI initiative are well documented: adopting trends blindly, ignoring negative signals from the test phase, and naively assuming that clean, structured data already exists. All three lead to the same result – a technically impressive feature that delivers no measurable business value.

The corrective is uncomfortable but simple: every initiative is measured against value, effort and risk before resources flow. A use case that is technologically fascinating but only optimises marginal processes gets rejected. That discipline starts in discovery – not in the roadmap debate, once political pressure has already distorted prioritisation.

The context workspace: scattered signals become product context

In most companies, market signals, customer feedback and technical knowledge sit spread across five or more systems – Jira, Confluence, code repositories, e-mail, people's heads. Good product decisions, however, need the whole context. A context workspace connects these sources into a living product context that keeps learning and can be extended manually with the nuances that matter.

For discovery this changes the day-to-day concretely: when a customer reports confusing behaviour in the price calculation, you research directly in the source code instead of pulling developers out of focused work – and the investigation flows back into the system as a permanent artefact. Without this context every AI guesses; with it, it knows the historical and technical background of a decision.

The AI MVP: test the wizard before you build the machine

Building a custom model is the most expensive and riskiest way to disprove a wrong hypothesis. The discovery phase therefore validates with the smallest possible stake: Wizard-of-Oz tests, in which a human simulates the AI, and foundation models that make an idea testable in days instead of months.

In this phase the MVP is not a sellable product but a learning instrument. It answers two questions: does the solution solve the problem well enough that users want it – and at what error rate does acceptance tip? The deep dive “The MVP for AI: test the wizard before you build the machine” shows the test setup in detail.

Customer journey: trust is part of the product

In surveys, roughly half of users say they distrust AI systems. For B2B software that means trust is not a marketing task after launch but a design problem for discovery. The AI journey has four decisive moments – expectation, first win, first error, habit – and the first error decides adoption more often than the first win.

A B2B user must be able to understand why a system makes a recommendation. A percentage alone is not enough; the product has to deliver the context of the decision. What an onboarding looks like that communicates uncertainty transparently instead of hiding it is covered in “Customer journey mapping for AI: onboarding that builds trust” – including how acceptance criteria for the define phase are derived from it.

The EU AI Act: compliance as a design principle, not a brake

The EU AI Act classifies AI systems by risk potential – and the risk class decides whether a product idea is legally and economically viable. That is why classification belongs in discovery, not in a legal review shortly before release. If the legal risk is too high, the problem framing or the data basis gets iterated before budget is committed.

Compliance by design means concretely: planning bias detection and mitigation, keeping data provenance fully traceable, and making machine decisions reviewable and overridable by humans – for high-risk systems this is mandatory. “The EU AI Act for product managers: compliance as a design principle” walks through risk classes, deadlines and the five building blocks that belong in the product.

Designing requirements for data, not just for features

Open language models have broad general knowledge. The strategic advantage of a B2B product comes from what they lack: specific process knowledge and proprietary, non-public data. The quality, relevance and real-world representation of that data base determine the quality of the end product – not the model choice.

For discovery this means: every product hypothesis comes with a data hypothesis. Where is the data captured, who owns it, which metric makes its quality measurable? Answer these questions in the discover phase and you avoid the most common failure of the build phase – a model waiting for data that will never exist.

The output of the discover phase: a qualified hypothesis

At the end of discovery stands a reviewable artefact, not a gut feeling: a proven user problem, a justified decision for or against AI, a defined error tolerance, a clarified legal position and a data hypothesis with a quality metric. Only this package justifies the transition into the define phase.

The order is the point. Teams that start with the prompt catch up on this work later – under time pressure, with budget committed and a half-finished feature at their backs. Teams that do it up front specify against a stable target.

Frequently asked questions