Overview
In this episode of The Dashboard Effect, Brick Thompson and Solutions Architect Will Trickett walk through a structured framework for stakeholder interviews that addresses one of the most consistent sources of rework in BI development: building reports based on metrics requests rather than business goals. The four-area questioning framework they describe inverts the typical approach, starting with purpose and working toward metrics rather than the reverse, and the difference in outcome is significant.
For any BI developer or data team that has delivered a technically correct report that missed the mark on what the business actually needed, this episode provides the interview structure that closes that gap before a single visual is built. See how Blue Margin’s Managed Analytics & Insights applies this kind of structured discovery process to ensure every report is built to deliver the business value it was designed for.
What This Episode Covers
Area One: Business Goal (1:35 – 3:39)
Before any conversation about metrics or visuals, the interview should establish the business goal the report is meant to serve. What is the intended return on investment? Is the report designed to save time, drive revenue, reduce risk, or improve a specific operational outcome? Without that clarity, the metrics selected are choices made without a standard to evaluate them against, and the resulting report may be data-rich and strategically inert. Starting with the why gives every subsequent decision a reference point.
Area Two: Personas (3:44 – 6:10)
Identifying exactly who will use the report is more nuanced than it appears. The person commissioning the report and the people who will actually rely on it day to day are often different, and their needs can diverge significantly. The hosts emphasize the importance of uncovering shadow stakeholders, users whose requirements are not represented in the initial brief but whose adoption or non-adoption will determine whether the report delivers value. Missing those users at the discovery stage means discovering their needs during a revision cycle instead.
Area Three: Knowledge Gaps and Questions (6:13 – 8:51)
The third area focuses on the specific questions users are trying to answer. This is distinct from asking what metrics they want to see. A metric is an answer without a question, and a report built around answers without questions tends to provide data that users look at without acting on. Understanding what decisions the report is meant to inform, and what information is currently missing that prevents those decisions from being made confidently, produces a report that closes a genuine knowledge gap rather than filling a page with numbers.
Area Four: Metrics and Slicers (8:52 – 10:33)
Only after the business goal, the user personas, and the knowledge gaps are established does the framework move to metrics and slicers. At that point, the earlier work has defined what success looks like and what questions need to be answered, which makes the metric selection process a matter of identifying the right tools for a defined job rather than choosing from an open-ended list of available data points. The slicers, the dimensions by which users will filter and explore the data, follow directly from understanding who is asking which questions in which contexts.
Inverse Thinking and Efficiency (10:45 – 11:15)
The hosts note that most stakeholder conversations start with metrics, which is the inverse of the order that produces the best results. Starting with the business goal and working down to the metrics is a more disciplined approach that takes approximately 45 minutes when the four areas are covered with focus. That efficiency is one of the framework’s practical advantages: it is not an extensive research process but a structured conversation that yields the clarity required to build something that works.
Who It’s For
This episode is worth your time if you are a BI developer or data analyst who conducts stakeholder interviews regularly and wants a more structured approach that reduces the likelihood of building the wrong thing, a solutions architect or project lead responsible for the discovery phase of a BI engagement and looking for a framework that can be consistently applied across different clients and contexts, a data team lead trying to establish a standard interview process that improves the quality and alignment of reports across the team, or any organization that has experienced the frustration of receiving a delivered report that was technically accurate but did not serve the decision-making needs it was built to address.
Why It’s Worth a Listen
The inverse thinking point is the most structurally important idea in the episode. The instinct to start with metrics is understandable because metrics are concrete and discussable in a way that business goals sometimes are not. But a conversation that starts with metrics anchors the report to what data is available rather than what the business needs to know, and that anchor is responsible for a significant portion of the rework that BI projects generate. Reordering the conversation produces better requirements without requiring more time to gather them.
The shadow stakeholder concept is worth particular attention for anyone who has delivered a report that was approved by the sponsor and then not adopted by the people it was built for. The gap between what the person commissioning a report needs and what the people using it need is real and consistent, and the only reliable way to close it is to identify both populations before the build rather than discovering the second one during the rollout.
And the 45-minute efficiency benchmark is a useful practical anchor for teams that treat discovery as a time cost to be minimized rather than an investment that reduces total project time. A focused 45-minute conversation that produces the clarity to build the right thing the first time is a better use of time than multiple revision cycles that collectively take far longer and produce a worse relationship with the stakeholders the report is meant to serve.
