12.1 — Customer Discovery and Requirement Gathering

1. What is it?

Customer discovery is the structured process of understanding a customer's actual problem, business context, and constraints before proposing any technical solution. It is the practical, real-world application of Part 11.1's "requirements and constraints come before architecture" principle — except now conducted through an actual conversation with a customer who has not read this handbook, does not think in terms of RAG or agents, and often doesn't yet know precisely what they need.

2. Why does it exist?

Every AI project failure story that traces back to "we built the wrong thing" traces back to a discovery failure, not a technical failure — the team executed competently on a misunderstood or incomplete problem statement. Discovery exists because a customer's first articulation of their need ("we want an AI chatbot") is almost never a complete or even accurate specification of the actual underlying problem, and the gap between what's said and what's actually needed is exactly what a skilled discovery conversation closes.

3. What problem does it solve?

It solves "how do I make sure I build the right thing" before any engineering investment happens — directly preventing the wasted effort, damaged trust, and sunk cost of discovering a fundamental misunderstanding only after a prototype (Part 13) has already been built around the wrong assumption.

4. How does it work internally? — The reasoning process, illustrated

The prompt.md instruction behind this handbook was explicit: "Do NOT immediately recommend RAG or agents. Teach the reasoning process first." Here is that reasoning process, worked through on the canonical example:

CUSTOMER: "We want an AI chatbot for our employees."

A junior response jumps straight to "sure, we'll build you a RAG-based chatbot over your internal docs." An FDE's actual first move is a structured set of clarifying questions, each closing a specific gap in understanding:

Q1: "What should employees be able to do with it that they can't easily do today?"
    → surfaces the actual JOB TO BE DONE, not just the requested artifact.
    Answer might reveal: "Find answers to IT/HR policy questions without
    emailing the help desk" — now we know this is fundamentally a
    knowledge-retrieval problem, not (yet) an action-taking one.

