QRC (Quality, Reliability, Consistency): The Three Pillars of a Great Software Product
After a number of years leading software product development teams and also personally being part of such teams in various industries, building websites, apps, integration systems, etc., I have come to realize that there are three guiding principles behind every truly great software product. They are Quality, Reliability, and Consistency. These three seemingly simple, yet powerful ideologies make up what I call the QRC system, and they have come to guide me in creating products that have earned national recognition. If these three pillars are consistently followed throughout the SDLC process — not just during QA testing — the end product is almost always something amazing. Neglect any of them, and your product will be in chaos, resulting in unhappy users, countless bugs, numerous downtimes, and unhappy investors. Make QRC part of every product iteration, improvement, user story, use case, or workflow and you will see tangible, measurable product success.
So what does the QRC system include?
Quality
Any software product, no matter how large or small, has to have quality. Quality is the product’s ability to fully satisfy the user’s needs and to have him/her feel a sense of accomplishment after the product/feature use. This might seem intuitive and easy to achieve, but the majority of software products, either as a whole or in part, do not conform to this ideology. Although most products fulfill users’ needs, they do not do so with quality. Users are usually left wanting something more out of their experience. This could be anything from better, more appealing visual design to easier navigation to simpler workflows.
For example, a bank user may want to deposit a check using his/her smartphone. After downloading the app and authenticating, s/he is left flustered by how to actually go about depositing. Some apps do not have an easy way to access the deposit feature, contrary to what they may advertise. After navigating through a plethora of options, the user may finally find the right place to begin the deposit. Before s/he could do so, however, the user has to first manually fill in all the check information (amount, account to deposit to, etc.) and to take a picture of the front and back of the check.
In this scenario, the user may have been able to achieve his/her goal of depositing a check, but the bank app did not provide a quality experience. At the end of the interaction with the app, the user was most likely left wanting more — easier, faster way to find the deposit feature, not having to complete information manually and have the app extract it from the picture, etc. Thinking through this customer journey, planning for it in advance, and ultimately adding features that would not only address the basic users’ needs but would also enhance their satisfaction would increase the Q (Quality) in the bank’s app.
Reliability
It goes without saying that a product has to be reliable. R (Reliability) in a software product is the ability of the product provider to have the product up and running and available at all times in all necessary places. Reliability in this sense could be synonymous with product availability. However, reliability is a more appropriate term to use because a product could be available (up and running) but not accessible or usable in any way. Reliability ensures that the product is both available and usable.
Every day, major services are being hacked and, therefore, not available and not usable. Heavy loads crash sites constantly and consistently. Many products have issues with integrations, time zone changes, prolonged maintenance windows, and more. This is not reliable! The user has to be able to rely on the product at all times and has to have the confidence that when s/he navigates to a site, opens an app, uses a desktop application, the product will be there to serve and work without bugs.
Consistency
Consistency, in my opinion, is the most important pillar of the QRC system. Product consistency is the ability of the product to do what it was designed to do at all times, with no variations, ALWAYS. Simply put, the product as a whole, or a single feature, must do one thing and do it well.
Products have bugs, they crash. Features disappear, become unavailable. Users get different results depending on how they use the product. Data inconsistencies plague modern software. Integrations are unreliable. These and an almost infinite number of reasons cause products to be inconsistent. This simply cannot happen and, as software product developers, we must not find it acceptable. Software must consistently achieve its purpose without fail.
Imagine a piece of software deployed in a hospital, in an ICU. Medical personnel — doctors, nurses, staff — deal with immense amounts of pressure on a daily basis. They have to get things right because human lives are at risk. Imagine a glucose injection piece of software miscalculating injection dose on a critical patient. The consequences would be disastrous. The software provider must take all risks factors into consideration to ensure consistency of the product at all times.
My ICU example may be extreme, but it shows just how crucial the three QRC pillars are. They must all and always be taken into account when developing any software product. Ignore one of them, and the product as a whole will suffer or be ruined for good.
There are always fires to put out, quick features to implement, C-level executives asking for something to be done quickly, budgeting cuts, low development resources, etc etc. They cannot, however, prevent you as a product owner, developer, provider from following the QRC system. Every feature, every bug fix, and every user story or case should be sieved through QRC first, starting from the requirement solicitation phase. If, at times, you are forced to cut corners on one of the three pillars, do so knowingly, so that you can come back at a later time when things cool down. Fix and patch. Don’t let features that haven’t gone through the QRC check run rampant through your product.
Note: It is possible to add more pillars to QRC to better fit your use case or to emphasize an ideology for your product/company as a whole. Most likely, however, any extension to QRC will fall under one of the system’s pillars and create redundancy.
