Most of the world is outside the bubble.

In BI that means point-and-click dashboard mode; AI debugs code, but otherwise it’s the same old workflow from 2019. That workflow is slow and manual and produces a ton of friction. In tech we hate friction; in reality, friction is often the only thing that forces quality. So it makes sense that people are afraid to hand the BI reins over to AI, where getting a single number wrong can destroy your reputation. Vibing seems frictionless in a bad way that signals chaos to practitioners and data leadership.

However the advantages of AI coding BI in ease, speed and front end customization are getting too big to ignore. What we need is an AI built BI set of practices to give us quality without friction, and that’s what I’m trying to develop. Here is an example of a classic BI application I built in about six hours, along with the steps I took to give it something close to real BI rigor without clicking around a screen.

Thank you MotherDuck for sponsoring Super Data Summer here on the blog. Read this article then try your hand at Agentic BI in their DiveMaxxing contest for your chance to win a Mac Mini. Details here.

Picking A Tool

One of the challenges with agentic BI is a total lack of infrastructure. Building agentic BI is much more like software engineering than classic data development, but many data teams don’t think that way and don’t have the tooling. Things like git, CI/CD and analytics-as-code have been slow to spread, especially at the enterprise. But without these things you really are inviting chaos if you vibe code BI.

For this example I used only two tools: Claude to scope, design and write code, and MotherDuck for database, orchestration, computation and rendering. MotherDuck is this blog’s current sponsor and a close partner of mine; it’s also legitimately my favorite ‘analytics stack in a box’ provider. Full transparency.

MotherDuck offers three things that make this possible: A high performance analytics database; a react app development, management and viewer tool called Dives; and a new python execution environment called Flights. All of these tools are very simple and that’s their beauty for agentic coding. They provide the fundamental blocks of an ETL, data warehouse and BI application and rely on Claude (or ChatGPT) to do the building via MCP or API. There are some limitations - for example, MotherDuck doesn’t offer row level security or a robust BI content management system. And you don’t need an all-in-one to do this by any means. But the advantages of a single place to manage the full pipeline can’t be ignored.

Meet The Financial Briefing Book

The biggest objection I see to agentic BI is not in its ability to build a dashboard - AI can clearly build dashboards more quickly and flexibly than any BI tool. Instead people often point to older, more foundational BI patterns like standard reports with complex personalization and distribution patterns as the type of thing AI coding can’t easily do. So that’s what I set out to replicate.

Say hello to the Financial Reporting Briefing Book - a report that pulls data from Yahoo finance and renders the big 4 financial statements for each of the Dow Jones Industrial Average companies. This type of report is very difficult to build in most BI tools made in the last 20 years, which focus almost exclusively on dashboards. And yet this style is fundamental to how most large companies operate to this day, particularly in finance.

Building this report and deploying it as a Dive in MotherDuck took less than an hour. But the form factor itself isn’t the trick - it’s the automated end-to-end pipeline that pulls fresh data, personalizes it per recipient and distributes it online and as a PDF over email that is the hard to replace BI infrastructure. So I built that too.

First, I created a version of report that pulls the ID of the person logged in via the md_user() function and compares it to a table that maps usernames to filter values at runtime. This ensures each user only sees the companies assigned to them when they view the dive on the MotherDuck server.

So we have interactive personalization and filter-level security in place. What about automated distribution via PDF - aka ‘report bursting.’ That was a bit trickier. I built a ‘burst table’ for recipient information including full name and email.

The two tables combine to give you the identity, email address and filter set for each report recipient. Now for the hardest part - distribution. Here’s where the new Flights capability comes into play. For this I built two Python applications. The first ETLs the data from Yahoo Finance into a data warehouse every morning. The second dynamically builds a four page PDF per company and emails them to recipients based on the combinations in the tables above at 9AM Eastern every day. The third… we’ll get to in a bit.

The PDF generation looks at each individual and what company combinations they receive, then constructs a complete briefing book with all four pages for each company, attaches them all to a single email and sends it out along with a link to the live environment. It has failure states built in to prevent duplicate or empty emails.

This all got fairly complicated with multiple Python Flights and Dive reports, calls to 3rd party email services, database loads, orchestration, etc. How could I ensure it was running properly and quickly analyze and debug if it fails? I actually built an app for that too called Control Tower. It automatically analyzes a MotherDuck environment, builds the logical and physical models and captures execution and recipient run status and history. It does this by analyzing the MotherDuck catalog, audit and run history tables I built, and an object manifest appended to each code file to dynamically map the environment at runtime.

All of this was accomplished with about six hours of work spread across two days. It’s been running for almost a week with zero downtime. A small test, but a real one.

Subscribe now

Agentic BI Principles In Action

How was I able to do this so quickly and effectively? It was simple but not easy. Here are the high level principles you should follow:

Taste And Experience Matter

A CEO could not have built this, nor could an early career analyst or developer. I knew the correct structures to build and the most effective language to describe them. I understand the common failure states and could recognize them by analyzing the build plans before writing a single line of code. The ability to judge architecture, project plans and output quality on aesthetic and product-market fit grounds matters a ton for this kind of work.

Use Plan Mode

Plan Mode in Claude is amazing. Turning it on and describing the shape of your development goals causes Claude to create a detailed step-by-step proposal of how and what it will build. Using your taste and experience to evaluate and shape these plans saves enormous amounts of time, frustration and tokens and improves final output quality. Don’t skip this, ever.

Prompting With Invariants

My most effective prompts combined invariant conditions - something that must always be true - with the reason it matters. For example when building on June 9, the first Flight merge silently dropped ~540 rows of aging-quarter detail due to how Yahoo Finance operates, which caused some reports to have missing quarters. Once I identified the issue, I didn’t work with Claude on a point solution. Instead I provided the invariant rule and the reasoning behind it like this:

The tables can never shrink. Yahoo finance drops old records that we want to retain to properly render the reports.

Stating an invariant principle like this prompts Claude to fix the specific problem, comb the code for other instances that violate the principle, and write its own data quality checks into the pipeline to enforce it.

Probabilistic Reasoning, Deterministic Processing

Everything Claude does must execute as code and be treated like real software. Claude can build analytics internally by firing up hidden tools and burning a ton of tokens, but this results in one-off outputs that you can’t replicate in a second session if you try. Instead, make Claude commit everything it does to disk as files and version them like code. Make sure it builds checks into each process that you can fall back to when things don’t work - rules like ‘the row count can never go down’ are written into Claude’s context files AND the Python pipeline to become both a reasoning guide and a deterministic fallback that prevents errors and improves data quality.

Increment And Test

Each step is built and tested independently with verified and documented handoff standards. Working on the front end, the pipelines and the orchestration at once introduces too much cognitive load and clutters Claude’s context with too many variables. Once the full system exists you can do broader, cross-stage development. But to start, one thing at a time.

Tests should be isolated by design to only route to you. For example, email bursts don’t go to anyone else until you really trust the application. Build a ‘test mode’ and ‘production mode’ into the app, where switching to production is only changing a few variable values. This makes promotion easy.

Never Silently Destroy Data

It’s possible for Claude to mistakenly delete rows, tables or entire databases, even if you give it instructions not to. Write the ability to destroy data silently out of your code and require Claude to edit and execute that code instead of freestyling on its own. Transaction tracking, grow-only merges and verification queries help avoid true vibe coding disasters.

Manifests On Every Object

Each code file must have a manifest describing what it is, what it does, what objects or databases feed into it, and what objects or databases feed out of it. This makes it easy for Claude to find and understand each part of your app structure. Without manifests it’s easy to lose track of the overall shape of your application and very hard to construct process flows after the fact.

Personalize Through Data, Not Code

Resist the urge to personalize by forking code or creating ‘Briefing_Book_Steve_Final_FINAL_V2’ style reports. Minimize the file count and personalize by query filters and render variables. Build customization into the underlying data structures where they are auditable and extendable.

Capture The Context

You will make hundreds of little decisions while vibing. At the end of every session, ask something like this:

What decisions did we make, design patterns we uncovered, or universal rules we applied that should be stored for future development or shared with others?

Let Claude propose a list of what context needs to be stored for re-use, then write it to disk as a markdown file. Provide that markdown file as part of all future development.

How To Start Your Agentic BI Pilot

If you’re one of the twenty eight people who didn’t raise their hand, don’t panic. You aren’t behind - or rather, everyone’s behind, even the people at the front of the race. Here are some practical steps you can take to get started.

1. Pick one real report to build. Not a sample, not a demo. Something you would normally build by hand that somebody will actually read. If it’s not worth reading, it’s not worth the effort.

2. You really only need two tools. An AI code assistant like Claude, Codex or Cursor, and a place to run SQL. Hosted Python and React become important when you want to share with others, and it’s worth planning for them now. But the bare minimum to start is just a coding buddy and a place to send your SELECT statements.

3. Plan before you code. Understand what the point of the app is and be ready to articulate how it delivers value for end users to your AI. Then flip on Plan Mode and describe what you want and how it benefits your users. Argue with the plan instead of the output. This is where your experience does real work and separates you from the pack.

4. Write everything as a file. If AI did something you can’t re-run from disk tomorrow, it might as well not have happened. No hidden tools or one-off magic.

5. Give it rules, not fixes. When something breaks, state what rule was broken and why. Let AI hunt down everything that violates the rule and propose fixes.

6. Capture Context. What did you do and why? What rules did you uncover that can be re-used for future development and shared with your team? All of that must be captured in markdown.

7. Go live in test mode. Production identical output routed to you and your team until you trust it. Flipping to production just changes routing rules, nothing else.

The friction doesn’t disappear with these agentic BI principles - you are still writing deterministic processes, still rigorously testing, still developing in a non-production capacity before you flip to live. But you’ve moved it out of your clicking hands and into code that checks itself at 9AM every morning whether you are watching it or not. That’s Agentic BI.

In each case, the decision was made above the data team at the executive level, and in each case the data leader I spoke with was not thrilled. Migrating BI platforms is expensive even when there are significant licensing reductions, it’s a huge distraction from any strategic work the data team could deliver instead, and usually nobody is better off afterwards. You’re just re-arranging the deck chairs.

A special thank you to MotherDuck for sponsoring Super Data Summer. I love their new Dives feature; AI authored analytics apps delivered in hours, not weeks. Check out the financial reporting Dive I built here, and learn more at motherduck.com/product/dives

A few trends revealed themselves during the conversation that we should really sit with as analytics and business intelligence practitioners. First, executives often thought BI was ‘just dashboards’ and that AI could deliver the same results for less money. The hard work of BI was invisible to them. Next, the value the BI department delivers was not enough to overcome the expense of the tooling. Finally, cultural factors were ultimately the driver of low perceived value; reducing license costs and onboarding new software does nothing to fix that.

In each case the data leader was clearly frustrated and looking for answers - I have less than a year to get off Tableau, what should I do? What software should I consider instead?

If you’re in this situation, first of all I’m sorry. I know it sucks. And secondly, here is my advice on what to do. I don’t know your specific situation; if you want to deep dive on it DM me, I do this for a living.

Subscribe now

Focus On Metrics Locked In BI

There’s this platonic form of a data environment where all the metrics are in a data warehouse with a well documented and designed semantic layer serving up verified results to users and developers. We sometimes catch glimpses of its shadow on the cave wall.

In the real world, critical metrics that run the business are often defined ONLY in the BI layer, nowhere else. And nobody knows that, until migration time comes and suddenly you have a problem on your hands. This is compounded by the sheer size and complexity of old BI environments, like many Tableau installs today. Tens of thousands of reports with little understanding of who does what with them or what they contain.

So your first task is to map all that out with a particular focus not on the dashboards, but the metrics they contain. You need to untangle the web of what operationally or strategically critical data points exist only in BI and plan your migration around replicating them into your warehouse if possible, or safely shepherding them into the new BI tool.

Data that exists in five places doesn’t need to be migrated at all, and taking one necessary calculation out of a Tableau workbook and into a database is much easier than replicating the entire dashboard that delivers it.

Get Creative Finding New Tools

Some of the leaders I spoke with were in a real tough situation. One of them had done a pilot of Omni and felt it was the best option. The Omni semantic layer would help organize their data and the AI tooling was ahead of what they expected. There was just one problem.

They couldn’t afford Omni either.

If there’s huge cost pressure to reduce BI spend, you are probably not shopping at BI Nordstrom, you are shopping at BI Nordstrom Rack. And that’s okay - there are lots of options out there that are very good at much lower prices. Look outside the ‘Leaders’ quadrant of the Gartner MQ for enterprise vendors at lower price points for traditional BI replacement.

One obvious option if you’re in this trap - and honestly I expect for large companies this is probably the most appealing - is to just port your Tableau workload to Power BI… or your Power BI workload to Tableau, or Amazon. The reality is you can probably lower BI spend significantly just through vendor consolidation. There are some really good specialty consultancies who can make this way easier for you. DM me if you need a recommendation.

But don’t restrict yourself to popular vendors. Search for smaller startups that might offer what you need. There are really interesting options like Golden Analytics, Ridge Data, Zenlytic, Count etc that can take a significant portion of your BI workload, often times for a reasonable price. Some of these are more like traditional BI, others are pretty different. But being traditional brought you to this point, maybe it’s time to shake things up. And getting in early has its advantages.

Start A Vibe Coding BI Pilot

AI is the elephant in the BI room. Multiple people I spoke with shared that executives seem to think that BI is easily replaced by AI, so why are we paying for this? If you read Super Data Blog you already know that this isn’t true. Yet.

But let’s be real with one another here - the day is fast approaching where vibe coded BI applications will compete with traditional BI workloads directly. They are already more flexible and easier for both self-service and professional users to build. Things like MotherDuck Dives or Zenlytic Artifacts create extremely good looking reports very, very quickly.

The challenge is all the other stuff BI does - security, auditability, content management, reusability, load balancing, caching, distribution, metrics stores - it’s a big list. AI can already make a good dashboard, it can’t automatically personalize a report and send it to 1,000 people every Monday morning. There’s nothing out of the box that combines vibe coding with classic BI infrastructure to my knowledge. Hex Data Apps might be closest - I haven’t dug in yet.

It also brings up an existential question for BI platforms - does the presentation layer even need its own tool anymore? I am working with MotherDuck on some really wild ‘BI right in your database, developed by Claude’ stuff that goes beyond dropping AI built HTML dashboards in a shared folder. If that sounds crazy, well it is. But crazy in a good way.

Share

Do Some Soul Searching

You’re walking out of a meeting shell shocked. The powers that be just told you that they won’t be signing your upcoming BI renewal. Panic is setting in. Take a deep breath and follow the advice above.

But not before you do some soul searching. Here’s a painful fact - if your BI practice was delivering real value, you probably wouldn’t be in this situation. One of two things is true; either your work just isn’t that important, or you’ve done a terrible job marketing it.

Business intelligence is often pigeonholed as the dashboard factory. Nobody sees the hard work that goes on inside the factory, they just get a car from the dealership and drive away. And they don’t think about it again until the car breaks down. That’s where you are now.

It’s time to get creative and throw out your old ways of working. That’s the one silver lining of a migration - suddenly the operational drag of ‘I need this slight report variation by 5PM’ stops and you can step back and ask, what would make this function really valuable at this company? So look at new tools, yes, but also new approaches. Embrace AI to the greatest extent possible to make your work faster, better and more targeted to end user needs. It’s an incredible tool to help you think, even if you never use it to write a single line of code. My upcoming book teaches these techniques, but you don’t have to wait. Start now.

Thank you to MotherDuck for sponsoring Super Data Summer on the blog. MotherDuck Dives are the easiest way to build and deploy analytics apps with AI. Check them out here.

Why Dashboards Were Expensive

Building a dashboard was really hard. Requirements gathering, data modeling, SQL writing, design, validation, maintenance - it all added up to a ton of human work that could only be done following months of learning. And the tools were expensive - I remember paying $30,000 for a single Cognos administrator license in 2010. The human and financial friction in the system limited volume, and limited volume forces prioritization. In every organization the demand for dashboards far outpaced the supply chain for building them. The downside was obvious - people can’t get the data they need. The upside is only becoming clear now; friction is a quality control mechanism.

Hyper-Temufication

That’s all out the window. Claude and ChatGPT build ‘good enough’ report outputs in minutes from spreadsheets. They aren’t going to win an Iron Viz contest, but they don’t have to. The demand for perfectly formatted, beautiful dashboards rarely came from the business - rather, it came from the practitioners themselves, who took pride in making something elegant. There’s no time for pride in the age of AI.

