A Product Requirements Document (PRD) is a written specification that describes a feature or product to be built. It defines the problem being solved, the target users, the success criteria, and the functional requirements · but not the technical implementation. A PRD bridges the gap between a business need and an engineering deliverable.
A PRD is a document that describes a complete feature or product area · it includes the problem context, success criteria, and all related requirements. A user story is a single, specific requirement written in the format "As a [user], I want [action] so that [outcome]." User stories are the atomic unit of work in agile development; a PRD might contain 5-20 related user stories. PRDs are written by product managers; user stories can be written collaboratively with the engineering team.
As short as possible while containing everything the team needs to build and test the feature correctly. For small features, one page. For large features or new products, five to ten pages. A PRD that runs to 30 pages typically contains too much design speculation, too many implementation details, or too little focus. If your PRD includes wireframes, database schemas, or API contracts, you have crossed into design specifications and technical architecture documents · which are separate artifacts.
The product manager is the author and owner of the PRD. Engineering, design, and data should be consulted during writing · not handed a finished document. A PRD that is written in isolation and thrown over the wall to engineering produces resistance and misalignment. The most effective PRDs are written with an engineering lead as a thought partner from the start, which surfaces technical constraints early and produces requirements that are actually buildable.
MoSCoW is a prioritization framework for requirements: Must Have (non-negotiable for launch), Should Have (important but not blocking), Could Have (nice to have if time allows), and Won't Have (explicitly excluded from this version). Applying MoSCoW to every requirement forces the product manager to make explicit trade-off decisions before engineering begins, rather than treating every requirement as equally important. It also gives engineering a clear framework for descoping under pressure without needing to escalate every decision.
Non-functional requirements describe how well the product must behave under real conditions. The international software quality standard groups these qualities into nine characteristics: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility and safety. Use the list as a checklist when you write the PRD, and keep the ones that matter for this feature. Make each requirement measurable, for example "search results load within two seconds for 95 percent of queries" or "every action works with a keyboard alone". A requirement nobody can test gets argued about at release. Source: ISO/IEC, ISO/IEC 25010:2023 Systems and Software Quality Requirements and Evaluation (SQuaRE): Product Quality Model (2023).