You have the data. You don't have the questions. Why dashboards don't make you money

You paid for them, they’re pretty, and nobody opens them

Do an experiment, now. Open the last dashboard you had built — the one you spent time and money on, maybe with a consultant, maybe with the tool “that does everything”. Look at the date of the last access. Ask yourself who, in the company, opened it this week to take a decision. In most cases the answer is depressing: nobody, for weeks, and anyway not to decide anything.

Dashboards nobody uses are one of the most expensive and most silent failures of companies that “invest in data”. Silent because nobody declares them: the dashboard is there, it technically works, the charts update. It simply doesn’t change anything. It has become digital wallpaper: pretty, present, and irrelevant. And the frustrating thing is that the problem is almost never the data — that’s there. The problem is that the questions are missing.

And it isn’t a problem of backward companies: it happens especially to those that have invested, that took the good tool and the right person. Precisely because they did “things properly” on the technical plane, they can’t explain why the result is silence. The explanation, almost always, is that they bought answers before they had the questions.

This article is for anyone who already has numbers and dashboards but extracts no value from them, and for anyone about to hire or commission someone “to make dashboards” thinking the problem is producing more charts. Let’s see why self-service BI almost always fails, why without questions data is only decoration, how you pull out the right questions (which is work, not an illumination), and what distinguishes a pile of charts from a company data product people actually use.

The myth of self-service BI

In recent years they’ve sold us a dream: buy the right tool (Power BI, Tableau, Looker, whatever you want), connect the data, and “people will do their own analyses”. Self-service business intelligence. Democratisation of data. Every manager becomes an analyst. It’s a beautiful dream, and for the vast majority of SMEs it’s exactly why self-service BI fails.

Why does it fail? Because it assumes two things that are almost never true. The first: that people have the time and desire to explore the data. They don’t. The owner, the sales manager, the department head have a job to do, and “playing with the dashboard to discover insights” isn’t that job. The second, deeper: that they know which questions to ask. And here’s the point. Giving someone a powerful tool and a thousand data points without giving them the right questions is like giving someone a library and saying “learn”. Learn what? Where do I start?

The result of self-service is predictable: after the initial enthusiasm, almost nobody opens the tool. Whoever opens it gets lost among dozens of charts and closes it. And the expensive dashboard becomes the monument to a wrong idea: that the problem was lack of access to data, when the problem was the lack of questions the data answers. The tool isn’t useless: it’s that it arrived before the question, and without a question it isn’t needed.

Without questions, data is only charts

Let’s be clear on a distinction that looks philosophical and is actually the most practical of all. A datum is a fact: “yesterday we sold 12,000 euro”. A chart is that fact drawn. But neither the datum nor the chart, on their own, are worth anything for the business. They’re worth something only when they answer a question that precedes a decision.

“We sold 12,000 euro” is useless if you don’t know compared to what. Compared to yesterday? To the average? To the target? And above all: what will you do if the number is high or low? If there isn’t a decision behind it, the number is trivia. The healthy sequence is always: decision → question → number → chart. First you decide which decisions you take (what to reorder, who to call back, where to push), then from there the questions derive, then the numbers that answer, then the way of showing them.

Self-service and cemetery-dashboards do the path the other way round: they start from the available data, make charts of it, and hope someone finds a decision inside. It almost never happens, because it’s like building answers and looking for the questions. A dashboard born that way is technically impeccable and practically useless: it shows everything that can be shown instead of what you need in order to decide.

This is tightly linked to the problem of wrong KPIs and vanity metrics: a dashboard without questions inevitably ends up filling with the easiest numbers to show — visits, totals, averages — which are also the least tied to a decision. The lack of questions and the abundance of vanity are the same disease seen from two sides.

How you pull out the questions (it’s work, not an illumination)

The good news is that the right questions don’t arrive by inspiration: you pull them out with a method. It’s the most valuable and most underestimated part of the work, the one that turns a report factory into a data product. Here’s how you do it, in practice.

You start not from the data, but from the recurring decisions of whoever is in charge. You sit with the owner, or the sales manager, or the operations head, and you ask: “which decisions do you take every week, every month, and what would you like to base them on?”. Not “which charts do you want”, which always leads to “give me everything”: which decisions. The answers are concrete: I decide what to reorder, I decide who to give priority to, I decide if a promo continues, I decide where staff is needed.