Like your first $12 pair of good enough shorts, the initial burst of freedom from AI - authored BI is exhilarating for end users, who are used to waiting somewhere from hours to infinity for their data requests to be answered. But soon the problems become apparent. AI can explore data, model it, generate SQL, visualize it and even explain it. But it can’t tell you it’s accurate, or meaningful, or wise. AI builds without discernment.

And it builds fast. Where we used to have a single human authored dashboard, there will soon be dozens or hundreds made by AI. Humanity was like a levee holding back the data flood, and the levee just broke. There’s no patching it back up; the time to build a raft is now.

The Failure Modes of Temu BI

I’ve been dire up to this point, but let me be clear - this change is probably good in the long run, when we’ve ironed out all the kinks. Waiting so long to get data questions answered that they become irrelevant is not a sustainable way to operate; getting the right answers quickly is good; getting a flood of unmanageable AI data slop is bad.

Temu BI will fail in four big ways. Be on the lookout.

Dashboard Sprawl

The systems to create are exploding right now; curation is far behind. This is the classic Excel problem on steroids. When everyone can build impressive outputs via the upload button, but comparatively few understand and can validate what was built, the volume of content explodes and the quality craters. Current incentive structures within organizations have not adjusted to this bounty - walking into a meeting with a good looking visualization carries value so everyone will do it.

False Confidence

Okay so everyone walks into the meeting with their own numbers. That’s not new. But now they also bring an AI generated sycophantic narrative about how their numbers are right (and they are also really good looking and smarter than their rivals too!)

Metric Drift

The classic ‘we have three different definitions of revenue and customer’ is not easy to solve - oftentimes it’s totally valid that different parts of the organization view the same metric through a personalized lens. Data governance programs and data catalogs exist for this reason.

What AI changes is the speed of metric mutation. Even when you’ve established a rock solid, agreed upon definition of a metric it only takes one person letting Claude inject a hallucinated calculation to begin a cascade of bad answers rippling through the organization. The problem is old, AI intensifies it.

Analytics Theater

Everyone wants to be data driven, or at least to claim they are. But a lack of data was often cover for going with your gut - and many decision makers preferred that anyway, data be damned. Now that building analytics is easy, the temptation to generate data assets that justify your intuitions will be impossible to resist. Analytics Theater is when you torture the data, build the fancy charts and put on a big show of being “data driven” when the decision was made before the dashboard was opened.

Resistance Is Futile

Holy crap that all sounds horrible! We have to lock Copilot down and cancel the Claude subscriptions immediately to save the firm from a data disaster!

Of course this is impossible. Be honest, who controls the budget for data tools? Even if it falls under IT on the accounting statement, does the BI team really have veto power over what tools users can access? In my experience, basically never. You can’t shovel the flood back behind the dam.

But you shouldn’t want to. We have a real, longstanding and unsolvable problem in business intelligence and analytics - people want more of our product than we can possibly supply. BI adoption is stuck around 25% and has been for decades, and no amount of drag-and-drop innovation was going to solve that.

For the first time, AI lets our users truly feel like they can do it themselves without us. The dangers are clear, but here’s the opportunity: Embracing AI and enabling end users to build fast, accurately and safely makes you more valuable, not less!

Look at those four failure modes of Temu BI above - those are HUGE problems. Solving them is worth way more than building yet another dashboard nobody reads.

If BI Is Temufied, Become Amazon

The cost of the analytics product - the dashboard - is plummeting to near zero. It’s a terrible business for a human being to be in. But managing the environment that delivers dashboards, curating them, managing context, building AI apps - that’s an opportunity.

Start by learning how to dev with AI now. A $20 a month Claude subscription and a free MotherDuck account are all you need to build analytics apps today. Get the basics down, learn where it succeeds and where it fails. Getting AI to build a ‘good enough’ app is easy; getting it to build the perfect app is hard. Learn perfect then teach others. Start creating the infrastructure to scale AI authored analytics - you literally just need a shared drive and markdown files to begin, nothing else.

Above all don’t wait. The $12 shorts business is commodified, you can’t make money there. But the management and logistics of distributing $12 shorts on demand at scale is incredible. Let AI be the shorts factory outside Hanoi; set your sights on becoming Jeff Bezos.

Thank you to MotherDuck for sponsoring this post - stick around at the end for an example data app I built riduckulously fast with Claude and MotherDuck Dives.

Thanks to Claude, I would not have wasted months building that system - I could have delivered it in days! Unfortunately, without a proper grounding in the actual needs of the business it would have been just as useless. Today the risk of spamming users with AI authored data slop is real; high velocity garbage is still garbage, just faster.

In this article I will introduce you to the product thinking mindset that helps you determine what to build and the practical steps to capture business context that Claude needs to build analytics. Using these techniques, I built a complete pipeline, warehouse and dashboard solution in an hour. Don’t skip to the practical stuff - no amount of AI skills will save you if you’re building the wrong thing.

Product basics for data nerds

Product thinking is not new, but it is relatively new to data. I first encountered it in Dan Olsen’s The Lean Product Playbook and it completely changed the way I think about analytics development forever. There are great resources if you want to go deep on product thinking in data - Anna Bergevin’s Substack is a must read.

Start with value

The number one sin of the data developer is building before you know what the point of your app is. If you can’t articulate it, neither can Claude. That means identifying the theory of value your app delivers before you do anything.

Great debates have raged about what value means in data. shared my favorite definition on an episode of the Super Data Brothers show:

Increased revenue, decreased cost, reduced risk. You could hair split a little bit, but those are the three buckets of value that our customers care about, and we need to demonstrate and quantify how our data drives one of those three things.

It sounds simple; it isn’t. Getting users to articulate how data will help with these three pillars of value is a real challenge, one we’ll return to later in this post. Identifying up front exactly how you plan on pulling one or more of these levers, and providing it to Claude, becomes the north star for all development.

Work backwards

I have heard ‘We need to sort out our data foundations before we can even think about building apps for users’ so many times in my career. It has the gloss of wisdom, but it’s exactly backwards. Value flows from user needs, not from data itself.

Design the surfaces that deliver value first - the dashboard, chatbot, API, app, whatever. These points of contact with human beings are the place your project lives or dies. This doesn’t mean the data and its infrastructure are unimportant - they’re critical. But recognize that you can’t even tell what data matters until you know who it matters for and why.

Build Small

‘Don’t boil the ocean’ is hard won advice in our field. It takes on new meaning working with Claude. Claude’s default behavior is to go absolutely fucking nuts building out insanely complex architectures when simple ones will do. If you’ve never seen nine nested CTEs where a select * works just as well, now is your chance! You need to explicitly tell it not to in the project context (covered here). Small architectural units yield clean, understandable designs and easy to build outputs.

Deliver Fast, Learn Fast

Building in digestible, deliverable chunks makes collecting user feedback much easier, dramatically raising your chances of avoiding a data slop avalanche. The gap between what users say they need and what they actually need to realize the project’s theory of value is often huge. But here’s the truth; users don’t know what they want until you give them what they asked for. Give it to them fast.

Turning Claude Into A Product Person

Let’s get practical and show how to apply the mindset so Claude helps you ship value over slop.

Tell Claude how you want to work

The whole mindset I outlined above needs to be explicitly defined to Claude in your project instructions. Type something like this:

This project takes a product approach to scoping, architecture and delivery. Prioritize end user value outcomes above impressive technical implementation. Build in discrete, deliverable sprints designed to maximize user feedback and minimize delivery time. Ensure we have identified a ‘theory of value’ grounded in saving money, making money or mitigating risk and tailor all interactions and development decisions towards that end.

Here it is in the Claude Web UI. Add it to your claude.md if you’re a code user. This establishes the way you want Claude to behave as you scope.

Brain dump what you think you know

You almost always walk into the first project meeting having some idea what a good outcome looks like - maybe you’ve worked with these users before, maybe you know their data or industry especially well. Maybe you don’t, but you’ve got intuition. No matter the scenario, brain dump your stream of consciousness ideas directly into Claude. Don’t worry about consistency, formatting or even logic. Just get it all out. Trust me, it’s cathartic.

Here’s the crucial thing to remember: At this stage we aren’t thinking much about technical implementation! Instead, we’re capturing things like:

• What value might be delivered from the project?

• What distinct user communities exist? How are they similar or different?

• What people, personalities or politics could drive success for the project?

• What standard industry metrics, approaches and outcomes might the project seek to deliver?

• What similar engagements have you done in the past and what made them successful or not?

• At a high level, what data might be useful? What metrics?

• At a high level, what front-end might be useful?

We aren’t getting into ERDs, DAGs, SQL, or JSONs. We need to get the theory of value and the story of how we deliver that value correct before we move onto implementation.

Once you have it all out, tell Claude:

Here is what I think I know about this project. Help me structure my thinking and prepare to meet with the project users and sponsors. What makes sense about what I’ve written and what doesn’t? What are my potential blind spots? What can I learn before the meeting to be prepared to identify the theory of value of this project and how to best deliver it? Give me output as both a pdf and a structured markdown file for storing in your context.

Take the time to iterate with Claude in a session. It’s worth it. And notice that last bit - it’s helpful to have Claude produce human readable AND markdown versions, one for you, one for Claude.

When you’ve gone back and forth and feel confident that you’ve explored the problem space as you understand it today, ask Claude:

Produce a structured briefing book in advance of my meeting with these users. Pay special attention to the assumptions I’ve made that I need to confirm before designing this project. Help me understand the social and political dynamics to best relate to my stakeholders. Call out any ambiguities or weaknesses in my understanding, and prepare a list of the top questions I need answers to by the end of the meeting.

Think of this output as your battle plan going into the first stakeholder meeting.

Meet with your users and record it

You’re walking into your first project meeting outrageously prepared, which is great! The goal of this meeting isn’t to show how smart you are and how much homework you’ve done, it’s to deeply probe your assumptions about value delivery to discover all the ways in which you’re wrong. Remember, users often don’t know what they want; they need something to react to.

Come in with an open mind. Listen to how they articulate their problems and what solutions they think might solve them. Refer back to your prep work and ensure you get your pressing questions answered. Most importantly, don’t start solutioning immediately in the meeting. This is a fact finding mission.

Record the meeting if you can. This transcript is incredible for Claude; drop it directly into project context and let it inform all subsequent work.

Build a Product Requirements Document

A product requirements document (PRD) defines a product’s purpose, features, functionality and behavior before it gets built. They can be very complex for software products; for analytics apps developed by Claude, keep it to a high level and save specific technical implementation or architectural information for later.

The PRD I use captures seven key areas to consider when developing an analytics project in Claude. This list is not exhaustive - customize to your environment and needs.

1. Value statement: Qualitative and quantitative statements of measurable impact.

2. Personas: Specific humans with specific needs who will use what you build. They should represent a type of user.

3. Features & Functionality: MVP features to deliver that test the value statement. Again, these are high level. If the dashboard has filters, just say that. No need to list every one.

4. Technical Requirements: Technologies to use, data sources to pull, etc. Did I mention high level?

5. Constraints and Risks: Hard business or cultural constraints, known risks.

6. Success Metrics: Measurements that confirm the identified value was delivered.

7. Key Business Terms: Terms where your organization’s definition differs from common usage.

It helps to establish a standard format to ensure consistency across projects. You can drop this list in to Claude and ask it to build a template.

To fill out product requirements document, start a new chat with Claude and submit a prompt something like this:

I need to prepare a product requirements document for this project. I have a PRD template, my own structured thoughts, notes from the meeting with stakeholders, and the meeting transcript for you to use. Iterate through each section with me, asking questions to fill it in. Be skeptical and push back when necessary. Our goal is to identify the right value statement, then design a product that delivers. When we’re finished, deliver the output as a sharable formatted PDF and a markdown file for use in your context.

The PRD is traditionally the last step before designing the technical architecture; before Claude we’d jump right in. But because Claude makes development so much faster, there’s one final step before starting the serious technical work.

Build a front end prototype

Two things you should never forget from this article: ‘Users don’t know what they want until you give them what they asked for’ and ‘Design the surfaces that deliver value first.’

With that in mind, take your PRD and quickly build a prototype of the human contact points of the project for feedback. Because users often get hung up when numbers don’t match their spreadsheets, consider sourcing the data from their spreadsheets.

Much of what you hear will concern visual design. This is valuable feedback, but encourage the users to focus more closely on whether or not the prototype delivers the value they expect. Prod them for what obviously won’t work now that they see it - that’s a dead end you found quickly.

This type of thing would take days or weeks in the past; with Claude it takes minutes or hours. I built a complete pipeline, data warehouse and operational dashboard in Claude in under an hour. With the right context this dashboard was a one-shot prompt.

Build a dashboard I can use to collect feedback from my users, based on the PRD. Render it in the style of Stephen Few.

Repeat the PRD creation process with this second round of feedback.

What Claude Can’t Do (Yet)

You probably noticed what we didn’t ask Claude to do - any project management work. Claude is terrible at estimating time. Without the ability to say ‘this task should take 8 hours’ it’s hard to build a reliable project plan, design a gantt chart or pick a project deliverable date. It can assist you in all those things, but it can’t one-shot them with good context like it can a dashboard.

At this point you’ve done deep thinking on the problem, met with end users, designed a PRD, delivered a prototype and solicited a first round of feedback. Most importantly, you’ve developed a theory of value and have agreement on the broad scope of how to deliver it.

For personal projects or very simple deliverables, you’re ready to work. But in an enterprise context with many stakeholders, complex systems, office politics, regulatory requirements, legacy code, data steward reviews, and all the rest, you can’t rely on AI to build autonomously without an architecture plan in place that gives prescriptive instructions on what and what not to build. AI will create an HTML dashboard; your enterprise standard in Power BI. That’s a problem.

The next article in the series covers two things: Designing technical architectures with Claude that you can actually deploy, and identifying when and how to use AI as a component of those architectures that unlocks powerful new capabilities without destroying security or burning 10k on tokens to answer ‘What were sales last week.’

MotherDuck Dives: Claude Analytics Apps On Easy Mode

The claim ‘I built a complete pipeline, warehouse and dashboard in an hour’ requires some proof. Here’s an example of a complete financial briefing book built using Claude and MotherDuck Dives. Pick any Dow 30 company and get the full picture - income statement, balance sheet, cash flow, equity - all rendered instantly in your browser. Check it out for yourself here.

Dives make building analytics with Claude super easy. Try them out for free at motherduck.com.

It’s drawn from my upcoming book with Wiley on building analytics and business intelligence applications with AI. The space is changing fast, but some durable realities are emerging on how to best work with AI that should stand the test of time (until we hit AGI or whatever). This series covers those basics at a high level.

Subscribe now

I’ll focus on Claude. It’s what I use every day, and it’s rapidly emerging as the go-to model for business applications. Everything applies to other models too, just with different terminology. And I’m assuming you’re new to AI-driven development, so we’re starting from the ground up.

What does AI really know?

AI models are trained on the internet, so they know what’s on the internet. It’s not quite that simple in 2026 - frontier models have access to books, news articles, academic papers, synthetic data, not just snarky reddit posts. But the most important thing to understand is they are trained on public or specifically licensed (or sometimes stolen) private data.

That data almost certainly includes nothing from your actual work environment. None of your data models. None of your BI and visualization standards. None of the specific value your users seek or the pain points you need to address. None of the social, cultural or personal factors you use to prioritize the thousand little decisions you make every day. Closing this gap is your first, most important task in building data apps in Claude.

Why does AI make stuff up?

You already know AI makes stuff up - aka hallucinations. Maybe a cynical coworker dismisses it entirely because you can’t trust the results. They aren’t entirely wrong - in data work wrong numbers equals wrong decisions, and meticulously checking every AI response can feel less efficient than just doing it yourself. Minimizing hallucinations is what takes AI from glorified Stack Overflow to a real development partner.

Eliminating hallucinations is impossible. LLMs are very sophisticated predictive text generators, and like any predictive technology, sometimes they predict wrong. What’s worse is that the way AI models are trained makes them very, very reticent to proactively identify when they’ve made a mistake or even admit it when you’ve called them on it.

But there’s some good news too. AI is often NOT just making stuff up. Instead, it’s making reasonable assumptions based on training data that are incorrect in your specific situation. Consider the following:

You ask AI to write a simple SQL statement and it comes back with table and field names that don’t exist. Did it hallucinate?

