Requirements Discovery

TL;DR: The costliest AI mistakes come from building the wrong thing, and the usual cause is skipping discovery, jumping to a solution before understanding the problem. Requirements discovery means uncovering the real problem behind the stated request: who the user is, what success actually means (and how you will measure it), what the data truly looks like, and the constraints (latency, cost, accuracy bar, compliance). The core skill is working backwards from the user's outcome, not their proposed solution, and asking the questions that surface what they did not say.

The stated request is rarely the real problem

A user asks for "an AI chatbot for our docs," but the real need might be "support agents waste hours finding answers," which could be a search box, not a chatbot. Taking the request literally and building it leads to a technically-fine system that solves the wrong problem, the most expensive failure because you find out at the end. Discovery is the cheap insurance against it.

What to uncover

• Who is the user and what outcome do they want? Work backwards from the outcome, not the proposed feature. "What would success look like for them?"
• What does success mean, measurably? This is where discovery meets evaluation, if you cannot define how you will measure success, you cannot build toward it.
• What does the data actually look like? Volume, quality, format, freshness, edge cases. AI projects live or die on data reality, and the demo data is never the production data.
• What are the constraints? Latency budget, cost ceiling, the accuracy bar (how good is good enough, and what is the cost of being wrong?), privacy/compliance.
• What is out of scope and what is the simplest version that delivers value?

Working backwards

The discipline is to start from the user's problem and desired outcome and reason back to a solution, rather than starting from "we have an LLM, what can we build." This avoids technology-in-search-of-a-problem and keeps you solving something real (the customer-obsession instinct). Often the right answer is simpler than the impressive thing the user (or you) imagined.

Why interviewers probe this

For applied-AI roles you build with and for customers, and the half of the job most engineers under-train is understanding the problem. A strong answer treats the stated request as a hypothesis, asks who/what-outcome/what-success/what-data/what-constraints, works backwards from the user's outcome, and ties success to a measurable definition. Demonstrating that you would not just build the literally-requested thing is the core signal.

Common misconceptions

• "Build what the customer asked for." The stated request is often a solution, not the real problem; uncover the outcome first.
• "Discovery slows you down." Building the wrong thing is far more expensive; discovery is cheap insurance.
• "The data is fine." Demo data is never production data; understand the real data early.
• "Start from the technology." Start from the user's outcome and work backwards, or you build a solution in search of a problem.

Key takeaways

• The costliest AI mistakes are building the wrong thing; discovery prevents them.
• Uncover the real problem: who the user is, what measurable success means, what the data really looks like, and the constraints.
• Work backwards from the user's outcome, not their proposed solution; the right answer is often simpler.
• Tie success to a measurable definition, the seam between discovery and evaluation.