Building HEART Metric Dashboards to Power Your Product Manager Roadmap

Overview

How It Works

Step-by-Step

1. Step 1: Audit Your GSM Definitions

   Before touching any tool, pull up the Goals-Signals-Metrics table your team created during the HEART GSM process. For each of the five dimensions, confirm you have at least one concrete metric with a defined data source.

   Create a simple audit table:

   | Dimension | Goal | Signal | Metric | Data Source | Available? | |-----------|------|--------|--------|-------------|------------| | Happiness | Users feel satisfied | Survey responses | NPS score | Delighted/Typeform | ✅ | | Engagement | Users interact regularly | Session frequency | DAU/MAU ratio | Amplitude | ✅ |

   Any row where the data source is missing or the 'Available?' column is ❌ needs to be resolved before you build. Building a dashboard on incomplete data creates blind spots that undermine trust.

   Tip: If you haven't completed the GSM process yet, pause here. A dashboard without well-defined metrics is just decoration. Spend 1-2 hours with your team on GSM first.

2. Step 2: Choose Your Dashboard Tool and Data Architecture

   Select a tool based on your team's existing stack and data maturity. Common options:

   • Looker / Looker Studio (Google Data Studio): Great for teams already on BigQuery. Free tier available for Looker Studio.
   • Tableau: Best for complex visualizations and large datasets. Requires a license.
   • Amplitude / Mixpanel Dashboards: Ideal if your HEART metrics are primarily behavioral (Engagement, Retention, Task Success) and already tracked in a product analytics tool.
   • Google Sheets + Supermetrics: Low-cost option for early-stage teams. Limited but functional.

   Next, map out how data flows: raw events → aggregation layer → dashboard queries. For most teams this means product analytics events feed into a warehouse (BigQuery, Snowflake, Redshift), and the dashboard queries that warehouse. Survey data (Happiness) often requires a separate connector or a scheduled CSV import.

   Document this architecture in a one-page diagram. This prevents the most common failure mode: building a beautiful dashboard that breaks silently when a data pipeline changes.

   Tip: If your team already has a BI tool with established permissions and sharing, use it—even if it's not your personal favorite. Adoption beats aesthetics.

3. Step 3: Design the Dashboard Layout with the Five-Panel Pattern

   Sketch the layout before building anything. The proven pattern for HEART dashboards is:

   Top row: Five KPI summary cards, one per dimension. Each shows the current value, a trend arrow (vs. last period), and a color indicator (green/yellow/red based on your threshold).

   Below the summary: Five collapsible or tabbed sections, one per HEART dimension. Each section contains:

   • A time-series chart (line or area) showing the metric over the last 8-12 weeks
   • A segment breakdown (by platform, user cohort, geography, or plan tier)
   • A comparison to the target threshold

   Bottom row (optional): A correlation view showing how changes in one dimension (e.g., Task Success) relate to changes in another (e.g., Retention). This is advanced but extremely powerful for product manager roadmap prioritization because it reveals which UX improvements have the highest downstream impact.

   Sketch this on paper or in Figma first. Share the sketch with at least one stakeholder and one data engineer for feedback before building.

   Tip: Label each panel with the dimension name AND the specific metric. 'Engagement: DAU/MAU Ratio' is far more useful than just 'Engagement' when someone pulls up the dashboard cold.

