Tracing work back from the customer

Module 1 showed why speed only counts at the bottleneck. This module finds yours. It runs from day 1 to day 14, and by the end you'll have one bottleneck, someone to lead it, and a prediction written down before anyone changes anything. It starts with the simplest move in the framework: begin where the work reaches the customer, and walk backwards.

Value lands at the customer, not at the desk

Most AI rollouts start at the desk. Who could use a tool? Where could someone save an hour? It feels practical, and it produces real gains for real people. But it measures those gains where they're made, not where they land. A team that drafts twice as fast has only created value if more finished work reaches a customer, and most of the time it doesn't.

That's what starting at the desk looks like from the top. The companies that get value do something different: they look at the whole flow of work, from request to customer, and change it. Tracing back from the customer is how you see that flow.

Walk upstream, one handoff at a time

Pick the thing your aim measures: the quote that goes out, the ticket that gets closed, the month-end report that gets signed. Start at the moment it reaches the customer, then step back one handoff at a time. At each step, ask three questions.

• Does work wait here? Things sit in an inbox, a queue or a tray before anyone touches them.
• Does it pile up here? The queue is bigger this week than last week.
• Does it get redone here? Work comes back with questions, corrections or missing pieces, and goes through the same step twice.

Count rather than guess. Two numbers per step are enough: how many items are waiting right now, and how many the step clears in a normal week. Divide the first by the second and you have the wait, in weeks. Operations researchers call this Little's law, after John Little, who proved it in 1961. It's why a pile tells you more than any opinion in the room.

Notice what the pile does to the steps around it. Steps after the bottleneck sit part-idle, waiting for work. Steps before it look busy, because their work is piling up downstream. So a busy team isn't evidence of a bottleneck, and neither is the loudest complaint. A pile in front of a step, with the steps after it waiting, is.

Now map your own. Start with what the customer receives, then add steps backwards. Rough numbers are fine for a first pass. The example is the quoting team from the pilot kit, so you can see what a finished map looks like before you clear it.

Then step outside the line

A map of your own steps can only show bottlenecks inside your own walls. Sometimes the limit sits outside, and the framework asks you to look there too. Three questions do most of the work:

• Customers. What would they pay more for, wait less for, or leave over? If buyers choose whoever quotes first, speed at the bottleneck is worth more than it looks.
• Competitors. What do they now do faster or cheaper than you? That sets how much your bottleneck costs you, not just how annoying it is.
• Your pricing model. Does faster work earn you more, the same, or less? A firm that bills by the hour can make its work faster and watch its billings fall. Better to see that on day 3 than on day 90.

If every step in your line could handle more than arrives, the bottleneck isn't in the line at all. It's demand. That's a market bottleneck, and you'll meet it properly in lesson 3.

Look at your own desks too

The framework names one more place to look, and it's the least comfortable: leaders. Approvals that wait for the leadership meeting. Decisions that only one director can make. Sign-offs that sit in an executive inbox while the work behind them piles up. A leader's desk is a step like any other, and it can be the one everything waits on.

This is often the cheapest bottleneck to fix, because nothing needs buying. It needs a leader to delegate a threshold or move a decision closer to the work. But it only gets found if the people tracing the work feel safe writing “waits for leadership sign-off” on the map. That's what the promises in module 1 are for.