A client once handed our crew a spec sheet for a truck build with a very specific ask: four more monitors in the A2 bay, matching exactly what a competitor’s truck had. We could have just installed the monitors. Instead, someone on our team asked why — and it turned out the real problem wasn’t a shortage of screens, it was that their audio mixer couldn’t see the iso feeds he needed during a specific type of replay, so he’d started guessing. Four more monitors would have given him four more things to guess at faster. What he actually needed was one screen, routed correctly, showing the one feed that mattered at the right moment. We built that instead. He never asked for it, because he didn’t know it was the thing to ask for.
That gap — between what someone requests and what they actually need — is where most of the real work of building anything worthwhile happens, and it’s also the gap most organizations are structured to skip.
The request is not the requirement
“The client asked for it” and “we have a purchase order” are two of the most dangerous sentences in any planning meeting, not because clients and purchase orders don’t matter, but because they end the conversation exactly where it should have started. A request is someone’s best guess at a solution, made from inside their own limited view of the problem. Treating it as the requirement means building their guess instead of solving their problem, and those are not reliably the same thing.
“Faster horses” is apocryphal. It’s still right.
You know the line about Henry Ford and faster horses — probably never said quite that way, but durable anyway because it names something true. People are remarkably good at describing what’s wrong with their day and remarkably bad at inventing the thing that fixes it, because that second part isn’t their job. It’s ours. The discipline isn’t ignoring what people ask for; it’s treating the ask as a clue about the underlying job they’re actually trying to get done, and staying curious past the first answer until you find it.
Technology changes the tool. It rarely changes the job.
I’ve watched entire facilities re-equip around a new format, a new codec, a new cloud-based everything, and the language around it always promises transformation. Some of it delivers — new ways to remove a step, speed a process, connect people who couldn’t reach each other before. But underneath the tooling, the actual job the crew is doing on show night is nearly identical to the job crews were doing decades earlier: get the right picture, with the right sound, to the right place, at the right moment, without anyone in the audience noticing the machinery. Technology is the engine. It’s rarely the destination, and it’s worth remembering that difference every time a vendor pitch tries to collapse the two.
Hold that thought, because AI makes the request-versus-requirement trap easier to fall into, not harder. When building the exact thing someone asked for costs almost nothing and takes almost no time, the temptation to skip the “why” and just ship the literal ask goes up, not down. A team that can generate four more monitors’ worth of dashboard in an afternoon still hasn’t solved anything if nobody stopped to ask what the mixer was actually trying to see.
So let’s drop a waypoint: what people ask for tells you where to start looking, not where to stop. The shot that wins the night is rarely the one anybody requested — it’s the one somebody built after asking one more question than they had to.
Leave a Reply