Requirements Discovery

TL;DR: The stated request is a solution the customer already guessed at; your job is to recover the problem underneath it. Ask who touches the output, what counts as success in numbers, what data exists today, and why the deadline exists. The FDE who does this builds something used; the order-taker ships the literal ask and watches it die.

The request is not the requirement

The spine below is that recovery in order, from the guessed solution at the top to a proposal you can defend.

When a customer says "we want a chatbot for our support docs," they have already done a design step in their head and handed you the conclusion. Maybe a chatbot is right. Often the real pain is that agents spend nine minutes hunting across four wikis per ticket, and a ranked search box solves it faster and with less risk. You cannot know until you ask. The move that separates a great FDE from an order-taker is refusing to start building until you have traced the request back to the outcome someone is paying for.

This is not stalling. A deployment that solves the literal ask but misses the need is the most expensive way to fail, because you find out after the build. Discovery is cheap insurance bought up front.

Four questions do most of the work, and none of them is "what features do you want."

• Who actually uses the output, and what do they do right after they get it? This tells you the real interface and the real bar. An answer a support agent skims in three seconds is a different system than one a compliance officer files in an audit.
• What does success look like, in a number? "Better support" is unmeasurable. Push until you get "cut average handle time from twelve minutes to eight" or "deflect 30% of tier-one tickets." If they cannot name a number, the project has no finish line and no champion.
• What data exists today, and can I see a sample this week? The single biggest predictor of a doomed AI project is data that is assumed to exist and does not, or exists but is unlabeled, stale, or locked behind a team that will not grant access. Ask for a real sample early, before you have promised anything.
• Why this deadline? "End of Q3" attached to a board demo is a hard wall. "End of Q3" because someone picked a round number is movable. Knowing which one you are facing changes your entire scope.

Each question retires a specific risk:

A short discovery exchange

Customer: We need an AI tool that reads our contracts and flags risky clauses.

FDE: Who reviews the flags after the tool produces them?

Customer: Our two paralegals, before it goes to outside counsel.

FDE: So the tool's job is to make those two people faster, not to replace the legal review. What does their week look like now?

Customer: They read every contract end to end. Maybe forty a week, and they miss things when volume spikes.

FDE: Then success might be "paralegals review the same forty contracts in half the time and miss fewer clauses," not "the tool is 99% accurate." Is there a list of the clause types that actually cause you trouble, and do you have past contracts with those clauses already marked?

Customer: There's a checklist. The markups are in old email threads.

In four turns the project changed from "an accuracy benchmark on a model" to "a triage assistant for two known users, evaluated on time saved, blocked on whether we can reconstruct labels from email." That last fact, surfaced in week one instead of week six, is the entire value of discovery.

Why interviewers probe this

In the simulation round the interviewer plays a customer who deliberately gives you a vague or wrong ask, then watches whether you build it or interrogate it. They are screening for whether you treat the customer as the source of the spec or as a witness to a problem you still have to diagnose. The held-in-reserve follow-up is usually a hidden constraint they planted (data lives in a system you cannot touch, the "real" user is not the one in the room, the deadline is fake) and they want to see if your questions would have caught it. Candidates who jump to architecture never trip the constraint and fail quietly.

Common misconceptions

• "Asking a lot of questions makes me look unsure." The opposite. Sharp, specific questions signal you have shipped before and know where projects die. Generic ones ("what are your goals?") do read as filler, so make them concrete.
• "Discovery is a phase that ends before building." It is continuous. The sample data you get in week three rewrites assumptions from week one. Keep a living list of assumptions and confirm them as facts arrive.
• "The person who briefed me knows the requirements." Often they know the politics. The requirement lives with the end user and in the data, and those two frequently contradict the brief.
• "If they gave me a detailed spec, discovery is done." A detailed spec is just a more confident guess. Still ask why each item is there and what breaks if you drop it.

Key takeaways

• Treat the stated request as a hypothesis about the solution, not a statement of the need; recover the outcome behind it.
• Four questions carry most discovery: who uses the output, what success is in numbers, what data exists today, and why the deadline is the deadline.
• Ask for a real data sample in week one; assumed-but-absent data is the top killer of AI deployments.
• Keep confirming assumptions as the project proceeds. Discovery does not end at kickoff.