Six artefacts we expect to be holding on the Friday — not impressions and not a deck, but things somebody can disagree with in writing while disagreeing is still free.
A discovery week is the cheapest week of any project. Nothing has been built, so every decision is still free to change. It is also the week most often wasted, because it produces impressions instead of artefacts — and an impression cannot be argued with in month four.
01
The week, in sentences anybody can check
The first artefact is the least technical and the most useful: a plain description of how the work gets done today, written as sentences a person in that job would recognise.
Not a process diagram. Sentences. "An order arrives by email or by phone. Whoever picks it up writes it on the whiteboard. At four o'clock someone photographs the whiteboard and sends it to the warehouse group." Nobody draws that in a workshop, because everyone in the room already knows it and assumes it is too obvious to say. It is never too obvious to say, and it is almost always where the real system is hiding.
The test of this artefact is simple: hand it to someone who does the job and ask which sentences are wrong. They will correct three of them in the first minute, and those three corrections are worth more than the rest of the week.
02
The list of nouns, and what each one means to whom
Every organisation has about a dozen nouns that run through everything — order, customer, account, case, site, shipment, claim. The second artefact is that list, with a one-line definition for each and a note anywhere two departments mean different things by the same word.
That last part is the whole value. Finance's customer is the entity that is invoiced. Operations' customer is the person who signs for delivery. Support's customer is whoever is on the phone. These are three different things and all three teams will nod when you say "customer" in a meeting.
Catching that in week one costs a conversation. Catching it after the reporting module ships costs a migration and a very awkward call.
Two teams using one word for two things is not a vocabulary problem. It is a reporting problem with an eleven-month fuse.
03
A decision log with the reasoning attached
The third artefact is a running list of what was decided during the week, who decided it, and — the part people skip — why, including what the alternative was.
This matters because decisions get relitigated. A new stakeholder joins in month five, hears that the system does not do X, and asks why not. Without a log, that question costs a fortnight of re-investigation and a certain amount of political damage. With one, it costs ten minutes: here is what we considered, here is why we chose this, here is what would have to change for the other option to win.
Keep it to one line of reasoning per decision. A log nobody maintains is worse than none, because it looks authoritative while being out of date.
04
The risk list, written as sentences with owners
The fourth artefact is the list of things that could sink the project, each written as a specific sentence rather than a category, each with a name next to it.
"Integration risk" is not a risk, it is a noun. "We do not yet have a non-production credential for the finance system, and the person who can issue one is on leave until the 14th" is a risk, and it has an owner and a date. The difference is that the second one can be worked on.
The most valuable entries on this list are almost never technical. They are access, availability of the one person who understands the legacy rules, a decision nobody has the authority to make, and a dataset that has not been looked at yet.
05
The first slice, defined end to end
The fifth artefact is a description of the smallest piece of the system that would be genuinely useful to somebody if it were the only thing that shipped.
End to end is the operative phrase. Not the first screen, not the data layer, not "the admin area" — one complete path through the work, from the thing that starts it to the thing that finishes it, for one category of case. Half a path is nobody's working system, and a horizontal layer is nobody's anything.
Writing this down also forces the scope conversation to happen in week one, when it is a discussion, rather than in month three, when it is a renegotiation.
06
The one number that would prove it worked
The sixth artefact is a single measurement, agreed with the client, that will be different if the project succeeds.
It has to be a number somebody already feels: hours spent re-keying data, days from order to dispatch, percentage of cases that need a second phone call, time between a form arriving and someone acting on it. Not usage, not logins, not adoption — those measure whether people opened the thing, not whether it helped.
And it has to be measured before anything is built. A baseline collected after launch is not a baseline, it is a guess with a date on it. This is also the artefact that makes the project defensible internally when the budget conversation comes round again.
07
What we deliberately do not produce
No visual designs. No architecture diagram with boxes and arrows. No estimate with a number in it.
All three are tempting because they look like progress, and all three are lies this early — the design assumes a flow nobody has agreed, the architecture assumes a data model that is one conversation from changing, and the estimate assumes a scope that has not been cut yet. Producing them in week one does not accelerate the project; it anchors everyone to a shape that then has to be argued back out of.
What we do produce is a sentence about how long the first slice is likely to take and what would make that wrong. That is honest, and it survives contact with the next week.
08
How we run the five days
Day one is listening, with no laptops open and no solutions offered. Day two is the nouns, usually the longest argument of the week. Day three is walking one case end to end with the people who actually touch it, which is where the whiteboard-and-photograph discoveries happen. Day four is constraints — access, legal, data, who can say yes. Day five is writing it all down and reading it back to the room.
The reading back is not ceremonial. Every discovery week we have run has had at least one correction land in that final session, from someone who had been quiet all week because they assumed somebody else had said it.
Five days is enough for one business area. It is not enough for an organisation, and a week that tries to cover everything produces a thin version of all six artefacts, which is the same as producing none.
If you take one thing
Judge a discovery week by whether you could hand its output to a team that was not in the room and have them start. If the week only exists in the heads of the people who attended, it has not happened yet.
