AI product discovery: finding problems AI should actually solve
Marc GasserSerial Founder · GTM & MarketingConnects AI with revenue operations and builds autonomous GTM systems for predictable growth.TL;DR
- The most common AI product mistake isn't technical but strategic: a capability gets shipped instead of a problem solved. Discovery for AI therefore starts with the users' workaround, not the model.
- Four questions decide before the first prototype: is the problem proven? Is AI the best solution? How expensive is an error? Does the data exist, legally and accessibly? Fail to answer one and you build on sand.
- Cagan's four product risks (value, usability, feasibility, viability) remain the frame – AI sharpens feasibility (model quality is uncertain) and viability (compliance, the EU AI Act).
Key findings
- Gartner names “unclear business value” as one of the four main reasons GenAI projects die after proof of concept – a discovery failure, not a technology failure.
- Continuous discovery in Teresa Torres' sense – weekly customer touchpoints by the product trio – matters more for AI products, not less: that is where you see users improvising today.
- The use case's error tolerance is the underrated criterion: the same model quality is brilliant for brainstorming and negligent for invoice approvals.
Why discovery has to test harder for AI
With classic features the most expensive discovery question is: does anyone want this? With AI, two more arrive that are just as lethal: will the model get good enough? And are we even allowed to? An idea can be desirable, feasible and still not viable – say, because the training data conflicts with GDPR or the use case falls into a high risk class under the EU AI Act.
Marty Cagan's four risks – value, usability, feasibility, viability – remain the best frame, but AI shifts the weights. Feasibility is no longer binary (“can we build it?”) but probabilistic (“does the model reach 95 per cent, and is 95 per cent enough?”). That is precisely why error tolerance belongs in every discovery conversation: what happens when the AI is wrong – a shrug or a compliance case?
The four questions before the first prompt
1. Is the problem proven? Not by agreement in a meeting but by observed behaviour: workarounds, exports to Excel, recurring support tickets. Teresa Torres' continuous-discovery principle – talk to real users weekly – supplies this raw material more reliably than any survey.
2. Is AI the best solution? Check the boring alternative first: a rule set, a better form, clean search. AI wins where inputs are unstructured, patterns complex and answers linguistic – not where if-else logic suffices.
3. How expensive is an error? Define error tolerance in writing before anyone builds. It determines architecture (human in the loop or not), UX (suggestion or automation) and the compliance path. A feature with low error tolerance needs a different product than the same feature with high tolerance.
4. Does the data exist? Gartner names data quality as abandonment reason number one. The discovery question is threefold: does the data exist, is it accessible, and may it be used for this purpose? In DACH the third question decides more often than the first two.
The problem check: does this really need AI?
Too many open assumptions – this is “AI for AI's sake” risk. Back to interviews before engineering time flows.
Tick what is already proven for your product idea – the result tells you whether to build, validate or stop.
Where the best AI ideas hide
The strongest AI use cases are rarely in the brainstorming minutes. They sit in your existing data: support tickets circling the same three topics. Feature requests that are really duplicates. Onboarding steps where users drop off in rows. Cluster customer signals across all sources and you find problems with proven frequency – and frequency is the best argument against the loudest stakeholder's favourite feature.
In brownfield, the code is part of discovery too: which components would be affected, how risky is the intervention, which business rules hang off it? An idea that is brilliant functionally and a minefield technically should be spotted early – not in the sprint. Code intelligence turns that check into routine instead of archaeology.
Recommendations
- Start with the workaround. Look for AI use cases where users visibly improvise today – exports, copy-paste, recurring tickets. Proven frequency beats any vision.
- Force the non-AI alternative. Every AI initiative must document why the boring solution is worse. If that argument is missing, it's AI for AI's sake.
- Write down the error tolerance. Before the prototype: what does a wrong answer cost, who is liable, is a human in the loop needed? That answer belongs in the spec, not the corridor.
- Keep the cadence. Weekly customer touchpoints à la Torres – precisely when agents speed up execution, the quality of your discovery becomes the bottleneck.
Scope & caveats
- The four questions are a filter, not a substitute for judgement: there are legitimate strategic bets that deliberately start before full validation – but then as a bet with a budget cap, not a roadmap commitment.
- The abandonment reasons cited come from Gartner's July 2024 prediction and are industry aggregates. Your portfolio may fare better or worse – what matters is that you check the same four points before investing.
The takeaway
Discovery is the part of product work no AI takes over – it can only feed it. Answer the four questions with discipline and you build AI features that solve a proven problem, leaving AI-for-AI's-sake to the competition.
Matching use cases from the library
From the article straight into practice: these use cases put the concepts to work with Teklens.
No new piece without you.
New articles, new interactive tools, new evidence – in your inbox first. And when you reply, we reply: you write directly with the authors, not with a no-reply.
No spam, no sharing, unsubscribe any time.