Q2: "Where does that information currently live, and how often does it change?"
    → surfaces DATA REALITY (Part 10.2) before any architecture is chosen.
    Answer might reveal: scattered across three systems, updated weekly —
    directly shapes whether this is a simple RAG problem or a genuine
    data-engineering challenge (Part 10.2's real, common pattern).

Q3: "What happens today when someone gets a wrong answer from a colleague
     or an outdated document?"
    → surfaces the RISK TOLERANCE and STAKES (Part 8.1/9's proportionality
    principle) — a low-stakes convenience tool needs much less rigor than
    one where a wrong answer has real consequences.

Q4: "Who should NOT be able to see certain information, if anyone?"
    → surfaces ACCESS CONTROL requirements (Part 9.6/10.4) before they
    become a late-discovered, expensive-to-retrofit security gap.

Q5: "How would you know, three months after launch, whether this was
     actually successful?"
    → surfaces the SUCCESS METRIC (Part 15's ROI framing) that should
    have shaped the whole project from day one, not be invented retroactively
    to justify already-completed work.

Only after these five answers (and likely several follow-ups) does an actual technical direction — RAG? tool-calling? a workflow? none of the above, just better documentation? — become a reasoned conclusion rather than a premature guess dressed up as expertise.

Distinguishing stated wants from underlying needs

A customer's stated want ("a chatbot") is a proposed solution, not a requirement — often shaped by whatever they've seen in a demo, a competitor's product, or a conference talk, not necessarily the actual best fit for their specific situation. Discovery's job is to work backward from the stated want to the underlying need (the actual job to be done, Q1 above), and only then forward again to whatever solution genuinely fits — which might, after all that, still turn out to be a chatbot, or might turn out to be something else entirely (better search over existing documentation, a fixed workflow, or — a real, valid outcome — a recommendation not to build anything AI-related yet, because the actual underlying problem is a data-organization problem, Part 10.2, that would make any AI solution ineffective regardless of how well-built).

5. Simple mental model

Discovery is like a doctor's diagnostic process, not an order-taking process at a restaurant. A patient saying "I need surgery" is stating a proposed solution, not a diagnosis — a good doctor asks about symptoms, history, and context before agreeing surgery is even the right treatment, because patients (like customers) are experts in their own experienced problem, not necessarily in the correct technical solution to it. Taking the stated request at face value and executing on it directly, without this diagnostic process, is how you end up performing the wrong procedure competently.

6. Real-world example

A logistics company's initial request was: "build us an AI agent that can answer any question about a shipment." Discovery conversation (following section 4's structure) revealed: most actual questions were about current shipment status (a precise, structured, frequently-changing fact — a tool-calling problem, Part 3.3, not RAG), a smaller fraction were genuine policy/procedure questions (a good RAG fit, Part 3.5), and a very small fraction were genuinely open-ended troubleshooting questions that might warrant agent-level flexibility (Part 3.7). The single word "agent" in their original request would have led directly to over-engineering the entire system as an open-ended agent (Part 3.7's core warning), when the actual, discovered need was mostly a simple, fast, cheap tool-calling workflow with a small RAG component and a genuinely tiny agent-justified sliver — a completely different, better-fitting, cheaper, and more reliable architecture than the one their initial one-sentence request implied.

7. Architecture diagram

This chapter has no system architecture diagram — its "diagram" is the discovery question flow in section 4, which precedes and determines any subsequent architecture diagram (Part 11's system designs each implicitly assume a discovery process like this one already happened).

8. Production considerations

• Never let a customer's technology-specific language (chatbot, agent, AI) determine your architecture before discovery is complete — section 6's example shows exactly how costly this shortcut can be.
• Document discovery findings explicitly, not just informally — Part 11.1's requirements/constraints intake template is exactly this discipline made concrete and reusable.
• Revisit discovery findings as a project progresses — new information discovered during prototyping (Part 13) often refines or corrects initial discovery conclusions, and treating discovery as a one-time, unrevisited step misses this.

9. Common mistakes

• Taking a customer's stated solution (a specific technology name) at face value instead of working backward to the underlying need.
• Skipping questions about data reality, risk tolerance, access control, and success metrics because they feel like "getting to the fun technical part" more slowly.
• Treating discovery as complete after one conversation, rather than an ongoing practice refined as more is learned.
• Asking closed, leading questions ("you want RAG, right?") that confirm an assumption rather than genuinely surfacing what's actually needed.

10. Security considerations

Discovery is where access-control and data-sensitivity requirements (Part 9.6/10.4/10.5) should first surface — a security gap discovered during discovery costs a clarifying question; the same gap discovered during a pre-launch security review costs a redesign; discovered in production, it costs a real incident.

11. Performance considerations

Discovery is where latency/scale expectations (Part 11.1's non-functional requirements) should be established explicitly — a customer's implicit assumption about acceptable response time, left unstated and undiscovered, becomes a mismatched-expectations problem at launch rather than a design input from day one.

12. Cost considerations

Discovery is where budget constraints and expected usage volume should surface — directly shaping which architectural choices (Part 3.11/7.10's cost framework) are actually viable for this specific customer, rather than defaulting to a technically "best" solution the customer can't actually afford to operate at their real volume.

13. When to use it

At the start of every engagement, and revisited throughout — discovery is never fully "done" until the project itself is done, though its intensity concentrates heavily at the start.

14. When NOT to over-apply it

An engagement that's a small, well-understood addition to an already-deeply-discovered existing system doesn't need the full formal discovery process repeated from scratch — proportional rigor (Part 3.12/11.1) applies here too.

15. Alternatives and trade-offs

The "alternative" to structured discovery is simply building what was literally asked for — faster in the short term, but section 6 shows the real cost: a technically competent execution of the wrong (or a suboptimal) architecture, discovered only after real investment, versus a small, cheap upfront investment in getting the actual requirements right.

16. Practical Python/code example

A discovery-question checklist as a structured artifact, directly extending Part 11.1's requirements-intake template with the specific question categories from section 4:

from dataclasses import dataclass, field


@dataclass
class DiscoveryFindings:
    """Structured capture of discovery conversation findings, before any
    architecture decision is made."""
    job_to_be_done: str = ""              # Q1: what should be possible that isn't today
    data_sources: list[str] = field(default_factory=list)   # Q2: where data lives, update frequency
    risk_tolerance: str = ""              # Q3: consequence of a wrong answer
    access_control_requirements: list[str] = field(default_factory=list)  # Q4
    success_metric: str = ""              # Q5: how success will be measured

    def is_ready_for_architecture(self) -> bool:
        """Discovery should be substantively complete before architecture begins."""
        return bool(
            self.job_to_be_done and self.data_sources
            and self.risk_tolerance and self.success_metric
        )

17. Production-quality example

A discovery-conversation script structure, operationalizing section 4's five questions as a reusable interview guide:

# Discovery Interview Guide

## Opening
"Before we talk about any specific technology, I want to understand the
actual problem you're solving — can you walk me through a specific,
recent example of the situation you want this to help with?"

## Core questions (adapt wording to context, but cover all five)
1. What should be possible after this that isn't possible/easy today?
2. Where does the relevant information/data currently live, and how
   often does it change?
3. What happens today when something goes wrong or someone gets a
   wrong answer? What's the actual cost of that?
4. Is there anyone who should NOT have access to some of this
   information or capability?
5. Three months after launch, how would you know if this was a success?

## Closing
"Based on what you've described, here's my initial understanding of
the actual problem [restate in your own words] — did I get that right?"

Explicitly restating the understood problem back to the customer at the end (the closing step) is a deliberate, high-value practice — it surfaces any remaining misunderstanding immediately, while it's still cheap to correct.

18. Short exercise

A customer says: "We want AI to help our sales team write better emails." Using section 4's five-question framework, write out the specific version of each question you'd ask for this scenario, and predict (briefly) what kind of answer to each would push the solution toward a simple prompting-based tool (Part 3.1) versus a more complex RAG/agent architecture (Part 3.5/3.7).

19. Interview questions

• Walk through your discovery process for a vague initial customer request, and explain why you wouldn't recommend a specific technology in the first conversation.
• Why is a customer's stated solution ("we want a chatbot") not the same as their actual requirement, and how do you work backward from one to the other?
• Describe a real or hypothetical case where discovery revealed the customer's actual need was different from their initial request, and how that changed the resulting architecture.

20. FDE/customer scenario

CUSTOMER: "We want an AI chatbot for our employees."

FDE (following this chapter's process): "Happy to talk through that — before we get into any specific approach, can you walk me through a recent, specific example of a question an employee had that you'd want this to help with? And where does the answer to that question actually live today?"

This opening response is the concrete, practiced embodiment of this entire chapter: it doesn't reject the customer's stated request, but it also doesn't accept it as a specification — it redirects toward the concrete, specific information (section 4's Q1/Q2) that will actually determine whether a chatbot, a RAG system, a tool-calling workflow, or something else entirely is the right answer.

---

Key takeaways

• A customer's stated solution (a specific technology name) is not the same as their actual requirement — discovery works backward from stated want to underlying need before working forward to an actual architecture.
• The five discovery question categories (job-to-be-done, data reality, risk tolerance, access control, success metric) should be answered before any architecture decision, directly implementing Part 11.1's requirements-before-architecture principle in a real conversation.
• Discovery is never fully complete after one conversation — it continues throughout an engagement as more is learned.

Things you should be able to explain

• Why "we want a chatbot" is a proposed solution, not a requirement, and how to work backward from it.
• The five discovery question categories and what architectural decision each one shapes.

Things you should be able to build

• A structured discovery-findings template and a reusable discovery-interview guide.

Common mistakes

• Taking a customer's technology-specific language at face value instead of discovering the underlying need.
• Skipping questions about data reality, risk, access control, and success metrics.

Recommended next chapter

02-business-process-and-feasibility.md