User story
// Definition
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.
// Related terms
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 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.
BDD (Behaviour-Driven Development)
Collaborative specification writing using human-readable scenarios (Given/When/Then) shared across product, dev, and QA. Often automated with Cucumber, SpecFlow, or similar tools.
ATDD (Acceptance Test-Driven Development)
Extends TDD by writing acceptance tests collaboratively with the customer or product team before implementation begins. Aligns the team on what 'done' looks like in concrete, testable terms.