The Five Whys, and why “I want a new dashboard” is never the real request

One of the biggest challenges I’ve faced in my career is collecting requirements from stakeholders. Not because they’re vague. Most people are pretty confident telling you what they want. It usually starts with “I want a new dashboard” or “I want a new report.” Some will even sketch it for you. A few bar charts, a table, and yes, always a pie chart (argh).

As a people pleaser who wants to deliver, I’d go off and build it. Who doesn’t love building a pretty dashboard? Sleep, eat, build dashboards, repeat.

Then the stakeholder comes back. It’s not quite what they expected. It doesn’t answer the question they thought it would. It’s opened up more questions, so now they need another slice of data and more charts. This dance can run for weeks, sometimes months, quietly turning a small request into a sprawling development with a hundred metrics bolted on. Scope creep, but the polite version, the kind that sneaks in “just one more thing” at a time.

Then a few months after “done,” you check the usage. Zero. “Oh yeah, it didn’t actually solve the problem.” Or worse, “we’ve gone back to our Excel report, it worked better for us.” You go back to your desk, vent to a colleague, laugh about it while dying a little bit more inside, and start building the next thing. Sound familiar?

What changed my thinking

I learned the hard way, and honestly I’m still refining it. The principles of Agile shifted things for me completely. Agile was built for software development, but the thinking applies far beyond it: Lean’s focus on removing waste, Deming’s Plan, Do, Study, Act cycle, and one of my favourite tools, the Five Whys.

The real challenge with gathering requirements, especially when you sit alongside the business rather than inside the process itself, is that you’re often working in specialist areas you have no first hand experience of. And requirements aren’t static. Assuming what you collect today will still be accurate by the time you ship is naive. Businesses and people change faster than it feels like they do.

Building something that actually gets used comes down to understanding the real problem underneath the request, not the request itself. And even then, expect the stakeholder to change their mind as the build evolves. (It has happened to 99.9% of the time!) That’s not a failure of requirements gathering, that’s what happens when a build surfaces things nobody had considered yet.

The tool: the Five Whys

The Five Whys one comes from Sakichi Toyoda, founder of what became Toyota Industries, developed in the 1930s as part of the Toyota Production System. Keep asking “why” past the first answer, until you hit the root cause instead of the symptom.

The classic example, and you may well have seen a version of this before, is the Jefferson Memorial. Management was worried about the stone corroding and the cost of eventually replacing it. And finance was gasping at the spend on cleaning materials. The first instinct was simply to find a gentler, cheaper cleaning product. Then someone asked why it needed cleaning so often. And kept asking, until the answer turned out to be the floodlights left on too early each evening. Delay the lights, and the entire chain unravels: no flies, no spiders, no birds, no droppings, no aggressive cleaning, no corrosion.

Where it landed for me

When I applied that thinking to my own projects, and pushed my teams to do the same, something shifted. Getting closer to the business, asking “why” and then why again, being genuinely curious about their world, led to solutions that addressed the actual root cause rather than papering over the symptom sitting above it.

Senior stakeholders often just need to see the KPI. But what actually moves that number isn’t the seeing the KPI results in a dashboards, it’s what’s driving it underneath. You can’t assume they’ve already worked that out before they come to you. And I know first hand that not every analyst feels confident enough to question a senior, confident stakeholder.

The technical skills are the easy part to learn, especially now, sat in front of a laptop with AI doing some of the heavy lifting. Communication, stakeholder management, and the confidence to push back are what actually set analysts apart. They’ve paid off for me more than any good looking dashboard ever has.

Asking ‘Why’ can be hard

Yes I can hear you now. Asking “why” five times in a row could feel confrontational, even defensive, especially face to face with someone senior. So I’m not suggesting you literally interrogate people. Try softer versions instead: “Can you explain that a bit further?”,”Help me understand the problem behind the ask“, “How’s this going to be used in practice?“, “Is there a root cause behind this, or is it the immediate fix?”. Show genuine interest in their world, most people are flattered rather than put off by it. Keep asking until you get as far into the issue as you possible can, and hopefully you and the stakeholder may get the same ‘aha’ moment as the people looking after the Jefferson Memorial.

Keep going until you actually understand the problem and get as far into the issue as you possible. Dont just the jump to building with the initial requirements. Build for that problem, and you’re far more likely to create something that gets used, and something worth shouting about afterwards.

So, cheesy as it sounds: stop, and ask why. Then ask again!

What’s the request you built exactly as asked, that never got used?

If you liked this blog then you may find this one useful too: Why Agile Project Management could work for you! – Dataliciously Ella

If this resonated and you’re navigating a leadership transition and facing similar challenges, I coach people and organisations through exactly this — book a free discovery call.

Feedback always welcome

Best wishes

Ella

August 2026