Overview
In this episode of The Dashboard Effect, Brick Thompson and Landon Oaks make a case that anyone who has built a technically correct report that still missed the mark will recognize immediately: knowing the tools is not enough. Understanding the business behind the data is what separates a dashboard that gets used from one that gets quietly ignored or, worse, actively mistrusted.
The episode is a practical argument for slowing down before building, investing in discovery before writing a single query, and asking enough questions to understand not just what the data says but what it means inside the organization that generated it. See how Blue Margin’s Managed Analytics & Insights builds structured discovery into every engagement, ensuring that what gets built reflects how the business actually works rather than how the data suggests it might.
What This Episode Covers
Go Beyond the Data Structure (0:27 – 0:48)
The instinct for analytics engineers is to start with the data: find the tables, understand the schema, and begin modeling. Brick and Landon argue for a different starting point. Before touching the data, understand why it exists, what business process it reflects, and what decision it is supposed to support. That context shapes every technical choice that follows.
Discovery Is Essential (2:45 – 3:22)
Building effective reports requires dedicated time spent talking to stakeholders and mapping workflows before any development begins. Understanding how a process actually works, how trouble tickets are generated and routed, for example, reveals requirements that no data dictionary or schema diagram will surface on its own.
The Value of Frontline Interviews (5:45 – 6:55)
Stakeholders who define report requirements often have an outdated or incomplete picture of how systems are actually being used. The people performing the tasks day to day know things that do not appear in any documentation: how data is entered, what shortcuts are common, and where the system does not quite fit the workflow it is supposed to support. Talking to those employees is one of the most efficient ways to avoid building a report that looks right in a review meeting but fails in practice.
Watch for Hidden Data Sources (7:29 – 8:45)
Deep discovery frequently reveals that the primary ERP or reporting system is not the only place critical data lives. Secondary systems, workaround tools, and informal spreadsheets that have become load-bearing parts of a business process often go unmentioned until someone asks the right question. Discovering those sources late means rework. Discovering them during discovery means building something complete the first time.
Be Curious (4:15 – 5:12)
When data looks wrong or unexpected, the instinct is often to fix it at the surface level and move on. The hosts argue for a different response: ask why. Open-ended curiosity about why a number looks the way it does is what distinguishes a developer who surfaces structural business issues from one who applies band-aid fixes that mask problems without resolving them.
Who It’s For
This episode is worth your time if you are a BI developer or analytics engineer who has delivered technically sound reports that stakeholders pushed back on, a data team lead trying to build better discovery habits into your project process, a business stakeholder who has been frustrated by reports that did not reflect how your team actually works, or anyone early in a dashboard project who wants a framework for the conversations that should happen before the building begins.
Why It’s Worth a Listen
The gap between technical execution and business understanding is one of the most consistent sources of friction in data work, and it is rarely discussed as directly as it is here. Brick and Landon do not just identify the problem. They walk through the specific practices, stakeholder interviews, frontline conversations, and open-ended questioning, that close it.
The point about frontline interviews is particularly worth taking seriously. In most organizations, the person who signs off on report requirements and the person who actually enters the data are not the same person, and their understanding of how the system works can diverge significantly over time. Building without talking to both is a reliable way to produce something that is accurate according to one perspective and confusing according to the other.
For any team that has found itself going back to rebuild something that should have been right the first time, this episode is a useful diagnostic for where the process broke down and how to approach it differently going forward.
