Many of our clients use the term “Non-Functional Requirements” to group into a basket those portions of their solution that don’t easily fit into method or function-based execution of market needs. Examples of non-functional requirements often include things like “Availability”, “Scalability”, “Response Time”, “Data Sovereignty” (as codified within requirements such as the GDPR), etc. Very often, these “NFRs” are relegated to second class citizens within the development lifecycle and, if lucky, end up as a technical debt item to be worked on later. More often than not, they are just forgotten until major disaster strikes. This happens so often that we at AKF joke that “NFR” really stands for “No F-ing Resources (available to do the job)”.
While I believe that this relegation to second class citizen is a violation of fiduciary responsibility, I completely understand how we’ve collectively gotten away with it for so long. For most of the history of our products, we’ve produced solutions for which customers are responsible for running. We built the code, shipped it, and customers installed it and ran it on their systems.
Fortunately (for most of us) the world has changed to the SaaS model. As subscribers, we no longer bear the risk of running our own systems. Implementation is easier and faster, costs of running solutions lower.
Unfortunately (for most of us) these changes also mean we are now wholly accountable for NFRs. We now mostly produce services, for which we are wholly accountable for the complete outcomes including how our solution runs.
Most NFRS Are Table Stakes and Must-Haves
In the world of delivering services, most NFR capabilities are must-haves. SaaS companies provide a utility, and the customer expectation is that utility will be available whenever the customer needs it. You simply do not have an option to decide to punt attributes like availability, or regulatory compliance to a later date.
The Absolute Value of NFR Your Product/Service Needs Varies
While we believe most NFRs are necessary, and non-negotiable for playing in the SaaS space, the amount that you need of each of them varies with the portion of the market you are addressing within the Technology Adoption Lifecycle.
As you progress from left to right into a market, the NFR expectations of the adopters of your solution increase. Innovators care more about the differentiating capability that you offer than they do the availability of your solution. That said, they still need to be able to use your product and will stop using it or churn if it doesn’t meet their availability, response time, data sovereignty, and privacy needs. NFRs are still necessary – they just matter less to innovators than later adopters.
At the other end of the extreme, Late Majority and Laggard adopters care greatly about NFRs. Whereas Innovators may be willing to grudgingly live with 99.8% availability, the Late Majority will settle for nothing less than 99.95% or better.
It’s Time to Eliminate the Phrase Non-Functional Requirement
We believe that even the name “Non-Functional Requirement” somehow implies that necessary capabilities like availability and data sovereignty can somehow take a back seat to other activities within the solutions we create. At the very least, the term fails to denote the necessity (some of them legally so) of these attributes.
We prefer names like “Table Stakes” or “Must Have Requirements” to NFRs.
It’s Also Time to Eliminate the Primary Cause
While we sometimes find that teams simply haven’t changed their mindset to properly understand that Table Stakes aren’t optional investments, we more often find a more insidious cause: Moral Hazards. Moral hazards exist when one person makes a decision for which another must bear the cost: Person A decides to smoke, but Person B bears the risk of cancer instead of Person A.
Commonly, we see product managers with ownership over product decisions, but no accountability for Table Stakes like availability, response time, cost effectiveness, security, etc. The problem with this is that, as we’ve described, the Table Stakes are the foundation of the Maslow’s Needs for online products. Engineering teams and product teams should jointly own all the attributes of the products they co-create. Doing so will help fix the flawed notion that Table Stakes can be deferred.
AKF Partners helps clients build highly available, scalable, fast response time solutions that meet the needs of the portion of the Technology Adoption Lifecycle they are addressing.