For each decision, you dig until the question that steers it. “I decide what to reorder” → the question is “what’s accelerating and what’s slowing, by product, compared to the last few weeks?”. “I decide if the promo continues” → “is the promo increasing total margin or only revenue?”. Note that these questions aren’t obvious, and they often force you to clarify what you actually want — which is already half the value.

From a workshop like this, of a few hours, comes a list of 5–10 true questions: the ones that, if they had a reliable answer every morning, would actually change the decisions. That list, not the available data, is the spec of the data product. It’s the exact opposite of self-service: instead of giving everyone everything and hoping, you give each person the few answers they need to decide better.

A practical trick that unlocks shy workshops: instead of asking “what questions do you have?”, ask “tell me the last time you took an important decision in the dark, without the number you needed”. People remember very well the moments they had to decide by gut, and every memory is a missing question. From there you climb easily to the number that would have been needed. It’s much more effective than asking for questions in the abstract, because it starts from concrete pain instead of theory.

The questions you almost always start from

Every company has its own, but after many workshops certain questions come back almost always, because they’re born from universal decisions. Using them as a trigger helps unlock the discussion — but then they have to be dropped onto your business, not copied.

• What’s accelerating and what’s slowing, by product or line, compared to the last few weeks? (decision: what to push, what to reorder)
• Which customers are we losing, that is they used to order and they don’t order any more? (decision: who to call back)
• Where is the real margin, by product, customer or channel? (decision: where to concentrate effort)
• What’s at risk: delays, stock under threshold, deadlines? (decision: where to intervene today)
• Which promos or discounts actually work on margin, not only on revenue? (decision: what to continue)
• How are we doing today against the target and against the same period before? (decision: whether to change course)

Note that each one is hooked to an explicit decision, in brackets. A question without a decision behind it doesn’t enter the list: it’s curiosity, not a tool. The test is always the same: if I had the answer to this question every morning, what would I do differently? If you can’t answer, it isn’t a data-product question — it’s a chart looking for a purpose.

Who needs to be in the workshop room

The questions workshop works if the right people are in the room, and it fails if you send only IT or only a consultant. Who you actually need:

• Whoever decides — the owner, the managers — because they’re the ones who take the decisions the questions are born from. Without them, the workshop produces theoretical questions.
• Whoever knows the work on the ground — whoever sells, whoever produces, whoever is at the counter — because they know the exceptions and the real questions people ask themselves every day, not the textbook ones.
• Whoever knows the data — internally or the supplier — because you need to understand immediately which questions are answerable with what’s there and which require collecting something new.

Who isn’t enough alone: IT. They know how to connect and show, but they don’t have the decisions in their hands, so they can’t decide the questions. A workshop guided only by IT produces, again, technically correct charts that nobody will use. Questions are born where decisions are taken, not where databases are managed.

Every question has an owner and a frequency

A list of questions isn’t enough: for them to become a living product, every question needs two attributes almost nobody assigns. An owner and a frequency.

The owner is the person that question belongs to: the one who will use it to decide and who will notice if the answer is strange or missing. A question without an owner is a question nobody will look at — exactly like the self-service charts. “Does the promo increase margin?” belongs to the marketing manager; “what to reorder?” belongs to the purchasing manager. Assigning the owner turns an abstract number into someone’s tool.

The frequency is how often that question has to be looked at, because they don’t all have the same rhythm. “How much did we sell yesterday?” is daily; “which customers are we losing?” maybe weekly; “what’s the margin by line?” maybe monthly. Assigning the frequency avoids two opposite errors: drowning people in daily numbers that change a decision once a quarter, and hiding in a monthly report a number that should be seen every day.

With owner and frequency, every question becomes a small contract: this person looks at this number at this rhythm to take this decision. A dashboard built this way isn’t a pile of charts for everyone: it’s a set of tools, each with a master and a rhythm. And that’s why it’s used, while the chart cemetery isn’t. It’s the same principle for why hiring a data analyst without a system isn’t enough: without questions with an owner, even the best person produces reports nobody opens.

Why “adding more data” makes things worse

There’s an instinctive reaction, when a dashboard isn’t used: “maybe some data is missing, let’s add some”. It’s the exact opposite of what’s needed, and it makes the problem worse. More data and more charts on a screen already ignored don’t make it more useful: they make it more intimidating. Whoever opens it finds themselves in front of an aeroplane cockpit and closes it faster than before.

