North Star metric
// Definition
A North Star metric is the single number that best captures the core value a product delivers to customers — the one that, if it grows sustainably, predicts long-term business health. Spotify's was time-in-app; Airbnb's was nights booked. The North Star sits above vanity metrics (page views, sign-ups) and below revenue — it measures the value exchange, not the financial outcome. Choosing the wrong metric drives the wrong behaviour at scale: an engagement metric optimised without guardrails can increase usage while eroding user wellbeing. Supplement the North Star with counter-metrics to prevent gaming. For testers becoming PMs, this is a genuine mindset shift: QA thinks pass/fail (binary, per-release, reversible), while product thinks directional (continuous, long-horizon, probabilistic). Learning to act confidently on a trend rather than a verdict is the core adjustment.
// Related terms
AARRR metrics (Pirate metrics)
AARRR — Acquisition, Activation, Retention, Referral, Revenue — is a funnel framework coined by Dave McClure for measuring product lifecycle health. Acquisition: how do users find you? Activation: do they experience core value in the first session? Retention: do they return? Referral: do they tell others? Revenue: does the interaction generate money? Each stage surfaces different problems and often has different owners: marketing drives acquisition, product owns activation and retention. The framework's value is forcing you to look at the whole funnel — optimising acquisition while ignoring a leaky Retention stage is expensive failure. QA engineers naturally think in pipelines and staged execution; AARRR maps cleanly onto that mental model. The new skill is instrumenting each stage with real behavioural metrics rather than coverage percentages or defect counts.
Product-market fit
Product-market fit is the degree to which a product satisfies strong market demand — a state where users acquire, retain, and refer at rates that sustain growth without heavy marketing spend. Marc Andreessen defined it as "being in a good market with a product that can satisfy that market." Sean Ellis's heuristic: if more than 40% of surveyed users would be "very disappointed" if the product disappeared, PMF is likely. Before PMF, optimise for learning, not efficiency — every process and metric should target understanding what the market actually wants. After PMF, optimise for growth. For QA engineers pivoting to product, PMF reframes the entire quality conversation: before PMF you are validating the concept, not production polish; after PMF, reliability and quality become competitive differentiators that directly affect retention.
RICE prioritization
RICE is a scoring model for prioritising features: (Reach × Impact × Confidence) ÷ Effort. Reach is the number of users affected in a given period; Impact is a 0.25–3× multiplier for the per-user effect; Confidence is a 0–100% weight to hedge uncertainty; Effort is person-weeks of work. The model makes assumptions explicit and creates comparable scores across very different feature types. Its weaknesses are real: Confidence is almost always optimistic — teams consistently overstate certainty — and Effort estimates drift. RICE also scores poorly on strategic bets with low Reach and low Confidence that matter enormously for company direction. For QA-to-PM transitioners, RICE feels natural: it is essentially a risk-weighted scoring matrix, the same format testers use for defect triage and regression priority decisions.
Product roadmap
A product roadmap communicates where a product is going and roughly when — it is a strategic communication tool, not a delivery schedule. Good roadmaps operate at the outcome level ("reduce time-to-first-value for new users"), not the feature level ("add onboarding wizard"), because specific features are hypotheses that may change; outcomes are the commitment. Common formats include Now/Next/Later (no dates, emphasises learning), quarterly OKR-aligned (dates, suits larger organisations), and opportunity-solution tree (connects problems to solutions visually). The hardest PM skill is saying no to stakeholders whose requests don't fit the roadmap and holding that line. QA engineers entering product already understand that not everything can be tested deeply before release; roadmaps require the same triage instinct applied to what gets built, not just what gets verified.