What-If Machines

I have sat in plenty of planning meetings where two capable people disagree about whether a plan will work. Both are experienced. Both care. The argument goes round three times and ends with someone agreeing to "take it offline".

Almost every time, when you dig in, they were not really disagreeing about the plan. They were working from different assumptions that neither had said out loud. One assumed the team could absorb the new work. The other assumed it could not. Neither had written down a number.

A what-if machine is my answer to that. It is a small, shared simulation with a few levers and one output. Its job is not to predict the future. Its job is to put the assumption on the table where everyone can see it and move it.

The queue does not care

Take a testing team. The numbers here are illustrative, to show the shape, not from any real program.

The team can properly complete 40 test cycles a week. The program is now sending 60 a week, because more releases have been squeezed into the same calendar. Each week, 20 cycles go unfinished. After six weeks, the backlog is 120 cycles.

Nobody in the room decided to build that backlog. It is just what happens when arrival rate is higher than finishing rate. Queueing theory has a name for the relationship between work in progress, throughput and wait time, Little's Law, but you do not need the name. You need to see the line go up.

The same arithmetic applies to a sort floor at peak. If parcels arrive 30% over forecast and the shift can only clear what it cleared last week, the extra does not vanish. It waits. Every day it waits, it becomes a customer contact.

Three levers, one output

The first version of a what-if machine should be embarrassingly small. Three levers, one output.

For the testing example, the levers would be:

• Arrival rate: cycles sent per week.
• Capacity: cycles the team can properly finish per week.
• Start backlog: what is already waiting.

The output is one line: backlog over the next twelve weeks.

That is enough to change the conversation. Instead of "I think the team will cope", someone moves the arrival slider to the number the program is actually planning and the whole room watches the line climb. Then someone asks the better question: which lever are we actually willing to move?

It is tempting to add more. Skill mix, rework rate, leave, defect severity. Resist it for the first version. Every lever you add is another assumption to argue about, and the point was to reduce the arguing.

No ghost numbers

The dangerous part of a sim is the defaults. A number typed in by whoever built it, with no source, quietly becomes the truth. I call these ghost numbers.

My rule is that every default has two things next to it: a name and a source. The name is the person who owns that assumption. The source is where it came from, even if the source is "the test lead's estimate from last quarter".

And the person who sets an assumption should be the person closest to the impact. The test lead sets capacity. The program sets arrival rate. The depot manager sets what the shift can clear at peak. Not the person with the best spreadsheet skills. I have said to my own team that frontline feedback is operational data. This is where it goes in.

If nobody will put their name to a number, it does not go in the model. That alone surfaces more than the model does.

When nodding is not feeling

Sometimes the room already agrees with the number and still does nothing.

Picture a slide in a steering committee. It shows a customer journey with six handoffs between teams. Someone points out that every arrow is a place where work waits. Every leader in the room nods. Then the meeting moves on, and nothing changes.

Nobody disagreed. They just did not feel it. The people who feel it are on the counter, on the dock and in the depot, living with the wait every shift. For that problem, a slider is not enough. The machine has to be played.

The one I want to build first is a parcel game. A parcel moves from a customer to a doorstep through six handoffs: counter, collection, sortation, linehaul, depot, delivery. Each handoff adds some time and a small chance of an exception: a missed scan, a wrong bay, a label that will not read. Each round, the player can remove one handoff or make one more reliable. The end screen shows how many parcels arrived on time and how many needed someone to chase them.

One mechanic, no badges, under five minutes. The lesson should fit in one sentence a player can repeat to their boss: every handoff you remove is worth more than any single step you speed up. The numbers are illustrative and labelled that way. The point is the shape of the cost, not a forecast of a real network.

It teaches the cost, it never proves the fix

Both versions, the sim and the game, share the same limits, and I would not bend them.

Use it on the problem, early. A working prototype is not evidence that we are solving the right problem, and a slick model can make a weak plan look rigorous. Go slower on the problem so we can move faster on the right solution. If the machine only appears after the decision, to justify it, it is decoration.

Do not fake the proof. The machine shows why the cost is real. It does not show that your fix works. That needs a pilot, real data, or a real person showing the new way at real speed.

Do not gamify anyone's real job. The game is for people who do not feel the cost. The people who do feel it do not need their shift turned into a scoreboard.

Why this is cheap now

A tool like this used to be a consulting deliverable, and a game like it needed a studio. Now I can describe the levers or the mechanic to an agent and have a rough, shareable version the same afternoon. The build is no longer the hard part. The hard part is agreeing which numbers matter and who owns them.

The signal I would look for afterwards is simple. Does the next meeting start at the assumption, or the handoff, instead of at the recap?

I have not built one of these yet, at work or for myself. Before I do, I want to avoid a trap I see all the time. We jump to the solution before we understand the root cause. With AI there is a second version of the same trap: we go looking for a problem for AI to fix, instead of starting with a real problem and then asking whether AI can help.

So the what-if machine is the next thing I will try, and it has to start from a real argument in a real planning meeting, not from the fact that I can now build one in an afternoon. If I cannot name the assumption the room is stuck on, I do not need the machine yet.

Next time your planning meeting goes round in circles, what are the three numbers each side is assuming, and who in the room is closest to knowing the real ones?