4. Step 4: Build the Summary Row First

   Start with the five KPI cards. This is the most viewed part of the dashboard and the section stakeholders will reference in every review.

   For each card, configure:

   1. Current value: Pull the latest aggregated metric (e.g., this week's NPS, this month's DAU/MAU)
   2. Comparison period: Show the delta vs. the previous period (week-over-week or month-over-month, depending on your metric's natural cadence)
   3. Threshold coloring: Define three zones. For example, for Retention: green = >80%, yellow = 70-80%, red = under 70%. These thresholds should come from your GSM definitions or be agreed upon with your team.
   4. Trend indicator: A simple arrow (↑ ↓ →) communicates direction at a glance.

   Test each card by verifying the number against a manual query or your analytics tool's native report. Discrepancies at this stage erode trust permanently.

   Tip: Set thresholds conservatively at first. It's better to tighten thresholds over time than to trigger false alarms that train your team to ignore the dashboard.

5. Step 5: Build the Dimension Detail Panels

   For each of the five HEART dimensions, create a detail section with three core visualizations:

   Time-series trend: Plot 8-12 weeks of data. Use a line chart for single metrics, an area chart if you're stacking segments. Add a horizontal reference line for your target threshold. This chart answers: 'Are we getting better or worse?'

   Segment breakdown: Choose the most actionable segmentation for each dimension. For Adoption, segment by acquisition channel. For Happiness, segment by user tenure (new vs. returning). For Task Success, segment by feature or flow. Use a bar chart or small multiples. This answers: 'Where is the problem?'

   Annotations: Add vertical markers for major product releases, experiments, or external events. When Retention dips and you can see it coincided with a pricing change, the dashboard tells a story instead of just showing a number.

   Build each panel referencing the detailed metric guidance from Tracking Engagement and Retention Metrics at Scale and Measuring Adoption Rates and Task Success for New Features.

   Tip: Add a text box or annotation widget at the top of each dimension panel where the responsible PM can leave a brief written interpretation after each review cycle. Data + narrative is far more persuasive than data alone.

6. Step 6: Configure Alerts and Automated Sharing

   A dashboard that nobody looks at is worthless. Set up two mechanisms to drive ongoing engagement:

   Threshold alerts: Configure email or Slack alerts when any HEART metric crosses from green to yellow, or yellow to red. Most BI tools support this natively. Keep alerts sparse—only fire on genuine threshold crossings, not normal fluctuations.

   Scheduled snapshots: Set up a weekly automated email or Slack message that sends a screenshot or link to the dashboard summary row. Time it to arrive 1-2 hours before your weekly product sync so the team reviews it with fresh context.

   In many teams, this single step—automating the nudge—is what separates dashboards that die after two weeks from dashboards that become indispensable to the product manager roadmap process.

   Tip: Create a dedicated Slack channel (e.g., #heart-metrics) for alerts and discussion. This keeps metric conversations visible and searchable.

7. Step 7: Run a Dashboard Walkthrough with Stakeholders

   Before declaring the dashboard 'done,' schedule a 30-minute walkthrough with your core stakeholders: product leads, engineering managers, design leads, and at least one executive sponsor.

   Structure the session:

   1. 2 minutes: Explain the HEART Framework briefly (or link to your team's GSM document)
   2. 5 minutes: Walk through the summary row, explaining each metric and its current status
   3. 10 minutes: Drill into 1-2 dimensions that have interesting stories (a recent dip, a successful improvement)
   4. 10 minutes: Collect feedback: Are the metrics the right ones? Are the thresholds reasonable? Is anything confusing?
   5. 3 minutes: Agree on the review cadence (weekly sync, monthly deep-dive, quarterly planning)

   Document the feedback and iterate. The walkthrough isn't a presentation—it's a calibration session that builds shared ownership of the dashboard and ensures it influences the product manager roadmap going forward.

   Tip: Record the walkthrough and share it in your team wiki. New team members can onboard to the dashboard without scheduling another live session.

8. Step 8: Establish a Maintenance and Evolution Cadence

   Dashboards decay. Data pipelines change, metrics evolve, and new features require new tracking. Schedule a quarterly 'dashboard health check' where you:

   • Verify all data sources are still connected and accurate
   • Review whether the current metrics still reflect the team's goals (goals shift as the product matures)
   • Add or retire dimensions as needed (e.g., Adoption may be less relevant for a mature product with stable user growth)
   • Update thresholds based on the last quarter's performance
   • Incorporate new segmentation if your user base has evolved

   This maintenance cadence ensures the dashboard remains a living tool rather than a historical artifact. Teams that skip this step find their dashboards become irrelevant within 2-3 quarters, forcing a costly rebuild.

   Tip: Assign a 'dashboard owner' on the product team. Without clear ownership, maintenance tasks fall through the cracks.

Examples

Best Practices

• Keep the summary row visible without scrolling—stakeholders should grasp overall UX health in under 10 seconds, which makes the dashboard effective for both quick check-ins and formal product manager roadmap reviews.

• Use consistent color coding across all five HEART dimensions (green/yellow/red thresholds) so viewers instantly recognize which areas need attention without reading labels.

• Include the date range and last-refreshed timestamp prominently on the dashboard. Stale data presented as current is worse than no data at all.

• Pair every quantitative metric with a qualitative annotation space. The NPS number tells you what changed; the PM's written note tells you why it changed and what the team is doing about it.

• Design for your least technical stakeholder. If your VP of Marketing can't interpret the dashboard without explanation, simplify the visualizations until they can.

• Version your dashboard. When you make significant changes to metrics or layout, save the previous version and document what changed and why. This preserves historical context for retrospectives.

Common Mistakes

Frequently Asked Questions