Overview
In this episode of The Dashboard Effect, Brick Thompson and Caleb Oaks make the case that the most damaging assumption a BI project can start with is the belief that it will be finished. The conversation covers why business intelligence is inherently iterative, what drives the need for updates over time, and why the version one mindset, focused on quality without demanding perfection, produces better outcomes than attempting to anticipate every requirement before a single user has seen the work.
For any team that has delivered a report and been surprised by how quickly the requirements evolved, this episode reframes that experience as the normal and healthy function of good BI rather than a sign that something went wrong. See how Blue Margin’s Managed Analytics & Insights builds iterative refinement into every engagement, ensuring that BI investments continue to deliver value as the business evolves rather than becoming static artifacts that drift out of alignment with how the organization actually operates.
What This Episode Covers
Embrace Evolution (0:16 – 2:40)
Business needs change, the questions leadership wants to answer change, and the data landscape changes with them. A report built to reflect how the business operated twelve months ago may be answering questions the business has already moved past. Treating BI as a living capability rather than a delivered artifact is what keeps it relevant and used rather than accurate and ignored.
The Power of User Feedback (0:55 – 2:07)
Users frequently do not know what they need until they see their data visualized for the first time. The first draft of a report is not just a deliverable. It is a discovery tool that surfaces new questions, reveals gaps in existing thinking, and opens lines of inquiry that no amount of upfront requirements gathering would have produced. That dynamic is not a failure of the planning process. It is the planning process working as it should.
Avoid the One and Done Mentality (2:40 – 5:06)
The expectation that a report must be perfect before it is released creates two problems simultaneously: it delays delivery until a standard that cannot be fully defined in advance is met, and it reduces the collaboration that makes reports genuinely useful. A high-quality version one released for User Acceptance Testing generates the feedback that shapes version two, which is a better use of development effort than trying to anticipate all of that feedback before any user has seen anything.
Discovering Holes in Business Processes (6:54)
One of the most common catalysts for iteration is a report that reveals a gap in a business process that nobody knew existed until the data made it visible. That discovery is valuable, but it requires updating the report to reflect the corrected process and often surfaces additional questions that the original report was not built to answer.
Uncovering Data Quality Issues (7:25)
Reports that surface data quality problems are doing their job. But addressing those problems typically requires changes to how data is captured, processed, or structured, and those changes flow back into the report. Data quality improvement and report iteration are connected processes, and treating them as separate tends to result in reports that are technically updated but still reflect the underlying problem.
Changing Business Models (10:06 – 11:12)
Internal business model changes, like shifting from hourly to fixed-price billing, change the meaning of the metrics a report is built around. A report designed for one billing model does not simply need to be updated. It needs to be reconceptualized around how the business now measures value, which is a more significant iteration than a data quality fix but equally necessary for the report to remain useful.
Iteration as Value Creation (11:48 – 12:35)
The hosts close with a reframe that is worth internalizing: iterative updates are not more work appended to a finished project. They are what makes BI valuable over time. Organizations that treat each iteration as evidence that the original build was insufficient are approaching the work with the wrong model. Organizations that treat iteration as the mechanism through which BI stays relevant are the ones that get lasting returns from their investment.
Who It’s For
This episode is worth your time if you are a BI developer or data team lead trying to set realistic expectations with stakeholders about what happens after a report is delivered, a business leader who has experienced the frustration of a report that felt finished and then quickly became outdated, a project manager responsible for scoping BI work and looking for a framework that accounts for the evolution that inevitably follows initial delivery, or any organization that has low adoption of existing reports and suspects that the reports have not kept pace with how the business has changed.
Why It’s Worth a Listen
The one and done expectation is one of the most persistent sources of friction between data teams and the business users they support. Stakeholders who expect a report to be permanent are disappointed when it needs to change. Developers who are rewarded for finishing rather than improving have no incentive to maintain what they built. This episode gives both sides a better mental model for what BI projects actually are and what success in them actually looks like.
The user feedback discussion is particularly useful for teams that struggle to get meaningful input during UAT. The insight that users often do not know what they need until they see the data visualized reframes UAT from a validation exercise into a discovery one, which changes what questions are worth asking and what feedback is worth collecting.
And the business model change example is a useful reminder that the most significant triggers for report iteration are often external to the data team entirely. Reports that were built carefully and accurately can become misleading not because anything went wrong technically but because the business they were built to describe has changed. Staying close enough to the business to catch those changes before they corrupt the reporting is part of what makes a BI function genuinely useful rather than just technically competent.