If you never gave it the necessary context to understand your tables and fields, then no. It tried to be helpful by generating SQL for you, and it incorrectly guessed what the field names might be called.

Providing the right context to Claude is the key to making it useful for building data apps, not just creating spicy LinkedIn memes.

What is context?

In the book I go a little deeper on context, context windows and context management. That’s not for this blog post. What you need to understand is that context is the stuff AI needs to know to be useful. For data applications that means table and field names, join paths, business terminology, metrics definitions, visualizations preferences, etc. It’s also the ‘soft’ stuff of our industry - the project goals and requirements, the decision making dynamics, etc. All the stuff that’s in your head about how shit gets done that AI doesn’t know.

Providing context to AI can get complicated - ontologies, semantic layers, knowledge graphs - all this is important to do huge AI projects at scale. You, however, are not ‘scale.’ And for you simple text files will do, usually in markdown. Here’s an example:

Always include the stuff AI would not just know by querying the database. For example, the grain of the table, the source system and load cadence, the definition of Order Total - these are all things you know so deeply you don’t consciously think about them. Let AI assume these variables at your peril.

Providing context to Claude by manually finding and pasting it in or typing it at the beginning of every chat would be exhausting. Luckily, Claude has tools to help you manage context that make it much easier.

Context in Claude

Automatically providing context lets Claude intelligently use it to write code or visualize data for you. How exactly this works depends on which version of Claude you are using - Claude web and desktop handle context for you, while Claude Code requires more manual intervention. Like most things, the automated option is easier while the manual is more powerful. I’ll assume you’re using web/desktop for these examples.

Global Context

Global context is the context that applies to EVERYTHING. Whatever you want Claude to consider as part of every conversation you have, every time, no matter what. In Claude, global context is called ‘personal preferences’ and it’s set in your profile in the settings menu.

There are a few categories of instructions you should consider for personal preferences.

• Interaction rules: How do you want Claude to interact with you? By default it will gaslight you into thinking you’re a super genius. This feels good but it’s not useful at work, so rules like ‘Tell me what I need to hear, not what I want to hear’ are a must.

• Development rules: How should it behave when building? If you’re an expert at BI but your python is shaky, asking it to always comment code snippets will help you understand what it did and learn as you build.

• Tech stack: If you always use the same tools for every project, make that clear. But it has to be every project. If you tell it to always use Power BI here, your Streamlit project is going to have some challenges.

• Enterprise standards: How does your business make money? What are the major initiatives for the company? For your team? What regulatory constraints must always be respected? The big picture of your work environment belongs here.

I find that I typically keep this just to high level interaction rules, development preferences and enterprise standards and leave technical details for lower levels of context.

Project context

Project context is anything that applies to just a single project. If you’re working on an ad spend optimization project, the stuff Claude needs to know to help you with this, but not the project you’re doing for the office of finance goes here.

In Claude web/desktop, you need to be building in projects, not just a long chat. Long chats make context management very challenging and they inevitably run into platform limitations that make them forget stuff you’ve already talked about. Projects centralize context and let you have many chats on the same topic with the same context. The project screen looks like this:

Here you have a few elements to play with:

Instructions

Anything you put here will apply to every interaction with Claude for just this project. So global context = all interactions period, project instructions = all interactions for one project. Typically this is where you put more detailed technical requirements, development standards, code preferences, etc. You also define project specific terms here so Claude speaks the right language without assuming.

Files

Files are the meat of your context. These documents contain the details Claude needs to build. Database manifests, metric definitions, visualization examples, etc are obvious additions. But to make Claude as useful as possible, you must also include non-technical context. Keep in mind, the decisions you make are driven by way more than ‘what’s my favorite python library.’

The four mandatory files for project context are:

• Project Requirements Document: This is a big one. The PRD contains all of the ‘who, what, where, when and why’ of the project. PRDs give AI the business value of the project and how you intend to deliver it.

• Architecture Designs: The technical architecture which tells AI at a high level how data flows from source system to user interfaces.

• Tech Stack: Detailed information about the technology being used and what techniques/standards must be followed during development.

• Meeting Notes/Transcripts: Criminally overlooked. Having notes or transcripts in context makes Claude ask really good questions and point out things you might forget. Transcripts in particular are gold, if you can get them.

Setting all this up before you write a single prompt may seem daunting - but it doesn’t have to be. In reality, Claude can interview you to glean what it needs to know to produce a first draft of most of these files. Then you flesh them out as you work.

Context vs No Context Example

I created a synthetic data set to test the context vs no context approach to dashboard development in Claude, complete with all the project context mentioned above.

No Context

I uploaded the CSV and said ‘Build me a dashboard.’ Claude did a quick analysis and recognized that the data set was pretty sparse and had some quality issues, which it gently suggested I should investigate someday. It then asked some basic questions - what’s the goal of this dashboard, who is it for? Because I said it was for executives, it defaulted to a narrative briefing document in HTML format.

This looks good - but in a corporate environment, this probably doesn’t match visual standards and it’s hard to operationalize html files. This is exactly the problem with contextless AI - it’s a quick path to good looking, unusable outputs.

With Context

Same data set and initial prompt, but with the context files and instructions I mentioned above. It evaluates the data and pushes back hard:

It’s looking at the project context and saying, in nerd speak, ‘Bro. I can’t use this data!’ A few things to note:

• It correctly identifies that it can’t generate CAC as per the metric standard because it doesn’t have enough data. It didn’t just guess!

• It points out the project standard is Snowflake semantic layer and I’m asking it to yolo a CSV.

• It determines it can’t create Power BI files and offers alternative paths to accomplish the task.

The last point illustrates the benefits and drawbacks of using LLMs and why context is so necessary. Claude is correct that it can’t create a PBIX file because it’s a desktop binary, but Power BI’s new PBIR file type is a JSON-based format that is developer and AI friendly. Claude doesn’t know this, because it’s not in the training data yet.

The solution is to update our context so Claude knows to build with it. I provided Claude the following prompt: ‘Look up the PBIR format for Power BI reports and generate a context file you would need to know how to work with it.’ It created a markdown file that I added to context, and now it can utilize PBIR.

The final output, which you see here in mockup form, follows the design standards I provided for operational executive reporting - basically, Stephen Few dashboards. It includes the specific metrics I identified in the PRD, not metrics it made up on the fly. It didn’t freestyle a nice looking but nonstandard executive briefing, it built exactly what the project context demanded.

Context means better, not necessarily easier

You’ll see the path with context had more hoops to jump through before it would build. The friction is the point. On its own Claude will ask a few questions, make a ton of assumptions and bang out a nice looking result that could violate dozens of design, security and architectural standards. Providing the correct context makes Claude stop and ask hard questions to ensure it stays within your guidelines.

Setting up the right context is the first step in using Claude to build data apps, and there’s a lot more nuance than what I can cover here. The book is where you get the real deep stuff. Up next we’ll dive into the best interactivity patterns for Claude, building out strong project and architecture context, getting the most out of dashboards, building skills and agents, chatbot creation and more. So stay tuned.

The technology industry is in a constant state of death and rebirth. Technologies, categories, vendors - these things come and go. The needs they fill, however, remain remarkably consistent. Business Intelligence evolved to fill a niche defined by:

• The need to make decisions based on proprietary company data

• The need to quickly distribute the data to relevant audiences

• The need to standardize important calculations across the company

• The need to establish a shared data vocabulary

These needs are not going away. But perhaps the way BI currently meets them is.

Subscribe now

Data display is a commodity; the rest is not

The dominant paradigm of BI, created by Tableau and exemplified by Power BI, is all about speed to human authored insight. Distribute a huge number of desktop tools to analysts embedded in the business. Give them access to the corporate data. Magic happens!

There’s just one big problem. No drag-and-drop interface can compete with prompted viz and dashboards, which look as good or better than most human-authored dashboards I’ve seen in the real world and have the bonus that anyone can make them in five minutes. Seriously. BI tools that position on front end magic are cooked.

However there’s a lot more to BI than pretty visuals - a lot that was forgotten in the desktop BI era. Semantics, security, auditability, scalability, standard reporting, etc. The back end of BI is hard and if anything, it’s even more important if business people can pump out 10k dashboards a day.

The BI Market Reacts

I see four major trends in BI tooling today. Practitioners need to understand these trends - BI people are very tribal around the tooling and the tooling is changing FAST.

Vertical integration into end-to-end data stacks. ServiceNow bought Pyramid Analytics. Databricks is building AI/BI and Genie. Microsoft, Amazon, Google, Oracle and IBM already had vertically integrated stacks. If the BI category collapses but the feature set is still valuable, the path to survival is through a bigger ecosystem. More and more enterprises view BI as part of a cloud vendor contract anyway.

Horizontal integration into BI-adjacent use cases in an attempt to be the front end for business. This is most apparent with Sigma Computing, which is refashioning itself from a BI tool to more of a business app builder with a strong data foundation. Adding features from planning tools like scenario modeling and write back, SaaS integration capabilities, embedding and application building tools are all examples of horizontal integration.

The Big New Thing is where it gets exciting. This is the bet that BI will still be a distinct category, but that it will be different than what we conceive of today. These are all your BI chatbot and AI analyst companies, your agentic BI agents, your enterprise search + analytics combinations, your BI as code vendors. This bet is that you’ll still want an independent BI tool of some kind, but it won’t look like Tableau at all. In this category I pay attention to Count, Zenlytic, Supersimple, Omni, TextQL, Golden Analytics, Evidence.dev and others. The list here is huge, I’m sure I left a few off. The key thing is each of these companies can explain in a single sentence how they are different from BI as you know it today.

Claude will just do it. The bet here is no, the category is collapsing. Claude can make great dashboards already. It doesn’t need any specialized tooling at all to do everything BI does today. And this is true, for the front end. But BI is about more than data display, and Claude currently does not solve the problem where everyone shows up to the meeting with a different sales number. At least not yet. Motherduck is making this bet - storage, compute, light BI infrastructure, let Claude handle the rest.

This last one is also the bet I’m personally making. I use Motherduck every day to run my business, and the book I’m writing will guide you down this path.

Where is all this headed?

Here’s the fun part. I have no idea. All four strategies make sense and could work. Or not. The one thing that won’t work for a BI vendor is standing still and assuming that those fat renewals are going to continue forever. They aren’t - the runway is almost gone.

The same lesson applies to practitioners, especially those whose value derives from building dashboards. Now is the time to learn about semantics, context, AI assisted application development. The same advice as above.

Go Vertical and learn the full data stack of a mega vendor.

Go Horizontal and learn planning, app dev, SaaS integration.

Learn the next big thing and be the one to bring it into your org.

Go Claude and master AI analytics app development.

Pick a lane and become the expert. The runway is almost gone, for vendors and for practitioners whose resumes are just dashboards.

Did you know I have a YouTube channel full of deep hour long interviews with people like , , , Zhamak Deghghani and more? Check out the Super Data Brothers today!

Prefer to listen? I got you..

BI vendors in particular clearly feel they are well positioned to be the context hub for agentic analytics based on my conversations at Gartner. Many were already racing to add semantic layers, the hype term of six months ago in BI, and the leap to context is easy. A BI semantic layer already contains the tables, joins, descriptions, aggregations, aliases, business names, etc.. that AI needs to generate SQL on the fly. So just build that and job done!

Ehhh…. no. The BI semantic layer is a foundational piece of the context puzzle that delivers clarity to runtime query planning and execution. But it’s actually not the most important thing BI tools or BI teams can provide to AI. Understanding context for BI is a three layer cake with the top layer the most valuable but hardest to model.

Layer 1: Data Context

Data context concerns the data itself - definitions, structure and relationships. Classic BI semantic layer stuff that we’ve had for twenty plus years, dating back to the Business Objects Universe and Cognos Framework Manager. We didn’t call it a semantic layer back then, but that’s what it was. Cube, AtScale, dbt metrics are all modernizations and extensions of this basic concept - define the tables, relationships, descriptions, aliases, metrics, business terms, etc up front to allow easier access and ad-hoc query generation from BI interfaces.

These tools also abstract SQL away from the front end by translating data requests into database SQL. This standardizes SQL generation while providing flexibility to end users - you can combine any related elements in a semantic layer on the fly and the system generates the SQL for you.

You may believe AI needs robust semantic layers to write queries. It doesn’t. AI is getting really, really good at writing SQL directly. But they do standardize AI generated SQL, provide reproducibility and resolve ambiguity. If there are two query paths AI could take to generate a result set, a semantic layer will enforce the correct one every time.

Providing good data context helps AI write correct SQL and produce accurate reports. It’s extremely important. But anyone who has used a BI tool chatbot knows that data context doesn’t help AI interpret user language or intent, and it doesn’t move the needle towards AI autonomy.

Layer 2: Knowledge Context

One level above the data context, knowledge context is about what all this stuff means. This is where the graph and ontology experts come into play, the s and s of the world. This is their bread and butter and you should give them a follow. Here I’m strictly talking about its application to analytics and BI.

Knowledge context is about concepts, what they mean and how they relate to one another. We have all had the experience of ‘Revenue’ meaning ten different things to ten different people or departments. Knowledge context in analytics is about resolving this ambiguity to answer business questions.

This is the difference between a frustrating chatbot and one that actually works. With data context alone, the question ‘How are we doing in EMEA’ is very difficult to answer because ‘how are we doing’ is ambiguous and ‘EMEA’ carries many potential assumptions about inclusion criteria, currency conversions, fiscal calendars, etc… that aren’t easily described in the language of relational databases.

Let’s be real - most major BI vendor chatbots suck right now, because they struggle to capture knowledge context with systems and technologies designed strictly for data context. It’s a hard thing to bolt on.

This is the cutting edge of context management for analytics and BI today. With strong knowledge context, AI can answer ambiguous questions and have meaningful conversations with end users without translating everything into precise specifications and pre-built queries. Most BI vendors claim to be here but few actually are.

Layer 3: Decision Context

This is the context that exists in your head today, not in any system. The people, politics, priorities and unwritten rules of engagement. Decision context is the intuition you have about what works that drives a thousand little prioritization and development choices every day.

I am not aware of a tool in the BI or analytics space that even attempts to capture this context today, but it’s crucial to building semi-autonomous AI systems inside real companies.

Consider Gary. He isn’t a decision maker, but he has real political and social sway. When Gary asks for something, you move it up the queue. When you deliver a dashboard, you make sure to get his input first because his opinion matters. Nothing in the org chart gives away that you ignore Gary at your peril. Every organization has a Gary.

Who are your decisions makers vs influencers vs blockers? Who are your champions and detractors in the business? What does the CFO say she wants, vs what does she actually want? Why do you present the same data one way to the CEO and a different way to the ops team? What decisions are ruled out from the start regardless of what the data says? What biases do decision makers have? What pitfalls must you avoid?

AI cannot possibly know this. No model has it. No vendor (that I’m aware of) is building it. But this is what AI needs to operate autonomously without making reasonable decisions that are wrong given the social and political dynamics of the enterprise.

How do you even capture this? Is it something you model? Do you extract it from Slack or Teams? And how could an existing BI tool make use of it?

I argue that today, they can’t. A vendor is not going to solve this for you. Capturing and using decision context is your job as a BI practitioner or data analyst and your maximum point of AI leverage. How to start?

Every major AI tool has some kind of context file. As an avid Claude Code user, I’m deep into .md files but this works for all of them. Next time you are starting a project, before you do anything, drop the following prompt into your AI.

‘I am starting a new project about [description of project]. I would like to capture the social, cultural and decision making dynamics so you can help me prepare and deliver the project. What questions do you need answered to generate a useful markdown file for AI guided development?’

This becomes foundational context for every interaction you have with AI, whether it’s helping you plan or writing your SQL. See where that takes you and adjust.

BI teams can lead data enterprise context

All three layers are necessary for AI to take the leap to true productive co-creator in the enterprise, and BI teams are uniquely positioned among data practitioners to lead the transition. No other specialization in data touches all three layers daily.

The super power of good BI people is not their knowledge of SQL or data structures or reporting tools. It’s their ability to understand the social dynamics of decision making within an organization, map the conceptual landscape of the enterprise and translate that to supporting data structures and reports. This was true before AI and it’s doubly true now.

Practitioners who embrace that power have a bright future. But it starts now. Don’t sit back and wait for your vendors to put context management in place, see what you can accomplish today. As in NOW. Go do it now.

The industry talks endlessly about Iceberg, you feel like the Titanic. And with AI looming on the horizon, you’re falling further and further behind.

Your fear is justified. The days of being just a dashboard monkey are numbered.

