Motivation
Product owners are normally more concerned about things you can do with the solution you are building than about the quality of what it can do. As a result, items turning up on the backlog are mostly related to a feature (as in, something the user can do) rather than overall quality. From the product owner's perspective, the team might be making good progress, whereas in reality what is getting produced will never be able to cope with what can be expected to happen when going live.
Applicability
Every project should carefully consider the quality related attributes that need to be addressed. That does not necessarily mean that all projects need to have the same non-functional requirements. In fact, in some cases, after short but conscious consideration, the decision might be to just ignore non-functional requirements altogether. (In case of a one-off script?)
Application
Setting proper objectives for non-functionals is not easy. The problem is: your product owner (ideally the money owner) might have a hard time understanding what these quality attributes are all about. Yet, at the same time, you want to make sure that the product owner backs the plan to address a particular quality requirement, so you do want them to understand what they are essentially asking for.
One way to address it is by avoiding scales that are (mostly) well understood by developers, but not by non-IT people. So, you just define your own scales that are meaningful in the minds of the product owners. In some cases, that means defining some higher-order quality requirements, from which you then derive the lower-level quality requirements with related measurable scales that can be translated in actual work to be done.
One way or the other, the quality requirements eventually need to be translated into user stories, or be woven into the definition of done of other stories. You need the product owner's awareness of the fact that you are going to work on this, and you do want him to understand the relevance of it all.
One of the best sources of working this way is probably Gilb's 'Competitive Engineering'. You might not need to adopt his language. In most cases, it will be fine to define your own, one that is based on terminology that is well understood by the team. Aim for the riskiest non-functional requirements first.
Consequences
Spending time on working out the quality requirements with your product owner is going to take time. Plan for it. Start early, and refine the requirements iteratively.
References
- Competitive Engineering, Tom Gilb, 2005