Seven days, one round of real evidence
A day-by-day plan for the first field cycle, and the three artefacts it must produce. The point is not to finish — it is to arrive at day eight knowing something you could not have guessed.
Updated 2026-10-304 min read
Most first deployments die of planning. A month of internal design, a proposal, a kickoff, and by the time the code meets a real data source the team has invested so much in the design that contrary evidence is unwelcome. The seven-day cycle exists to invert the order: contact first, design second.
The unit of progress is not features shipped. It is one round of evidence — a claim tested against the customer's own data, witnessed by the person who would have to act on it.
The week
Day 0 — choose one battlefield. One process, one team, one metric. Not the most valuable process; the one with the shortest path to a number and a real owner. Write the choice in one sentence and get the owner to agree to it out loud.
Day 1 — get in and get data. System access, a real extract, and the names of the two people who can answer questions about a field. Half the day usually goes to access, so start on day 0. The extract must be real; if the customer cannot provide real data by day 1, that finding is the week's result.
Day 2 — build the horizontal slice. End to end, ugly, one path. The goal is that something runs from their source to a visible output, not that anything is good. Instrument it on the way: you cannot add logging later without another change ticket.
Day 3 — break it on purpose. Take the ten worst records you can find and push them through. This is where the metric gets defined, because the definition has to survive those ten. Write the metric table today, not after the demo.
Day 4 — put it in front of the operator. Not the sponsor. The person who does the work, sitting at their own desk, with their own next case. Watch where they hesitate and resist the urge to explain.
Day 5 — show the number to the decision maker. Ten minutes, one screen, one number against its baseline, plus the list of what is not built and what might be wrong. This is the readout, and its job is to end with a decision rather than applause.
Day 6 — write what you learned. Two pages: the claim, the evidence, the three things that surprised you, the thing that would have to be true for this to be worth continuing.
Day 7 — decide. Continue, narrow, or stop. All three are legitimate outputs and the third has to be sayable out loud, or the process is not a test.
The three artefacts
By day eight there should be three things that did not exist before.
- A number with a baseline. Not a target — an observation: this step takes 4.1 minutes on 400 cases a day, and the error rate on the disputed subset is 9%.
- A list of what the data is actually like. Fields that were empty in 30% of records, three spellings of the same supplier, a timestamp the customer's system writes in local time while the log is UTC.
- A named next decision, with a person and a date. Continue with what scope, or stop, decided by whom, by when.
If the week produced a working prototype and none of those three, it produced a demo and the schedule slipped by a week without anyone noticing.
Why seven and not thirty
A month allows a design to become an identity. Once the architecture is in a slide deck that three people have seen, contradicting it costs social capital, so teams stop looking for the contradiction and start looking for confirmation. Seven days keeps the design cheap enough to throw away.
It also front-loads the two things that most often kill projects, both of which are cheap to discover and expensive to discover late: the data is not what the customer said, and the person who would have to change their behaviour was never asked.
Where it fits
The sprint is the first pass through the delivery stage, not a replacement for it. It produces the evidence that justifies a scoped deployment; it does not produce a deployed system, and pretending otherwise ships a prototype into production under a different name. What the prototype must contain is in its five conditions; what happens when the week's output is used for four weeks is the four-week rule.
What it costs to skip
A team that skips this and goes straight to a scoped build usually discovers the same three artefacts in week six, at which point the scope is signed, the customer has announced the project internally, and the honest finding — this process cannot be improved without changing who owns it — is politically unsayable. The seven-day version costs a week and says it while it is still cheap.
Sources and further reading
- 《FDE 现场工程手册》 — CC BY-SA 4.0;七天节奏改写自该书步骤章,改编部分同样以 CC BY-SA 4.0 提供
This article is original analysis by FDE Wiki. Frameworks and case material that originated elsewhere are credited below.