Subscribe now

In the age of AI, anyone can generate a chart. What separates people who get promoted from people who get automated is knowing which problems are worth solving.

This skill transcends tools and trends and it’s something you can build despite whatever legacy tech stack you are saddled with today. Here are four steps to transcend tooling that will set you up for the next stage of your career.

The first is the most important and it has nothing to do with technology.

Focus on people, not technical problems

Most BI and analytics professionals suffer from what I call the ‘builder mindset.’ Like the medieval stonemason, the builder is concerned with how. How am I going to set the keystone in the cathedral arch; how am I going to visualize this data? The builder has the secret knowledge and skills to make the vision of others a reality.

Being a data builder is a satisfying job that has paid very well. But there’s a big problem. Increasingly, how will be handled by AI. The skill of knowing every menu and button in Tableau or Power BI was already commodified, soon it will be the domain of machines.

You need to move from how to what, why and for whom. These are the critical gaps that you can fill TODAY regardless of what BI tool you are using. So how?

Stop obsessing over the data and start obsessing over the people. Value doesn’t exist in clean data models or optimized queries, it exists in the real world, in the feelings, thoughts, goals, and fears of your users, executives, and customers.

Here’s my success metric: I want someone to tell me, ‘The data you gave me helped me get a promotion.’ That’s the bar. Not ‘nice dashboard,’ not ‘this was helpful.’ I want to know I changed their career trajectory.

Start there. Not with questions about what reports they need or what metrics they track. First, understand their goals in human terms. Then translate to metrics and reports. Then build.

When you succeed, you dramatically improve the quality of your output without modernizing your technology at all.

Move fast despite bureaucracy

Legacy BI teams often have governance-focused, default to ‘no’ cultures. As frustrating as it may be, that culture has a purpose; to protect the people who put it in place by eliminating risk and externalizing blame. I ran headlong into this culture early in my career.

I was on an enterprise BI/DW team with a seventeen step SDLC that involved multiple gates, approvals and migration paths for literally every change in production - and this was after we transitioned to ‘agile.’ No matter how hard I argued against it, changing things was viewed as just too risky.

So I de-risked it. I identified a class of changes that were perceived as low risk, mostly focused around display elements like colors and chart types, but also more meaningful changes like adding metrics that already exist in the semantic model to non-regulatory or financial reports.

I then ran the analysis and showed that these requests took up roughly 30% of our total development with a truly horrible ratio of process time to actual development - something like 5 to 1. This meant that 25% of our total department work effort was going to bureaucracy for these low risk requests.

Armed with this, I designed a ‘quick access workflow’ that had 5 steps with just 1 gate. Because I understood that fear of risk was the number one motivation for my department leaders. I argued that the risk of burning so much effort on busywork was greater than allowing this well defined set of tasks to proceed quickly, and I eventually won out.

You may be in a similar situation. Identify what drives that culture and find concrete, low risk ways to start pushing against it.

When you succeed, you dramatically improve the velocity of your output without modernizing your technology at all, and over time can expand the scope of requests that can be done quickly.

But you’ve also done something very sneaky - you’ve planted the seeds of a rapid, AI driven workflow in your organization. It’s just nobody knows it but you.

Create your personal AI toolkit

Is there a huge AI-native data stack you need to start doing modern BI? No. Forget semantic layers, ontologies, AI chatbots for now. Remember, you are stuck in legacy land. Don’t wait for your boss, start where you can - your own work.

Odds are you have a massive amount of metadata stored in your head about how to get shit done at your organization. You need to get it out and into a format AI can interpret to help you build.

Pick a domain or business area you know extremely well, pop open the model you have access to and input the following prompt:

I am setting up the necessary documentation for you to help me create dashboards, reports and ad-hoc answers for end users in [[domain]]. The final output will be in one or more files for you to interpret. What questions do you need answered to begin helping me with this.

You don’t need to be an expert in interacting with AI to start. Let AI guide you and learn as you go. It will probably ask about data sources, metrics and calculations, semantics, personas, visualization standards. If it leaves one of these out, prompt it in eventually.

Then dump everything to Google Docs, YAML, whatever. Feed it back in every time you start a new project.

This is the basis for your one person AI analytics department. The important thing is that you created the personal AI development infrastructure to accelerate your work and teach you the basics of the technology.

Get AI on your resume

Now is the time to take the step beyond legacy to become an AI driven BI developer. You developed the right mindset. You created options for fast moving, modern development styles. You built your personal AI skills and have an assistant ready to go.

Put them all together and identify a low risk BI output that you can deliver end to end with AI. Here’s what this looks like in practice:

A stakeholder asks for a ‘sales performance dashboard.’ Instead of jumping into Power BI:

1. Use AI to research: ‘What are common sales performance metrics in [industry] that we don’t use yet? What decisions do sales leaders typically need to make?’ This gives you intelligent questions to ask before the meeting.

2. Come prepared: Instead of ‘what do you want to see?’, walk in saying ‘I understand these are common concerns in your role,which resonate with you?’ Suddenly you’re a strategic partner, not an order-taker.

3. Use AI to prototype and iterate: Have AI generate sample metric definitions and visualization specs before you touch the BI tool. Iterate in minutes instead of days.

4. Build in legacy tool: Go ahead and click the buttons in Power BI, you’ve already done the strategic stuff much faster thanks to AI.

When you’ve done this a few times one of two things will happen.

Your velocity and work quality will improve so much that your employer loosens up and embraces the future.

Or you’ll be able to walk into your next interview and say: ‘I used AI to accelerate my analytics workflow, improved delivery speed by X%, and drove strategic outcomes in a legacy environment.’ That’s a compelling story.

Evolve or die, BI style

You’re 35. You’ve got 10-15 years before you’re either leading data teams or explaining why you’re still a senior BI developer. The people who make the leap aren’t the ones who got lucky with modern tools, they’re the ones who accelerated past their constraints to embrace the future their employer wasn’t ready for.

The Brutal Truth: Your company will eventually replace your legacy BI tool. The question is: will you be part of the modernization, or will you be the person they replace alongside the tool you’ve been maintaining?

There are dozens of levers to pull when planning a conference. Session length, sequencing, location, lunch, keynote, happy hour - it’s just a ton. And I’ll be real, we were staring at a spreadsheet debating what to put where and for how long and it was 4:00 on probably the last nice Friday for six months here in Detroit and I and the rest of the team had enough.

Subscribe now

So we turned to ChatGPT for help. Everything you see from here on out was done live on a Teams call and took about 7 minutes.

Structuring the conference schedule

We were struggling to establish the basic schedule - how long are the sessions, how long is lunch, etc. Rather than hashing it out, let’s see if AI can make it for us.

To me this is the goldilocks level of prompting - not too much info, not too little, just right. I could have loaded it up with ultimately irrelevant details, but why? It gave me a perfectly servicable response using just this.

GPT 5 will always suggest next steps for you. In this case, it suggested all sorts of stuff not pictured above which I ignored. I usually ignore its suggestions to be honest.

This was a good first stab, but , our keynote speaker, always brings the heat to a data conference and cramming him and a welcome into thirty minutes is silly so we iterated.

Getting closer, but that town hall is too tight. We need room for the participants to get comfortable and open up. Because we don’t want to just extend the conference, we have to trim somehwere.

And there we had it. A reasonable, well structured conference schedule. But that’s the easy part. The hard part is the agenda and presentation sequencing. We used AI for that too.

Teaching our AI the conference context

Data in the D has four tracks with four presentations each focused on BI and Analytics, Data Culture, Data Engineering and Artificial Intelligence. With that mix we could have spend days debating the best sequence.

Instead, I uploaded a screenshot of the presentation spreadsheet that our organizer had shared on Zoom. The grain of the spreadsheet is at the presenter level, and since we have panel discussions there were more rows than we have presentations. But that was easy to explain to ChatGPT via a simple prompt.

You can see how it picked up the necessary details without further explanation. At this point it understand our tracks and their titles, who our sponsors are, and the overall flow of the day. It even gave us a proposed agenda without me explicitly asking.

The agenda was in long text format and hard to read. So I asked for a table. Easy fix.

It got a few things wrong here - it has some people marked as sponsors who aren’t. But that’s not relevant to our goal. In fact, we could have just run with this proposed agenda, it was pretty good. But not perfect.

After reviewing together for two minutes, we suggested a few changes to the sequencing of two of the tracks to spread out the sponsored presentations and the panel discussions so that they don’t all overlap.

And that was that. The Data in the D Conference agenda was complete in 7 minutes.

Three rules for AI prompting

This wasn’t really about scheduling, it was about how fast teams can co-create with AI. The days of tasking an intern or spending hours in spreadsheets are over. You just need one good prompt and a team that’s not afraid to try.

We followed three simple rules to get this result in minutes, not hours:

• Start simple. A “Goldilocks” prompt beats an over-engineered one.

• Iterate fast. Every tweak teaches you something.

• Show, don’t tell. Screenshots explain more than paragraphs ever could.

Our real win was treating AI like another team member. By keeping prompts simple, moving quickly, and using screenshots instead of long explanations, we saved days of debate and made it out in time to enjoy the last nice Michigan Friday of the year.

Join us at Data in the D!

Data in the D is an annual conference celebrating Detroit’s rich history of innovation in technology. We are bringing the best national speakers and ideas to the Motor City while elevating local voices.

The one day event on Saturday, November 8th includes a ton of amazing talks, a keynote by Joe Reis, an open mic town hall, and a sponsored night out.

Come join us to experience cutting edge data in America’s Comeback City.

Tickets here.

Zhamak Dehghani joins us on Super Data Brothers

Zhamak Dehghani, creator of data mesh and founder of Nextdata OS, joins Eric and I on the Super Data Brothers show this week at 12PM Eastern. While we normally do our interview live, Zhamak is busy running one of the world’s most innovative data companies so the interview will be pre-recorded.

I am recording the interview with her today. If you want me to ask Zhamak your question, DM it to me on Substack!

Catch it the show live at 12:00 PM Eastern and on demand here: https://youtube.com/live/CBrCuJ_6-Us

Until next time,

Ryan

But what about tooling? If drag and drop query builders and analytical dashboards are no longer the end all, be all for analysis and consumption, what actually happens to BI tools? The short answer is, nobody knows. But there are some hints of what’s coming that we can explore now.

Subscribe now

The BI platform of the future

So what does the BI platform of the future look like? Dashboards will still exist, of course, but they will be just one element of a broader BI ecosystem. Chat interfaces are certainly a part of it. I also expect new, guided data analysis interfaces where humans and AIs collaborate in realtime. Exactly what this looks like is uncertain, but there are some principles that I believe will guide the emergence of these new platforms.

Pervasive

BI in the future will not be limited to the BI tool. Study after study shows that BI has hit an upper limit of ~25% adoption in the current paradigm. I believe there are two primary reasons for this: BI tools are too hard to learn, and nobody wants to switch from operational to analytics interfaces to interact with them.

In the future, data consumers move from operational work to analytical work while staying in flow, thanks to rapid advances in conversational AI, analytics-as-code and embedding. At GoodData, I see clients evolve from creating a walled analytics section of their app to embedding analysis capabilities - not just visualizations - directly in operational interfaces. Adoption jumps.

In short, the future BI platform lets you find existing data, analyze new data, and share that analysis from anywhere, not just from within a dashboard. And it features easier interfaces like chat to bring data work to a wider audience.

Proactive

Future BI platforms will not wait for a human to ask a question before analyzing data and alerting people who need to know - or eventually taking actions themselves. Most BI tools can only handle the basics, but the path forward is clear. I see five stages of proactivity:

1. Threshold alerting: ‘Email me if this number is over 1M’

2. Relative alerting: ‘Email me if this number changes by 5% YoY’

3. Forecast alerting: ‘Email me if this number deviates from the forecast or plan’

4. Proactive alerting: ‘Email me if there is a change I should know about’

5. Agentic alerting: ‘Take an action I would take if you think you should, and let me know about it’

Almost all BI tools are stuck at stages 1 or 2 even though stage 3 has been technically possible for over a decade. We should demand at least this level as a baseline today, but the really exciting stuff happens in stages 4 and 5.

Proactive alerting is where true autonomous analysis comes into play. Proactive BI systems will scan data as it changes and evaluate against a set of criteria provided by data consumers to determine if an alert should be triggered and even who should be notified. Criteria will be a mix of quantitative and qualitative decision points that combine facts and narratives to drive alerts. ‘Let me know if sales decline by more than 3% AND you have a root cause analysis to tell me why.’

Agentic alerting goes further. Here the AI analyzes, alerts and acts. Imagine a system scoring inbound leads and assigning them to the right rep in a CRM. In this setup, the BI platform performs the analysisand and triggers the best action downstream.

LLM systems are especially well suited for this kind of analysis when they are deployed alongside traditional, deterministic statistical analysis. The LLM handles meaning and qualitative analysis, while traditional statistical methods handle the numbers without risk of hallucination.

Predictive and Prescriptive

Business Intelligence has long been stuck in a narrow ‘descriptive only’ mode: what happened in the past. Predictive (what will happen in the future) and prescriptive (what you should do about it) being siloed into separate technologies and teams. This was even codified in the ‘analytics maturity model.’

This ridiculous divide kept advanced analysis hidden in data science groups while day-to-day business users were left with static reports.

The future BI platform does not draw these distinctions. It offers traditional descriptive analysis in the form of queries, charts and dashboards. It also calls ML models or apply statistical analysis as necessary. And it is all orchestrated and presented by LLMs which find, produce and contextualize these outputs.

Most importantly, it relies on the right technology for the right task. LLMs should not be free to make up a statistical analysis or render a dashboard when there is a pre-existing, trusted asset on the shelf ready to be used. All things in balance.

Perspective

The most exciting aspect of BI’s future is our ability to offer perspective to data consumers. This means moving beyond presenting numbers to generating narratives that tie past performance, current metrics and future plans together in an easily digestible story. Humans are storytellers, and the next generation of BI platforms will meet them there.

For data consumers this will feel like having a team of expert analysts at your side, finding patterns, adding context and tying data to your goals. These findings will exist in context, in the narrative of your personal or business goals, with projections of what happens next and advice on how to react.

For those of us building these systems, they will throw off incredible new data streams of the questions and intent of our consumers. Data teams struggle to understand what customers want in part because they struggle to tell us, and in part because we simply have no good alternatives to figure it out.

Imagine asking, ‘How have the questions my users asked changed in the last week, and what does that tell me about shifts in their business strategy’ and getting an answer back!

The real breakthrough is BI that teaches data teams what consumers care about, not just what they are able to articulate.

What’s the timeline

It’s Summer 1994, and I’m parked in front of a CRT monitor riding a wave of dial up into the irc room where I roleplay Wheel of Time with people spread across the globe. Tech gurus widely predict that the internet will rapidly change everything; jump forward five years and the world fels mostly the same. 25 years later, it has transformed daily life.

The same will be true for BI. In the next five years, we’ll see real progress: better chat interfaces, stronger ML integrations, easier ways to combine structured and unstructured data. But the core experience may still look familiar.

In twenty five years, it won’t. The BI front end will be unrecognizable, and the role of the analyst will shift from building dashboards to guiding intelligent systems, shaping narratives, and steering decisions.

That’s the future worth preparing for.

Yes AI will kill BI. As we know it.

But something new will rise in its place and that thing will still be BI.

Confused? Welcome to Summer 2025.

Subscribe now

BI has already died at least once

When people say AI will kill BI, what do they mean? There are two common themes; that AI will kill both the development style and form factor of BI. Consider:

1. AI is or will soon be so much better and doing BI development tasks that we will no longer need nearly so many BI developers, thus killing BI. This is true.

2. AI driven experiences like chatbots, AI driven alerts and agents will replace the BI front end completely, thus killing BI. This is also true.

What many people don’t know is that we’ve already gone through at least one total and complete ‘death of BI.’ It was called Tableau.

In the late 2000s, BI had a development style defined by a centralized team of technical professionals with almost no business knowledge operating in a waterfall development lifecycle. And BI had a form factor, the standardized web report paired with the mass distributed PDF.

This development style and form factor was the basis for tens of thousands of careers and multiple 1B+ vendor exits. It was BI.

And that’s completely gone now1. It was replaced with ‘Visual Data Discovery,’ originally a niche subset of BI where data analysts embedded in the business used their technical and business acumen to rapidly answer questions and build visually stunning interactive dashboards, with minimal IT oversight.

