Product Management

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.

Acceptance criteria are the conditions a feature must meet for a PM to sign it off as done. They define the boundaries of a user story: what the system will do, what it won't, and which edge cases matter. Well-written criteria are specific enough to test ("the export produces a valid CSV within 3 seconds for up to 10,000 rows") but not so prescriptive they dictate implementation. They are not test cases — they are the precondition for writing test cases. QA engineers write acceptance criteria implicitly every time they design a test suite; the PM transition requires writing them explicitly, before code exists, as a negotiated contract between PM, engineering, and QA. The common failure is covering only the happy path — experienced testers instinctively reach for edge cases, which is exactly the right instinct to carry forward.

Cohort analysis groups users by a shared characteristic at a specific point in time — usually when they first signed up or first performed an action — and tracks their behaviour across subsequent periods. It is the standard method for measuring retention without the distortion that new-user growth introduces: rising daily active users can mask worsening retention if you acquire users faster than you lose old ones. A cohort retention chart has signup week on one axis, weeks since signup on the other, and retention rate as the cell value. The signature of product-market fit is a retention curve that flattens above zero rather than trending toward zero. For QA engineers, cohort analysis resembles regression tracking across release cycles: both ask whether a population maintains expected behaviour over time, just at different scales.

Jobs to be Done is a framework for understanding why customers hire a product. A "job" is the underlying progress a person is trying to make in a specific situation — not demographics ("35-year-old manager") but motivation ("help me give stakeholders confidence the release is safe"). Clayton Christensen popularised the idea; Tony Ulwick operationalised it into Outcome-Driven Innovation. JTBD interviews focus on the purchase story: what triggered the search, what alternatives were considered, and what caused the switch. The insight is that competitors are not always obvious — a spreadsheet competes with a project management tool if the job is "stay in control of my team." For QA-to-PM transitioners, JTBD reframes users from "people who file bugs" to "people trying to ship confidently" — a small shift with large consequences for what you build.

Minimum Viable Product is the smallest version of a product that lets you test a core assumption with real users and generate validated learning. The word "minimum" does not mean low quality — it means minimum scope. An MVP can be polished; it is simply not feature-complete. The concept is widely abused to justify shipping half-finished work under the banner of "we'll iterate," which is a delivery failure dressed up as product thinking. Eric Ries's original definition centres on learning, not launching: an MVP is an experiment, not a release. QA engineers often recoil at MVPs because the scope looks under-tested. The reframe: an MVP is tested deeply for the one assumption it exists to validate, not for completeness. Coverage is deliberately narrow and intentional — a different discipline from full-release testing, not an absence of discipline.

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.

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.

Problem validation is the practice of confirming that a problem is real, significant, and widespread before building a solution. The tool set includes user interviews (direct evidence), support ticket analysis (indirect signal), usage data (quantitative), and competitor research (market signal). Validation fails in two directions: false positive (you believe the problem is real because your most vocal customers have it, but most users don't) and false negative (you discount a real problem because it is hard to articulate in interviews). The lean loop — problem hypothesis → smallest experiment → decision — applies directly. For QA engineers moving into product, the "what could go wrong" instinct maps cleanly onto validation: both disciplines search for failure modes in a hypothesis. The shift is running that search before code exists, on assumptions rather than implementations.

Product discovery is the work that happens before a single line of code is written: identifying real user problems, validating that they are worth solving, and shaping a solution hypothesis. It involves interviews, observation, prototype testing, and quantitative analysis — the goal is to collapse uncertainty before committing engineering effort. Discovery is never "done"; product teams run it in parallel with delivery to stay ahead of the build queue. The common trap is confusing discovery with research reports that nobody reads; discovery output is a decision: build this, not that, and here is the evidence. For QA engineers moving into product, discovery is where the instinct for "what could go wrong" is most valuable — testing a problem statement or a prototype applies the same rigour as testing a feature, just earlier and cheaper.

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.

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-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 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.

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.

User research is the practice of systematically learning how people think, feel, and behave in relation to a product or problem. Methods split into generative (discovery-oriented: interviews, contextual inquiry, diary studies) and evaluative (testing a solution: usability tests, A/B tests, surveys). The most common mistake is treating research as a one-time gate rather than a continuous discipline. A 30-minute user interview per week, compounded over a quarter, builds pattern recognition that transforms product intuition. Recruiting bias — talking only to power users or company friends — corrupts findings badly. QA engineers have a natural head start: writing a test case requires modelling user behaviour under adverse conditions, which is essentially the same cognitive work as a usability test. The gap is comfort with ambiguous, open-ended questions rather than pass/fail verdicts.

A user story is a short, human-centred description of a feature: "As a [type of user], I want [some goal] so that [some reason]." The format forces scope discipline — if you can't complete the sentence, the story is not well understood. Stories are units of conversation, not specification; the real value is the discussion they trigger between PM, designer, and engineer. Story splitting is a core skill: a story that takes more than one sprint to deliver is almost certainly two or three stories in disguise. For QA engineers moving into product, user stories feel immediately familiar — acceptance criteria are test conditions expressed in business language. The adjustment is writing stories before knowing how they will be implemented, living with ambiguity in the what while the team works out the how.