Building Domain Knowledge Quickly: The FDE Ramp-Up Method

Every new engagement drops you into an industry you've never worked in — healthcare on Monday, logistics on Thursday. FDEs don't have months to become experts; they need working domain knowledge in days. This tutorial is the method: how to learn a domain fast, what to learn first, and how to prove you've learned it.

Table of Contents

• How Much Domain Knowledge Do You Actually Need?
• The Five Things to Learn First
• The Fastest Sources, Ranked
• Build a Glossary as You Go
• The Teach-Back Test
• Common Traps
• A One-Week Ramp Plan

How Much Domain Knowledge Do You Actually Need?

You don't need to become a doctor to build a scheduling tool, or a banker to automate KYC document checks. You need three things:

1. The vocabulary — enough to follow conversations without asking about every third word.
2. The core workflows — the 2–3 processes your project touches, traced end to end.
3. The constraints — the regulations, deadlines, and physical limits that bound every solution.

That's the target. Depth beyond that comes later, driven by the actual work — not by reading the whole industry's Wikipedia tree in week one.

Common Mistake: front-loading too much generic research. Reading industry reports for a week feels productive but produces knowledge you can't use. Ten hours of talking to the customer's staff beats forty hours of reading about their industry.

The Five Things to Learn First

In any new domain, hunt these five in order:

1. Who the customer's customer is. Every domain decision flows from who pays at the end. A hospital's processes serve patients and insurers; a factory's serve distributors and buyers.
2. How the customer makes money. Which core process earns revenue? (Tutorials 1–2 in this series give you the lens: revenue, cost, margin.)
3. The nouns. Every domain has its own words — claim, work order, denial, settlement, SKU. The nouns are the domain's data model; learn them and the systems start making sense.
4. The one workflow your project touches. Trace it end to end using the method from Tutorial 1 of this series: trigger, steps, decisions, handoffs, output.
5. The hard constraints. Regulations (HIPAA, PCI, AML), deadlines (month-end close, shift change), physical limits (the line stops). Ask "what are you never allowed to get wrong?"

The Fastest Sources, Ranked

Not all learning sources pay equally. Ordered by return on time invested:

Best Practice: ask for the new-hire training material. Every company has something they give day-one employees — it's a pre-built domain crash course that nobody thinks to offer you. Ask for it explicitly.

Build a Glossary as You Go

Domain vocabulary evaporates from memory within hours. Capture it as you hear it:

| Term        | Plain meaning                          | Where I heard it |
|-------------|----------------------------------------|------------------|
| Denial      | Insurer rejecting a claim              | Billing team     |
| WISMO       | "Where is my order?" support ticket    | Support lead     |
| Three-way   | Invoice vs. PO vs. delivery match      | Finance manager  |
|   match     |                                        |                  |

Three rules for the glossary:

• Write the meaning in plain words, the way you'd explain it to a friend — not the official definition.
• Note who said it, so you know who to ask when the meaning gets fuzzy.
• Keep it to one page. If a term hasn't mattered enough to recur, it doesn't belong.

The glossary doubles as a requirements tool: the exact terms in it are the ones your software's labels, fields, and messages should use. A build that speaks the customer's language feels custom; one that invents its own terms feels foreign.

The Teach-Back Test

How do you know you've actually learned the domain? Teach it back.

At the end of week one, ask your main contact for fifteen minutes: "Let me play back my understanding of how order processing works — correct me wherever I'm wrong." Then walk through the workflow, the vocabulary, and the constraints in your own words.

Two things happen:

1. Gaps surface immediately. The customer corrects you on exactly the parts you were fuzzy on — the highest-value feedback you'll get all engagement.
2. Trust compounds. A customer who hears their own business described accurately starts handing you the real problems, not the polite ones.

Note: schedule the teach-back before you write requirements, not after. A misunderstanding caught in the teach-back costs five minutes; the same misunderstanding caught in a requirements review costs a rewrite.

Common Traps

Three traps eat ramp time:

• Pretending to understand. Nodding through a word you don't know guarantees confusion later. Ask in the moment: "Sorry — when you say 'allocation,' what exactly happens?" People respect the question; they don't respect the wrong build that follows.
• Trusting one person's view. Every role sees a different slice of the process. The manager's version and the operator's version disagree in the details — and the details are where you build.
• Importing assumptions from other domains. "In e-commerce we just…" — different industries solve the same-looking problem under different constraints. Enter curious, not comparative.

A One-Week Ramp Plan

Put the method on a schedule:

By Friday you have what most projects don't get in month one: a verified picture of the workflow, in the customer's own words.

Best Practice: keep the artifacts — glossary, workflow trace, constraint list — in a shared doc the customer can edit. Domain knowledge that lives in your head walks out the door with you; knowledge in a shared doc compounds across the whole engagement.