If that sounds like BI at your company, that’s because it likely is. ‘Visual Data Discovery’ completely replaced traditional BI and the job of data analyst was born. And yet, we still call it BI.

And that is the paradigm that AI is going to kill very soon.

How will AI kill BI

BI takes an enormous amount of work with middling payoff. I am the BI guy, I can say it. There are three main reasons for this, in order of importance:

1. It is too hard to get the right data in the right place at the right time to have a consistent positive impact on business outcomes.

2. It is too time consuming to develop front end visualizations, dashboards and reports to keep up with demands from data customers.

3. It is too challenging for data customers to learn BI interfaces to answer questions themselves.

AI is rapidly closing these gaps.

BI chatbots are vastly easier to use than drag-and-drop viz tools for 95% of people, even when they aren’t very good, which they mostly aren’t. But keep in mind that every BI chatbot you use is the worst it’s ever going to be. The need to ping a data person for every modestly complex query is rapidly fading.

Likewise for building visualizations and dashboards. AI can already do this, and do it quite well. It struggles with building what the user actually wants vs what they asked for, which is the art of good BI. But even now, the cost-benefit is tilting in favor of allowing AI to build the BI front end for routine requests because it’s simply so much faster and cheaper.

Finally, getting the right data at the right time. This is the toughest part, because it requires coordination across domains, business knowledge and deep technical skill. But even here, AI is making data engineers vastly more productive on its path to eventually replacing them. BI’s role is often to put the finishing touches on data and make it relevant to a specific data audience

When it’s easy to get the right data fast, simple to build the data front end, and trivial to query and iterate as a data consumer without ever calling your BI team, BI as we know it is dead.

BI is dead. Long live BI!

Once AI can do all the core technical tasks of the BI team, what is left? Ironically, it’s the same tasks that separate the good from great BI practices today - being the human face of data while managing the meta tasks relating data to consumer.

Being the human face of data is simple and devilishly complex at the same time. Because the BI team traditionally sits and the end of the data pipeline, they are the ones in contact with business reality. The best thing a BI team can do is not to clear adhoc queries requests, it’s to represent the business consumers and be their advocates in the data gristmill.

This role is not going away until data consumers get radically better at articulating their needs, goals, desires and fears, or until AI’s are able to intuit them from a combination of institutional knowledge and reading non-verbal and visual cues. The automation and ease coming to BI will only amplify the need for someone to combine technical mastery, business and domain knowledge and human understanding and empathy. This is the ‘soft stuff’ that will be the key to BI in the future.

Then there’s managing the ‘meta tasks’ of BI. This is the hard, technical stuff that will remain when AI is answering queries and building visualizations. Examples of meta tasks in BI include:

• Creating, customizing and maintaining the front end data assistants, chatbots and agents that end users interact with. These are complex systems that require a ton of care and must be infused with highly relevant data context.

• Curating, securing and enriching the metrics library available to AI. Even if AI is defining all the metrics, someone has to maintain the metadata and business context for those metrics.

• Contributing to domain and enterprise knowledge graphs, metadata catalogs, context libraries, etc. Especially translating business speak into technical instructions for machines.

• Defining and maintaining libraries of ‘approved’ front end assets. Why let the AI generate the same chart 1000x a day when it can just take it off the shelf?

• Building mission critical data assets alongside AI peers - the dashboard the CEO relies on cannot be 100% an automated system.

• Doing deep data research and answering the most critical, business altering questions. Yes, with an AI assist.

• Other technical tasks we can’t imagine yet.

These BI meta tasks are vastly more valuable than building dashboards, but building dashboards has soaked our BI bandwidth. In fact the top complaint of BI teams is something like this:

‘We spend so much time building dashboards and answering ad-hoc queries on slack that we can’t focus on solving the business problems that really matter!’

The good news for BI practitioners is that AI will relieve you of this problem quite quickly. The bad news for many is that having technical skills in a BI suite is rapidly losing it’s economic edge.

What’s next for practitioners and platforms

This is the transition to manage then. As a BI practitioner, skill up rapidly in AI assisted data development. Learn about knowledge graphs, ontologies, context windows, semantic layers. Don’t assume Tableau and Power BI skills will keep the family fed. And most of all, get laser focused on understanding the people who consume your data and what drives them.

As far as the BI platforms themselves, they are rapidly evolving AI capabilities. If history is any guide, some of the current leaders will not adapt fast enough and will fade from prominence, while startups or very innovative mid-level firms will push the industry rapidly forward.

But what does the BI platform of the future actually look like? That’s a question for a future post. Subscribe so you don’t miss it!’

Catch up on the best of Super Data Brothers

Season 3 of Super Data Brothers has wrapped for the summer, and we are knee deep in planning Season 4 kicking off in September. Have a topic or guest you’re dying to see? Hit me up here.

Season 3 is available on demand on YouTube:

Revolutionize your data mindset with Malcolm Hawker - How to ditch loser mentality and become the beset data leader

How to get a data job in 2025 with Aaron Wilkerson - the lowdown on getting paid in 2025.

Gartner BI MQ 2025 revealed - who moved up, who moved down and why!

Will AI doom or save the data industry with Joe Reis - The legend himself tells us where it’s all heading.

AI will steal your soul, not just your job with Ramona Truta - How to use AI systems in an ethical, uplifting way

Data is the new bullshit with Scott Taylor - Get boardroom buy in and do work that matters!

Databricks AI/BI tool review - Full breakdown of AI/BI and Genie’s strengths and gaps

Making data more human with Tiankai Feng - Design and empathy in data work

Fight health insurance denials using AI with Kolden Karau - Healthcare AI to save your life

Surviving the data engineer job crunch with Eevamaija Virtanen - Career strategy and good vibes

A BIG thank you to the Season 3 sponsor, GoodData!

Ship now and ask questions later?

I perfectly understand the pressure you are under to ship your data work ASAP. Business moves fast and today’s mandatory metric is tomorrow’s abandoned dashboard. Urgency is paramount - but unquestioned urgency leads to poor decisions, skipped steps and sloppy, abandoned work. Understanding the value, visibility and longevity of a data request gives you the ammunition you need to slow down and do it right when appropriate. It also helps you ensure your work is worth the wait - nobody likes to wait three months for a low impact request.

Breaking down the Value - Visibility - Longevity Framework

Let’s break down what these terms mean and why they matter.

Value is the project’s importance to decision-making or its direct and measurable operational or revenue impact. Value is not a vibe or a hunch, it flows urgent busienss needs, clearly defined KPIs or direct leadership requests. Anything else is noise.

Visibility is a combination of the sheer number of people impacted plus the praise or blame you will get if it goes wrong. If a thousand analysts are building dashboards on incorrect metrics, that’s high visibility. Likewise, if the CEO is the only person who will ever see this data request, well… that’s maybe more visible than the thousand analysts.

Longevity is simply the length of time the data work is expected to be relevant. This is the most neglected axis in data work. Teams over-invest in throwaways and under-invest in artifacts that live for quarters or years. For example, in data modeling longevity may push you away from the short-term convenience One Big Table (OBT) and into something more resilient and reusable.

If you only take one idea from this section, make it this: Longevity deserves more of your attention.

Right sizing your data efforts

Once you honestly assess all three components, deploying VVL becomes simple.

Low on all three: Quick and dirty is fine.

High on one: Move fast but polish the rough edges.

High on two: Slow down and make a real investment.

High on all three: Treat this like a product release with all that entails.

This isn’t a rigid process, it’s judgment with structure that puts you ahead of most practitioners. It trains your team and stakeholders to stop expecting pixel-perfect dashboards when the request is low-value, low-visibility, and short-lived. It also builds credibility when you say, ‘This one’s worth waiting.’

How to use Value-Visibility-Longevity

You can apply VVL thinking in two key places: Internally within your team and externally with stakeholders.

Internal to the team, use it regularly in grooming, planning, and retros. Treat it as a heuristic when prioritizing tasks—and because it’s not an exact science, track how often your bets are right. Are you investing in the right work? Are you flagging low-VVL requests correctly? Nothing’s worse than making someone wait three weeks for a dashboard no one opens.

External to the team, introduce VVL early in stakeholder conversations. Once they understand it, they can start framing their own requests in these terms and you’ll have the language to push back on unexamined urgency. Try: ‘We can get you something quick, but this one’s high visibility and long-lived. A little more time means fewer risks later.’”

Not a silver bullet, but a damn good compass

VVL thinking is not the only tool in your data leadership kit, but when applied correctly it’s enormously helpful in deciding when to slow down, take a breath, push back a little and do something right.

Try it. Apply it. Report back.

Catch up on the best of Super Data Brothers

Season 3 of Super Data Brothers is in full swing and we’ve already dropped some real banger episodes. A big thank you to GoodData for underwriting this season. Check the replays out:

Databricks AI/BI tool review - Full breakdown of AI/BI and Genie’s strengths and gaps

Making data more human with Tiankai Feng - Design and empathy in data work

Fight health insurance denials using AI with Kolden Karau - Healthcare AI to save your life

Surviving the data engineer job crunch with Eevamaija Virtanen - Career strategy and good vibes

Don’t miss us LIVE today at 12:00PM EDT where Scott Taylor joins us to show how great storytelling wins real budget!

We’ve got a killer lineup this season, mark your calendar every Thursday at 12:00PM EDT

May 29th: Metabase review - What works, what doesn’t, what to do about it

June 5th: Malcolm Hawker - Masterclass in data governance and metadata strategy

June 12th: Ramona Truta - Practical AI deployment in the enterprise

June 19th: Joe Reis - No introduction needed!

June 26th: Jean-Georges Perrin - The data contract guru debates the data product master!

Catch the full show archive here!

Upcoming appearances

Analytics Without Engineering is Just Reporting with Joe Reis and Matt Housley

Tuesday, May 27th at 12:00 EDT, registration required

Join Joe, Matt, and me for a live GoodData webinar on the future of Analytics and AI and why a code-first approach isn’t optional in 2025.

Tech Show Frankfurt June 5th - 6th with GoodData

I’ll be speaking live on Tuesday and hanging out at the GoodData booth throughout the event. swing by, say hi, and test my terrible German.

That’s it for now - hope the start of your Summer is great!

Cheers!

Ryan

Bonus question: This entire post was written listening to the album Moon Safari by the dreamy, retro-futurist French pop band AIR. What’s your go-to ‘it’s time to be creative’ music?

Power BI: the cause of and solution to all of BI’s problems

So job done? In a way, yes. If you define ‘business intelligence’ as the art of quickly creating dashboards on questionable data infrastructure to be consumed like candy which gives a temporary high, a brutal crash and a ton of empty calories then Microsoft has nailed it. This is the 2010s way of doing BI and its apex achievement is Power BI and the data analyst - driven workflow that it enables. Give a flexible tool to someone close the business and let it rip, problem solved.

I may sound dismissive of this way of working. It’s because I am. But not because it’s ineffective - in fact it solved a very, very real problem that plagued business intelligence in the Cognos and Business Objects era - the fact that accomplishing anything required an interminable wait for IT to do even simple modeling or reporting tasks. We can’t return to that world. And the people close to the business SHOULD be empowered to solve data problems.

The BI pipeline is broken

But neither can we continue to live in a world of one-off Snowflake views feeding one-off data models feeding one-off dashboards, where every metric is ‘bespoke’ in the worst sense of the word, where most visualizations are useless and most dashboards collecting cobwebs. The need to deliver something - anything - as quickly as possible so that we can say we incorporated data into our decision has resulted in a lot of rushed, repetitive and unscalable work.

It’s not fun. It’s not fun to build, it’s impossible to maintain, and for business people it’s not fun to use. We have a conundrum - any wait is too long and yet moving fast delivers the ‘break things’ part, but very little of lasting impact gets made.

Self-service can’t solve it

I talk to a lot of data leaders, and they feel increasingly burned by this. You might think the obvious answer is self-service and yet they question whether the investment in ‘self-service’ has really resulted in anything. Becoming ‘data driven’ has driven them mad, and the infinite dashboard sprawl of BI work has become an end unto itself.

The reality is that the idea of self-service - that we could just push the creation of business metrics and the dashboards that depend on them directly to business people - has created a noble yet ungovernable mess. Our current crop of tools - lead by Power BI - have become a brutal combination of too complex for business people to use to create anything, and yet too simple for data people to build the kind of robust metrics delivery systems of the past which can guarantee timely, accurate data in a repeatable, auditable, scalable way.

This may be a distressing message. Many data teams are struggling mightily to deliver self-service, and yet here I am arguing that it won’t solve their problems. Well - it won’t. So what will? I’m the first to admit, I don’t know for sure. But here’s where I see things going.

Step 1: Remember the point of BI

In the pre-Tableau era, BI was not defined by visual fidelity. Humans are, of course, visual creatures and many a BI contract was inked based entirely on an awesome demo of 3d column charts. But the purpose of the BI system was widely acknowledged to be the delivery of timely and accurate metrics. This was accomplished by modeling business logic directly withing the BI tool and exposing that logic to EVERY report or dashboard in the system. There was no tight coupling of data model to output - instead a single model would feed sometimes thousands of downstream objects.

Of course you could build report-level metrics, but it was often frowned upon, and great care was given to backing those metrics out of the report and into the BI model as soon as they were broadly useful. This took time, it took expertise and (from the business’ perspective) it took freaking forever, but it did result in 10k reports that used the exact same calculation for ‘revenue’ guaranteed, no matter what.

Tableau came around, and the focus shifted to communicating with data - telling stories. This was a critical and badly needed advancement in BI. However, the bedrock purpose of BI was neglected and now we have sprawling BI deployments with absolutely zero high quality data models. Recognizing this need is step 1.

Step 2: Rediscover the BI practice

The only way to build the kind of high quality metrics distribution system I describe is develop a broadly accepted, repeatable set of steps that you can hone over time - aka, a practice. I encourage you think explicitly in these terms.

A practice is something you do again and again, keeping what works and discarding what does not. But the key is, you do not start at square one every time. You build upon what came before. This means, practically, modeling data for reuse. Maintaining accurate metrics over time. Always using the metric from the model - not a metric scoped to a single report - whenever possible. It means following standards in how you visualize data, how you design dashboards. It means providing these high-quality, reusable models as the basis for self-service.

The key is to figure out how your team can do these things fast, and then doing it over and over until you’re really, really good at it. It means learning as you go.

Step 3: Treat BI (sort of) like software

Business intelligence is just woefully behind its cousins data science and data engineering in embracing code-first approaches to modeling and visualizing data, to our extreme detriment. And I’m not entirely sure why - maybe it’s that BI attracts less technically inclined people, maybe it’s a result of the over-focus on self-service, or maybe it’s an historical accident. But in practice, BI people are often stringing a chain of UI-bound tools together via vendor-provided integration points that are constantly breaking and have almost zero auditability and which require immense effort to build, deploy and maintain.

This has to stop. These problems have been solved using software engineering techniques. Modern BI tools should offer declarative APIs, SDKs and integrations with CI/CD. And modern BI teams should embrace this way of working, because while it seems more complex at first, it’s actually far simpler to copy, diff and edit code and config files than it is to build a whole new BI object in a GUI.

Step 4: Embrace the data model and metrics layer

The only way BI can fulfill it’s purpose of distributing high quality metrics to aid in decision making is to focus, first and foremost, on the metrics. Not the visuals. And that means building a BI model via a semantic or metrics layer.

There are lots of them to choose from. Some are tied to BI tools (GoodData has such a layer) and some are standalone software. The key is to select one that is open, meaning that many applications can access it via SQL and API/SDK endpoints, rather than one that is proprietary, meaning it is locked to a single BI front end. Like most of them.

The reason for this is obvious - the promise of BI is only fulfilled if you can maintain metrics quality across applications. In order to do so, you need a single place to define the metric, where you can update the metric and see that update automatically flow through to all downstream uses - AI, BI, data science, custom applications - anywhere.

You may be tempted to say, ‘my data warehouse is my metrics layer!’ Well… maybe. The issue is, the data warehouse itself must make concessions to accommodate the needs of ETL/ELT and often contains structures that exist explicitly to assist in data processing and storage. An independent metrics layer abstracts away this complexity and gives you a single place that contains metrics from many systems. The underlying physical reality of your data is undoubtedly very complex, but a metrics layer can make it appear simple to external users and applications

The pendulum swings back

Ultimately, what am I advocating here? In many ways this is a return to the wisdom of a previous age, but with modern tools and techniques. The big reason we left all this ‘metrics layer, BI practice’ stuff behind is because it was too slow and complex. However while the BI world was focused on building ever-prettier charts, the engineering world developed techniques and software to handle this complexity.

