A quick-commerce business running dark stores maps the value stream for "launch a new product category". The map has five boxes - groomed, built, reviewed, tested, deployed - totalling 11 working days with flow efficiency of 46%. On the strength of it, leadership funds a £600k pipeline programme to cut the 11 days. Review the map and the decision.

What is actually required

The stream is named "launch a new product category" and the map measures from a groomed ticket to a deployment. A category launch is not live when code deploys. It is live when the items are buyable, pickable, priced, taxed correctly and returnable. The real stream runs from the category decision through supplier onboarding, master-data creation, store planogram changes, picker training, pricing and tax setup, and only then the software.

The map covers 11 of what is usually 60 to 90 elapsed days, so a programme that halves the mapped portion moves the true lead time by about 8%. That is the review's central finding and it should be stated first, in days, before anything else is discussed.

Value-stream mapping has carried this warning since the lean-manufacturing literature of the 1990s: a stream mapped only where the mapper has authority confirms the mapper's priorities, and the steps that fail in production are the ones outside the boundary.

What I would remove, and why it is safe to

• The 46% flow efficiency figure. It is flattering because the denominator is wrong. Flow efficiency over the mapped segment of a stream is not flow efficiency; recomputed over the real stream it will land in the 5% to 15% band that mapping almost always finds.
• The four-box breakdown inside engineering. Build, review and test wait times of under a day each are not where the decision lies, and arguing about them consumes the review.
• The £600k programme, for now. Not because pipelines do not matter, but because its benefit is bounded at roughly 5 days out of 70. Choose the step with the longest wait, or the spend fails to move the only number leadership asked about.

The one change that matters

Map the stream to the first customer order in the new category and put the clock on master-data creation and supplier onboarding. In businesses of this shape those two steps routinely hold weeks, because they are queued behind a shared data team and a manual approval, and because nobody owns the end-to-end date. The architectural consequence is usually a self-service product-data path with validation at the edge rather than a review queue, which is a far smaller build than a pipeline programme.

What I would leave alone, even though it looks odd

The manual planogram and picker-training steps. They look like obvious automation targets and they are not the constraint; they run in parallel with the data work and they are bounded by physical reality in the stores. Automating a step that is not on the critical path converts engineering budget into no change in lead time, which is the same mistake the pipeline programme makes.

How I would argue this in the review

Not by attacking the map. By asking one question with a number attached: "From the day we decided on this category to the day a customer could buy an item in it, how many days passed, and which step held the longest?" If nobody has the number, that is the first deliverable, and it costs a week rather than £600k. When the number arrives, re-run the funding decision against it. The map was not wrong, it was scoped to the part the room could see — which is what value-stream mapping exists to correct.

When this critique would be wrong

If the mapped 11 days were themselves a hard constraint on something else — a regulated change window, a release train that only runs monthly, or a team whose deploy pain is causing attrition — then cutting them has value the lead-time arithmetic does not capture. Say so explicitly rather than letting the flow number carry the whole argument.