One question has trailed the AI wave into every product conversation this year: why bother with customer discovery when you can build the thing in a weekend?
The answer got clearer, and it points somewhere most teams are not looking. AI multiplied every team’s capacity to act. We get more code shipped, and more tickets closed. It added nothing to our capacity to know where to act. Over half of new features still fail to deliver the value teams expected. Mostly because they aim at the wrong problem, faster.
The scarce skill moved from acting to aiming. Aiming has one discipline that survives everything: never ask customers what they want or what they would do. People answer politely and imagine a better version of themselves. The answers mislead you without a single lie in them. Instead, ask what they did the last time the problem actually hit. Observe it if you can. Past or present behavior is the only evidence that holds up.
I have applied that discipline inside engineering and operations teams for over 15 years. This one engagement here shows exactly how it plays out.
The diagnosis
An IT operations manager at a financial institution ran 17 technicians across a dozen office buildings, handling phone and printer incidents. Clients were unhappy and he knew it. Complaints reached him through directors, forwarded emails, hallway remarks. But he had no data on what exactly was broken and no way to prioritize. There was frustration everywhere, but he did not see any leverage.
I’ve met support and platform teams living that situation. Feedback reaches them constantly. They never get a signal they can act on.
The countermeasure
We built a structured Voice of Customer collection with the team. It contained eight questions, asked by phone, each anchored to one specific incident that had just closed:
What did you ask for, and what did you get in the end?
Where and how did the exchanges happen on this incident? What would have suited you better?
What has happened since the fix?
Walk me through the timing, from when you reported it to when it was solved. How did that fit what you needed?
What did you have to do yourself to get this resolved?
Rate this resolution, 1 to 10.
If under 10, what was missing to reach 10?
From your side, how should this ideally have been resolved?
Let’s focus on the design of the questions. There is nothing that asks for an opinion about “our service” in general. Question 6 rates one resolution, at one moment. Questions 7 and 8 pull out the hidden need behind the stated one: a client who asked for a faster printer fix actually wanted to know his ticket was not lost.
The mechanic matters as much as the questions. I called clients the same day their incident closed. I reached thirty of them over a few days. Same-day memory gives you concrete detail and zero recall bias. For me, it’s interviewing while the truth is still warm.
The case
The calls produced the first real baseline: satisfaction at 6.4 out of 10, 17% of incidents resolved within two hours (which was the SLA), 19 incidents per day (the volume). Two issues dominated the verbatims: clients never knew where their ticket stood; and too many incidents should never have happened in the first place.
Each fix answered one of the two findings. Clients didn’t know where their ticket stood, so the team put up a live board showing the status of every open incident, visible to technicians and managers at all times. Repeated calls stopped. Too many incidents were happening, so a structured root-cause cycle (PDCA) traced a large slice of the daily volume back to cabling problems. The team put preventive measures in place. On top of that, technicians started assigning work by impact instead of arrival order, and trained themselves on a “standard” diagnosis routine so resolution quality stopped depending on who picked up the ticket.
Three months later, client satisfaction stood at 8.7, a 45% jump. The two numbers underneath explain why it moved: two-hour resolution climbed from 17% to 31%, and daily incidents fell from 19 to 12. Those are exactly the two frustrations the calls had surfaced, and they were pushed in the right direction. All that happened with zero new hires, and zero new tools.
That engagement predates the AI wave. The manager’s constraint was not capacity. He had 17 technicians and no shortage of effort. His constraint was signal: he could not see where the system leaked, so he could not aim. Today’s teams have more capacity than he ever did, and more telemetry too. They have the same missing signal. Seven questions and thirty phone calls still beat any dashboard at that job.
If you want to see where your own system leaks, the Delivery Scorecard takes two minutes. Ten questions, and you know where to look first. And if defining value from your customer’s side is the wall your team keeps hitting, I run a half-day working session with leadership teams. Reply to this email, or message me directly on Substack, and I’ll send you the outline.
P.S. AI made acting cheap. It did nothing to the cost of acting on the wrong problem. Voice of Customer is how you find the right one.