What this means is that it’s realistic once again to embrace modeling, embrace standards, embrace accuracy without sacrificing so much speed as to make your business unhappy. This is how you move forward in 2023 and beyond to build big, bold and audacious BI systems that leave desktop BI tools like Power BI in the dust. Or, at least, supply them with high quality metrics so that they aren’t churning out so much beautiful garbage.

Want a video recap of Gartner Data and Analytics 2023? Check out this episode of Super Data Show

Gartner Analytics Trend #1: Lack of data ROI

This was a major theme across the whole conference - after a decade of ridiculously low interest rates and tons of data hype made investing in data easy, we find ourselves suddenly asked to show genuine ROI for the first time in ages. For a long time it almost felt as if data was a self-justifying investment. Those days are over and Gartner delivered that message forcefully. I’ve heard it lots of other places too.

Subscribe now

Deep data ROI

Gartner distinguishes what they call ‘financial metrics’ from ‘financial influencing metrics’ as a way to reflect the deep value of data investments. Financial metrics are the things you immediately think of to justify spend on data - increased revenue and productivity, reduced cost. These things are great! But Gartner argues that the value of S&P 500 companies is now largely driven by long-term strategic financial influencing factors rather than traditional tactical factors - things like the value of company grand, innovation and know-how. They argue that data teams should focus on delivering long-term strategic value over short term tactical value.

I agree with Gartner - sort of. Data teams should strive to tie their work to long-term strategic sources of value. But in reality I think there are tons of data teams who struggle to tie their work to short-term tactical value. If we do have a significant recession coming CFOs are going to make short-term, tactical decisions about what to cut. They are more than willing to sacrifice ‘the brand’ to make the balance sheet and cashflow work this quarter. The incentives of our entire financial system practically mandate that they do so. Being able to show data’s contributions to classic metrics like revenue is probably your best shield against short-term thinking and short-term cuts.

If you can’t show how you increase revenue and productivity and reduce cost and risk with your data practice, figure it out immediately! Then by all means, move on to showing long term value.

Gartner’s Enterprise Value Equation

The Gartner Enterprise Value Equation is their method for building long-term, financial influencing value for data teams. Here’s an example they shared from the conference:

There are two things I really like about this:

1. It’s circular - you’ve seen me argue over and over that the future of business intelligence is not a linear supply chain of insight, but something more circulatory that promotes the good and prunes the bad. The Gartner Enterprise Value Equation is exactly that - a system that seeks to build virtuous feedback loops between data and business teams.

2. It’s very focused on identifying, delivering and measuring value to the business in business terms. Too many data teams measure value in terms of their own assets - number of dashboards, count of monthly users, amount of raw data processed - which ultimately have no relationship to business value. By first identifying the desired business goal and focusing all your efforts on that, you can build a much more valuable data practice.

Ultimately this is one of many systems for building out a successful data and analytics practice - you are free to shop around for what works. But a far as it goes, the Gartner Enterprise Value Equation has the solid foundation of business value and positive feedback loops that I endorse.

Gartner Analytics Trend #2: The franchise model

The overall structure and operating model of enterprise analytics has become a hot topic, just another sign that the Tableau era is over. Zhamak Dehghani’s Data Mesh is my personal favorite, but there’s also Data Fabric and Data Vault. You can now add ‘The Franchise Model’ of analytics to the list. It has a lot in common with these other approaches.

The Gartner Franchise Model of Analytics is designed to allow your business units autonomy to run their own tailored analytics programs while maintaining a centrally provision platform, suite of tools and operating model. The idea is to bring back governance, data quality and some degree of standards while maintaining the speed and agility that accompany business-lead analytics.

The analogy here is to any franchise style business - McDonald’s, for example. Your D&A Center of Excellence is like McDonald’s corporate. Just as McDonalds corporate provides the machines, products, advertising and operating instructions, your COE provides the underlying data platform and infrastructure, centralized metrics and analytics playbooks. Each business unit is then a franchise and brings domain knowledge and their own unique way of looking at and deriving value from data.

If you choose the right tooling for your centralized platform, you can easily provide the bedrock technology for a distributed data practice. Features like headless metric stores, composability and analytics-as-code are key to unlocking the Gartner Franchise Model of Analytics in my opinion. An underlying platform that has these capabilities will be use case agnostic, meaning it will no longer matter that Supply Chain likes Power BI while Marketing likes Tableau while your data scientists like to code their own python. The underlying platform can handle connections to all these endpoints while maintaining consistency of data and UX.

Gartner Analytics Trend #3: Return of data governance

Three big trends in the BI space drive what I call ‘The Return of Data Governance’ in 2023. It’s not that governance ever went away, but it was definitely deprioritized during the 2010s in favor of speed and data analyst agility. In essence, the ability to quickly pump out dashboards trumped data governance concerns. However we’ve reached a point where many companies have 2500 Snowflake views driving 2500 Tableau dashboards and simply can’t manage it all, let alone maintain high quality data. That’s where modern governance techniques come in.

In order to be successful this time around we need some new approaches. Luckily there are a ton of smart people trying to bring back governance without killing agility or innovation. In that vein, the top three trends driving modern data governance as I see it are:

Semantic layers and data catalogs

This is the modern incarnation of an old idea - that there should be a layer that sits between the data and the analytics that allows for high quality, consistent metrics across all downstream uses. It was in fact mandatory to build a semantic layer in legacy BI tools like Cognos, but fell out of favor in the Tableau era. Now they’re back, but they have some very interesting changes from ye olden days:

• Open metrics layer: These tools work with any front end - BI tools, AI/ML or data apps. They are not proprietary to a single use or company.

• APIs, SQL and more: At a minimum these tools allow API and SQL access, but they often can interpret DAX, MDX and other data languages as well.

• Catalog + metrics in one place: Many of them offer catalog and search capabilities alongside real-time metrics query.

• Designed as a graph: Semantic layers are really knowledge graphs, and modern tools are designed this way from the ground up..

Some examples of tools that do some or all of this are GoodData, AtScale, Illumex and Data.World.

Composability

Composability is a term that has yet to permeate the data world, but it’s quickly picking up steam. Composability mean modularity - a composable data platform is made up of components that can be created, altered, re-arranged and combined in unique ways, either by the IT team or - more powerfully - by the business.

Composability enhances governance by allowing the IT team to maintain a library of analytics components that can be used by anyone downstream. For example, you may maintain composable metrics, data catalog and visualization capabilities centrally. An individual business unit then chooses to use the metrics and data catalog but keep their own visualization tool. By choosing a composable data platform you increase adoption by offering a better deal than the traditional ‘all or nothing’ offer from central IT.

As far as I know GoodData is by far the leader in the composable BI space.

DataOps and analytics-as-code

The final piece of the modern governance puzzle is DataOps and analytics-as-code. These concepts come to us from the software development world, where they’ve already completely transformed the industry. By moving away from UI based data platform management, you dramatically increase speed and scale. Code is just more efficient and easier to manage once you embrace it. Some advantages of this approach:

• Super fast deployments: Modern software deployment and testing techniques eliminate downtime and allow you to test and push changes to prod with no downtime and at tremendous speed. Composability ensures that you’re only updating a single component at a time, which reduces risk.

• Scale rapidly: Using declarative code, you can build out an entire analytics environment very quickly, and update it even faster. Because you can parameterize the environment, it becomes incredible responsive to change. Things that used to take weeks (change in org structure anyone?!) can be done in a day when properly architected.

• Code and change management: Speaking of enhanced governace, by using industry standard code management techniques you have the ultimate in data platform governance. You’ll always know who changed what code, when and why, and be able to roll back easily.

• Easy integration: Analytics-as-code platforms have declarative APIs and SDKs that make bi-directional integration between your data platform and downstream AI/ML and data apps much easier. Imagine a single python script that imports data, transforms it, provisions a BI environment, creates the dashboards and applies security based on a set of parameters in the data - this is possible!

Subscribe now

This is another area where GoodData has invested heavily as an end-to-end data/BI platform. Other interesting players are dataops.live for data engineering and Nextdata for data mesh implementation.

What about the 2023 BI Magic Quadrant?

One puzzling thing about the conference was that the 2023 Magic Quadrant for Analytics and Business Intelligence was not released. I’m not sure why - this was the obvious time to share this year’s update. Anyway, they did discuss the top trends impacting the MQ in its absence.

We’ve already discussed governance, headless (semantics) and composability at length above. Consumer design focus really represents a shift in the front-end UX away from data analysts and towards data consumers. This is a trend I wholeheartedly agree with, as you can see here:

Super Data Blog

How to Build an Analytics Front End that Doesn't Suck: Presentation-Purpose Fit

Too often, the valiant efforts of data engineers and business intelligence professionals are wasted in a limp dashboard-only front end that fails to show ROI and makes their work look trivial and uninspired. You know this feeling - when you work hard as a team on the pipelines, tables, metrics and orchestration for a ‘critical’ data need, only to find t…

Read more

3 years ago · 2 likes · 3 comments · Ryan Dolley

Another interesting thing they shared was potential changes coming to the structure of the BI MQ itself. They’ve considered combining it with the Data Science and Machine Learning MQ as the capabilities of these categories are bleeding into one another. They’ve also considered splitting analytics front end and analytics platform into two separate MQs.

Of these two, I support the second. With the rise of ‘The Franchise Model’ and the Return of Governance, comprehensive platform capabilities are rapidly becoming more important than having the prettiest dashboard. The current BI MQ is really tailored to the Tableau era and is heavily over-weighting the dashboard building experience for data analysts. I believe Gartner should either split these into separate categories, or at the very least re-weight the current MQ to give more credence to metrics layers, composability and platform capabilities.

I went into this conference believing a significant MQ shakeup is coming, and the perspective Gartner shared reinforced it. I wouldn’t expect a huge change this year, but 2024 feels like a big one to me.

One last thing on the MQ presentation - while Gartner didn’t say ‘Tableau is dead,’ they did mention that it’s under enormous pressure from Power BI and too expensive at scale. Being the best viz tool is not going to be sufficient in the 2020s I suspect.

Final thoughts

This was my first time at Gartner, and I had a blast. As someone from Michigan, going to Orlando in March is a default win. I know people have mixed feelings about Gartner, and I’ve certainly had my share of grievances over the years. But attending the conference gave me a different perspective and more appreciation for their research and what they bring to their clients. Unlike most other data conferences, this really was driven by Gartner analysts and customers as opposed to vendors and it showed.

Overall I was happily surprised by Gartner’s evolving perspective on analytics. I have been preaching the critical importance of analytics practice design, composability and metrics governance for years. During most of that time it felt like Gartner was on a different wavelength, but we seem to be coming more into alignment. My biggest takeaway for you is that it’s time to start thinking big picture again about your data practice design, embrace the modern data platform approach to analytics and think about how you can partner with the business to deliver real value, not just dashboards.

The thing about events like this is they are hard to unpack in the moment. What seems inevitable in hindsight is only visible beforehand to those with incredible foresight. I am not one of those people - but I’m lucky enough to know them.

Which is why I’m sending out this brief update. It just so happens that we have Lauren Balik and Mary MacCarthy - aka The Tech Bros - scheduled to appear on Super Data Show this week. Lauren and Mary have been sounding the alarms about the venture funded data industry for a long time now, and do have the vision and knowledge to help you understand what is happening, why it happened and what impact we can expect as data people.

So join us LIVE at 12:00PM Eastern this Wednesday, March 15th for an hour long livestream to get your questions answered, or catch it on demand on YouTube. It’s a wild and scary week in the data world and while I don’t think The Tech Bros will offer us much comfort, they will give it to us straight.

PS. I’ll just say one more time about Lauren and Mary - their show is ridiculously good. I can’t think of a better set of guests to have on Super Data Show this week and I hope you get a chance to tune in.

PPS. The implications of hosting this podcast on the Ides of March is not lost on me. Et tu Jerome Powell?

By better aligning the presentation style of your data front end with the way it’s supposed to inform or influence people - ie, its purpose, you can deliver more timely, better received and more important insights. I call this presentation-purpose fit. Embrace it as a key to justifying data spend in the tough economic conditions of 2023.

What is Presentation-Purpose fit?

This isn’t a new concept exactly. ‘x-y fit’ is most commonly seen as ‘product-market fit,’ which describes the alignment between a product’s features, pricing, delivery model, etc… and the needs of the specific market it is trying to serve. If you’ve ever worked at a startup - or been within 50 feet of someone who has - you’re familiar with this term. Extending this idea to the data realm gives us presentation-purpose fit.

Presentation - Purpose Fit is the alignment between the presentation style of data and the specific business needs the data seek to address.

When presentation-purpose fit is high the data is well received, easily understood and does its job supporting business goals. These presentations of data satisfy needs of the business and lead to high value ad-hoc questions and business action.

When fit is low, data is poorly received, confusing or seldom used and fails to support business goals. These presentations leave the business no better off than before and lead to low value ad-hoc questions and frustration on business and data teams alike.

This emerges from product and design thinking, in which you focus tightly on your audience, understand them as people, build positive feedback loops between users and developers and iterate through hypothesis about what will serve them best until you achieve a tight coupling between what they need and what you actually produce. There are dozens of books about this process - I was first introduced to it in The Lean Product Playbook1 by Dan Olson, which changed my thinking about BI forever.

We’ll be discussing presentation-purpose fit and how to build useful analysis that go way beyond dashboards on this week’s episode of Super Data Show, Thursday, March 9th at 12:00PM Eastern.

Advantages of high presentation-purpose fit

This isn’t something you can achieve overnight - it’s a process that requires a shift in your delivery model, attitude and relationship with users. It’s hard, but worth it. Here are just a few things to expect as the benefit of all this effort.

Drive actions with data

The first thing high presentation-purpose fit delivers to the business is obvious next actions. This is the holy grail of data teams IMO, because the impact - and thus the justification for your budget - is immediately felt. It’s easy to identify the big wins here - running a successful new marketing campaign based on a clever analysis, for example. But sometimes the impact is simply to spur an intelligent follow up question someone wouldn’t have thought of otherwise. That’s an important action too.

Reach the right audience with the right message

When you align the needs of your audience with the content and style of your reporting and reach the right person at the right time with the right message something magic happens - a heady mixture of joy, relief and action.

Reduce wasted effort

Too often data teams put enormous effort into a front end that, ultimately, nobody uses - most commonly an abandoned dashboard. By finding presentation-purpose fit your efforts align with the needs of the moment. Complex dashboards are fine when called for, but in many cases you’ll find a simple data set or even single chart with a written explanation takes way less time and has immediate impact.

Align high value ad-hoc vs low value ad-hoc

I often talk to data teams that feel so inundated with ad-hoc questions that they can no longer contribute to the strategic mission of the company. They only exist to pump out simple answers to repetitive, one-off questions. One person told me they felt like a ‘chart monkey,’ which I’m sure is a horrible feeling. The first step to solving this is learning to distinguish between high and low value ad-hoc questions.

High value ad-hoc questions deliver insights that materially improve business outcomes. They may require new ways of thinking supported by new data pipelines or metrics. They lead people to take action. High presentation-purpose fit leads to high value ad-hoc questions.

Low value ad-hoc questions aren’t unimportant, but they don’t have a large impact on the business. These are often reconfigurations of existing knowledge to show a slightly different slice of the business. Think, ‘Can I see this metric by quarter?’ Low presentation-purpose fit leads to low value ad-hoc questions.

Low value ad-hoc drives a huge amount of data team frustration and wasted data spend. Improving presentation-purpose fit will lower the volume of these questions by heading them off at the pass. Once reduced, the rest can be shunted off to self-service while your team focuses on high value ad-hoc.

Finding presentation-purpose fit

Finding presentation-purpose fit is a process that applies product thinking to evolve how you deliver business intelligence and analytics. The unsatisfying - to some - answer is that it’s both art and science. You need to develop a repeatable process that starts with user needs and works backwards to how you present the data. You also need to deeply understand the communities that consume your analytics to develop intuition about their needs.

The single most important thing you can to do improve presentation-purpose fit is to work backwards from user needs to data, rather than forwards from whatever data happens to be available!

While it’s best to approach this in a systematic way as part of a rethinking of your analytics practice (which I can help with, message me!) there are practical questions an individual can ask to start developing better presentation-purpose fit today.

1. Do I know how this data requests contributes to the company making or saving money (the ultimate ROI justification!)

