Mapping Input Metrics That Drive Your North Star
This skill teaches you how to identify, define, and validate the 3-5 input metrics that causally drive your North Star Metric, turning an abstract guiding star into a concrete product manager roadmap of measurable levers your teams can actually move.
Start by decomposing your North Star Metric into the 3-5 measurable behaviors or outcomes that directly influence it. For each candidate input, test whether improving it would reliably move the North Star. Validate causal relationships using historical data or experiments. Then assign ownership to specific teams so each input becomes an actionable lever on your product manager roadmap, not just a number on a dashboard.
Outcome: You produce a validated input metric map—a documented set of 3-5 measurable, team-ownable metrics with demonstrated causal links to your North Star—that becomes the operating backbone of your product manager roadmap and weekly team rituals.
Prerequisites
- A defined North Star Metric (see Identifying Your Product's North Star Metric)
- Access to product analytics data (event-level or aggregated)
- Basic understanding of correlation vs. causation
- Familiarity with your product's core user journey and key touchpoints
Overview
Once you've identified your North Star Metric using the North Star Framework, the next critical step is figuring out what actually moves it. A North Star Metric alone is a compass heading—it tells you where you want to go, but not which levers to pull to get there. Input metrics are those levers. They represent the specific, measurable user behaviors and product outcomes that causally drive your North Star. Without them, teams stare at a single number they can't directly influence, and the metric becomes a vanity scoreboard instead of a working tool.
Mapping input metrics is the bridge between strategy and execution. It transforms your product manager roadmap from a list of features into a system of bets—each initiative tied to a specific input metric, each input metric connected to measurable progress on your North Star. When Spotify chose weekly active listeners as their North Star, for instance, they needed to identify inputs like 'new playlists created,' 'tracks added to library,' and 'listening sessions per user per week' to give individual squads something concrete to optimize.
This skill is where the North Star Framework becomes genuinely operational. You'll learn to decompose your North Star into candidate inputs, stress-test causal relationships, avoid vanity sub-metrics, and assign ownership so every team knows exactly which number they're responsible for moving. Done well, this mapping exercise eliminates the 'but what should we actually build?' paralysis that plagues product teams who have a North Star but no idea how to steer toward it.
How It Works
The mental model behind input metric mapping is causal decomposition. Your North Star Metric is an outcome—it's the result of multiple upstream behaviors and conditions. Input metrics capture those upstream drivers. Think of it like a river system: your North Star is the flow volume at the mouth of the river, and your input metrics are the tributaries feeding it. If you want more flow at the mouth, you need to understand which tributaries contribute the most and which ones you can actually influence.
The key distinction is between correlation and causation. Many metrics will move in tandem with your North Star, but only a subset actually cause it to move. For example, if your North Star is 'weekly meals cooked using the app,' you might notice that users who connect their grocery list also cook more. But does connecting the grocery list cause more cooking, or do already-motivated users simply do both? This distinction matters because you'll invest engineering time and product manager roadmap priority based on these relationships.
Input metrics must pass three tests. First, they must be influenceable—your team can take specific actions to move them. 'GDP growth' is not an input metric. Second, they must be leading indicators, meaning they change before your North Star changes, giving you an early signal. Third, they must be non-redundant—each input should capture a distinct dimension of what drives the North Star. If two candidate inputs are 95% correlated with each other, you likely only need one.
The typical sweet spot is 3-5 input metrics. Fewer than three usually means you're oversimplifying and missing an important driver. More than five creates focus problems—teams can't meaningfully prioritize across too many competing inputs, and your product manager roadmap becomes fragmented. The goal is a compact, complete model: together, your inputs should explain the majority of variance in your North Star.
Step-by-Step
Step 1: Decompose your North Star into candidate drivers
Start with your North Star Metric and work backward through the user journey. Ask: 'What has to happen for this number to go up?' Write down every user behavior, product event, and system condition that could plausibly influence it. Don't filter yet—aim for 10-20 candidates. If your North Star is 'weekly active projects,' candidates might include new projects created, collaborators invited, templates used, files uploaded, comments posted, and integrations connected. Use journey maps, funnel data, and team brainstorms to generate a comprehensive list.
Tip: Run this as a cross-functional exercise with engineering, design, data, and customer-facing teams. Each function sees different parts of the user journey and will surface candidates others miss.
Step 2: Filter for influenceability and directness
Review each candidate and apply two filters. First, can your product team directly influence this metric through product changes, experiments, or campaigns? Remove anything outside your control (e.g., 'user's internet speed'). Second, is the relationship direct or does it pass through multiple intermediate steps? Prefer metrics that are one causal step from your North Star rather than two or three steps removed. A metric like 'onboarding completion rate' is more direct than 'blog visits' when your North Star is activation-related.
Tip: If you're unsure whether something is influenceable, ask: 'Can I design an experiment in the next quarter that would move this number by 10%?' If the answer is no, it's probably not a useful input metric.
Step 3: Test for leading indicator behavior
For each remaining candidate, examine whether changes in the candidate precede changes in your North Star. Pull 6-12 months of historical data and look at time-lagged correlations. If inviting a collaborator this week predicts the user having an active project next week, that's a leading indicator. If the candidate only moves simultaneously with or after the North Star, it's a lagging indicator or a side-effect and won't help you steer. Use cohort analysis—compare users who did and didn't perform the candidate behavior and track their subsequent North Star contribution.
Tip: You don't need rigorous statistical modeling at this stage. A simple cohort comparison in a spreadsheet (users who did X in week 1 vs. those who didn't, then tracking North Star behavior in weeks 2-4) is often sufficient to validate or disqualify a candidate.
Step 4: Check for redundancy and coverage
Plot your surviving candidates against each other. If two candidates are highly correlated (e.g., 'files uploaded' and 'storage used'), keep the one that's more actionable and drop the other. Then check for coverage: together, do your candidates represent the major pathways to your North Star? A common framework is to ensure you have at least one input from acquisition/activation, one from engagement/depth, and one from retention/expansion. If all your candidates cluster around engagement and none touch activation, you have a blind spot.
Tip: Arrange your input metrics as a simple causal diagram on a whiteboard. Draw arrows from each input to the North Star. If you see two inputs that would always move together, that's a redundancy signal.
Step 5: Define each input metric precisely
For each of your 3-5 selected inputs, write a metric specification: the exact name, the calculation formula, the data source, the time window (daily, weekly, monthly), and any filters or segments. 'Collaborators invited' is ambiguous—does it mean invitations sent, invitations accepted, or unique projects with at least one collaborator? Precision matters because different definitions lead to different product decisions. Document edge cases: does a user re-inviting someone who already declined count? Getting this right now prevents months of confusion later.
Tip: Use a metric spec template with fields for Name, Definition, Formula, Data Source, Owner, Time Grain, and Known Limitations. Share it in your team wiki so everyone references the same document.
Step 6: Assign team ownership for each input
Each input metric needs a single team or squad that is primarily responsible for moving it. This doesn't mean other teams can't influence it, but one team holds accountability. Map your organizational structure against the inputs: if your 'activation' input is 'first project created within 7 days,' the onboarding team owns it. If 'weekly collaboration events' is an engagement input, the collaboration features team owns it. Without clear ownership, input metrics become shared dashboards that everyone watches and nobody acts on.
Tip: When multiple teams could own an input, assign ownership to the team with the most direct influence over the user experience that drives it. Shared ownership almost always means no ownership.
Step 7: Validate with a pilot period
Before locking in your input metric map and restructuring your product manager roadmap around it, run a 4-6 week pilot. Have each owning team propose one initiative specifically designed to move their input metric, execute it, and measure whether the input moved and whether the North Star followed. This is your causal validation in practice. If a team successfully moves their input by 15% but the North Star doesn't budge, the causal link is weaker than you assumed and you may need to revisit your mapping.
Tip: Set explicit success criteria before the pilot: 'If we increase [input] by X% and see [North Star] move by at least Y% within Z weeks, we'll confirm this input.' Without pre-committed thresholds, you'll rationalize ambiguous results.
Step 8: Document and integrate into team rituals
Finalize your input metric map as a living document that shows each input, its definition, its owner, its current value, its target, and its relationship to the North Star. Integrate these metrics into your weekly product review, sprint planning, and quarterly roadmap planning. Each roadmap initiative should be tagged with the input metric it's designed to move. This closes the loop between strategy (North Star), tactics (input metrics), and execution (roadmap items), making your product manager roadmap a coherent system rather than a feature wishlist.
Tip: Create a one-page visual—sometimes called a 'metric tree' or 'North Star constellation'—that shows the North Star at the center with input metrics radiating outward. Post it where the team can see it daily. Visual proximity to the work keeps the framework alive.
Examples
Example: B2B Project Management SaaS
A mid-stage B2B project management tool has defined 'weekly active projects' as their North Star Metric. The product team has 25 people across four squads (onboarding, core editor, collaboration, and integrations). They have 18 months of analytics data and have noticed growth plateauing despite steady new sign-ups, suggesting a retention and engagement problem rather than an acquisition one.
The team brainstorms 14 candidate inputs, including projects created, tasks added, collaborators invited, templates used, integrations connected, files uploaded, comments posted, and mobile app usage. After filtering for influenceability and running cohort analyses on 12 months of data, they find three clear causal drivers: (1) 'Projects with 3+ collaborators in the first 14 days' (collaboration squad, r=0.72 with subsequent weekly activity), (2) 'Tasks completed in first 7 days' (core editor squad, strong leading indicator), and (3) 'At least one integration connected' (integrations squad, users who connect an integration have 2.3x higher 30-day retention). They drop 'templates used' despite high correlation because a cohort test showed that encouraging template use didn't move weekly active projects—motivated users just happened to use templates. Each squad now has one input metric they own, and the onboarding squad takes on a cross-cutting mission to improve all three inputs during the first-time user experience. The quarterly product manager roadmap is restructured: 60% of engineering capacity goes to initiatives explicitly tagged to one of these three inputs.
Example: Consumer Fitness App
A consumer fitness app has chosen 'weekly workouts completed' as their North Star Metric. They're a 30-person company with a single product team. They've seen strong download numbers from a viral TikTok campaign, but 7-day retention is only 18%. They need to figure out which behaviors in the first week predict whether a user becomes a regular exerciser through the app.
The team maps the user journey from download to third-week retention and identifies 11 candidate behaviors. Cohort analysis reveals four strong inputs: (1) 'Completed onboarding workout' (users who finish the introductory workout are 4.1x more likely to be active in week 3), (2) 'Set a weekly workout goal' (goal-setters have 2.8x higher retention), (3) 'Added a workout buddy' (social accountability drives 3.2x more weekly workouts), and (4) 'Logged a workout streak of 3+ days' (streak behavior strongly predicts long-term habit formation). They drop 'profile photo uploaded' and 'explored the exercise library' as correlated but not causal—experiments nudging those behaviors didn't move the North Star. The team settles on inputs 1, 2, and 3 for the current quarter, deferring streaks to Q2 since it depends on first getting users through inputs 1-3. The product manager roadmap shifts: the team deprioritizes a planned social feed feature (not connected to any input) and instead focuses on reducing friction in the onboarding workout (input 1) and making buddy invitations seamless (input 3).
Example: B2B Marketplace Platform
A two-sided B2B marketplace connecting manufacturers with distributors has defined 'monthly completed transactions' as their North Star Metric. They have separate teams for the supply side (manufacturer onboarding and catalog management) and demand side (distributor search and ordering). Both sides of the marketplace need to be healthy for the North Star to grow, but the teams have been working in silos with no shared framework for prioritization.
The cross-functional mapping session surfaces 16 candidates spanning both sides. After analysis, they identify four inputs: (1) 'New manufacturers with 10+ SKUs listed' (supply-side team—below this threshold, manufacturers don't get enough orders to stay active), (2) 'Distributors who complete their first order within 30 days of signing up' (demand-side team—first purchase is the strongest retention predictor), (3) 'Repeat order rate' (demand-side team—measuring the percentage of distributors who place a second order within 60 days), and (4) 'Average catalog freshness score' (supply-side team—a composite metric measuring how recently manufacturers updated pricing and availability, since stale catalogs drive distributors to competitors). The teams discover that their biggest North Star bottleneck isn't acquisition on either side—it's catalog freshness. Distributors abandon the platform when they encounter outdated pricing. This shifts the product manager roadmap dramatically: instead of building more distributor acquisition features, the supply team prioritizes automated catalog sync integrations, and the demand team builds real-time inventory visibility. Within one quarter, repeat order rate increases by 22%.
Best Practices
Limit yourself to 3-5 input metrics. Every additional metric above five dilutes team focus and makes it harder to attribute cause and effect. If you have six strong candidates, force-rank them and drop or combine the weakest—you can always rotate inputs in later quarters as your product manager roadmap evolves.
Ensure each input metric is owned by exactly one team with the authority and capacity to run experiments against it. Shared ownership leads to diffused accountability. If no single team can own a metric, it's probably defined at the wrong level of abstraction.
Revisit your input metric map quarterly. Products evolve, user behavior shifts, and what drove your North Star six months ago may not be the dominant driver today. Schedule a quarterly review alongside your roadmap planning to assess whether each input still demonstrates a causal link.
Favor behavioral metrics over proxy metrics. 'Projects with 3+ collaborators' is better than 'invitations sent' because it measures the outcome you care about rather than an action that may or may not lead to it. The closer your input is to real user value, the more reliable your model.
Document your reasoning, not just your choices. Write down why you selected each input metric and what evidence supports the causal link. When new team members join or leadership questions the framework, this documentation prevents the entire mapping exercise from being relitigated from scratch.
Use input metrics to say no. One of the most valuable functions of a well-mapped input metric set is giving you principled reasons to decline feature requests or initiatives that don't connect to any input. If a proposed project doesn't plausibly move one of your 3-5 inputs, it doesn't belong on the product manager roadmap this quarter.
Common Mistakes
Choosing vanity metrics as inputs because they're easy to measure
Correction
Page views, sign-ups, or app downloads feel satisfying to track but rarely have a direct causal link to your North Star. They're top-of-funnel volume metrics, not drivers of the core value your product delivers. To catch this mistake, ask: 'If we doubled this number overnight, would our North Star reliably increase?' If the answer is uncertain—perhaps more sign-ups just means more churn—the metric isn't a valid input. Replace it with something closer to the moment of value delivery, like 'users who complete their first workflow within 48 hours.'
Confusing correlated metrics with causal inputs
Correction
This is the most dangerous mistake because it leads you to invest roadmap resources in levers that don't actually work. Teams often see that users who perform behavior X also have high North Star values and conclude X drives the North Star. But the relationship might be reversed (high-value users just naturally do X) or both might be driven by a third factor. Always test directionality: do a cohort analysis where you compare users who started doing X in a specific period against those who didn't, and track whether the X-cohort's North Star contribution increased. If you can run an experiment that encourages X and measure the North Star impact, even better.
Mapping too many input metrics to avoid making hard choices
Correction
Teams frequently end up with 8-12 input metrics because every function wants their work represented. This defeats the purpose—when everything is a priority, nothing is. The symptom is that weekly reviews become status update marathons with no clear action items, and teams can't tell which metric matters most this quarter. Force yourself to a maximum of five. If stakeholders push back, remind them that omitting a metric from the input map doesn't mean ignoring it—it means it's not one of the primary levers for this phase. You can rotate inputs as your product matures.
Defining input metrics ambiguously so different teams interpret them differently
Correction
If engineering counts 'active users' as anyone who triggers an API call and product counts it as anyone who logs in to the UI, you'll spend meetings arguing about numbers instead of making decisions. This happens because teams skip the metric specification step and assume everyone shares the same mental model. Write a formal definition for each input with the exact event, filters, time window, and edge case handling. Circulate it, get sign-off from data engineering and analytics, and reference it in every dashboard. When in doubt, query the production database together to confirm you're counting the same thing.
Setting input metrics once and never revisiting them
Correction
Products change. A metric that was a powerful driver at the growth stage may plateau or become table stakes as you mature. Teams that treat input metrics as permanent fixtures end up optimizing for diminishing returns—pouring effort into an input that's already saturated while a new, untracked driver emerges. Build a quarterly review into your operating rhythm: check whether each input still moves the North Star, whether any input has hit a ceiling, and whether new user behaviors suggest an unlisted driver. Treat your input metric map as a living part of your product manager roadmap, not a constitutional amendment.
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.
Building Dashboards to Track Your North Star and Inputs
How to set up real-time dashboards and reporting structures that visualize your North Star Metric and its supporting input metrics.
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
How many input metrics should I map to my North Star Metric?
Aim for 3-5 input metrics. Fewer than three usually means you're missing an important driver—your model is incomplete and your product manager roadmap will have blind spots. More than five creates focus problems: teams can't meaningfully prioritize across too many competing inputs, weekly reviews become unfocused, and it becomes difficult to attribute which input is actually driving North Star changes. If you have six strong candidates, force-rank them and either drop or combine the weakest. You can always rotate inputs quarterly as your product matures.
How do I tell the difference between a correlated metric and a causal input metric?
Correlation means two metrics move together; causation means changing one reliably changes the other. The simplest test is a cohort comparison: find users who started performing the candidate behavior in a specific period, compare them against similar users who didn't, and track whether the behavior group's North Star contribution increased afterward. If you can run an A/B experiment that encourages the candidate behavior and measure the North Star impact, that's even stronger evidence. Be skeptical of metrics where the causal direction could be reversed—high-value users often perform many behaviors that look like inputs but are actually side effects of engagement.
How often should I revisit and update my input metric map?
Review your input metrics quarterly, ideally as part of your quarterly roadmap planning cycle. Check three things: (1) Does each input still show a causal relationship to the North Star in recent data? (2) Has any input hit a ceiling where further improvement yields diminishing returns? (3) Have new user behaviors or product changes introduced a potential new driver that isn't being tracked? Treat the input metric map as a living document on your product manager roadmap, not a one-time exercise. Most mature product teams evolve at least one input metric per year.
Can two teams share ownership of the same input metric?
Avoid shared ownership whenever possible. When two teams share an input metric, accountability diffuses—each team assumes the other will take the lead, and neither feels the urgency to run experiments or prioritize initiatives against it. If a metric genuinely spans two teams' domains, either redefine it at a more specific level where ownership is clear, or assign a primary owner with a secondary contributor. The primary team leads the metric in weekly reviews and has final say on prioritization decisions related to it.
What if my North Star Metric moves but none of my input metrics changed?
This signals that your input metric map is incomplete—there's a driver you haven't identified. First, check for external factors (seasonality, marketing campaigns, press coverage) that might explain the North Star movement. If those don't explain it, dig into your analytics to find which user cohorts or behaviors drove the change. This investigation often reveals a new candidate input metric you should add to your map. It's also possible that your North Star is defined too broadly, capturing value drivers that your current inputs don't represent. Use this as a trigger for a mapping refresh.
How do input metrics connect to my product manager roadmap and sprint planning?
Every initiative on your product manager roadmap should be tagged with the input metric it's designed to move. During sprint planning, teams prioritize work that moves their owned input metric, not just work that ships features. In weekly reviews, teams report on their input metric's trajectory and what they're doing to move it. This creates a direct chain from daily work to sprint goals to input metrics to North Star. If a proposed feature or project can't be connected to any input metric, it either reveals a gap in your input map or it's work that doesn't align with your current strategy—both are important signals.