3 min read
The question that stopped working: why 'tell us what you want' is now the wrong thing to ask
Paul Heaton : Aug 24, 2026, 9:57:17 AM
Last week a client told me she couldn't tell me what she wanted, because she didn't know what was possible. It was the most useful thing anyone has said to me about AI this year.
The conversation was about SharePoint, not AI, which is why it matters. Two executives from a mid-sized operator — exactly the kind of organisation this industry calls the sweet spot for modern workplace — sat down to explain why a platform they have been paying for years still isn't doing anything for them.
“We basically use it as a big OneDrive,” one said. “We need a tutorial on steroids that takes us through the options, and then we can make decisions based on that. Because how we got to this point is that we didn’t know the options that you could have.”
Her colleague put it more bluntly: “Tell us what’s possible, and then we’ll say what we want.” And then the line I keep coming back to: “I feel like there was a big step that was missed in everyone’s education, from saving files in a folder to SharePoint. It just never happened for non-IT people.”
They are right. And this industry, mine included, has been quietly living off that gap for a decade.
The method broke before AI arrived
Here is what makes this more than a complaint about training.
The standard way our industry starts work is requirements elicitation. We ask the client what they want. We run a discovery workshop, we build a mind map, we produce a scope. It underpins every statement of work ever written, and it rests on an assumption nobody says out loud: that the buyer holds a working mental model of what the technology can do.
For servers, that assumption held. Everyone understands “the file server is slow” and “we need email that doesn’t go down.” For AI and the modern workplace, it does not hold at all.
The same client told me she had been asked, a year earlier, to draw a mind map of what she wanted. Her reaction: “Asking me what I want is like — what does it do?”
That is not an unsophisticated buyer. That is a method failing in the field. And when the method fails, one of two things happens. Either nothing happens — the project stalls, quietly, for years — or something worse happens: the client buys what they were shown rather than what they needed. A colleague described another organisation’s history with a previous provider this way: they paid a lot of money for workflow that doesn’t work properly. “They didn’t know enough to say no, or what they really wanted.”
Unbounded requirements plus an uneducated buyer is not a discovery problem. It is an exploitation risk. And it now sits underneath every AI conversation in the mid-market.
Education debt is the hidden variable
Call it education debt. For roughly fifteen years this industry rolled SharePoint, Teams, OneDrive and M365 into organisations of 50 to 1,000 people and measured success in tenants migrated rather than people who understood what they now had. Technical adoption succeeded. Human adoption was skipped, because nobody was paid for it and nobody audited it.
That debt was survivable while the platform behaved like a filing cabinet. It is not survivable now, because AI is the first technology in this stack whose value is determined almost entirely by the buyer’s ability to imagine an application for it. You cannot prompt your way to an outcome you cannot conceive of. You certainly cannot write a requirement for one.
So we get a paralysis the market is currently mislabelling. It gets written up as “AI readiness,” as though the blocker were data hygiene and identity. Those matter. But in the rooms I have been in this month, the block came earlier than that: the buyer could not form a request. They were not unready. They were uninformed — by us, over a decade, through neglect rather than intent.
What this changes — for how you buy, and how we sell
If you run a 50-to-1,000-person organisation and your AI programme is stuck at “we should really do something with this,” test one thing before you test anything else. Ask your provider to show you the option space before they ask you to define scope. If the first artefact they produce is a requirements questionnaire, they are outsourcing the hardest part of the job back to you — and charging you for the privilege.
And if you run a provider, as I do, the uncomfortable version is this. Our discovery method is a legacy of an era when clients could reasonably be expected to know what they were buying. That era has ended. Turning up with questions when the client needs a demonstration is not consultative. It is an abdication dressed as consultation.
We changed our own approach after that conversation. Rather than come back asking them to specify what they wanted, we went the other way and showed them what the platform could actually do, and what we would do about it, before asking them to decide anything. That got things moving again.