2. Am I working backwards from user needs to determine my design, rather than forwards from what data happens to be available?

3. If I had to sell this report as a product, would my end users choose to buy it? Why or why not?

4. Have I really understood the motivations of my users and what drove them to request this data?

5. What real world action will they take based on what I’m presenting?

6. Do I know the ultimate purpose for this data - or just a step on its journey?

7. Does everything in my report communicate something important? Is there fat to trim?

8. Have I reckoned with how Excel fits into what I’m building (It’s always the elephant in the room?)

Ultimately, product thinking in data is about creating data products that delight end users. ‘Delight’ is a very specific word and feeling that describes the joy felt when one unexpectedly discover exactly what they needed. In the context of BI, our product is the front-end presentation of what may be a long, complex data transformation process. If you fail to build a delightful front end, all of your backend work may be wasted.

Subscribe now

Presentation-purpose fit for dashboards

Alright enough theoretical stuff - let’s look at an example. This is probably the single worst offender of presentation-purpose fit in the analytics industry - the dashboard. Analytics environments are often so littered with derelict dashboards they resemble the aftermath of some great, grinding battle. Why?

Why do you build dashboards nobody cares about?

Because that’s what people ask for, what they expect, what they’ve been trained to know and understand for over a decade. The logic behind the typical dashboard is simple:

1. Charts are good. We like charts.

2. However our screen is too big for just one chart!

3. If we put multiple charts on the screen, and they are at least sort of related, that will be even better!!

4. And if we can do some simple filtering, that will be best!!!

This algorithm is already running in the heads of data and business people alike, just waiting to be called forth to spit out a collection of charts that you hope will move the needle. The challenge is that a dashboard is a tool; when perfectly applied to its intended uses, it works brilliantly. When applied to things it’s just okay at, your results are just okay. When used irresponsibly and haphazardly, you get maimed.

What are dashboards for anyway?

To properly use dashboards, you need to understand when they are most effective. A lot of this thinking goes back to Stephen Few among others. What are the key aspects of dashboards and what sort of usage do they suggest?

• Dashboards give a high level view of many metrics at once.

• The use of position, color and sequence can show relationships between the metrics

• When showing time variate data, they can suggest correlation between metrics

• Basic filter controls allow for a degree of governed self-service exploration

Considering these characteristics in the context of presentation-purpose fit, we see following:

Perfect fit: Operational oversight

This is the grand purpose of the dashboard - to give you a single screen to that tells if something is going wrong in the real world that contains the information you need to take action. The further you get from tangible, understood, actionable processes - whether physical or digital - the further you get from the platonic ideal of the dashboard.

Acceptable fit: Executive reporting, guided slice-and-dice

You may be surprised to find executive reporting here. I find that executives often want deeper answers than fit easily into a dashboard, and they don’t typically use them to make decisions2. Instead I would create a standardized notebook of the metrics an executive cares about and prepare written summaries of what changed and why that can be presented to them at a regular interval. Still, it’s not a terrible use of the dashboard format.

Looking to take your BI to the next level? The Super Data Brothers are a dynamic duo that applies presentation-purpose fit to every project and builds business intelligence systems that have real impact. Contact us to learn how we can help.

Slice-and-dice is another area where dashboards are an okay solution when paired with the ability to easily jump to self-service BI or excel. A well built dashboard with a reasonable number of filters provides an analyst the ability to identify the right direction for further inquiry. High level analysts will be better served going straight to the data, but for some a dashboard is a reasonable place to start. There are better solutions though.

Poor fit: Everything else

The worst offender here is using dashboards as a storytelling interface for high value ad-hoc requests. It’s just hard to explain what was done, why and what should come next in a dashboard. On the other end of the spectrum, sometimes you really should just send someone a screenshot of a chart, or an excel sheet, or give them a table. A dashboard is an extremely overcomplicated response to simple data requests.

How to know if you’re building a bad dashboard

There are a few telltale signs that the dashboard you are building has poor presentation-purpose fit.

• You have no idea what real world actions someone would take from looking at it

• There doesn’t seem to be any theme or relationship between the visualizations

• You struggle to find charts to fill the space or

• You struggle to fit all the charts into 10 tabs

• You add dozens of filters

• You’re just building a dashboard because the business explicitly requested one

• You know everyone is just going to dump this to excel anyway

These are all individually red flags and in combination are probably a sign that you need to step back and ask yourself - should this be a dashboard? Do I fully understand what real world impact this data demands? Is there a more elegant, focused way to present this data?

Presentation-purpose fit in action

This blog post is long enough - hopefully I’ve introduced you to this concept, convinced you that it’s important and spurred some thoughts on how you can improve presentation-purpose fit to deliver more impactful analytics, save yourself wasted effort and improve the ROI of your data team. I’ll write more about this topic in the future, but for now here are a few examples of use cases and the presentation style I would recommend to quickly increase presentation-purpose fit for your analytics front end.

The future of Business Intelligence: Meet the Data Tree

So how does this metaphor actually work? Unlike the one-way supply chain of data, the growth of the data tree is fed by insights generated at the edge. That’s what powers the whole system.

• The roots are your source systems, which feed raw data nutrients into the data tree.

• The trunk is your centralized data platform and metrics. It supports the system with standardized, trusted data and components

• Each individual branch is a domain or department, which grows towards the sun in an autonomous way.

• The leaves are individual data products or uses. They could be data sets, dashboards, data apps or ML models.

• The sun is the light, the insight, the business value that drives the whole thing. All aspects of the data tree grow towards the light.

When it’s laid out this way, you can see how the conversion of nutrients to food - raw data to insights - happens at the edge, but how that insight is fed back through the whole system to power growth.

This is why I like the tree metaphor. It’s living, breathing, organically growing thing that seeks the light autonomously but supports the whole. I envision a future of many organizations planting small trees and watching them grow into a mighty forest.

Properties of the data tree

If we extend this metaphor to the aspects of a BI tool, some properties of the ideal platform begins to emerge:

• Balanced: A data tree that outgrows its roots simply falls over. Wave 3 of business intelligence is about a balanced approach to insight generation and distribution. It is not focused on needless growth and does not derive its value from the sheer amount of charts created, but rather its veracity and total value added.

• Circulatory: If sap flows in only one direction the data tree dies. Wave 3 must support bi-directional interaction with decision makers and downstream systems to create feedback loops to drive growth and change. This must be built into the DNA of the tool.

• Branching: A data tree takes many branching paths towards the sun. Wave 3 supports many uses via the traditional BI experience, but also composable and embeddable components, API-first integration points and flexible presentation layers to do more than churn out dashboards. It enables individual departments to grow at their own pace and direction.

• Rooted: Just as a data tree grows best in great soil, Wave 3 requires an accurate foundation of clearly defined, valuable metrics that can feed any upstream process - whether that’s traditional BI, AI/ML or analytic/operational apps. These metrics are the foundation of balanced self-service.

• Adaptable: In the forest or in a manicured lawn, a data tree adapts to and exists in harmony with its surroundings. Wave 3 tools are multi-cloud or on prem. They support SQL and python, code and UI. They adapt to their environment.

• Resilient and self-healing: A healthy data tree withstands the storm and heals any damage. Wave 3 tools require observability to alert when something is broken and proactively heal when possible.

The data tree is organic and long-lived. It provides balance between governance and speed by building a circulatory system to easily incorporate self-service insights into the centralized metrics store. The trunk of the system is crafted by the data team while the branches are allowed to grow toward the sun in the most efficient way possible. The nutrients they generate (in the form of important metrics) are fed back into the whole.

Want to talk about this live with me? Tune in Thursday, 2/21/2023 for the Youtube livestream, or watch the replay later.

How does this manifest in BI Wave 3?

So what the heck does this actually mean? The biggest set of changes I see coming for Wave 3 is the backswing of the ‘centralization - distribution’ technology pendulum into a place of balance, where the BI tool is a self-service insight generation platform that easily feeds into other important data processes, instead of being a black-box end point for the data supply chain.

People are always going to do stuff in BI that you didn’t plan for. It’s the easiest place for business people to work with data1 - they cannot be building data pipelines or building views in Snowflake. However, you still need their insights to permeate the data practice, upstream, to deliver value in AI/ML and apps. Therefore, you need a BI tool that can serve as a foundation for that process without having to engage in heavy, centralized data engineering tasks.

This is the virtuous cycle that Wave 3 BI tools need to unlock to break the supply chain of data wide open. I call this the ‘circulatory system of data.’ Insights are generated at the edges and incorporated into the whole with as little friction as possible. The value is created by the ability for an insight generated in one part of the business to be quickly and accurately incorporated into the whole. It ensures a proper flow of data up and down the stack and across the org.

To support this the platform must grow beyond just presenting dashboards. It needs to have an open, headless metrics store to feed AI/ML and apps. The APIs must be bi-directional so that these downstream uses can feed data back into the system to seamlessly integrate with BI. And the whole thing must be wrapped in analytics-as-code to unlock scale and consistency.

What about AI?

This is the elephant in the room and probably the thing you expected as the future of BI. Until recently I would have told you that AI is really not going to be a part of Wave 3 BI systems in a meaningful way. I have watched IBM, Microsoft, Tableau and every other major vendor struggle to implement NLQ and data science features that anyone cares about or even uses. They make great demos and they all fail with real world users. People just don’t like or trust these types of systems. Thoughtspot is perhaps the exception but it doesn’t seem to have set the world on fire.

But then ChatGPT happened, and everything changed. It is very impressive at summarizing existing knowledge and presenting users with confident sounding, usually correct-ish answers. I do think it will become a powerful tool in the arsenal of BI, but there are a few caveats:

• Data quality is going to matter even more than it does today, because of how compelling ChatGPT’s answers sound to humans. If your data sucks, it will very confidently give you sucky responses.

• A lot of firms may have very poor training data that results in very poor performance and a very bad initial impression.

• It’s most impressive initial uses will be to help developers and engineers design and code systems. It can generate usable SQL and DAX, for example. Developers using ChatGPT will be very productive.

• There is going to be a major ‘trough of disillusionment’ with this tech when it gets widely implemented in BI and 3% of its answers are egregiously incorrect but sound great. It’s fun and funny as a Google replacement, but any error rate at all is unacceptable for systems that have major business decision making impact.

Fundamentally, AI-driven BI will struggle with Wave 2 data because the just-in-time supply chain of analytics prioritized speed over quality, especially at the pipeline level. How is ChatGPT going to make sense of your 1700 table Snowflake instance where the same metric appears in slightly different, nuanced ways in 53 tables? It’s not.

To make the best use of AI-driven BI, you’re going to need the Wave 3 features I described above to feed the system high quality, up-to-date and consistent metrics. Otherwise it’s going to spit out junk. But I do now see how it’s going to be a major factor going forward, once we get past the growing pains. However the future is hazy on exactly how this is going to play out, so I set it aside as its own separate thing for now.

Is anyone actually building this stuff now?

Yes! There are bits of this being done across lots of interesting tools. Some of them you know well, others you’ve never heard of. Nobody is doing all of it, but some players are close. For true enterprise adoption, someone is going to have to provide all or most of these capabilities in a single package. The ‘Modern Data Stack’ approach of point solutions for every component of the data supply chain works for that metaphor, but it runs into serious issues when you have a large organization to support. It’s just too hard for a huge firm to onboard 17 best-in-class point solutions to get a functioning analytics practice.

Better to have a single BI platform built of composable, code-first features that can fit into many use cases, both traditional dashboarding and AI/ML apps. And that’s what we’ll discuss in part 3 of this series - what interesting tools and platforms fit into this vision of the future.

Well… how did we get here? A history lesson

Before launching into what the next platform looks like, we need to cover a little history. This is more than just stage setting, as forgotten elements of past BI paradigms are poised to make a comeback and understanding how they arose and why they were (temporarily) discarded will be crucial in using them again without replicating the mistakes of the past.

Wave 1: Enterprise reporting

Wave 1 of business intelligence1 emerged thanks to the web browser and corporate intranet in the early 2000s. Like most IT technologies of the era, the goal was to migrate a real world process into the digital space largely as-is while relying on the scale and speed of the web to deliver value. For BI, this meant taking the form factor of the paper report - headers, footers and a table of numbers - and moving it to your computer, available on demand or via scheduled email distribution. This alone was revolutionary.

A curated library of insights

The key advancements of wave 1 allowed a centralized team of skilled data professionals to build a rock solid, large scale report distribution system that served tens of thousands of people with curated and accurate metrics. Some of these are:

• Centralized metrics modeling: The ability for the IT team to define a single metadata model that provided metric consistency across potentially tens of thousands of reports.

• Variable prompts: The ability for the end user to provide variable values at runtime via a series of cascading UI elements like pick lists, radio buttons and date selectors. Coming from a world of paper reports this was pure magic.

• Bursting: The automatic, mass scale generation and distribution of parameter driven, personalized reports to email via pdf.

• Server based architecture: When managed by a skilled administrator, these systems provided a consistent experience for all users with high uptime, and enabled centralized processing with vastly more power than was available on a user’s machine.

• Centralized security: Because everyone accessed the BI system via the browser with no desktop component, security was applied consistently to all users. Security was done at the folder, report, object, table or field level. Turtles all the way down.

• Observability and audit: The system kept a comprehensive record of who logged in and what they did in each session, as well as capturing the identity of burst report recipients.

Subscribe now

This all sounds great, and it was! As someone who built these systems I can assure you, they continue to deliver exactly what I describe above at a level of sophistication that is sometimes shocking to people in the startup space today, where this suite of capabilities would require 5 products and a lot of custom code. However, big changes were afoot in the early 2010s that would quickly brand this way of working with the dreaded ‘legacy’ epitaph.

• A generalized move away from attempts to mimic the pre-digital world and into what we’d now call ‘digital native experiences.’ In the case of BI, this meant abandoning the ‘report’ form factor which mimics a sheet of paper and adopting the ‘dashboard’, which is native to the computer screen. This is also where you see the move from tables of numbers to visualizations.

• Wave 1 BI was powerful, but it was slow. Everything ran through the IT data team as the developer tooling was too complex for business people to use for even the most rudimentary purpose. Simple requests like updating a calculation would sometimes take months or even years as they languished in a ticket backlog.

Wave 1 BI was great at answering well defined, agreed upon questions and distributing those answers to a huge audience. But when it comes to speculative data exploration or situations where you need data to make a decision now, this approach simply didn’t work.

This is, of course, where Wave 2 enters the scene.

Wave 2: Desktop data discovery

Wave 2 of business intelligence came hard and fast and in the form of a plucky visualization tool called Tableau2 that a reasonably data savvy business person could install on their desktop and, in a few hours or days, turn out a great looking dashboard. It was everything Wave 1 was not - highly visual, decentralized, easy to use and built for a digital-first world. This way of working ate old-school BI’s lunch over the 2010s. Let’s explore why.

Power to the business people

There are many important software features that help explain the rise of Wave 2 BI, but nothing is as important as the culture shift it kicked off in how we build analytics - decentralization and business control. This enabled two key things:

• An end run around IT: Tableau was easy to use compared to wave 1 and could be procured as a desktop tool with just a few licenses. This meant a department or even a single individual could start churning out analysis without IT involvement, skipping that interminable ticket queue entirely.

• Analytics by the analysts: By moving the BI function to data analysts, Tableau enabled the people who actually understood the data to explore and report on it in an intuitive, visual way. This lead to a huge productivity increase compared to Wave 1, which split this function between business and technical experts.

Connect with me on LinkedIn

These two points are critical in understanding why Wave 2 was so successful. I would often tell IBM Cognos departments quite bluntly, ‘Tableau’s number one feature is that your users don’t have to call you to use data in their jobs.’ People didn’t like hearing that, but it was true.

As far as specific features of Wave 2, the critical ones are:

• Visual and digital first: Wave 2 tools are built for visual data exploration and dashboard-style reporting on computer screens. They aren’t trying to mimic anything in the real world3.

• Way better graphics: There was just no comparison between Wave 1 and Wave 2 when it came to the looks department. Tableau is really pretty.

• Analytics at the edge: Building a desktop tool in the late 2000s was a bold thing to do. The ethos of the era was to push as much compute as possible to a centralized server and rely on an IT team to manage it. Wave 2 could be productively used and managed on a single analyst laptop.

• Workbooks: Wave 2 took the workbook format of Excel as it’s organizational principle, which was already the default mode of content management for most analysts.

