What's the Deal with Dashboards?

Imagine a RevOps comedy showcase. Overworked and traumatized (yet endlessly passionate) RevOps professionals taking turns at a microphone under a spotlight on a stage. 

What would they be talking about? 

Someone approaches the mic, the audience leaning forward in anticipation. They grab the mic, pause for a moment, and hit the audience with the opener:

“What’s the deal with dashboards?”

The audience groans, someone catcalls, the drunk enablement manager in the back falls off his chair in protest (or maybe just instability, we can’t assume anything). 

That reaction? We know where this is going. We’ve all been there. We’ve been sitting at our computers, minding our own business building Salesforce flows, when the Slack message chimes and the CRO/VP of Sales/VP of RevOps/FP&A is asking innocently:

“Do we have a dashboard that…..”

“NO, WE DON’T AND I’M NOT BUILDING IT, SO STOP ASKING.”

That’s what you want to say. What do you actually respond with? 

“No, but we have this other dashboard that has that data.” 

“Yeah, I’ve seen that one, but does it have…..”

And you’re on the hook for it now. Because duty calls, and RevOps responds. 

How many dashboards do we really need?

Let’s be honest, the intent of reporting solutions is pure. The idea of taking complex data, cleaning and normalizing it, then presenting it in a digestible fashion is one that any organization can get behind. Unfortunately the practice of deploying analytics solutions often falls short of resounding success, and at worst introduces unneeded complexity, tedium and pain. 

The reality is, most dashboards do a great job of displaying data. The issue is when the dashboards you built to simplify the complex data…don’t. 

Tabs and drill downs with filters at every step add layers of complexity that business users quickly balk at. RevOps analysts are great at knowing exactly how to get to a very specific data point, but business users aren’t, and the more steps they have to take to get to what they want in a dashboard, the less likely they are to keep using it after the initial rollout. 

This problem, where a dashboard might be “good enough” for RevOps but completely unusable to the business? That’s the n+1 problem: the number of dashboards an organization needs to function is always the number currently built (n) + 1. Into eternity. In fact, the average enterprise organization has built 1,000 dashboards. At that point, it’s just noise without facts and data without interpretation. 

That brings us to the next point: dashboards sans insights are meaningless, and insights without actions are useless. 

Dashboarding for dashboarding’s sake

One of the problems plaguing RevOps and analytics teams is that too often, building a dashboard becomes the first and only deliverable. It’s really no surprise that this approach to analytics yields volume, but doesn’t necessarily drive business impact. Before even beginning the build, RevOps teams need to be asking questions: 

• Who is the end user of this solution?
• More importantly than who will be using it, HOW will they be using it?
• Is there a clearly defined process that this analytics solution supports and how does it align with that process?
• What unique business insight can this solution actually surface?
• Once that unique insight is realized, what action is expected to be taken from it? 

This should be part of the internal requirements discovery, gathering and documentation process. If these cannot be clearly answered and documented, the dashboard should not be built. 

The hardest part is being able to say “we aren’t building this”. RevOps is used to being helpful and used to saying yes, but without clear value, no solution is worth deploying. In the absence of a leader who will hear a rational argument, you can always point to one thing: cost. 

Your dashboards are prohibitively expensive

As data changes upstream, downstream processes must be altered to adapt to the changes. For analytics and reporting solutions, that means dedicated resources to keep data clean and up to date, maintain any supporting transformation processes, and keep dashboards from breaking. The technical debt alone is a slog, but the cross team coordination required to maintain these dashboards? That’s the real cost. 

Consensus doesn’t come free, and consensus on reporting will need to be gleaned from every business unit that will consume it. If a high functioning RevOps team can get to that point, eventually the number of dashboards start competing as “sources of truth”. This quickly turns into dashboard-driven analysis paralysis, metric contradiction, and no tangible business outcome. 

Why that one RevOps person is so valuable

Raw data is valuable, but requires interpretation. Dashboards are visual, which is a deceptively comfortable way to display raw data in a digestible format. What’s the problem with that? Both solutions require interpretation of data. The belief that visibility = understanding is a common trap that organizations fall into. 

The interpretability conundrum is difficult to solve, especially when the democratization of data and analytics is such an aspirational goal. Each individual in an organization can interpret data differently. The variation of interpretation isn’t inherently bad, but it moves an organization away from a source of truth and toward something worse: a source of disagreement. 

How many times have we sat between a head of marketing and a CRO and watched the inevitable dissection of a sales dashboard vs. a marketing one. Both data sources are the same, but the interpretations are different. This disconnect leads to poor enterprise decision making. Worse? It leads to no decisions, no course corrections, no improvement. Just inertia for inertia’s sake. That’s the analysis paralysis perfect storm that sends companies on a one way road to layoff city. 

What’s the alternative? 

In a traditional analytics tech stack, organizations can make headway by implementing safeguards around reporting: 

• Centralize analytics around a single leader. Even if analytics groups are maintained outside of this leader’s direct supervision, they should be checked and accounted for by that individual. 
• Build and maintain a company wide metric dictionary. Include sources, calculations, and agreed upon display methods. Every team adheres. 
• Monitor usage with hawk-like vision. If a dashboard wasn’t adopted, isn’t being used and isn’t driving value? Get rid of it. 
• Always couple dashboards with processes, insights, and actions. As part of documentation, outline scenarios: if you see this? It means this, and you need to do this. Do not build dashboards without these. 

Alternatively, embrace the data technology that’s carrying us into the age of agentic AI. True democratization of data begins when source data is the agreed upon place of truth and AI is employed to view, contextualize, analyze and recommend action to the user. Better yet? Suggested actions that can be carried out directly via agentic action. In this way, users can get insights from source data directly with the interpretation baked in (no RevOps all-star to read it back, no long transformation processes or dashboard updates), then take action directly to notify the owner, draft that follow-up email, or create that new account in CRM. 

The more steps there are in this process? The less likely an organization is to be able to fully engage in data driven decision making.

Dashboards aren’t dead, but they aren’t the future

There will always be a need to show a graph with a trend line, but dashboards are becoming less and less scalable in a world obsessed with velocity, context and action. Organizations don’t need more dashboards, they need better insights and answers that allow for quick pivots and specific actions. Embrace your data sources as the source of truth. Scale back complex data preparation and dashboards. Scale up on speed, contextualization, and action.