MoSCoW prioritization

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.

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.

Stakeholder management

Stakeholder management is the ongoing practice of understanding, aligning, and communicating with people who have influence over or interest in your product — executives, engineering leads, sales, support, and customers. It is not about making everyone happy; it is about building enough trust and shared context that stakeholders don't derail prioritisation at the last minute. The failure mode is reactive management: taking feature requests in isolation, over-promising against the roadmap, and losing credibility when commitments slip. Proactive management means bringing stakeholders into the problem space before you have solutions, and narrating tradeoffs rather than outcomes. For QA engineers entering product, stakeholder management builds on an existing strength: writing clear bug reports is fundamentally about communicating risk to decision-makers, which is exactly what product management does for scope and priority decisions.