Non functional requirements

For those who's been in the business of writing project definitions for outsourcing development activities recognize that any section of functional requirements would also be accompanied by a section with non functional requirements (NFR's from now on). The non functional requirements focused on how the product was supposed to work rather than what it was supposed to do. From distant memory I'd generalize that in terms of priority NFR's did not get much attention at the early stages of the development cycle, however at the end they received a lot more attention. I have a problem with the "requirements" part of NFR's but I'll leave that for a separate post.

NFR's usually contains all the boring stuff, you know performance, safety, scalability, availability etc... intangible stuff that really doesn't seem important until it isn't there and fails. In the agile mindset we trust a lot of this to the people who knows this in and out, skilled engineers. This is the best way of doing it since even small mistakes or nudges from a product owner might push these crucial aspects of the product off a cliff. However I see a two strong reasons for everybody in a team to be engaged in the design decisions affection NFR's.

Implicit
The biggest difficulty with NFR's is that they are often implicit and unspoken. Discussions about products can easily get stuck on what it should do and which features it should have. This means that the team must dedicate attention explicitly on the non functional aspects of the product, typically this should also be done from the UX perspective as an important part of this analysis also needs to consider who is going to use it. It is common for agile teams to have a person that focus on the user, but extremely rare with a person dedicated to the NFR's.

The difference between a prototype and an MVP
NFR's are key for putting a product in production and in turn in the hands of customers. Worst case if you don't do it right your product may fail and people will die. In a prototype that is demoed in controlled environments you can skip NFR's to some extent, it's not used for real, it's displayed or used in a predefined and scripted way. However even when you try to design you most aggressive MVP you can't skimp on the NFR's, you can leave functional features out to much larger extent but the NFR's tend be almost the same.

Early decisions, big impact
NFR's are frequently affected less by details in the application and more by the fundamental infrastructure and architectural decisions. This means that you are consciously (or not) making a lot av very important decisions about your NFR's very early in the design and build process, for this reason it is extremely important that everybody in the team is included in what might feel like lengthy discussions about details to get this right. Typically when a design fails on some NFR's the cost to fix it is almost always very costly and sometimes impossible to the point of requiring a complete redesign.

The essence of design
The biggest benefit of putting much effort into NFR's is that whilst features come and go out of fashion and can be added or removed depending on cost or user group targeting, the NFR's will mostly strike a very deep connection to how your customer thinks of your product. The discussions of NFR's will keep your mind at what is the lasting impression of your product and in the end it will often impact your brand, is your product fast? Dependable?