A demo dazzles, a budget gets approved, and nobody asked what problem it solves. Here's the three-question test that stops you buying the wrong answer.
Let me describe a meeting I've sat in at least a dozen times. The specifics change - the company, the city, the technology - but the shape of it never does.
A senior leader comes back from a conference, or a vendor dinner, or a LinkedIn rabbit hole at 11pm on a Tuesday. They've seen something. A platform. A tool. An AI-powered something. And they're genuinely excited, which is rare enough in most leadership teams that people pay attention. Within a fortnight, there's a slide deck. Within a month, there's a budget request. Within a quarter, there's a signed contract.
Six months later, the technology is live. It works exactly as specified. And almost nobody is using it.
I watched this happen recently with a mid-sized consulting firm - around 200 people, solid reputation, good clients. The managing partner had seen a competitor talking about their new client portal at an industry event. Slick demo, impressive functionality, all the right buzzwords. He came back on Monday morning and told his COO they needed one. By the following quarter they'd spent north of £180k on a portal that, twelve months on, had a 14% adoption rate among clients. Fourteen percent. The technology worked beautifully. Nobody had asked whether clients actually wanted a portal, or what specific problem it was supposed to solve for them.
The clients, it turned out, were perfectly happy with email.
What gets me about this isn't that the people making these decisions are stupid. They're usually sharp, commercially minded leaders who wouldn't dream of signing a lease on a new office without understanding exactly why they needed the space. But something about technology short-circuits that discipline. The demo is compelling. The vendor is persuasive. A competitor seems to be doing it. And suddenly the investment case is being built backwards - starting with the solution and working out to find a problem that justifies it.
McKinsey's 2024 data puts it starkly: 70% of large-scale transformations fail to achieve their expected outcomes. Not fail completely - just don't deliver what was promised. And in my experience, the single most common thread running through those failures isn't bad technology or incompetent implementation. The technology was selected before the problem was properly understood.
The symptoms are predictable. Requirements get written to fit the technology rather than describe the actual need - you end up with a spec that reads like the vendor's feature list with your logo on it. Adoption is low because the tool was designed around what the technology can do, not what your people or clients actually need to do. ROI measurement becomes impossible because nobody defined a specific outcome before the investment. And - this is the bit that really bothers me - the organisational learning from the failure is incomplete, because the real cause is rarely named. The post-mortem blames implementation, or change management, or "cultural resistance." Never the decision to start with the answer.
We saw what this platform can do. It solves exactly the kind of problems we have. We know we need this.
I hear you. And honestly, you might be right - the technology might genuinely be relevant to your situation. But "relevant" and "ready to buy" are very different things. The fact that a tool could theoretically solve a problem you have doesn't mean you've done the work to understand the problem clearly enough to buy well. It's like walking into a pharmacy because you feel unwell and buying the most expensive thing on the shelf because the packaging mentions your symptoms.
There are three forces at work here, and they're worth naming because they're all completely human.
The first is demo gravity. A good product demo is engineered to make you feel something. The vendor has spent millions on making their platform look inevitable. They show you the happy path - the perfectly configured dashboard, the integration that just works, the delighted user clicking through a workflow in four steps. What they don't show you is the six months of configuration, the data migration headaches, the change management programme you'll need to run alongside it, or the 60% of features you'll never touch. I'm not blaming vendors for this - it's their job to sell. But the emotional momentum from a demo is almost always ahead of the readiness to buy.
The second is competitive anxiety. Gartner's research shows that 80% of the B2B buying journey now happens without direct vendor contact - people are researching, comparing, and forming opinions long before they talk to a salesperson. That same dynamic works on you as a buyer of technology. You see a competitor's announcement, or a case study, or a conference keynote, and the fear of falling behind kicks in. The question shifts from "what do we need?" to "what are we missing?" Those lead to fundamentally different investments.
The third - and I think this is the sneaky one - is that defining problems properly is harder and less exciting than evaluating solutions. Sitting in a room arguing about what's actually broken, who it affects, and what "fixed" would look like? That's genuinely uncomfortable work. It surfaces disagreements. It requires honesty about things that aren't working. Watching a demo, by contrast, is pleasant. It feels like progress. So the gravitational pull towards the technology conversation is partly just a pull away from the harder conversation that should come first.
Right, so this is where I need to be practical rather than just critical. Because "start with the problem" is easy to say and genuinely hard to do well.
The discipline comes down to answering three specific questions before any vendor conversation begins. Not after. Not during. Before.
What exactly is not working now? And I mean exactly. Not "our digital experience needs improving" or "we need better client engagement." Those aren't problems, they're vibes. Something specific, measurable, affecting identifiable people. Something like: "34% of broker applications contain errors that require manual follow-up, consuming 15 hours of operations time per week and causing brokers to place business with competitors." That's a problem. You can point at it. You can measure it. You know who it's hurting.
What would "working" look like? A concrete outcome, not a capability. Not "we need a modern portal" but "broker application errors drop below 10%, operations time on follow-up drops to under 4 hours per week, and broker NPS improves by 15 points." The first answer has a technology baked into it. The second describes a future state that could be achieved several different ways - maybe a portal, maybe a form redesign, maybe better training materials, maybe a combination.
How will we know if we've achieved it? A metric or observable change that's independent of the technology used to get there. This one matters because it's your protection against the most common failure mode: declaring success because the technology was delivered, even though the problem wasn't solved. If your success metric is "portal launched on time and on budget," you've already lost. If it's "broker application errors below 10% within six months," you've got something real to aim at.
These three questions sound simple. They are simple. But I can count on one hand the number of times I've walked into an organisation that had answered them clearly before starting a technology evaluation. Usually what I find is a brief that describes the solution in loving detail and the problem in one vague paragraph at the top.
We worked with a 400-person professional services firm that had been quoted over £400,000 for a full website and CRM rebuild. The COO had a feeling they were about to spend a significant amount solving the wrong problem, and asked us to take a look. Our 14-day assessment revealed that roughly 60% of the original brief was unnecessary. The actual problem - a broken enquiry-to-onboarding handoff that was losing qualified leads - could be fixed in a 90-day sprint for around £80k. They saved £320k and saw a 22% improvement in enquiry-to-client conversion within three months. The technology they ended up using was almost incidental. What mattered was that someone had finally asked "what's actually broken?"
I should mention WHNN here - it's a framework we developed at Distinction precisely because we kept seeing this pattern and wanted a structured way to prevent it. WHNN stands for The What and the How, for the Now and the Next, and it runs on a quarterly cycle.
The bit that's relevant here is the sequencing. WHNN forces you to start with "What needs to change?" - which demands a clearly defined problem before any technology conversation can begin. Only once you've properly scoped the problem do you move to "How will it be delivered?" - which is where technology selection sits. The Now gives you an honest assessment of where you actually are today, and the Next defines where you need to be in 3, 6, or 12 months.
It's not magic. It's just discipline. But that discipline makes technology-first thinking nearly impossible because you literally can't get to the technology conversation until you've done the problem definition work. I've written a separate piece on what WHNN looks like in practice if the framework interests you.
Worth saying though: WHNN is one approach. The principle matters more than the specific framework. Any process that forces problem definition before solution evaluation will produce better outcomes than one that doesn't. The important thing is having something that creates that gate.
There's a commercial consequence to technology-first failures that doesn't get talked about enough. Every failed digital investment makes the next one harder to approve.
I call it scar tissue. The board that approved £180k for a client portal nobody uses isn't going to be enthusiastic about the next proposal, even if it's genuinely good. The partners who sat through the last "transformation" and watched it deliver nothing are going to be sceptical of the next one. The finance director who had to write off the investment is going to scrutinise every line of the next business case with a level of suspicion that borders on hostility.
And here's the kicker - they're right to be sceptical. Their pattern recognition is working perfectly. The problem is that scar tissue doesn't just make them resistant to bad investments. It makes them resistant to all investments. The organisation develops a kind of digital flinch. Someone says "we need to invest in..." and half the room is already thinking about the last time someone said that.
McKinsey's finding that 54% of firms switch suppliers due to poor digital experience should concentrate minds here. Your competitors who got the sequencing right - who started with problems and selected technology to solve them - are building digital capabilities that actually work. While your organisation is stuck in a cycle of failed investments and growing reluctance to try again, they're pulling ahead. Not because they picked better technology. Because they asked better questions before picking anything.
I've written separately about how to rebuild the case for digital investment after a previous failure - if you're in that position, it might be useful. But it's far easier to get the sequencing right first time than to repair the damage after getting it wrong.
So here's my practical suggestion, and it's deliberately low-effort because I know you're busy and I know the last thing you need is another process.
Before any digital investment decision - any of them, regardless of size - require the proposing team to produce a one-page problem statement. One page. Answering the three questions I outlined earlier:
The rule: the problem statement cannot reference a specific technology or vendor. If the team can't describe the problem without naming the tool, the investment isn't ready to be approved. Send them back to do the work.
This sounds almost comically simple. One page. Three questions. No technology mentioned. But I promise you, the first time you apply this test, at least one active proposal in your organisation will fail it. Probably the most expensive one.
A managing partner I work with started doing this about eighteen months ago. First proposal through was a £95k investment in a marketing automation platform. The one-page problem statement came back as essentially a rewrite of the vendor's capabilities brochure - couldn't describe the problem without naming HubSpot in every other sentence. He sent it back. Two weeks later, the revised version identified the actual problem: the firm was generating 40+ thought leadership pieces per year but had no systematic way to connect them to business development activity. The eventual solution cost £30k and didn't involve marketing automation at all - it was a content taxonomy and distribution workflow built into their existing CMS.
Saved £65k. Actually solved the problem. And - maybe more importantly - gave the marketing team a win they could point to when they came back with their next proposal.
If you're reading this and recognising the pattern - if you've been the person who came back from the conference excited about a technology and pushed for the investment - that's not a character flaw. The technology probably was impressive. The instinct that your organisation needs to modernise is probably right. The problem isn't your judgement about what's possible. It's the gap between what's possible and what's needed right now, for your specific situation, given your specific constraints.
And honestly, some of the best digital investments I've seen started with someone getting excited about a technology. The difference is what happened next. In the good outcomes, the excitement triggered a proper problem definition exercise - the technology became one option among several for solving a well-understood problem. In the bad outcomes, the excitement became the business case, and everything else was reverse-engineered to justify a decision that had already been emotionally made.
The discipline I'm describing isn't about suppressing enthusiasm or being a technology sceptic. It's about channelling that enthusiasm through a process that gives it the best chance of actually delivering something. Because there's nothing more demoralising than watching a genuinely good technology fail because it was deployed against the wrong problem - or no clearly defined problem at all.
If this resonates and you're thinking about how to apply it to a real investment decision - particularly one where budget is under pressure - there's a companion piece on planning digital investment when budgets are tight that puts a practical framework around this.
But you don't need a framework to start. You need the one-page test. Print it out, stick it on the wall of whatever room your investment decisions get made in, and don't let anything through that can't answer those three questions without naming a vendor.
It won't make you popular with the salespeople. It will make you significantly better at spending money on things that actually work.