A few years ago I sat at the back of a room while a leadership team scrolled through a dashboard. It was a beautiful dashboard. It had been built carefully, with proper drill-down, consistent color, and the kind of cross-filtering that takes a week to get right. The team scrolled through it for about ninety seconds, asked two questions whose answers were not on the page, and moved on. That was the entire engagement with the work. The next morning a member of that team forwarded me a one-paragraph email summary written by someone else, with a single bolded sentence, and asked me to confirm whether the number was right.
The summary was the artifact that drove the meeting. The dashboard was wallpaper.
I have been thinking, on and off, about that morning for the better part of two years. The thing I have come to believe is that the BI profession, mine very much included, has been measuring the wrong product. We have been treating the dashboard as the deliverable and the briefing as a side effect. The reality, in any organization where senior people are busy, is the reverse. The briefing — the short, opinionated, decision-ready synthesis that lives above the dashboard — is the deliverable. Everything underneath it is the means by which the briefing gets produced. Treating the dashboard as the artifact, in that frame, is like treating the kitchen as the meal.
This piece is about that briefing layer. What it is, why it has historically not existed as a first-class product, what it looks like when it does, and how to build one without writing a paragraph from scratch every Monday morning at six. I am writing this for the analytics leader who is tired of asking why the dashboard they spent a quarter building is being scrolled past in ninety seconds, and ready to consider that the dashboard was never the point.
The Sixty-Second Test
The discipline I want to put at the center of this piece is something I have come to call the sixty-second test. The test is simple. Imagine a senior executive has exactly one minute to engage with your work before their next call. What is the artifact you would put in front of them, in that minute, that lets them make a decision? Not understand the business — make a decision.
If your answer is "the dashboard," try the experiment honestly. Set a timer for sixty seconds. Open your weekly performance report. Pretend you have not seen it before. At the end of sixty seconds, what do you know? More importantly, what do you not know? What did you have to scroll past, drill into, hover over, or interpret to extract a number whose meaning depended on three other numbers on a different tab?
The first time I did this experiment with my own work, I was embarrassed. The dashboard I had built had thirty filters, twelve visuals, and roughly two hundred individual numbers on the landing page. At sixty seconds I had identified a single trend — revenue down week-over-week — and absolutely none of the supporting causal structure. The dashboard was rich. It was not actionable. To make it actionable I had to know which questions to ask, in which order, with which filters applied. That meta-knowledge lived in my head, not in the artifact. Anyone consuming the dashboard who was not me was, in effect, looking at a search engine without a query.
The briefing layer is the answer to that problem. It is not a replacement for the dashboard. It is the layer above the dashboard that converts data into a position — a written statement, supported by the dashboard's numbers, that a decision-maker can accept, reject, or act on without doing the synthesis themselves.
Why the Briefing Layer Has Not Existed
If the briefing is so obviously the right product, why have we not been building it all along? Several reasons, none of them mysterious.
The first is that briefings are expensive to produce by hand, and the cost is borne by the most expensive person in the analytics function — usually the lead, the manager, or the director. Producing a single week's briefing involves opening the relevant reports, scanning them with experienced eyes, identifying what is unusual, deciding what to investigate, running the investigation, writing it up, deciding what to recommend, and then trimming the whole thing to a length the audience will actually read. Every step of that is judgment work. Junior analysts can build the dashboards; only senior analysts can build the briefings. As a result, briefings get done sometimes, by the most expensive person, and when that person is on vacation they do not get done at all.
The second is that briefings, unlike dashboards, are not durable. A dashboard built last quarter is mostly still a dashboard this quarter; the data refreshes itself. A briefing written last week is, by definition, the wrong briefing this week. The work has to be redone every cycle. Analytics teams, like most teams, gravitate toward work that compounds. Dashboards compound; briefings do not. So dashboards win the priority arguments and briefings get sketched on the back of an envelope at the start of the meeting they were supposed to lead.
The third is that briefings, written well, are opinionated. They take positions. They say "the dormancy in our distributor network accounts for fifty-five percent of the royalty shortfall this month, and most of it is concentrated in three operators whose location count has dropped by half since January." That sentence is a claim. It can be wrong. It can be challenged. It exposes the analyst to a kind of accountability that a dashboard does not. The dashboard says "here are the numbers, you decide what they mean." The briefing says "I have decided what they mean, and here is the evidence." Many analytics teams, often without realizing it, prefer the safety of the former. The briefing layer is a request to give up that safety.
The fourth, and this one I want to put a fine point on, is that the current dashboards-and-decks paradigm produces a comforting feeling of completeness that briefings do not. A nicely formatted forty-page weekly deck feels like a thorough product. It is thorough; it is also unread. The briefing is short and looks slight. Short artifacts feel cheap. Senior leadership consumes the short artifact and acts on it; the analytics team feels under-credited for the deck that produced the briefing's evidence. There is a cultural negotiation underneath all of this that I do not want to gloss over, because it is, in my experience, the actual blocker in most organizations. The technical work is the easy part.
What a Briefing Layer Actually Is
In its most refined form, the briefing layer is a single page — sometimes a single screen, sometimes a single email — that contains five things and almost nothing else.
First, a headline. A single sentence that summarizes the state of the business in the dimension that matters most this week. "Combined net sales were one point six four million, up ten point three percent year-over-year, with all of the growth concentrated in two product lines." That sentence is the briefing in microcosm. If the executive reads nothing else, the headline should leave them with a defensible position on the question "how are we doing."
Second, a delta. What changed since the last briefing? Not which numbers moved — what changed. A delta is causal, not numeric. "Royalty revenue is down sixteen thousand a week against forecast; about fifty-five percent of that is dormant locations in three distributors, twenty-five percent is platform migration from V1 to V2 in Sweeps, and twenty percent is seasonal." A list of numbers is not a delta. A decomposition of the difference into its causes is.
Third, a small set of decisions to make. These are the actionable items the briefing exists to surface. "Approve outreach to the three distributors with concentrated dormancy. Confirm migration timeline for the remaining V1 footprint. Decide whether to adjust the May forecast for the seasonal effect or hold." If a decision does not need to be made, it does not belong in this section. The briefing's job is to compress the time between observation and choice. If there is nothing to choose, there is nothing to brief.
Fourth, a log. What was decided last time? What happened as a result? This is the section most teams skip and the section I have come to consider non-negotiable. Without the log, every briefing is the first briefing. With the log, the briefing accumulates organizational memory. The right format is mechanical: date, decision, owner, status, observed outcome. The log should be brutally short and brutally honest. "We chose to defer the price increase three weeks ago; volume since has been within the noise band; recommend revisiting" is more useful than three pages of supporting analysis nobody will read.
Fifth — and only fifth — the evidence. The numbers, the charts, the tables. These exist to support the first four sections, not to substitute for them. The evidence is the dashboard. The briefing layer points at the dashboard. The dashboard is not removed from the building; it is moved one tier down in the stack, where it can be examined when a claim in the briefing is challenged.
That is the whole shape. Five sections, one page, sixty seconds of reading. Underneath it, the analytics team's entire infrastructure: warehouses, models, dashboards, runbooks. On top of it, the executive's decision. The briefing is the surface where those two layers meet.
Three Reinforcing Loops, as a Scaffold
A briefing is a synthesis, and a synthesis needs a scaffold. The scaffold I have ended up using, after iterating my way through several worse ones, is a framing of the business in terms of three reinforcing loops.
The Game Loop is the inner cycle: a product, a player, a session. Are the units of consumption working? Is hit frequency in band? Is the math model performing as designed? Is session length compressing or expanding? These are questions about the product itself, asked at the smallest scale that still has meaning.
The Distribution Loop is the middle cycle: a venue, an operator, a geography. Are the places where the product reaches the player growing or shrinking? Which distributors are adding locations and which are losing them? Where are we under-penetrated relative to demand? This is the spatial layer of the business.
The Performance Loop is the outer cycle: revenue, cost, margin. What is the consolidated financial picture, and how is it moving against forecast and against prior periods? This is the layer leadership instinctively asks about first and, in my opinion, the layer they should ask about last.
The three loops are reinforcing because each one feeds the next. A healthy game loop produces sessions that distribute well; healthy distribution converts sessions into revenue; healthy revenue funds investment that improves the game loop. When the outer loop softens, the cause is almost never in the outer loop. The cause is upstream, in one of the inner two, and the time signature of the softening is what tells you where to look.
I use this scaffold for two reasons. The first is that it gives the briefing a consistent structure across weeks. The reader knows, before they open the page, where to find the answer to "is the product okay" versus "is the network okay" versus "is the P&L okay." The second is that it forces me, in writing the briefing, to confront whether I have an answer to all three. If the Game Loop section is empty this week, that is itself a finding. Either the game loop is not moving, or I have not looked carefully enough.
Your organization may need a different scaffold. The three loops happen to fit a business where a product moves through a distribution network to a customer; a SaaS business probably wants acquisition, expansion, and retention as its loops, and a manufacturing business probably wants something else again. The point is not the specific loops. The point is that the briefing should be structured by a consistent mental model of the business, applied every cycle.
The Problem Decision Sheet
For the action portion of the briefing — the part where decisions get surfaced — I have settled on a unit I call the Problem Decision Sheet. The name is unromantic, which is fine. Each sheet is a single block of structured text with the following fields, all kept terse:
- Problem. One sentence stating what is wrong or what is at risk.
- Owner. The single person responsible for moving this forward.
- Priority. A single letter or word — now, next, later — that signals urgency. No second-order qualifiers. If a problem is now, the decision is being made this meeting.
- Solution under consideration. A short statement of the action being proposed.
- Success criterion. How we will know whether the action worked, stated in terms specific enough to be checked against next cycle.
The fields look bureaucratic on the page. In practice they are the opposite of bureaucratic, because each field exists to defuse a specific failure mode I have watched repeatedly in unstructured meetings. The Owner field defuses the "everyone agrees something should be done" failure. The Priority field defuses the "we will get to it" failure. The Solution field defuses the "we are aware of the problem" failure that produces no movement at all. The Success Criterion field defuses the "we did the thing and now have no idea if it worked" failure that leaves the same problem on the next cycle's briefing.
Sheets are generated by the analytics team and brought to the meeting in draft form, with the Solution and Owner fields deliberately left blank or only sketched. The job of the meeting is to fill them in. The job of the next briefing is to update the sheet's status — usually one of open, in-flight, observed, closed — and to move closed sheets into the Decision Log.
That last move is the one that makes the whole system compound. The Decision Log is the institutional memory the briefing layer accumulates over time. Six months in, you can look back at the log and ask hard questions of yourself: what did we decide to do, and did it work? The log tells you, with the specificity of the success criteria you wrote down at the time. Most analytics functions do not have an answer to that question across any meaningful time horizon. The Decision Log gives you one, and the discipline of having one changes how you write the next briefing.
The Role of Synthesis, and What Language Models Do and Don't Change
A reasonable question, raised by every leader I have shown this framework to, is: doesn't the LLM do all this for me now? Cannot I drop the dashboard into a model and ask for the briefing?
The honest answer is: partially, and the parts it does well are different from the parts you might expect.
What the model does well, in my experience, is the mechanical synthesis. Given a clear definition of the inputs — the relevant weekly numbers, the prior briefing, the open Problem Decision Sheets — a competent LLM will produce a draft briefing that is roughly the right shape. The headline will be on the correct quantity. The delta will name the right movement. The structure will be consistent week over week, which is itself a win, because consistency is the part of briefings humans are worst at.
What the model does not do well, and may never do well, is the part that distinguishes a good briefing from an adequate one: deciding what to investigate. The mechanical synthesis takes the inputs and produces a description. The human work, the part that I do not see being automated away, is deciding which of last week's anomalies are worth pursuing this week. The model is excellent at describing what changed; it is much weaker at deciding which of the changes is important. Importance is a judgment about the business, not a property of the data. A two-percent move in one line is a crisis; a twelve-percent move in another is noise. The model has no idea which is which until you tell it, and even then it tells back what it was told, rather than choosing on its own.
The right division of labor, in my current practice, is this. The model produces the first draft of the briefing's mechanical sections — headline, delta, evidence pointers — from a structured pull of the underlying numbers. The human (me) rewrites the headline if it is not pointing at the right quantity, sharpens the delta into causal language, identifies what the model missed, drafts the new Problem Decision Sheets, and updates the log. The model then does a polish pass on the prose. Total time from "the data is refreshed" to "the briefing is in the inbox": about thirty minutes, down from the better part of a morning.
That compression is the actual product of putting an LLM in this workflow. Not the writing — the speed of writing, which is what makes the briefing possible to produce every cycle rather than as a heroic effort once a quarter. The briefing layer was always the right product. It was never the priority, because it was always too expensive. The model changes the cost structure.
What it does not change is the underlying expectation that someone is taking a position. The briefing is opinionated; opinions require an opinion-haver. A briefing fully generated by a model, without a human in the loop deciding what to claim, is exactly the kind of artifact that produces confident, fluent, slightly-wrong leadership decisions. The model is the assistant. The analyst is the author.
Operating the Briefing Layer
Some practical notes from operating one of these for a while.
The first is on cadence. The briefing should be produced on a strict rhythm. Weekly is the right cadence for most operational businesses; monthly is too slow and daily is too noisy. The discipline of weekly forces you to make claims with limited information, which is the same condition under which leadership makes decisions, which is the whole point. If you slip the cadence, the briefing loses its place in the operating rhythm and reverts to ad hoc, and within a quarter you are back to where you started.
The second is on length. I have written briefings that were three sentences and briefings that were two pages, and the three-sentence ones have, without exception, been more useful. The natural pressure on length is upward — the analyst always knows more than fits — and the natural pressure should be enforced downward. A useful constraint is: the briefing fits on one screen of an executive's phone, scrolling once. That is somewhere between two hundred and five hundred words. If it does not fit, something needs to come out. Usually what needs to come out is evidence that belongs in the dashboard layer below.
The third is on consistency. Use the same structure every week. Use the same words for the same concepts. If you call something "active locations" this week, do not call it "operating sites" next week. Consistency is what makes a briefing skimmable; the executive's eye learns to find the section it cares about, and any deviation in structure costs reading time. This is unromantic and unglamorous advice, and it is the most important practical thing in this entire article.
The fourth is on honesty. The briefing should report what is happening, including what is happening badly. The temptation, especially when the briefing is the visible product, is to soften the language around bad news. Resist it. The credibility of every future briefing rests on the leadership's confidence that this one is telling them the truth. A briefing that says "we did not hit forecast, here is why, here is what we propose to do" earns trust. A briefing that obscures the miss in language earns the opposite. The single greatest investment an analytics team can make in the credibility of its work is the consistent willingness to be the bearer of bad news clearly.
The fifth, and last, is on what comes out of the room. The briefing's success is not measured by whether the meeting goes smoothly. It is measured by whether decisions are made, and whether those decisions show up in the log next week with status updates against their success criteria. If the briefings are smooth but nothing changes between cycles, the briefing layer is decorative. The point is the loop: observe, decide, do, observe again. The briefing is the artifact that closes the loop.
What the Briefing Layer Doesn't Solve
I should be honest about the limits.
The briefing layer does not produce its own raw material. If the dashboards underneath are wrong, the briefing will be confidently wrong, in fewer words. The discipline of producing a weekly briefing has, in my experience, surfaced more issues in the underlying data than the dashboards alone ever did — the act of having to say something forces a level of scrutiny that the act of displaying something does not — but the surfacing is a side effect, not the primary purpose. You still need good measures, good models, and good pipelines underneath.
It does not solve organizational alignment. If two business units mean different things by "active customer," the briefing will inherit that ambiguity. The briefing layer is a place where these inconsistencies become legible; it is not a place where they get resolved. The resolution still requires the conversation between the business units, with the analytics team as the facilitator. The briefing makes the conversation necessary; it does not have the conversation for you.
It does not protect against the wrong question. A briefing perfectly answers the question it was designed to answer. If leadership is asking a different question than the briefing was designed for, the briefing will be a beautifully crafted answer to the wrong thing. The cure here is periodic recalibration: every quarter or so, ask leadership what they think the briefing is for, and adjust the scaffold accordingly. The scaffold should be stable across weeks and revisited across quarters.
It does not eliminate the work. The whole point of this article is that the work is the briefing; everything else is the apparatus that makes the briefing possible. There is no architecture that produces a useful briefing without a thinking human deciding what claims to make. The work changes shape — less wrangling, more synthesis — but the work does not go away. Anyone selling you a tool that promises otherwise is, in my experience, selling you a dashboard with extra steps.
The Thesis
The reason I keep returning to the moment I described in the opening — the team scrolling past the dashboard, the bolded sentence in an email driving the meeting — is that it captures something I think the analytics profession has been slow to acknowledge. The artifact our customers act on is the synthesis, not the substrate. The dashboard is the substrate. The briefing is the synthesis. We have been investing, very capably, in the substrate, and treating the synthesis as a side effect.
The briefing layer is the proposal that we invert that. That the synthesis is the product, and the dashboards exist to make the synthesis possible. That a serious analytics function is judged not by the volume of its dashboards but by the quality of the decisions its briefings drive. That a weekly cadence, a consistent scaffold, a Problem Decision Sheet, and a Decision Log are the four primitives a senior team actually wants, and that an LLM-accelerated workflow brings the cost of producing those primitives within reach for the first time.
Dashboards are not enough. They never were. The real product is the synthesized narrative leadership can act on in under sixty seconds, and the rest of the stack exists to produce it.
Next in the series: a methodology born in mid-century quality engineering, and why it has become my fastest path to optimizing the math underneath the product.