Overview
In this episode of The Dashboard Effect, Greg Brown of Blue Margin sits down with Brian T. O’Neill, founder of Designing for Analytics, for a conversation that approaches the data product failure problem from a direction that most data teams do not naturally look: human-centered design and product management. Brian’s argument is consistent and well-grounded in practice: the reason most data initiatives underdeliver is not that the technology is wrong or the data is bad. It is that the teams building them are solving the wrong problem because they never uncovered what the business actually needed.
For data teams trying to understand why adoption is low despite technically sound work, and for business leaders trying to get more value from data investments that have not delivered what was expected, this episode offers a clear diagnosis and a practical path forward. See how Blue Margin’s Managed Analytics & Insights applies human-centered discovery to ensure data products are built around the outcomes that matter to the business rather than the outputs that are easiest to deliver.
What This Episode Covers
The Data Tennis Problem (3:45 – 5:45)
Brian describes a pattern he sees consistently in data projects: teams engage in a back-and-forth of surface-level requests and technical responses that never gets beneath the stated ask to the actual business need. The business asks for a dashboard. The data team builds a dashboard. The dashboard goes unused. What was never surfaced was the underlying problem the business was trying to solve, which a dashboard may or may not have been the right answer to. He uses the skin cream analogy to illustrate the point: treating the visible symptom without diagnosing the underlying condition produces solutions that look relevant and miss the mark.
Outcome vs. Output (6:27 – 8:15)
The reframe Brian advocates for is from technical outputs to business outcomes. Shipping a dashboard is an output. A change in behavior, a better decision, a measurable improvement in a business metric: those are outcomes. Data teams that define success by whether they shipped something on time and within scope are measuring the wrong thing, and that measurement leads to work that is technically complete and operationally irrelevant. Shifting the definition of success to downstream business impact changes how projects are scoped, how requirements are gathered, and what done actually means.
The Role of User Experience (13:40 – 16:30)
Good UX in data products is not primarily about aesthetics. It is about trust and friction reduction. The best-designed data tool is one so well integrated into a user’s workflow that it becomes invisible, surfacing relevant information at the moment of need rather than requiring users to remember to log in and look. Brian describes the ideal as a tool that pushes alerts to users rather than waiting to be consulted, which is a higher bar than most BI implementations aim for but a useful design aspiration that reorients how teams think about the interface between the data and the people it is meant to serve.
User Adoption as the Gateway to Business Value (16:43 – 17:23)
Brian makes the dependency explicit: there is no path to business value that does not run through user adoption. A technically sophisticated data product that end users do not trust or find indispensable delivers no business value regardless of the investment behind it. That framing elevates adoption from a rollout concern to a design constraint that should shape every decision made during the build, not just the communication plan at the end.
Starting Points for Smaller Teams (17:45 – 19:46)
For mid-market firms or smaller teams facing skepticism about data initiatives, Brian’s most effective recommended starting point is deceptively simple: listen. Qualitative interviews that ask thoughtful questions about what problems are keeping stakeholders up at night surface the real issues that a data initiative could address, generate genuine buy-in from the people whose adoption will determine success, and create a clear path to value that is grounded in what the business actually needs rather than what the data team assumed it needed.
Who It’s For
This episode is worth your time if you are a data team lead or BI developer who has delivered technically correct work that did not get adopted and wants a framework for understanding why and doing it differently, a product manager or solutions architect responsible for the discovery process on data engagements and wanting a more structured approach to uncovering unarticulated business needs, a business leader who has invested in data tooling without seeing the organizational behavior change the investment was supposed to produce, or any organization that is planning a new data initiative and wants to build the human-centered discovery process into the project from the start rather than treating adoption as something to manage at the end.
Why It’s Worth a Listen
Brian O’Neill’s perspective is genuinely unusual in data conversations because it comes from product design rather than data engineering, and that difference in origin produces insights that are largely absent from the technical discourse around BI. The data tennis framing is one of the most accurate descriptions of a failure pattern that happens constantly and rarely gets named clearly enough to be addressed deliberately.
The outcome versus output distinction is worth internalizing as a career-level reorientation for data professionals who have been rewarded primarily for shipping. The work of building something is visible and measurable in ways that the downstream business impact often is not, which creates incentive structures that reward output even when the outcome is missing. Naming that gap and building measurement frameworks around outcomes rather than outputs changes what success looks like in ways that ultimately produce more valuable work.
And the listening recommendation for smaller teams is worth taking seriously as a low-cost, high-return starting point for any organization that has been skeptical about data initiatives because previous ones did not deliver. A series of well-conducted qualitative interviews costs almost nothing and produces the clarity required to build something that addresses a real problem rather than a stated one. That is the kind of return on time investment that justifies the approach regardless of whether the organization ultimately pursues a larger data initiative afterward.
