The Data Leader's Reset: From Reporting to Decisions (Part 2 of 3)
Early in my career, I spent several weeks building a dashboard people had been asking for for years. I spent a couple of weeks gathering requirements, another couple writing and debugging a complicated backend, and another few days building a beautiful Tableau dashboard that looked amazing. Borderline artwork.
I’m sure you can see where this is going.
The dashboard was retired eighteen months later without any fanfare because no one noticed.
The problem wasn’t the dashboard, it was that it delivered the right information – that’s why everyone was asking for it – but at the wrong time, in the wrong place and in the wrong format.
Last week we covered Phase 1 of a data team reset: understanding the system, sorting the work, getting your manager’s backing. Phase 1 removes the wrong work. Phase 2 is where you pivot towards the right work.
This is the second of three posts summarizing a longer guide in the Penguin Analytics store.
Pick the decisions worth getting good at
In your mind, you already know which business decisions carry weight. From Phase 1 and from your time in the role. Now you need to name them.
You’re looking for decisions where:
The outcome has a clear dollar value, whether that’s revenue, cost, risk reduction, or resource allocation.
The decision happens on a predictable cadence: weekly, monthly, quarterly.
A real owner exists who is willing to partner with you on improving how the decision gets made.
Better information would change the outcome, not just confirm what people already believe.
Common examples: pricing reviews, capacity planning, marketing spend allocation, churn intervention targeting. Your list will be specific to your business.
Pick three to five. The temptation is to choose seven or eight because they all feel important but resist it. Depth on three is worth more than surface coverage of eight. Depth means your team understands the decision context, knows the decision-maker personally, and can describe what a good outcome looks like before they pull any data.
One easy trap you need to avoid: don’t pick decisions based on what’s analytically interesting. The most stimulating analysis isn’t always the most valuable. A simple view that changes a pricing call every month is worth more than a sophisticated model that nobody owns.
Build decision products, not dashboards
For each decision you pick, your team is going to build a decision product. The name matters because the framing matters.
A dashboard is a collection of charts and filters that a user can explore. A decision product is the thing that lands in front of the decision-maker at the right moment, in the right format, with a clear recommendation. A dashboard says “here is some data.” A decision product says “here is what you need to know to make this call, and here is what we recommend.”
You know, like my fancy dashboard didn’t.
For each one, define:
The decision owner.
The decision cadence.
Three to five key metrics.
The narrative structure the data needs to tell.
The delivery channel.
Who on your team owns the product end-to-end.
The format should follow the decision-maker’s workflow, not your BI tool. It might be a slide in a recurring meeting deck. It might be an email summary that arrives Monday afternoon before Tuesday’s review. It might be embedded in the tool where the decision-maker already works. What matters is that it helps them make the call.
Co-design or you’ll rebuild your graveyard
The fastest way to recreate the dashboard graveyard is to design decision products based on what you think stakeholders need rather than what they tell you.
For each product, run a short co-design session. Thirty minutes with the decision-maker and one or two of their direct reports is enough. Walk through how the decision happens today, what information is missing, what format works for them, and what would make them stop using whatever you build.
That last question is the most important one, and the one analysts skip most often. Previous analytics tools died in their workflow for a reason. Find out why.
Prototype lightly. Wireframes, a rough slide, a simple query. Review within days, not weeks. Every week you spend building in isolation is a week where assumptions harden and misalignment grows. The co-design process itself builds trust because it shows stakeholders you’re building with them, not for them.
Retire the graveyard with purpose
With your critical decisions identified and decision products in motion, you have the context to start retiring unused content.
This is the scariest part of the reset, because you’re taking things away from people, and people get attached to things even when they aren’t using them.
Handle it in stages. For dashboards that haven’t been accessed in more than 90 days, send a short notification to the last known users. “This dashboard hasn’t been accessed in X days. We’re archiving it on Y. If you still need it, reply and we’ll keep it active.” Most won’t reply. The ones who do will tell you something useful about whether the dashboard matters.
For duplicates, consolidate into the single source of truth your decision products will use. Frame it as a benefit. Everyone working from the same number is a win, even for the people losing their preferred version.
For dashboards with a real audience that are being replaced by a decision product, explain the transition. Don’t archive silently. People feel ownership of work even when they don’t use it, and quiet retirement reads as a trust violation.
Watch where your team is spending their time
As decision products take shape and the graveyard shrinks, your team’s time allocation should start to shift. More decision-linked work, less undifferentiated maintenance and ad-hoc fire drills.
Track it. A rough weekly estimate from each analyst is enough. How much of the week went to decision products, how much to ad-hoc, how much to maintenance. You’re looking for a trend, not for precision.
Use your 1:1s to reinforce the shift. Ask what decision the work supports. Ask whether anything on their plate isn’t tied to a decision and whether it should be. You’re training the team to think in decisions and outcomes, not deliverables, tickets and enhancements.
If you’re not seeing movement after three or four weeks, the answer is usually one of two things. Either the intake filter isn’t as good as you intended and ad-hoc requests are coming in unchecked, or you haven’t retired enough to free the capacity. Both are fixable, but you just need to know which one.
A little assignment
Pick one decision. Just one. Something that recurs on a predictable cadence and has a named owner you could talk to this week.
Write down, in fewer than a hundred words, what your team would deliver to support that decision if you started from scratch. What’s the format. When does it land. Who reviews it before it goes out. What recommendation or framing does it include.
Compare that to what your team currently delivers against the same decision. The gap is your Phase 2 work.
This is the second of three posts on running a 90-day reset for a data team. The full guide, with the decision-product brief template, the retirement playbook, and stakeholder language for the harder conversations, is available in the Penguin Analytics store.