Report Requirements: End Users Don’t Know What They Want

I have seen a few posts on LinkedIn about dashboards, and more so on collecting reporting requirements. A few imply the end users don’t know what they want. That the stakeholder group cannot provide the report requirements.

I agree, but also disagree. Let me explain.

(btw, this started as a LinkedIn post, but couldnt help myself)

Not Knowing Reporting Solution, Does Not Mean Not Knowing the Business

I agree that the end users don’t know what they need from a reporting solution.

But, that doesn’t mean they don’t know the business, the area they work in, their responsibilities, their pain points, the processes and so on. They do know it! And if for any reason they don’t... well, the business has much bigger problems than reporting.

Here’s the truth… if this is your excuse, you are not doing right by the end users who are asking for a solution. It may sound harsh, but I feel its needs to be called out.

Your Role as the Reporting Expert

Yes, they might not know what they need from a reporting solution, but that’s because they’re not reporting experts. It’s on us (as reporting experts) to ask better questions, navigate the awkward silences, trigger the right conversations, guide their focus to what truly matters and help them piece together a solution that works.

As the reporting expert, you can’t expect to simply ask "What do you want?" and have all reporting requirements handed to you neatly so you can go on your way to build a report.

The Old Approach to Requirement Gathering is Falling

In my opinion, the days of such an approach are coming to an end… and good riddance to them. This is what made people think dashboards are dead. I wrote about this previously when discussing whether AI will replace the report developer. My view… it will replace report developers, but these types of report developers. The ones who just ask a high-level question and wait for requirements or even worse, just wait for requirements to come to them. Think about it: Copilot, ChatGPT, Claude, they can already do this to some extent, they do it faster and they will only get better. I’d also like add, organisations and end users now expect more. They’re no longer satisfied with a few visuals thrown on a canvas for the sake of it. Expectations are rising and a shake-up is coming.

Real Values Comes From Understanding - Not asking a "What do you want" Requirements Template

I have helped and continue to help clients build reporting solutions that offer genuine value. How?

By going through some pain, hard discussions and much back and forth. The point I am making, I could also just ask "what do you want?", take the first ask provided by end users and just go with it. It will make my life a lot easier and I will still get paid. But, that’s how you also produce solutions that end up being underutilised, offering no genuine value and end up in the dashboard graveyard.

More time, more effort is needed with the end users - yes its harder as you are diving into their world, their area of the business, but in the end you understand them and what they need. YOU, as the reporting expert, can then convert that understanding into a reporting solution.

The Zero-Tech Rule for Better Requirement Gathering

Here's the thing, in early discussions, when I gather requirements for a dashboard I say we should talk zero tech. In fact, I push this and prepare everyone - no visuals, no reporting, no data, no features.

Why? Because, we want to create solutions that provide genuine value. The tech and data alone doesn't offer value, its what we do with it, what we do with it. Once I have the right end-users, we talk about their ambition, long-term plan, core challenge…. Genuinely getting to know them and why we are having this meeting? If we are here to build a solution, what benefit does it offer, who does it help, how does it help? Does it Help us move closer to an objective, overcome a challenge, generate sales, save on costs, minimise risk, be more compliant… This is the foundation to building a reporting solution that is highly used, adopted and which provides some level of actionable insights.

But Isn’t That the Role of the Business Analyst?

You might be thinking, “Isn’t a lot of this the job of a BA?”. Yes, you’re right, in many setups, engaging with end users and gathering requirements is traditionally seen as the BA’s domain.

But here’s what I’ve seen in reality:

Many organisations either don’t have Business Analysts at all or the ones they do have aren’t always equipped to ask the kind of questions that surface reporting needs tied to real challenges or objectives.

Also, I did mention this above, but relevant here, I think many BI developers, especially those who focus purely on development reports/dashboards, need to start stepping into this space more.

Getting comfortable understanding the business. Its challenges. Where it’s heading. Speaking their language. AI is only going to get better at building reports. If your role is limited to just building, the future doesn’t look great. The value is shifting from building dashboards to connecting with the people and purpose behind them

Summary

So yes, end users might not know what they need from a reporting solution. But that’s not their job. It’s yours. Your job is to understand their business objective. The challenge they’re facing. Where they’re trying to go. Once you know this, translate that into a solution that actually helps them get there. Stop waiting for perfect requirements. Start doing the work to uncover them.