Customer Discovery and AI Problem Scoping
How to run discovery sessions with non-technical stakeholders, translate vague requests into buildable AI specs, and use the AI feasibility quick-check before writing a single line of code.
Why Discovery Is the Hardest Part
Technical interviews are graded on a known answer. Discovery sessions are graded on producing a useful answer from a conversation where the customer often does not know what they actually need. This is not a failure of the customer - it is the nature of working with people who are experts in their domain but not in what AI can and cannot do. Your job in discovery is to bridge that gap in one or two sessions.
The risk on both ends is real. Underdiscovery means you build the wrong thing and find out at the demo. Overdiscovery means you spend three days in meetings and arrive at prototyping with nothing built. The target is a discovery session that ends with a written specification you could give to a developer who was not in the room and have them build the right thing.
The Three Questions That Drive Every Session
Regardless of the customer domain or the stated problem, every FDAE discovery session orbits three questions:
The AI Feasibility Quick-Check
Not every problem is a good AI problem. Before committing to build, run the AI feasibility quick-check - five questions that take ten minutes and can save a week of misdirected work:
| Question | Green signal | Red signal |
|---|---|---|
| Does the task require judgment over text, images, or structured data? | Yes - core LLM strength | No - consider a rules engine or query |
| Is there an example of a good output I can show the model? | Yes - few-shot ready | No - spend more time in discovery |
| Is a wrong answer obviously wrong (or at least detectable)? | Yes - safe to iterate | No - silent errors in production are high-risk |
| Does the customer have the data the model needs as input? | Accessible today | Locked behind a 6-week access request |
| Is a 90% solution acceptable? | Yes - common in enterprise AI | No - regulatory or safety requirement for 100% |
If you get four green signals out of five, build. If you get more than one red signal, spend more time in discovery or redirect to a different problem in the same workflow.
Translating Vague Requests Into Buildable Specs
Customers describe problems in business language: “we need AI to help with our customer feedback process.” The FDAE spec that drives prototyping is technical: “Given a plain-text customer feedback email (mean length 200 words), extract: (1) sentiment {positive, negative, neutral}, (2) product area mentioned (mapped to a controlled vocabulary of 12 categories), (3) a one-sentence summary suitable for a team dashboard. Output as JSON. Latency under 3 seconds.”
The translation process has four steps:
Common Anti-Patterns in Discovery
The Discovery Output: The One-Page Spec
Every discovery session should produce a one-page specification before you leave the room (or end the video call). The format does not matter - a whiteboard photo, a shared doc, a quick typed summary. The contents that matter: input artifact, output format, quality bar, constraints, and the single most important thing the customer wants to be able to say at the end of the engagement. Read it back. Get a verbal “yes, that’s it.” Now you have a build contract.
Ready to Go Deeper?
Live instructor-led courses from our partners. Affiliate disclosure.