You are the Forward Deployed Engineer embedded at Northwind Field Services, a company that sends technicians to install and repair equipment at customer sites. You just got off a call with Dana, their VP of Operations. Dana is not technical. Here is the brief, in her own words:
"Our dispatchers live in spreadsheets and five different screens. In the morning they cannot answer simple questions fast: which jobs are running late, where is a given technician right now, who is free to pick up an urgent call. I want something where they can just ask, in plain English, and get an answer they trust. Make it feel like asking a really sharp assistant. We have the data somewhere. Can you build this?"
That is all you get. The ask is real but vague. This capstone is the whole end-to-end engagement — the same job you do on a real deployment: turn an ambiguous stakeholder ask into a scoped plan, build it, and hand it back in language the customer understands.
Work through the five milestones below in order. Each builds on the last. Do not jump straight to code — the scoping and communication are graded too, and they are what separate a real FDE from someone who just types fast. AI tools are allowed and encouraged throughout: think with the agent, do not just accept an answer you cannot defend.
Milestone 1 — Understand the ask (≈10 min)
Before writing anything, get clear on the problem. In your explanation box, jot down: who the user is (the dispatcher, not Dana), the top 3 questions they need answered in the morning, and the single outcome that would make Dana say "ship it."
Checkpoint: you can state the job-to-be-done in one sentence.
Strong looks like: you separate the buyer (Dana) from the user (dispatcher) and design for the user.
Milestone 2 — Scope it: write the mini-PRD
In a few short paragraphs in your explanation box, state: what you will build in v1, the key edge cases you will handle, what you are explicitly NOT doing in v1 (out of scope), and a rough timeline. Dana only said "we have the data somewhere," so call out the assumptions you are making about the data.
Checkpoint: a reader who was not on the call could tell exactly what ships and what does not.
Strong looks like: a tight v1 that solves the 3 morning questions, an explicit out-of-scope list, and named assumptions.
Milestone 3 — Model the data & state assumptions
Decide the minimal data you need: jobs (status, scheduled time, location, assigned tech) and technicians (name, current location/status, availability). Define a small, realistic shape and note where real Northwind data would plug in. Seed a handful of example rows so you can build and test.
Checkpoint: you have a concrete schema and sample data to run against.
Strong looks like: the model is small but covers late jobs, tech location, and availability — the three things Dana named.
Milestone 4 — Build the assistant (incrementally)
Build a dispatch assistant that answers natural-language questions over your job and technician data. Do it in layers, testing each before moving on:
- One query first: answer "which jobs are late?" end to end.
- Add coverage: "where is Maria?" and "who is free right now?"
- Make it trustworthy: it must degrade gracefully when data is missing, stale, or ambiguous, and it must never invent an answer it cannot support from the data — say what it does not know.
Checkpoint: all three questions return correct, grounded answers; a question it cannot answer is handled honestly.
Strong looks like: a clear path from question → data → answer, with the "no hallucinated answers" guarantee visibly enforced, not hoped for.
Milestone 5 — Ship it: the launch readout
Write the brief you would give Dana after building. Cover: what it does, what it does not do yet, the tradeoffs you made, the timeline, and what could go wrong in production. Keep it in her language — trust, timeline, risk — not implementation detail. You will deliver this as the stakeholder conversation.
Checkpoint: a non-technical VP could read it and decide whether to go live.
Strong looks like: honest about limits, specific about risk, and framed around the business outcome.
State every assumption. If a real decision depends on information you do not have, make a reasonable call and flag it clearly. That judgment — under ambiguity, defended in plain language — is exactly what is being graded.