The reason is that the problem was never the quantity of information, but its focus. A dashboard that isn’t used doesn’t suffer from a shortage of data: it suffers from an absence of questions. Adding data to an absence of questions is like raising your voice with someone who hasn’t asked you anything. The cure is to take away, not to add: reduce to a few screens, each answering a question with an owner. A data product that works is almost always smaller than the one that didn’t work, because the difference isn’t in the data, it’s in the question. When someone proposes “let’s add more metrics” as a solution to non-use, they’re treating the fever with more fever.

The right order: the question before the tool

I’ll summarise the principle that runs through the whole article, because it’s the one that makes the difference between spending well and spending badly: the question comes before the tool. Always. Self-service, cemetery-dashboards, AI on the data all fail for the same reason — they put the tool before the question, and hope the question emerges. It doesn’t emerge.

The order that works is the opposite, and it isn’t negotiable: first the decisions you take, then the questions that steer them, then the definitions of the numbers that answer, then the tool that shows them. Every time a project starts from the tool (“let’s buy Power BI and see what we do with it”) or from the data (“we have lots of data, let’s pull something out”), it’s starting from the wrong piece, and the result will be yet another dashboard that isn’t opened. It isn’t a question of budget or technical skill: it’s a question of order. The same tool, the same data, the same money give you a cemetery or a living product depending on whether you start from the question or not.

From the notebook to the screen that gets used

There’s another way data projects fail, more technical but equally common: the analysis stays an analyst artefact and never becomes a product for the company. The good analyst finds the insight — “customers who buy X within 30 days are worth three times as much” — puts it in a notebook, in a slide, in an email. Beautiful. Then? Then nothing, because that insight isn’t hooked to any screen someone looks at to decide. It stays a one-off discovery, not a recurring tool.

The difference between an analysis and a data product is this: the analysis answers a question once; the product answers the same question every time it’s needed, on its own, in the place where whoever decides looks. Turning one into the other is real work — of data, of interface, of hooking to decisions — and it’s exactly the work that distinguishes an analyst who “makes reports” from an analyst who builds product.

A simple way to tell if you’re in front of an analysis or a product: ask yourself if, in six months, that answer will still be there, updated, in the place where it’s needed — or if it will be a forgotten email in an archive. The analysis ages the day after; the product stays alive. The recurring value sits in the second, and that’s why it’s worth doing the extra work of turning the insight into a tool.

It’s also why the right figure, when data has to make a difference, isn’t whoever can make the prettiest charts, but whoever can take a business question all the way to a screen that’s used every day. A rare and valuable profile, who thinks in product terms (who uses it, to decide what, when) and not in analysis terms (what interesting datum). The consulting that counts isn’t “I’ll make you the dashboards”: it’s “I’ll turn the right questions into tools people will use”.

LLMs on data: powerful, and dangerous if the definitions wobble

Today there’s a new temptation that promises to skip all this work: “let’s put an AI on our data, so anyone asks questions in natural language and gets answers”. On paper it’s the ultimate self-service. In practice, without the right foundations, it’s the fastest way to get wrong answers with maximum confidence.

The problem is always the same: the definitions. If you ask a model “how much did we sell in Milan in November?” and in the company “sale” isn’t defined in a unique way, the model will choose one interpretation — which, you don’t know — and give you a precise, plausible number, which might be the wrong one. A human who isn’t sure asks “do you mean orders or invoices?”; a model, by default, guesses with a confident tone. On data with wobbling definitions, an LLM doesn’t democratise the numbers: it democratises the errors.

This doesn’t mean AI on data is to be thrown away — it means it comes after, not before. First the questions, the signed definitions, the data product that respects them; then, eventually, a conversational layer on top, that queries numbers already calculated well with verifiable rules. The order is everything: AI on top of a solid data product is useful; AI on top of a chaos of definitions is a generator of false certainties. The shortcut doesn’t skip the questions work: it only makes skipping it more dangerous.

A typical case: the dead dashboard resurrected by three questions

A typical profile, architectural, no names. Mid-size manufacturing company, had spent well: a consultant, a serious BI tool, a dashboard with twenty charts covering sales, production, warehouse. Technically excellent. After three months, the last access was six weeks earlier. The owner was convinced they’d thrown the money into data.