Wave 2’s apotheosis came in the form of Power BI, which took the Tableau formula and made it faster, easier and - most importantly - cheaper. All of this adds up to an easy to acquire, easy to use tool that requires little to no IT oversight and, in the hands of a smart analyst, can deliver great looking visuals quickly. This model was and is extremely successful at churning out data content. But as we’ll see, it’s run into significant challenges now that it’s become the ubiquitous, default mode of BI.

The data supply chain theory of value is collapsing

The most commonly held purpose of Business Intelligence is to deliver timely insights to decision makers, and the most popular metaphor for this process is that of the supply chain. Source systems contain raw materials; data engineers refine these raw materials into usable components and store them in a warehouse; data analysts assemble the components into insights and deliver them to decision makers, who then do with them what they will.

This is data as logistics. It starts with raw materials mined from the digital records of real world events and flows in one direction to the decision maker. The job of the analytics practice is to make this flow as smooth and timely as possible. In this world, empowering the analyst with great tools generates tremendous value because they are close to the decision, understand the data and can manage ‘the last mile’ of ensuring each insight is accurate and arrives at its destination in time to make a decision. What they require then is maximum autonomy to manage the last mile independent of upstream processes. This is Wave 2’s theory of BI value. Get the right box onto the right porch at the right time and do it as efficiently as possible.

Wave 2 BI tools are the world’s most efficient insight delivery truck.

If the metaphor is accurate - and I think it does describe the status quo nicely - it also comes with the same issues as the modern day supply chain. The evidence of this is all over:

• Warehouses full of unused, unwanted data products that nobody asked for - or even worse, that they did ask for but turned out they didn’t at all need

• Brittle pipelines that fail when the system dynamics change

• Dozens or hundreds of dashboards or tables that show slightly different slices of the exact same thing

• Conflicting records or metrics with no easy ability to discern which is accurate

• Extreme duplication of work as data content or metrics are impossible to find and thus recreated over and over

So why is Wave 2’s theory of value collapsing? We’ve squeezed the lemon dry in terms of wringing additional advantage from delivering hopefully accurate, probably necessary, usually pretty dashboards to decision makers as quickly as possible. This did create tremendous value, but the business world has adjusted to this value and is now asking ‘what’s next?’ Just as you and I have adjusted to the novelty of Amazon delivering any cheaply made product on our doorstep in two days. The advantages of the system have been fully metabolized and the disadvantages and contradictions are becoming more and more clear. Wave 3 is on the horizon.

Wave 3: New tools, yes. But also a new metaphor

At the beginning of this post I used a word I’m told is unfamiliar to people who didn’t study Shakespeare4 or medieval history in college: Interregnum. This is the time between the death of the old king and the crowning of the new one. It’s a dangerous time, but also a time of wild possibility where the old order is upended and the powerful vie to define the new one. The emerging BI regime will be defined by new tools, but also a new philosophy of delivering value with data. And hopefully a new metaphor for how we do it.

What are the signs of the interregnum? During the peak years of a technology wave, there is so much value to be gained simply riding the wave that nobody challenges the prevailing order. Power BI - unquestionably the top BI tool in the world as I write this - emerged in the 2010s as a cheaper option to deliver the analytics supply chain. It challenges Tableau on price, but otherwise follows exactly the Tableau playbook.

As the wave nears it’s end, wild alternatives that attack specific weaknesses in the prevailing order start to emerge, as we see today. There has been a ton of interesting innovation in the BI space the last few years, but they are all point solutions attempting to solve specific, narrow-scope problems. They do it elegantly and create important new ways to tell stories and collaborate with data, but they aren’t trying to upend the enterprise BI market and it’s hard to see how they could evolve in that direction.

In fact the last truly important large scale BI tool was Looker, which was founded in 2012 during the transition period from wave 1 to wave 2 and has important elements of both built into it - combining enterprise metrics and modeling with an easy visualization layer. It’s been 11 years. It’s time for something new.

The value of a good metaphor

To successfully transform how we do business intelligence, we need more than just new technology. We need a new metaphor that puts in simple terms how the technology delivers value. The metaphor drives innovation by telling software vendors where and how to invest. It guides practitioners by telling them how to conceive of their data practice. It drives the culture of data teams. Until the post-supply chain metaphor emerges, we’re sort of grasping in the dark. I have some ideas what it should be.

Where do we go from here?

So, things are changing for analytics practitioners. It’s both scary and exciting. As someone who has been through one sea change before, I look forward to greeting the future as it arrives. Here on Super Data Blog we’re going to explore what that looks like in upcoming blog posts, as this one is long enough already! You can expect:

• Part 2: The new BI and Analytics metaphor: Not a supply chain, but a tree

• Part 3: Evaluating the tools of the future - who is moving in the right direction?

• Part 4: How is the data team going to change going forward?

Let me end by asking you - what are the biggest challenges in analytics and business intelligence right now, and what do you hope the future brings?

Hey - you made it to the end! There must be something you liked here, why don’t ya go ahead and…

Subscribe now

So in this post I’m going to take a look at how to pair a modern BI tool with your data mesh implementation to seek the BI product-market fit that will make your shiny new mesh obviously superior to what you had before.

Traditional BI doesn’t fit well in a data mesh

To understand why the leading BI tools aren’t great fits for a data mesh, we have to consider their purpose: To enable data analysts to generate dashboards and visualizations as quickly as possible. This is a laudable goal as speed is an important component of the coveted ‘agility’ that all teams seek. However data mesh isn’t about building useful charts or ML models, it’s about delivering data products that delight people. Products are built, tested and refined with a particular audience in mind, and the feedback from that audience drives further development of the product. Churning out dashboards is a poor way to achieve product-market fit for your BI, in part because that ‘supply chain of data’ methodology is typically a one way street. Data flows to the dashboard, and what happens to it after that is anyone’s guess. It doesn’t evolve over time.

In particular, tools like Tableau and Power BI have the following less than desirable downsides for a data mesh:

• Rigid, manual and UI-based development and management. Hard to automate.

• APIs are an incomplete afterthought

• Metrics sharing between BI and ML or business apps is very challenging

• Don’t fully integrate into CI/CD

• Lack of composability severely limits usefulness

• Encourage a one-way trip for data with no built-in feedback mechanisms

Why are these issues? Because the way BI fits into a data mesh, as I envision it, is by combining a composable, scalable and flexible front end with code-based automation and a universal metrics layer. This makes it easy to automate the creation of BI assets for existing and new domains and data products as they shift over time, while serving BI, AI/ML and app dev use cases with high quality components and metrics.

How this would work is as follows:

• A central team creates BI assets for use by any domain. These are data-agnostic features that can be customized by a data product team using code.

• Domain teams use these components to present a BI front end alongside their data product, as well as a utilizing the metrics layer to provide SQL and API access to their metrics.

• Downstream consumers - meaning other domains, data scientists or self-service users - can customize these components for their own uses.

The key thing is that changes can easily flow up and down the stack via the application, not a centralized manual process. Imagine a self-service users develops a new metric. Rather than that being locked in the BI layer - as it would be today - it can easily be added back to the data product, where it is immediately available for use in other applications or federation to other domains. No widely adopted BI tool works this way currently.

What is GoodData?

Which brings us to GoodData and why I think their approach is better suited to data mesh implementations or companies adopting product thinking for BI. They first appeared on my radar thanks to their universal semantic layer. Semantic layers are an old idea that have suddenly flared back to life, and something I spent a good deal of my earlier career building. We started working together and after learning about their overall approach, I felt that GoodData could do a lot of what I envision thanks to the following features:

• Everything in GoodData is code and manageable via modern devops practices.

• GoodData has workspace inheritance, which allows changes to flow from canonical, domain managed data products down to self-service environments, and back again.

• GoodData’s semantic layer ensures that metrics are consistent across use cases and can be easily federated and calculated between domains.

• GoodData supports both API and SQL access, which satisfies your data analysts and data scientists alike.

• GoodData can be deployed anywhere via kubernetes.

Okay that sounds great - but what do these features actually enable?

GoodData is ‘The Switzerland of Analytics’

One important benefit of Data Mesh is that, as envisioned, you reduce the reliance on monolithic cloud platform vendors by offering flexibility to your domain teams in terms of what tech they use. GoodData is architected from the ground up using industry standard devops practices and runs on any cloud or on-prem. It’s not designed to lock you in to a specific tech stack, push cloud CPU spend or favor one vendor ecosystem over another. Basically, it plays nice with everyone. Even in situations where GoodData would classically be viewed as a competitor - say, vs other BI platforms - their open, API-based architecture allows you to combine tools as you see fit. Already use Snowflake and Power BI? Great - maximize those investments by providing industrial scale metrics, discoverability, composability and an API-first experience with GoodData. You are free to mix and match the tools and approaches that work best for you.

API-first with massive customization at scale

A properly built Data Mesh requires a BI layer built on modern technology with a modern software development workflow. GoodData supports this today -  everything in GoodData is code that you can manage using devops best practices; metric models, visualizations, dashboards, workspaces, security and capabilities - all can be programmatically generated and are ready for CI/CD. Furthermore, their API-first approach using the GoodData.ui react SDK enables your app developers to easily query high quality metrics or embed visualizations and analytics components into any downstream application. This means that you can automate the build out of BI, metrics, security, etc… so that new data products can be supplied with standardized, high quality front end components on demand with little to no manual work.

Front end agnostic, Bi-directional metrics layer

One huge challenge for legacy BI applications operating in a Data Mesh is metrics lock-in. Self-service users may utilize the BI front end to combine domain data and produce valuable new insights, but those insights are stuck in BI and it’s quite challenging to extract them for uses in AI/ML or analytics applications. Not so with GoodData, which has a headless metrics layer and a suite of SQL and API access points. Insights uncovered by data analysts can be easily added to the metrics library and made available to developers across the company through their interface of choice. This significantly eases the burden on data engineering and ensures data quality and federation across the mesh. This can even be integrated into downstream operational apps, so that actions take by end users are automatically pushed to the metrics layer and made available to all. 

Simple self-service platform management

Data mesh doesn’t decentralize everything - you still need a team providing the underlying data platform which enables the mesh. Because GoodData is code-based and composable, your platform team can easily create and maintain the core BI elements of the data mesh, while allowing each data domain and data product team to customize as necessary for their unique needs. This creates consistency in data presentation and makes it easy to learn and navigate the mesh while maintaining the highest possible data quality and security. A smaller central team can establish the core presentation and metrics layer best practices and make these available as a set of components to new data domains, new data products and any downstream application.

A flexible front end for Data Mesh

A Data Mesh is not static - it evolves over time at the speed of business. It is fast and adaptive. But it also requires a bedrock data platform upon which the mesh can be built, like a painter requires a canvas. Fundamentally the appeal of GoodData in a Data Mesh is its ability to offer flexibility to domain teams and support all self-service and analytic uses while making it easy for the data platform team to create high quality, standardized and reusable components that satisfy the requirements of BI, AI/ML and downstream applications.

Most existing BI suites are not tailored for this kind of environment. They exist solely as an endpoint for distributing charts broadly throughout the organization. They are hard to scale and manage. They are uni-directional and lock insights into proprietary metrics layers, and they don’t play nice with non-BI use cases. Certainly Tableau or Power BI can be a useful front end for a data mesh, but in my opinion they can’t be easily integrated as an important component of the mesh itself. GoodData can, and that’s what really got me excited about it’s potential going forward.

The end of a way of life

Is Tableau dead? In the most obvious sense, no. The tool is not going to cease functioning tomorrow. It’s not going be replaced by a hot new startup anytime soon (though Power BI is an ever-growing threat). Tableau experts are not going to be suddenly unemployable.

But in a very real sense, the Tableau era is over. Starting roughly in 2012, the standard ‘supply chain of data’ approach to analytics picked up increasing steam. The focus of your average data team shifted to building pipelines that transform and move data as quickly and cost effectively as possible to a place where a data analyst could churn out dashboards and charts. This is where Tableau shines, and it was quickly embraced by creative people who made a lot of amazing, beautiful stuff.

However, we’ve squeezed all the juice possible from that lemon and the limitations of the one-way data highway that ends in a dashboard are becoming clear. You can see this in the exploding conversation around soft-skills, data quality and product-market fit for data teams. There’s a pervasive sense that we should be delivering something else, something more valuable built on better, more trusted data. Nobody knows exactly what that is yet but we can deliver it by being ‘closer to the business.’

And this gets us to the crux of the question - what does it mean for Tableau to be dead? It means that there’s a widespread recognition that the way of thinking about and doing analytics that Tableau ushered in is in need of modernization. It means that there’s a ‘next’ coming, just far enough beyond the horizon that none of us can see it yet. But we know it’s there, waiting for us.

This is scary, no doubt. But as someone who has been through it once before, let me assure you, not only will we be okay - we’re all coming out ahead when this shakes out.

Time is a flat circle

If you’re under the age of maybe 35, you don’t remember a world where Tableau and the Tableau way were not the standard operating procedure for data teams. For the rest of us, there is a faraway, hazy memory of an era populated with on-prem data warehouse appliances, powercenter ETL scripts and a big, beefy Cognos or Business Objects BI front end.

I can remember vividly when Tableau started taking my customers, one after another. And of course there was the disaster of the 2016 (I think) Gartner Magic Quadrant for BI, where the longtime leaders suddenly found themselves relegated to also-rans in the eyes of analysts. IBM began their valiant but ultimately doomed effort to incorporate the Tableau way into Cognos in a manner that would reverse the tide.

It was stressful, and I worried a lot about what I was going to do going forward. Would my skills be useless in short order? Should I just learn Tableau ASAP? I can tell you, in the end I didn’t become a Tableau expert - I was frankly never going to be as technically proficient as I was at Cognos, where I am very, very good. Instead I took everything I learned and started thinking higher level, more about project, practice and culture design. It was a great transition for me.

What can you expect from a ‘dead’ Tableau?

A dead Tableau will continue to be - pound for pound - the best dashboard and visualization building tool, possibly forever. Just as Cognos is still the best paginated reporting tool. There are going to be huge numbers of great jobs out there for Tableau pros throughout the 2020s and you’ll be able to make a lot of money using those skills. There is no need to panic.

I do expect some negative changes to pick up pace over the next few years though:

• Salesforce will invest less and less in Tableau over time. The pace of improvements will slow, the customer experience will diminish and the community support will drastically fade.

• The roadmap is going to get confused. It will align more and more with the overall Salesforce direction and less and less with the specific needs of the platform-agnostic analytics market.

• There will be other tools and approaches that pick up steam. Maybe Count with the data canvas, or one of the BI notebook companies will hit big. But something will come along and Tableau will be late to adopt it and their implementation will kind of suck.

• Startups and tech forward companies will move to whatever that new thing is. You won’t have a 25 person company choosing Tableau anymore.

• However at the enterprise level, Tableau will continue to have a huge, deep pocketed customer base. They may become increasingly jaded with Tableau, but the cost of moving off for them is just huge. Cognos still has many, many thousands of huge customers some ten years after it ‘died.’

• Jobs will slowly start to move to other platforms.

This is all from what I experienced directly with Cognos. I may be off on some of the specific points or timeframes, but I expect the overall story to play out in a very similar manner.

What will Microsoft do?

From a strictly Business Intelligence market perspective, one of the most interesting questions is how Microsoft responds. Power BI came to the BI market late, but thanks to pricing power and the ubiquity of their technology (and sales teams) across all industries it’s moved into the dominant position these last few years.

Microsoft does not have to lead on this, as they didn’t for desktop BI. They can see what new paradigms emerge and then run the Power BI playbook again. Microsoft has an obvious way to make money on whatever new BI approaches emerge simply by funneling the compute onto Azure. This is pretty much the whole reason Power BI exists in the first place.

Salesforce and Tableau don’t have this option, which puts them in a tough position and makes the level of investment needed to pivot to the changing needs of the 2020s unlikely. In my opinion.

What should Tableau pros do?

My advice is, don’t just do something - stand there! You have plenty of time to navigate whatever changes are coming. It’s going to be frustrating watching a tool you love lose its way, but I wouldn’t freak out. You can transition to other tools if you want to stay hands-to-keyboard, or you can explore what other options exist in the data space, as I did.

I don’t worry about Tableau people. The tool has attracted creative, flexible thinkers over the years, and their passion has transformed how we communicate with data for the better. People like that roll with the punches and are gonna land on their feet, no matter the landscape.

PS! You made it all the way to the end, so there must be something you liked! Why don’t ya go ahead and…

Subscribe now