Product Requirements Document (PRD)
// Definition
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.
// Related terms
User story
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.
Acceptance criteria
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.
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.
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.