They hadn’t thrown the data: they’d skipped the questions. We sat with them and the two managers for two hours, and instead of looking at the charts we listed the decisions: what you send into production first, when you warn a customer of a delay, when you reorder a raw material. From there three true, precise questions came out, which the twenty-chart dashboard didn’t answer clearly even though it had all the data to do it.

What was done: fifteen charts out of twenty were thrown away. Three screens were built, one per question, with an owner and a frequency. The “what’s at risk of delay” screen became the first thing the production manager looks at every morning. After a month they used it every day — not because they’d been forced, but because it answered a question they were asking themselves anyway. Same data, same tool: the only change was that now they started from the questions. The previous consultant hadn’t done a bad technical job: they’d done the work in the wrong order.

The hidden cost of dashboards nobody uses

Dead dashboards cost more than they seem, and on three fronts. The first is obvious: the money spent to build them, plus the tool licences you keep paying even if nobody opens them. The second is subtler: the decisions taken by gut anyway, while the answer was there, in a chart nobody looked at. Having the datum and not using it is almost worse than not having it, because you pay for information you don’t convert into action.

The third cost is the most insidious: distrust. After one or two dead dashboards, the idea spreads in the company that “data doesn’t work here”, “we’ve already tried, it didn’t work”. That distrust is expensive, because it also blocks the right projects: the next time someone proposes starting from the questions, they hit “yes, we’d tried with the dashboards”. The silent failure doesn’t stay silent: it becomes a prejudice that makes it harder to do the right thing. That’s why it’s worth tackling the problem at the root — the questions — instead of adding yet another chart and hoping.

“But we want to be able to explore”: the last misunderstanding

A recurring objection, when you propose a few targeted data products instead of self-service: “but we want to be able to explore the data freely, not only a few fixed screens”. It’s legitimate, and the answer isn’t “one or the other”. A well-made data product has two levels: in front, the few screens that answer the questions that count and that are used every day; behind, the ability to go down into the detail and explore when needed.

The difference from pure self-service is the order of priority. You start from the questions and the everyday-use screens, and exploration is an extra, not the main dish. Self-service fails because it puts exploration at the centre and the questions nowhere; a good product puts the questions at the centre and leaves exploration as a possibility for whoever, every so often, needs it and has the capacity. And there’s a detail that almost always turns out true: when people say “we want to explore”, they actually want their questions to have a ready answer. That’s what the product gives, not free access to a thousand charts to get lost in.

What to deliver: a product, not a file

If you’re evaluating a data project — with an internal or a supplier — the right question to ask is: what do you deliver me? And the answer that distinguishes serious work from a report factory is sharp. Not a file, not a slide, not “access to Power BI”: a product.

A data product, concretely, is made of:

• A list of questions with owner and frequency, which is the shared spec.
• The signed definitions of the numbers that answer those questions.
• A system that calculates the answers on its own, updating them at the right frequency.
• The screens where whoever decides looks at those answers, with alerts when something leaves the norm.
• A plan so the product stays alive: questions change, the business changes, and the product has to be updated.

Note what isn’t there: “thirty charts that cover every possible analysis”. A data product does a few things, the ones that count, and does them well. It’s the difference between a tool and a hardware shop: the shop has everything, but it’s the right tool in the right person’s hand that drives the screw. If what they propose you is the shop — “here are all the data, explore them” — you’re buying a chart cemetery. If they propose you the right tools for your decisions, you’re buying a product.

Failure signals at 60 days

How do you know, early, that a data project is becoming yet another dashboard nobody uses? There are clear signals already at 60 days, and recognising them in time lets you correct before you’ve thrown the budget away.

• Nobody opens it spontaneously. If the only moment someone looks at the dashboard is when you ask them, it isn’t a tool: it’s a task. A real tool is opened because it’s needed, not because it’s requested.
• It hasn’t changed any decision. Ask: “which decision have you taken differently thanks to this, in the last two months?”. If the answer is vague or absent, the product doesn’t work, however pretty it is.
• Charts are added instead of taken away. If the reaction to “nobody uses it” is “let’s add more metrics”, you’re diluting the problem. Products that work slim down, they don’t fatten up.
• Nobody notices if it breaks. If a number is wrong for a week and nobody notices, it means nobody was using it to decide. A number that’s actually used has someone who notices when it’s strange.
• The starting questions don’t exist. If there isn’t a written list of questions with an owner, the project started from the data and not from the decisions: the failure was in the DNA.

