When an interviewer asks you to design a dashboard or reporting system, they are not asking you to list KPIs. They want to see how you think about who uses the data, what decisions it supports, and how the design changes based on the audience.
This is one of the most common analytical PM interview questions, and candidates consistently underperform on it because they jump straight to metrics without establishing context.
Start with the user, not the metric
Before you name a single number, ask: who is looking at this dashboard? A VP of Product checking weekly trends needs a fundamentally different view than an ops manager monitoring real-time queue depth. The audience determines everything — the refresh cadence, the level of aggregation, the alert thresholds, and whether the dashboard is a wallboard, a morning email, or an interactive tool.
The three layers of a good dashboard answer
Layer 1: Context and decisions. What business question does this dashboard answer? If someone looks at it and nothing has changed, do they close the tab? If something is wrong, what action do they take? A dashboard that does not lead to a decision is a screensaver.
Layer 2: Metric hierarchy. Lead with 2-3 north-star metrics that map directly to the decisions from Layer 1. Below that, add diagnostic metrics that explain why the north stars moved. Avoid the trap of showing 15 metrics with equal visual weight — it forces the reader to figure out what matters.
Layer 3: Technical feasibility. Where does the data come from? What is the latency? Are there known gaps or biases in the data pipeline? Interviewers love when candidates acknowledge that dashboards are only as good as the data behind them.
Common mistakes
The biggest mistake is treating the question as a metrics-listing exercise. Saying you would track DAU, WAU, retention, revenue, and NPS tells the interviewer nothing about your product sense. The second mistake is ignoring the audience — a dashboard for the CEO and a dashboard for a feature team should look completely different.
A framework that works
Try this structure in your answer: (1) clarify the audience and their top decision, (2) propose 2-3 primary metrics tied to that decision, (3) add 3-5 diagnostic metrics that explain movement in the primaries, (4) describe the layout and cadence, (5) note one data quality risk and how you would handle it.
This structure shows the interviewer you think about dashboards as decision-support tools, not decoration.
References
Marty Cagan emphasizes outcome-driven product teams where metrics serve decisions, not vanity (Cagan, Marty. Empowered. Wiley, 2020). Jeff Gothelf advocates for measuring outcomes over outputs in lean product development (Gothelf, Jeff. Lean UX. O Reilly, 2021). Lenny Rachitsky regularly covers dashboard design principles in his newsletter for product managers (Rachitsky, Lenny. Lennys Newsletter. Substack, 2024).