RICE prioritization
// Definition
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.
// Related terms
MoSCoW prioritization
MoSCoW splits features into Must have, Should have, Could have, and Won't have for a given release. The framework is useful for scope negotiation because it makes tradeoffs explicit and forces a conversation about what "done" means before work starts. Its failure mode is Must-have inflation: under stakeholder pressure everything becomes a Must have, which defeats the purpose. A release where 80% of items are flagged as Must-have is not prioritised — it is just a list. Pairing MoSCoW with effort estimates exposes which Musts are genuinely feasible given the timeline. For QA engineers becoming PMs, MoSCoW maps directly onto test triage decisions: Must-have tests are release blockers, Should-have tests run pre-release, Could-have tests run post-merge, and Won't-have items are accepted gaps with documented risk. The framing transfers with minimal adjustment.
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.
North Star metric
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.
Product Requirements Document (PRD)
A Product Requirements Document defines the problem being solved, the intended users, the success metrics, and the scope of a feature. Good PRDs are short and opinionated: they explain why, give guardrails for the team, and leave implementation decisions to engineers. Bad PRDs are long specification documents that freeze decisions too early and age poorly. The PRD does not prescribe UI layouts or implementation details — it describes the job the feature must do and the constraints it must satisfy. A well-written PRD becomes the shared contract between PM, design, and engineering before a line of code is written. For QA engineers transitioning to product, writing a PRD is familiar territory: the structure mirrors a test plan (scope, in/out, assumptions, risks) but starts with user need rather than code behaviour. The hardest part is stating what is explicitly out of scope.