If you recognise two or three of these signals, you don’t need to throw everything away: you need to go back to the missing question. Start again from the decisions, pull out the true questions, assign owners, and rebuild the product around those. Almost always the problem isn’t the tool or the data: it’s that the questions step was skipped.

The owner’s role: you can’t delegate the questions

There’s a responsibility that, in all this, you can’t delegate: deciding the questions. You can entrust a supplier with the pipeline, an analyst with the calculations, a tool with the visualisation. But which decisions actually count for your company, and therefore which questions need an answer every morning, only you and your leadership know. It’s the piece of work that looks the least technical and is actually the most decisive.

This is also why data projects delegated in a block — “you think about it, make me the dashboards” — fail so often. Whoever arrives from outside can facilitate, can bring method, can build very well; but they can’t know, in your place, what keeps you awake at night and which choices you make every week. Two hours of your time in the questions workshop are worth more than months of technical work built in the dark. If a serious supplier asks you for those two hours, it’s a good sign; if they promise you the dashboards without asking for them, they’re about to build you another cemetery.

It’s for you if / it isn’t for you if

It’s for you if: you already have dashboards or reports nobody opens; you have “lots of data” but you still take decisions by gut; they sold you self-service BI and after the initial enthusiasm everything is stuck; you’re about to commission someone “to make dashboards” and you suspect the problem is something else.

It isn’t for you if: you already have clear questions with an owner and your dashboards are used to decide every week (then you’re fine); you don’t yet have the base data (first you need the numbers, then the questions about what to ask them); you’re looking for “more charts” and not “more decisions” — because the road here is to take away and focus, not to add.

Frequently asked questions

Is self-service BI always wrong? No: it works in organisations with a mature data culture and people who have the time and skill to explore. In most SMEs, though, it arrives before the culture and without the questions, and becomes an expensive tool nobody opens. Better a few targeted data products than self-service for everyone.

How do I understand which are the right questions? Starting from the decisions, not from the data. Sit with whoever decides and ask which choices they make every week and what they’d like to base them on. From there the questions derive. It’s a workshop of a few hours, and it’s worth more than months of dashboards built in the dark.

Do I necessarily need a data analyst? You need someone who can take a business question all the way to a used screen — which is a different profile from “makes charts”. It can be an internal with a product head or a supplier. What you don’t need is to hire to produce reports without having first defined the questions.

Can I use AI to query my data out loud? Yes, but after you’ve put definitions and the data product in order, not before. An LLM on data with ambiguous definitions gives confident and potentially wrong answers. First the solid product, then eventually the conversational layer on top.

How long does it take to turn dead dashboards into a used product? Less than you think, because often the data is already there: the questions step is missing. A workshop for the questions, the assignment of owners and frequencies, and the rebuild of the few screens that count can give results in a few weeks.

How do I know if I’m about to make the same mistake again? Ask yourself a question before you start: does this project begin from a tool, from some data, or from a list of decisions? If the answer is “tool” or “data”, you’re about to build another cemetery. If it’s “decisions and questions”, you’re on the right road. The order you start from predicts the result more than any technology.

And if every department wants different questions? Fine: every department has its decisions and therefore its questions, with its owners. The important thing is that they rest on the same base definitions, so the numbers don’t contradict each other. Different questions on top, common definitions underneath.

Do I have to throw away the dashboards I already have? Almost never entirely. Often the data and part of the work are good: the questions step is missing. You recover what you need, you throw away the useless charts and you rebuild around a few questions with an owner. Rebuilding from the right base is faster than starting from scratch.

How do I involve people so they use the new product? By involving them first, in the questions workshop. People use what they helped define and that answers a question they were already asking themselves. A tool dropped from above, however pretty, is ignored; one born from their decisions is opened every day.

In one line

If you’ve spent on dashboards and nobody opens them, the problem isn’t the data: it’s the questions. Self-service BI fails because it gives everyone the data hoping they’ll find the questions on their own; a data product does the opposite — it starts from the decisions, derives the few questions that count, assigns each one an owner and a frequency, and turns them into screens that are actually used. You don’t need more charts: you need the right question, hooked to a decision. It’s the thread that ties the whole guide to dashboards and data products, of which this article is the final stage.

If you want to turn your stuck numbers into a product someone opens every morning to decide, look at the projects I’ve built or drop me a line: we start from the decisions you have to take, not from the data you have.