Overview
In this episode of The Dashboard Effect, Brick Thompson and Caleb Oaks make the case for iterative BI development as a structural approach rather than a concession to imperfect planning. The conversation covers why the expectation that the first version of a report will be the final one consistently leads to disappointment, what drives the need for iteration even in well-planned projects, and how organizations that treat BI as a continuous cycle rather than a one-time deliverable get fundamentally better results from their data investments.
For any team trying to set realistic expectations with stakeholders or build a development process that accommodates the way user needs actually evolve, this episode provides the framework and the language to do both. See how Blue Margin’s Managed Analytics & Insights builds iterative refinement into the engagement model so 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 Flexibility (0:40)
Even the most thorough discovery process cannot fully anticipate how user needs will shift once people are actually interacting with data on a page. The act of seeing information visualized changes what questions users think to ask and what gaps they notice in the picture the report is painting. Planning for iteration from the beginning is not an admission that the planning process failed. It is an acknowledgment that discovery continues after delivery, and that the organizations which build that continuation into their development model produce better outcomes than those that treat the first version as the last.
Improvement Through Usage (5:16 – 6:34)
User behavior is one of the most reliable sources of feedback about what a report is missing or where it is falling short. When users export data to Excel, it is usually a signal that the report is not answering a question they have in a form they can use. When users begin interacting with dashboards regularly, they start identifying holes in their business processes that require further reporting. Watching those patterns rather than treating the initial delivery as complete reveals the next iteration before users have to articulate the gap explicitly.
Managing Expectations (2:43)
Setting the expectation that the first version of a report is a starting point rather than a finished product changes the dynamic of the entire development relationship. Users who understand they are participating in an iterative process engage with initial versions more collaboratively and with more specific feedback than users who believe they are receiving a final deliverable. IT teams that communicate this expectation clearly reduce the friction that comes from stakeholders who experience the first version as incomplete rather than as the beginning of something that will improve through use.
Business Evolution (9:55)
The reporting that serves a business well during one phase of its development is not always the reporting it needs in the next. A dashboard built to support CRM data cleanup may be superseded by higher-level metrics once the underlying data is reliable. A report designed for a particular business model may need to be rebuilt from a different foundation when the model changes. BI that is treated as a living capability adapts to those changes. BI that is treated as a delivered product tends to drift out of alignment with the business it was built to serve and eventually gets abandoned rather than updated.
BI as a Continuous Cycle (11:15)
The hosts close with a framing that connects the episode to a broader perspective on what BI investment actually purchases. The value is not in any individual report. It is in the ongoing cycle of creation, testing, and adjustment that keeps reporting aligned with how the business actually operates and what it actually needs to know. Organizations that understand that value and resource accordingly get compounding returns from their data investments. Those that treat each report as a project to be completed and moved on from get diminishing ones.
Who It’s For
This episode is worth your time if you are a BI developer or data team lead trying to build a development process that manages stakeholder expectations around iteration rather than treating every revision request as a scope change, a business leader who has experienced the frustration of a report that felt finished and then quickly became outdated, a project manager responsible for BI engagements who wants a framework for communicating the iterative nature of the work to stakeholders who are accustomed to project-based deliverables with defined completion points, or any organization that has delivered BI infrastructure and found that the reports are not keeping pace with how the business has changed.
Why It’s Worth a Listen
The iterative development conversation is one that recurs across many episodes of this podcast, and this one makes the case with particular clarity by grounding it in the specific mechanisms that drive iteration: user behavior signals, business model changes, and the gap between what planning can anticipate and what usage reveals. Understanding those mechanisms makes the argument for iterative development more credible than a general principle about flexibility would be.
The Excel export observation is one of the most practically useful pieces of the conversation for developers trying to identify where their reports are falling short without waiting for users to articulate the problem. Watching what users do when the report does not answer their question is a more reliable signal than asking them what they need, because users often do not know what they need until they encounter a situation where the current tool is insufficient. The workaround they reach for tells you more than a requirements interview would.
And the business evolution framing is worth taking seriously for organizations that are managing BI investments over a multi-year horizon. The reports that are most valuable today were built for the business as it operates today, and as the business changes, those reports will need to change with it. Budgeting for that evolution as a normal and expected part of the BI investment, rather than treating update requests as unplanned cost, produces a healthier and more realistic relationship between the data team and the organization it serves.
