In the context of product ownership analysis, non-functional requirements play a significant role in product development. They can be used to constrain the PBIs by specifying limits. Non-functional requirements for products have a longer-term effect on products compared to projects.

For example, non-functional requirements determine what hosting or cloud platform to adopt for the product with respect to:

• Product scale,
• Security,
• Accessibility, and
• Serviceability.

Practitioners must treat the analysis of non-functional requirements with care by broadening the categories of NFRs to encompass new technological constraints and challenges.

For example, it may not be sufficient to mention that some of the product APIs must be secure when transferring data in or out of the product. The practitioner may have to understand and analyze the detailed threat vectors for data protection and include them in the NFR analysis.

In a product setting, NFRs are captured in Definition Concepts (Definition of Done, etc.) or acceptance criteria. It is recommended to aggregate all the NFRs in one place so that there is a holistic picture.

POA Domain	Non-Functional Requirements
Applying Foundational Concepts	NFRs play a limited role in this domain, except some high-level NFRs. However, if not addressed correctly, they may create challenges for achieving strategic goals. For example, a marketing goal may position the product as always available, but NFRs related to product availability may not be analyzed upfront. Consequently, the product is not provisioned for better availability and serviceability. This may lead to significant loss of brand if the product becomes unavailable.
Cultivate Customer Intimacy	NFRs may not seem like the first set of requirements to successfully address the needs of the customers, but most quality requirements (NFRs) augment the product experience. If the product has the right features but it takes a long time for a customer to complete a process, it generates friction and may increase customer churn. NFR analysis must also be conducted from the point of view of the customer.
Engage the Whole Team	NFR analysis may require technical expertise that the POA Practitioner may not have. The entire team needs to validate how NFRs translate in a technical sense for a shared understanding. There may be feasibility issues that require clarity for the whole team.
Make an Impact	NFR analysis results in the team ensuring and testing the product on quality characteristics. Failure to achieve the desired NFRs might mean that the product may be unavailable resulting in negative impact. NFRs must be analyzed to prevent issues in the smooth operation of the product.
Deliver Often	Iteration, releases, and story-level discussions must include quality criteria, so the product team understands expectations, not only from a features perspective, but also from an NFRs perspective. NFRs may be examined as often as functional requirements.
Learn Fast	NFR analysis typically includes a threshold value, or a range as a quality attribute. For example, the product should be able to support 10,000 users in the first three months of launch. In cases where the product fails to meet these parameters, the team must conduct root-cause analysis to understand and avoid future issues.
Obsess About Value	Product value involves both aspects of providing the desired features as well as the desired experience. NFRs play a significant role in fulfilling customer needs for a good experience with the product and achieving customer value.