Introduction
A stakeholder says:
“I need a dashboard showing sales by region.”
It sounds like a clear requirement.
It isn’t.
What decision will the dashboard support? Who will use it? What does “sales” mean? How frequently should the information refresh? What should someone do after discovering that sales have fallen?
One of the most valuable skills a Data Analyst or BI professional can develop is learning how to turn a stakeholder’s request into a genuine business requirement.
The best analysts don’t simply build what was requested. They understand why it was requested.
Here are seven questions that can help.
1. What Problem Are We Trying to Solve?
Before discussing charts, colours or filters, understand the problem.
Suppose someone requests:
“Can you build a customer cancellation dashboard?”
Ask:
“What problem are you hoping this dashboard will help you solve?”
You might discover that the actual problem is:
“Regional managers don’t know which customers are at greatest risk of cancelling until after they have already left.”
That changes the project considerably.
The requirement isn’t really a cancellation dashboard.
The business needs early visibility of cancellation risk.
That distinction can influence everything from the data you select to the KPIs you create.
2. What Decision Will Someone Make Using This Information?
Every useful dashboard should support a decision or action.
Ask:
“Once you have this information, what will you do differently?”
Suppose a stakeholder wants a weekly sales dashboard.
Their answer might be:
“If a region is more than 10% below target, the regional manager will investigate product performance and agree corrective action.”
Now you understand something important.
The dashboard should probably highlight:
- Performance against target
- Variance percentage
- Underperforming regions
- Product-level drill-down
- Historical trends
Without that conversation, you might simply have produced a colourful regional sales chart.
3. Who Will Use the Dashboard?
Different audiences need different levels of information.
An executive may need:
- Five important KPIs
- Trends
- Exceptions
- High-level commentary
An operational manager may need:
- Detailed records
- Filters
- Drill-down capability
- Daily information
An analyst may need:
- Granular data
- Export functionality
- Additional dimensions
- Diagnostic information
Practical Example
Imagine a CEO and an operations manager both request a customer-service dashboard.
The CEO might need:
Customer satisfaction, complaint volumes and overall trend.
The operations manager might need:
Complaint category, team, location, agent, resolution time and individual cases.
The underlying data could be identical.
The reporting experience should not be.
4. How Do You Define the KPI?
This question prevents many reporting disagreements.
Suppose the stakeholder requests:
Active Customers
Ask:
“What exactly qualifies someone as active?”
Possible answers include:
- Logged into the website during the last 30 days
- Made a purchase during the last 30 days
- Has an active subscription
- Has not formally closed their account
Each definition produces a different number.
Document the agreed definition before development begins.
For example:
Active Customer
A distinct customer with at least one successfully completed transaction during the previous 30 calendar days.
Also document:
- Data source
- Calculation
- Exclusions
- Owner
- Refresh frequency
This is where stakeholder management, BI and data governance begin to overlap.
5. How Fresh Does the Data Need to Be?
Stakeholders often say:
“I want real-time data.”
But real-time reporting can add cost and complexity.
Ask:
“What decision requires the data to be real time?”
You may discover that the stakeholder reviews the dashboard every Monday morning.
A daily refresh could therefore be perfectly adequate.
Alternatively, a fraud-monitoring team may genuinely require information within minutes.
Refresh frequency should be determined by the business need, not simply by what technology can deliver.
6. What Would Make You Stop Trusting This Dashboard?
This is one of the most useful questions a BI analyst can ask.
The stakeholder might say:
“If the customer total doesn’t match our operational system, people will stop using it.”
Now you know that reconciliation should form part of your validation process.
Another stakeholder might say:
“If yesterday’s figures aren’t available by 9am, the dashboard isn’t useful.”
That identifies timeliness as a critical data-quality requirement.
Their answers can help you define appropriate controls for:
- Accuracy
- Completeness
- Consistency
- Timeliness
- Reconciliation
Data quality becomes much more meaningful when connected to what actually matters to the user.
7. What Does Success Look Like?
Finally, ask:
“How will we know this dashboard has been successful?”
Possible answers might include:
- Managers stop producing manual spreadsheets.
- Monthly reporting takes two hours instead of two days.
- Teams identify problems earlier.
- Senior managers use one agreed version of the KPI.
- Report-related support requests decrease.
- Business users can answer common questions without asking analysts.
This moves the conversation beyond:
“Did we deliver the dashboard?”
towards:
“Did the dashboard improve something?”
That is a much stronger measure of BI success.
Putting the Seven Questions Together
Imagine a stakeholder requests:
“Build me a Power BI dashboard showing customer complaints.”
Instead of immediately opening Power BI, conduct a short requirements conversation.
Question 1 — What problem are we solving?
Managers discover complaint trends too late.
Question 2 — What decision will the information support?
Managers need to identify categories experiencing unusual increases and investigate them.
Question 3 — Who will use it?
Customer-service managers and senior leadership.
Question 4 — How are the KPIs defined?
A complaint is counted when a formal complaint record is created, with reopened cases excluded from new-case counts.
Question 5 — How fresh must the information be?
Daily by 8am.
Question 6 — What would cause users to distrust it?
Totals not reconciling with the complaints-management system.
Question 7 — What does success look like?
Managers identify emerging complaint patterns during the week rather than waiting for the monthly report.
You now have a much stronger requirement.
And you still haven’t opened Power BI.
Document What You Agree
After the meeting, capture the important decisions.
A lightweight requirements document might contain:
| Requirement | Agreed Definition |
|---|---|
| Business problem | Complaint trends identified too late |
| Users | Customer-service managers and leadership |
| Primary KPI | New formal complaints |
| Refresh | Daily by 8am |
| Primary source | Complaints-management system |
| Key dimensions | Category, region, team and date |
| DQ requirement | Daily totals reconciled to source |
| Success measure | Earlier identification of complaint trends |
This simple documentation can prevent weeks of misunderstanding later.
What If the Stakeholder Changes Their Mind?
They probably will.
Requirements naturally evolve when users see their data presented visually.
The important thing is to distinguish between:
Clarification
and
New scope.
Suppose the original requirement covered sales performance.
Later, someone asks:
“Could we also add customer profitability and marketing campaign performance?”
That may be valuable.
But it may also require different datasets, business owners, calculations and validation.
Document the change rather than silently expanding the project.
Good stakeholder management isn’t about saying yes to everything.
It’s about making decisions and implications visible.
A Useful Interview Technique
Stakeholder-management questions are common in Senior Data Analyst and BI interviews.
You may be asked:
“Tell us about a time you dealt with an unclear stakeholder requirement.”
Avoid answering only:
“I arranged a meeting and clarified the requirement.”
Show your analytical process.
A stronger STAR structure is:
Situation: A stakeholder requested a dashboard but the original requirement was broad and several teams interpreted the KPI differently.
Task: Establish an agreed requirement and deliver reporting that users could trust.
Action: Identified the business decision, users and KPI definitions; investigated available data; documented assumptions; created a prototype; reviewed it with stakeholders; incorporated feedback; validated the numbers and obtained sign-off.
Result: The team received an agreed reporting solution with clearly defined metrics, reducing ambiguity and repeated reporting questions.
That answer demonstrates:
- Requirements gathering
- Stakeholder management
- BI delivery
- Data quality
- Governance
- Documentation
- Communication
Those are senior-level analytical skills.
A Seven-Question Checklist
Before starting your next Tableau or Power BI dashboard, ask:
- What problem are we trying to solve?
- What decision will this information support?
- Who will use the dashboard?
- How are the important KPIs defined?
- How fresh must the data be?
- What would cause users to stop trusting the dashboard?
- What does success look like?
Only then should the conversation move toward charts, filters and dashboard layouts.
Final Thoughts
Stakeholders usually describe the solution they imagine.
“I need a dashboard.”
Your job as an analyst is to discover the problem underneath it.
Sometimes a dashboard is the right answer.
Sometimes the answer is a data-quality fix, a simpler report, an automated alert, a new KPI definition—or even retiring an existing report.
The senior analyst’s value isn’t simply knowing how to build what was requested.
It is knowing which questions to ask before building anything.
Suggested Call to Action
Before accepting your next dashboard request, try asking these seven questions.
Did the stakeholder’s original request change once you understood the underlying business problem?
Share the question that has helped you most when gathering BI requirements with the Data Cruise community.
Leave a comment