What four weeks should leave behind
If week three of a discovery engagement has nothing running, the roadmap you get at the end of it is fiction.
Discovery has a bad name, and it has earned it. The format is familiar: a few weeks of interviews, a workshop with sticky notes, a maturity assessment scored against a framework nobody in the room chose, and a deck with a three-phase plan. The deck is well made. Nothing in it has been tested.
The failure is not that the consultants were lazy. It is structural. A plan written entirely from conversations inherits every assumption in those conversations. Somebody says the data is in the ERP, and it goes into the plan as a fact. Three months into delivery it turns out the data is in the ERP for 40 of the sites, and the rest send a spreadsheet. That discovery should have cost a day in week two. Instead it costs a quarter and the credibility of the programme.
So the thing I would insist on as a buyer is that by week three somebody has built the hardest part, badly, and it ran. Not a prototype of the easy bit, and not a mock-up. The specific part of the plan most likely to be wrong, attempted against the real systems with the real data, well enough to find out.
This changes the engagement from an opinion into evidence. The roadmap stops being what should work and becomes what we tried, plus what we learned when it did not. That rough version is usually ugly and often gets thrown away. It has still paid for the whole four weeks, because the one assumption that would have broken delivery has been found while it was still cheap.
Our discovery runs four weeks for that reason. Week one is the operation as it actually is, which means watching people work rather than asking them to describe it. Week two narrows to the few jobs where the effort is real and the inputs exist. Week three builds the hardest idea, roughly, against live systems. Week four prices and sequences what survived.
What you should hold the output to is specific. The plan should name systems, not categories. It should say what will not be attempted and why, because a roadmap with no exclusions has not made any decisions. It should carry an honest account of what the week-three build got wrong. And the price of the next stage should be a number, from the people who would be doing the building, because an estimate written by anyone else is a guess with a logo on it.
The reason I write the plan and then lead the build is not integration for its own sake. It is that the plan cannot promise what the build cannot deliver when the same person is answerable for both. A strategy practice with no delivery capability has no feedback loop, and its roadmaps drift towards what sounds sensible rather than what works.
If a discovery proposal does not include something running before the end, ask what you are actually buying. The answer is usually a document.