Non-functional requirements describe how well the product must perform its functions. They are the quality characteristics, constraints, and standards the product must meet alongside its core functionality.
They are not features. They are the conditions under which features must work.
A feature that works but loads in twelve seconds is not a working feature. A feature that works but is inaccessible to users with visual impairments is not a complete feature. A feature that works but exposes user data to unauthorised access is a dangerous feature. Non-functional requirements are what prevent these situations.
They are also the requirements most frequently left out of PRDs written by less experienced product managers. Their absence does not surface immediately. It surfaces during development when engineers ask questions that should have been answered in the document, or after launch when the product behaves in ways that were never specified but should have been anticipated.
Performance requirements define how fast the product must respond and how much load it must handle.
Examples:
Reliability and availability requirements define how consistently the product must be available and how it must behave when things go wrong.
Examples:
Security requirements define how user data and system integrity must be protected.
Examples:
Accessibility requirements define the standards the product must meet to serve users with disabilities.
Examples:
Compliance and regulatory requirements define the legal and industry standards the product must adhere to.
Examples:
Scalability requirements define how the system must behave as usage grows.
Examples:
Remember this: Non-functional requirements are not optional additions to a PRD. They are the difference between a feature that works in testing and a feature that works in production, at scale, for all users, without causing harm. Define them before development begins or pay the cost of defining them mid-build.