The Executive Dashboard Nobody Uses
A 400-store specialty retailer has a Merchandising Performance Hub used in the Monday 8 a.m. trading meeting. It contains 38 visuals, nine filters (region, district, store, category, subcategory, brand, week, channel, promotion), and loads in 20-30 seconds on a live connection to the warehouse. The 12 executives who attend export the data to Excel within the first ten minutes and then debate whose extract is right. The dashboard refreshes nightly at 3 a.m.; the meeting reviews last week's sales, margin, inventory turns, and promotion lift. Store managers have their own version with different filters. The BI manager is asked to make it faster and more executive-friendly before next quarter. Warehouse tables are 400 million rows; the largest fact table is not partitioned by date. There is no agreed definition of promotion lift. The team has two developers and a six-week window.
1. How would you redesign the dashboard for the Monday trading meeting? What do you cut and why?
Read the worked answer
I would start from the meeting's decisions, not the existing visuals. The trading meeting decides where to intervene on sales, margin, inventory, and promotions. That supports one screen with five KPIs, each showing actual versus plan and versus last year, plus an exception list of the stores and categories furthest off plan, a trend view, and a promotion table with a stated lift definition. I would cut the 38 visuals to roughly eight and reduce the nine filters to two defaults, week and channel; the rest become drill paths or pre-set views. Nine filters force executives to construct their own queries and explain why they export. I would add definitions and a data-as-of timestamp on the page, because the export behavior is a trust symptom, not a tooling preference. Store managers get a separate governed view with the same metric definitions. The redesign is a decision-support exercise: fewer choices, clearer exceptions, one shared number.
2. The dashboard takes 20-30 seconds because of a live connection and high-cardinality filters. What performance changes do you make?
Read the worked answer
The live connection plus nine high-cardinality filters means each interaction can trigger a large scan of an unpartitioned 400-million-row fact table. I would first partition the fact table by date and cluster by store and category, then build weekly aggregate tables at store-category level for the meeting's grain. Promotion lift should be precomputed, not calculated at query time from raw transactions. The dashboard should use import or extract mode with incremental refresh rather than a live connection; executives are reviewing last week's data, so five-minute freshness has no decision value. I would cap the filter list, set defaults, and use query folding where possible. Measure p95 load time before and after, with a target under five seconds for the landing page. If a drill still needs detail, send it to a separate query with a row limit. Performance work should follow the meeting grain, not every possible slice.
3. How would you measure whether the redesign succeeded beyond page views?
Read the worked answer
Page views reward curiosity, not decisions. I would baseline the current state: time spent reconciling in the meeting, number of Excel exports during the meeting, number of disagreements over whose number is right, and the share of agenda items that end with an owner and action. After launch, track those directly: exports per meeting, reconciliation minutes, open data-definition disputes, and whether the exception list is actually used to assign follow-ups. I would also sample five executives and five store managers at 30 and 60 days and ask what decision changed or what they still cannot answer. Adoption by store managers matters because they were using a different filter set. A dashboard that is opened daily but ignored in the meeting has failed. The success metric is faster, shared decisions, not higher click counts.