What Managers Ask For in Reports and What They Actually Use

Managers ask for dashboards and then check three numbers in a chat message. If you build reports for a living, the fastest improvement available to you is to stop taking requests at face value and find out which reports are actually opened. The gap between the two lists is usually large, and closing it frees more time than any new charting tool will.

The reason for the gap is not that managers are careless. It is that a request is made in a meeting, under pressure, about a worry. A worry is not a specification.

Why the requested report is rarely the used one

When someone asks for a report, they are usually doing one of three things.

They are anxious about something specific and want reassurance. They want a defensible answer for a conversation they are about to have with their own manager. Or they genuinely need to make a decision and do not have the input.

Only the third one produces a report that gets used repeatedly. The first two produce something that is looked at once, satisfies the moment, and then sits there being maintained forever.

The tell is the phrasing. "Can we see everything about X" is anxiety. "I need to know whether X is above or below Y by Thursday" is a decision.

Find out what gets opened

You do not need to guess. Most reporting tools record who opened what and when, and if yours does not, you can still learn a lot cheaply.

• Check access logs for the last quarter. Sort by report, count distinct viewers, and look at the last opened date. Reports nobody has opened in three months are candidates for deletion, not improvement.
• Watch where numbers get quoted. If a figure keeps appearing in messages and slides, that is a used report, whatever the logs say. If a dashboard exists that nobody ever quotes from, it is decoration.
• Look at what people rebuild by hand. Someone exporting to a spreadsheet every week is telling you the report is close but wrong. That is the most valuable signal you will get, and it is usually the one nobody follows up.

Do this before your next reporting cycle and you will probably find you can retire more than you build. What survives is usually closer to a one page capacity view a manager opens on Monday.

Ask a better question than "what do you need"

When a request comes in, three questions sort it out quickly.

What decision does this help you make? If there is no decision, it is reassurance, and reassurance can often be a single number in a weekly message rather than a page.

How often will you look at it? People overestimate this by a lot. If the honest answer is monthly, build something simpler than a live dashboard. Weekly answers tend to look like what a manager needs on a Monday morning.

What would you do differently if the number were bad? This is the strongest one. If nobody can answer it, the report has no consequence attached, and reports with no consequence do not get opened twice.

None of these are trick questions. Managers are usually happy to answer them, and the conversation often ends with a smaller request than the one that started it.

The maintenance cost nobody counts

Every report you build is a promise to keep it correct. Field changes, new teams, renamed projects, a process that alters halfway through a quarter. An unused report still breaks, and when it breaks somebody investigates.

A short list of well maintained reports beats a long list of half accurate ones, and the second state is where most teams end up by accident rather than by choice.

Give reports an expiry. Six months after launch, check the open count and either confirm it or delete it. Deleting a report almost never causes a complaint, which tells you something.

What to do this quarter

Pick your reporting set and split it into three piles: opened weekly, opened occasionally, and not opened at all.

Improve the first pile. Ignore the second. Delete the third, and tell people you are doing it before you do, which turns the deletion into a useful conversation about what they actually wanted in the first place.

Then, for every new request, write down the decision it supports in one sentence. Some of those decisions need no report at all, only reading the sprint board for overload. If you cannot write the sentence, the report is not ready to build yet, and the person asking for it will usually agree once you say it out loud.