FDE: The Job Is the Gaps

Table of contents

Three steps, on paper

The FDE pipeline is three steps: confirm the requirement, build it on your product, deliver.

Accurate. Useless. The hard parts live between the steps.

Requirements don’t exist yet

Ask a customer what they need and you get a wish, not a spec. Not carelessness — the workflow is tacit. It lives in muscle memory, in the spreadsheet nobody documented, in the step someone runs every Tuesday without thinking about it.

But the asks converge. Strip the domain language and most of them are the same requirement: automation. A workflow runs across their systems; they want it wired into your product and the manual steps gone. Service integration — their stack and yours, combined into one flow.

So “confirm requirements” is the wrong verb. There is nothing to confirm. The first conversation gives you a direction, not a spec. You extract the spec — and that extraction is the hardest step in the whole pipeline.

Access is the gate

Requirement roughly shaped, second wall: access.

You can’t integrate with a system you can’t touch. Credentials, VPN, a test tenant, security review, someone’s manager’s sign-off. One line in the plan, weeks of calendar time.

Ask for access in the first meeting. Every day you wait is a day added to the end.

The recording is the spec

Access granted — don’t schedule another requirements call. Record the screen.

Have them run the job once, narrating. The recording is ground truth: real systems, real clicks, the exceptions they handle without noticing, the field they always fill the same way. Things nobody thinks to say out loud.

A recording can’t omit steps. Watch it three times and you have the spec the customer couldn’t write.

Build is glue

The product covers the general case. The customer’s case is never general.

The middle of the job is custom development: adapters for their systems, transforms for their data shapes, handlers for their exceptions. Generic advice ends here — every integration is bespoke. The product is leverage; the glue is the work.

Validate in their environment as you build, not after. Surprises found at delivery cost ten times more.

Delivery is evidence

A demo proves nothing. An integration is delivered when it has run real test sets — their data, their volume, their edge cases — and the results ship with it.

The delivery artifact is the workflow plus its evidence: test runs, recordings, before/after numbers. Evidence turns “it works” from a claim into a fact.

Then optimize. The first version mirrors the manual workflow. The second deletes the steps that only existed because a human was in the loop.

The loop

extract requirement → get access → record the workflow → build the glue → validate on real data → deliver with evidence → optimize

Steps two and three are engineering. Step one is the job.