Building Dashboards to Track Your North Star and Input Metrics
This skill teaches you how to design and implement real-time dashboards that visualize your North Star Metric alongside its supporting input metrics, giving your team a single source of truth for product health and growth.
Start by placing your North Star Metric prominently at the top of a single dashboard, then layer in 3-5 input metrics that directly drive it. Use time-series charts for trends, set clear targets with visual thresholds, and connect to live data sources so the dashboard updates automatically. Include drill-down capability so any technical product manager or stakeholder can investigate metric movements without requesting ad-hoc analysis.
Outcome: You'll have a live, always-current dashboard that shows your North Star Metric and its input metrics at a glance, enabling your team to detect problems early, celebrate wins with evidence, and make prioritization decisions grounded in real data rather than gut feeling.
Prerequisites
- A defined North Star Metric (see: identifying-your-north-star-metric)
- Mapped input metrics that drive your North Star (see: mapping-input-metrics-to-north-star)
- Access to a BI or analytics tool (Looker, Tableau, Amplitude, Mixpanel, Metabase, or similar)
- Basic understanding of SQL or your analytics tool's query language
- Access to your product's data warehouse or event tracking pipeline
Overview
A North Star Metric only drives alignment when everyone can see it. Without a visible, shared dashboard, even the best-defined metric becomes something people reference in quarterly reviews but forget about day-to-day. Building a North Star dashboard transforms an abstract strategic concept into an operational tool—a living artifact that your team checks daily and references in every sprint planning, stakeholder review, and prioritization debate.
For a technical product manager, this skill sits at the intersection of data engineering, product strategy, and team communication. You need to understand the data model well enough to query it correctly, the product strategy well enough to choose the right visualizations, and team dynamics well enough to design something people actually use. The dashboard isn't just a reporting tool; it's the physical manifestation of your North Star Framework, as defined in the North Star Framework. When built well, it creates a feedback loop: teams ship features, the dashboard reflects the impact, and that reflection informs what to build next.
The difference between a dashboard that gets bookmarked and one that gets ignored comes down to design choices—hierarchy, simplicity, and actionability. This skill walks you through the principles and practical steps to build a dashboard that earns its place as your team's default browser tab.
How It Works
A North Star dashboard works by creating a visual hierarchy that mirrors your strategic hierarchy. Your North Star Metric sits at the apex—it's the first thing anyone sees. Beneath it, 3-5 input metrics show the levers your team can actually pull. Beneath those, optional operational metrics provide diagnostic depth. This layered structure means a glance tells you 'are we healthy?' while a click tells you 'where's the problem?'
The conceptual model is a causal chain rendered visually. If your North Star is 'Weekly Active Subscribers Who Complete a Workout,' your inputs might be new subscriber activation rate, workout content engagement rate, and push notification opt-in rate. The dashboard doesn't just show these numbers in isolation—it shows them in relationship. When your North Star dips, you should be able to scan the input metrics and immediately form a hypothesis about which lever moved.
This works because of a psychological principle: what gets measured and displayed gets managed. When a metric is visible on a shared screen or a team's home dashboard, it creates ambient awareness. People notice trends without being told to look. A technical product manager uses this ambient awareness to shift conversations from 'what should we build?' to 'this input dropped 12% last week—what's causing it and what should we do?'
The technical foundation requires reliable data pipelines. Your dashboard is only as trustworthy as the data feeding it. If numbers lag by 48 hours or occasionally show nulls, people lose trust and stop checking. This is why the implementation steps below emphasize data validation before visualization—you need to verify the data layer before investing in the presentation layer.
Step-by-Step
Step 1: Audit Your Data Sources and Pipeline Reliability
Before opening any dashboard tool, verify that the data underlying your North Star and input metrics is reliably collected, stored, and accessible. Check your event tracking implementation for completeness—are all the events needed to calculate your metrics firing correctly? Query your data warehouse to confirm freshness (how old is the latest data?), completeness (are there gaps or null values?), and accuracy (does a manual spot-check match expected numbers?). Document any known data quality issues and decide which must be fixed before dashboard launch versus which can be flagged with caveats.
Tip: Run your North Star calculation query manually and compare the result to a rough estimate from another source (e.g., a product analytics tool). If the numbers diverge by more than 5%, investigate before building any visualizations on top of unreliable data.
Step 2: Define Metric Calculations and Document Them
Write explicit definitions for every metric on the dashboard, including the exact SQL query or analytics tool configuration that produces each number. For your North Star, specify the time window (daily, weekly, trailing 28-day), any filters (exclude internal users, bots, test accounts), and the denominator if it's a rate. Do the same for each input metric. Store these definitions in a shared document or directly in your BI tool's metric layer. This prevents the 'which number is right?' debates that erode dashboard trust.
Tip: Use your BI tool's semantic layer or metrics layer (Looker's LookML, dbt metrics, Tableau calculated fields) to define metrics once and reuse them across dashboards. This ensures consistency and makes future changes propagate automatically.
Step 3: Design the Dashboard Layout on Paper First
Sketch the dashboard layout before touching your BI tool. Place the North Star Metric at the top in a large, prominent position—this is the hero element. Below it, arrange 3-5 input metrics in a row of cards or small charts. Below the input metrics, add time-series trend charts that show the North Star and each input over the past 8-12 weeks. Reserve the bottom section for diagnostic breakdowns (by segment, platform, cohort) that help explain movements. The layout should tell a story from top to bottom: 'here's where we are → here's what's driving it → here's where to dig deeper.'
Tip: Apply the 'five-second test': if someone glances at your dashboard for five seconds, can they answer 'are we on track?' If they can't, your hierarchy needs work. The North Star number and its trend direction should be instantly legible.
Step 4: Set Targets and Visual Thresholds
Every metric on the dashboard needs a target or acceptable range. Without targets, numbers are just numbers—they don't tell you whether to celebrate or panic. Work with your team and stakeholders to set realistic targets for the current quarter. Then configure visual thresholds in your dashboard: green when above target, yellow within 10% below, red when significantly below. For time-series charts, add a target line so the trend is always shown in context. These thresholds turn passive data consumption into active alerting.
Tip: Set targets based on historical performance plus a realistic improvement rate, not aspirational moonshots. If your North Star grew 3% month-over-month for the last six months, setting a 15% target will just make the dashboard permanently red, which teaches people to ignore it.
Step 5: Build the Dashboard in Your BI Tool
Implement your paper design in your chosen tool. Start with the North Star headline number and its week-over-week or month-over-month trend. Add input metric cards with sparklines. Build the time-series trend charts with consistent date ranges and axis scales. Add filters for common segmentation needs (platform, geography, user cohort) but keep the default view unfiltered to show the aggregate picture. Ensure the dashboard loads in under 5 seconds—slow dashboards don't get used. If queries are slow, consider pre-aggregating data in your warehouse.
Tip: Use consistent colors across the dashboard: one color for the North Star, and a distinct but harmonious palette for input metrics. When someone sees 'blue' on any chart, they should instantly know it represents your North Star.
Step 6: Add Drill-Down Paths for Diagnosis
A summary dashboard answers 'what happened?' but teams need to answer 'why did it happen?' Add drill-down capability so users can click on any input metric to see a breakdown by segment, cohort, or feature area. For example, if 'new user activation rate' drops, a drill-down might show activation by signup source, device type, or onboarding variant. These drill-downs can be linked sub-dashboards or expandable sections—the key is that investigation doesn't require leaving the dashboard ecosystem or requesting ad-hoc analysis from a data team.
Tip: Limit drill-down depth to two levels. If someone needs to go three levels deep, they probably need a dedicated analysis, not a dashboard. Keep the dashboard's purpose focused on monitoring and initial diagnosis.
Step 7: Configure Alerts and Scheduled Distribution
Set up automated alerts for significant metric movements—email or Slack notifications when the North Star drops below its threshold or when any input metric moves more than two standard deviations from its recent average. Also configure a weekly email or Slack digest that summarizes the dashboard state: North Star value, trend direction, and any input metrics flagged yellow or red. This push mechanism ensures the dashboard reaches people who might not proactively check it, especially executives and cross-functional stakeholders.
Tip: Tune alert sensitivity carefully in the first two weeks. Too many false alarms create alert fatigue faster than having no alerts at all. Start conservative (only red-level alerts) and add sensitivity once you've calibrated normal variance.
Step 8: Socialize the Dashboard and Establish a Review Cadence
A dashboard nobody looks at is worthless. Introduce the dashboard at a team all-hands or product review meeting. Walk through each section, explain what each metric means and why it matters, and show how to use drill-downs. Then establish a weekly ritual—a 15-minute 'metric review' at the start of your team meeting where someone walks through the dashboard state, highlights movements, and connects them to recent product changes. This cadence turns the dashboard from a tool into a habit. Reference the principles from aligning teams around a North Star Metric to structure these conversations.
Tip: Rotate who presents the dashboard review each week. This distributes data literacy across the team and prevents the dashboard from becoming 'one person's thing' that dies when they go on vacation.
Examples
Example: B2B SaaS Collaboration Tool Dashboard
A technical product manager at a 50-person SaaS company has defined their North Star Metric as 'Weekly Teams with 3+ Active Collaborators'—measuring the number of teams where at least three members performed a meaningful collaboration action (commenting, sharing, or co-editing) in the past seven days. They've identified four input metrics: new team activation rate, weekly collaboration frequency per team, feature adoption breadth, and churn-risk score. They use Looker connected to a BigQuery data warehouse.
The PM builds a Looker dashboard with the North Star as a single-number tile at top-center, showing 1,247 teams this week with a +4.2% week-over-week trend in green. Below that, four input metric tiles show: new team activation at 34% (yellow, target is 40%), weekly collaboration frequency at 8.3 actions/team (green), feature adoption breadth at 3.1 features/team (green), and churn-risk score at 12% (red, up from 9%). A time-series chart below shows all five metrics over 12 weeks with a target line for the North Star at 1,400 by quarter end. Clicking the churn-risk tile opens a drill-down showing churn risk by company size and signup cohort, revealing that teams from the Q4 marketing push have 2x higher churn risk—immediately surfacing a retention problem for the team to investigate.
Example: Consumer Health App Dashboard
A technical product manager at a health and fitness startup has set 'Weekly Users Who Log 3+ Healthy Meals' as their North Star Metric. Input metrics include daily app opens, meal log completion rate, recipe save rate, and grocery list usage. The team uses Amplitude for product analytics and exports aggregated data to a Metabase dashboard for broader company visibility.
The PM configures Amplitude charts for real-time input metric monitoring and builds a Metabase dashboard for the weekly company review. The Metabase dashboard opens with a large card: '23,400 users logged 3+ meals this week' with a sparkline showing the 8-week trend. Four smaller cards beneath show each input metric with trend arrows. The PM adds a cohort breakdown chart showing the North Star metric segmented by user tenure (0-30 days, 31-90 days, 90+ days), revealing that 90+ day users have a 62% meal-logging rate while 0-30 day users are at only 18%. This insight drives the team to prioritize new-user onboarding improvements. A weekly Slack digest auto-posts every Monday morning with the dashboard screenshot and a one-line summary generated from a simple template: 'North Star: 23.4K (+6% WoW). New user logging remains below target—onboarding experiment launching Thursday.'
Example: Marketplace Platform Executive Dashboard
A technical product manager at a two-sided marketplace (connecting freelance designers with businesses) needs a dashboard for both the product team and the executive team. The North Star Metric is 'Weekly Completed Projects with 4+ Star Rating.' Input metrics are new buyer activation, designer response time, project match rate, and repeat buyer rate. The data lives in Snowflake and the team uses Tableau.
The PM builds two connected dashboards. The executive dashboard shows just four elements: the North Star headline number (892 projects, +2.1% WoW), a 12-week trend chart with the quarterly target line at 1,100, a supply/demand balance indicator (designer availability vs. buyer requests), and a single table showing each input metric with its current value, target, and status color. The product team dashboard links from each input metric on the executive view and adds breakdowns by project category, geographic market, and designer tier. The PM configures Tableau alerts: if the North Star drops more than 5% week-over-week or designer response time exceeds 4 hours, a Slack notification fires to the #product-metrics channel. After the first month, the PM notices the executive team only looks at the dashboard during Monday leadership meetings, so they add a scheduled PDF email that arrives at 8 AM Monday with a snapshot—meeting the audience where they are rather than expecting them to visit Tableau.
Best Practices
Keep the default dashboard view to a single screen—no scrolling required to see the North Star and all input metrics. Scrolling kills engagement. If you need more detail, use drill-down links to sub-dashboards rather than cramming everything onto one page.
Version your metric definitions alongside your code. When the calculation for an input metric changes (e.g., you redefine 'active user'), log the change with a date so historical trend breaks are explainable, not mysterious.
Include a 'last updated' timestamp prominently on the dashboard. This builds trust when data is fresh and immediately flags staleness when a pipeline breaks—people should never wonder whether the numbers are current.
Design for your least technical stakeholder. The CEO and the engineering lead should both be able to read the dashboard without a tutorial. Use plain-language metric names ('Weekly Active Subscribers' not 'WAU_sub_excl_trial_v3'), and add brief descriptions or tooltips for any metric that isn't self-explanatory.
Add annotations for major product launches, experiments, and external events directly on your time-series charts. A spike or dip without context triggers speculation; with an annotation ('launched new onboarding flow 3/15'), it tells a story. Most BI tools support chart annotations natively.
Review and prune the dashboard quarterly. As your product evolves, some input metrics become less relevant and new ones emerge. A dashboard cluttered with legacy metrics signals that nobody is actively maintaining it, which erodes trust. This aligns with the iterative philosophy described in iterating and evolving your North Star Metric.
Common Mistakes
Putting too many metrics on one dashboard
Correction
Dashboard overload is the most common failure mode. Teams add 'just one more metric' until the dashboard has 20+ charts and nobody knows where to look. This happens because people conflate 'comprehensive' with 'useful.' Limit your primary dashboard to the North Star plus 3-5 input metrics. Everything else belongs on a drill-down or secondary dashboard. A good test: if you can't explain every metric on the dashboard in under 60 seconds, it has too many.
Building the dashboard before validating data quality
Correction
Excitement about visualization leads teams to skip data validation. They build a beautiful dashboard, share it widely, and then someone notices the numbers don't match another report—and trust is permanently damaged. This happens because dashboard building feels productive while data auditing feels tedious. Always run validation queries first. Compare your calculations against at least one other data source. Fix discrepancies before anyone outside your immediate team sees the dashboard.
Showing metrics without targets or context
Correction
A dashboard that shows 'Weekly Active Users: 45,230' tells you nothing unless you know whether that's good or bad, up or down. Teams skip target-setting because it requires difficult conversations about what's achievable. But without targets, the dashboard becomes wallpaper—people glance at it without processing what they see. Always show current value, trend direction (week-over-week or month-over-month change), and a target line on trend charts.
Making the dashboard but never establishing a review ritual
Correction
Many dashboards are built with great enthusiasm, shared once in Slack, and then gradually forgotten. This happens because viewing a dashboard is a passive activity—without an active ritual, it loses to whatever feels more urgent. The fix is to embed dashboard review into an existing meeting cadence. Even five minutes at the start of your weekly team sync creates the habit. The person who built the dashboard should champion the first four weeks of reviews to establish the pattern.
Using vanity metrics as input metrics on the dashboard
Correction
Teams sometimes include metrics like total signups, page views, or app downloads because they trend upward and make everyone feel good. These metrics correlate loosely with your North Star but aren't actionable inputs your team can directly influence. The test is: if this metric moved 20% tomorrow, would your team change what they're building? If not, it doesn't belong on the North Star dashboard. Refer back to mapping input metrics to your North Star for guidance on choosing genuine input metrics.
Other Skills in This Method
Identifying Your Product's North Star Metric
How to discover and define the single metric that best captures the core value your product delivers to customers.
Mapping Input Metrics That Drive Your North Star
How to identify, define, and connect the 3-5 key input metrics that directly influence your North Star Metric.
Running a North Star Framework Workshop with Stakeholders
A step-by-step guide to facilitating a collaborative workshop where teams define or refine their North Star Metric and input metrics.
Using the North Star Metric to Prioritize Your Product Roadmap
How to evaluate and rank roadmap initiatives based on their expected impact on the North Star Metric and its input metrics.
Iterating and Evolving Your North Star Metric Over Time
When and how to revisit, validate, or change your North Star Metric as your product matures and strategy shifts.
Aligning Cross-Functional Teams Around a North Star Metric
Techniques for communicating, cascading, and embedding the North Star Metric across product, engineering, marketing, and leadership teams.
Related Skills from Other Methods
Frequently Asked Questions
What's the best dashboard tool for tracking a North Star Metric?
The best tool is the one your team already uses and trusts. Looker and Tableau offer the most powerful semantic layers for consistent metric definitions, making them ideal for organizations where data governance matters. Metabase and Preset (Apache Superset) are strong open-source options that a technical product manager can set up without dedicated BI engineering. Amplitude and Mixpanel work well when your North Star is behavioral (user actions) but struggle with metrics requiring warehouse joins across multiple data sources. The tool matters less than the data quality and the review habit you build around it.
How often should I update my North Star Metric dashboard?
Your dashboard should refresh at least daily for the product team and weekly for executive stakeholders. Real-time updates (every few hours) are valuable during experiments or launches but aren't necessary for steady-state monitoring. The critical factor is consistency—if your team expects the number to refresh every morning by 9 AM, a pipeline delay that causes stale data at 11 AM erodes trust. Build in a data freshness indicator and configure alerts for pipeline failures so you catch staleness before your stakeholders do.
Should input metrics and the North Star Metric be on the same dashboard?
Yes, always. Separating them defeats the purpose. The entire value of the North Star Framework is the causal relationship between inputs and the North Star—if a technical product manager has to switch between dashboards to see whether an input movement affected the North Star, they'll stop doing it. Keep the North Star and inputs on one primary dashboard, with drill-downs linking to more detailed views. The exception is if your dashboard tool has severe performance issues with multiple queries; in that case, use a summary view with clickable links to input detail pages.
How do I handle it when my North Star Metric has seasonal patterns?
Seasonal patterns make week-over-week comparisons misleading. Add a year-over-year comparison line to your trend charts so people can see whether a dip is seasonal or a real problem. Also consider showing a 'seasonally adjusted' metric alongside the raw number—your data team can calculate this using the same period last year as a baseline. Annotate known seasonal events (holidays, back-to-school, industry conferences) directly on the chart so viewers don't need to remember the calendar to interpret the data.
What should I do when stakeholders keep asking to add more metrics to the dashboard?
This is inevitable and must be managed actively. Every request to add a metric is a sign that someone cares about something—which is good—but accommodating all requests creates dashboard bloat. Establish a rule: for every metric added, one must be removed or moved to a drill-down. Ask the requester, 'If this metric changed significantly, what would you do differently?' If they can't answer, it's an informational metric that belongs in an ad-hoc report, not the North Star dashboard. Keep the primary view sacred—it's a monitoring tool, not a data catalog.
How do I get engineering buy-in to maintain the data pipeline for the dashboard?
Frame it as product infrastructure, not a reporting request. Engineers care about reliability and impact, so show them that dashboard-driven decisions directly influence what the team builds and how it's prioritized. Include pipeline health as a metric the engineering team owns—if the dashboard shows stale data, that's an engineering quality issue. A technical product manager can also reduce pipeline burden by pre-aggregating metrics in dbt or a similar transformation layer, keeping queries simple and fast so maintenance stays low.