So, who should review a feature

“Why is that even a question!?”, you wonder. Well, it very much is a question, and the answer is “All stakeholders”.

The one who signed the contract
The one who turned it into a high-level idea
The one who approved the idea
The one who made business requirements out of it
The one who did design
One who wireframed it
The one turning it into acceptance criteria
The one who built it
The one who tested and signed off
The one who understood the risks before giving a Go
One who funded it and the one who sold it on paper

These and many more stakeholders.

“stakeholder” - is anyone who has an interest in the success of a company.

We want to ensure that the product we have built matches what we promised our customers (what they paid for).
I understand you might be thinking, this is obvious since requirements flow through each layer and each layer has an authoritative sign-off.

When you deal with a user’s money or health, it’s always a good idea to double-check what you are offering to users before going live.
In the case of a social media platform, undesirable behaviour may be acceptable since it does not have a direct impact on users' finances or lives.

There will always be reading between the lines and leakage of information by the time it reaches the last checkpoint in engineering, resulting in a product that differs from the intended one being brought to market.
And this eventually leads to undesired products. I am not talking about bugs.
The outcome could be error-free, but undesired.

Things the umbrella of the term ‘Undesired’ covers:

Slow to load the data
Feature isn’t easy for users to use or is not delightful
Long workflow answering multiple questions
No history before signing up (data from devices etc)
Not available in the language considering the population in the region going live
Generic Error message - Error message doesn’t inform of the actual error
No next steps are mentioned when stuck
Not intuitive

Why so -

Teams assume
Teams don’t question
Teams take it as is as the deadline approaches
Teams have some development constraints
Each stage of the feature involves a different set of stakeholders with their own interpretations of the requirements.
Teams misinterpret
Teams don’t resolve misinterpretation

Consider the Swiss Cheese model by James Reason (1990)
This model compares different levels on which mistakes (problem/ignorance in my understanding) happen with slices of Cheese.
In a mistake-free world, cheese would have no holes - you deliver what the customer expected - nothing was overlooked/assumed.

But in the real world, cheese is cut into many slices and each slice has many holes, which are at different places in different slices.
Imagine all the slices align on the holes - meaning the mistake, the assumption by one/more team gets carried forward and leads to catastrophe - undesired product.
If a mistake is irrelevant or gets caught early meaning holes don’t align - can be handled at least by another slice/another team and won’t penetrate deep.

Consider the
Cheese = product
Slices = stakeholders/teams
Holes = mistakes/assumption/ignorance/bugs

A small requirement within a feature may have a huge effort. Teams in silos (not all stakeholders) discuss and decide to go with another approach to avoid huge efforts.
The same could be money for different third-party licences. Or use of a different AI service giving undesired results than what was promised.

For example -
(1) The idea of having mangoes in the user’s own backyard by planting a mango tree was sold.
When it came down to the last checkpoint, the information leakage happened and the new message was “planting a tree in the user’s yard”.
The feature was built, no risks were reported and it was gone live. Now, the users aren’t happy with what they received.
We sold ‘a’ on paper but users received ‘a-5’.
All this may result in building something that is not valuable for users.

(2) Suppose you are building a banking app, and you promised customers that they would receive a feature of security questions along with biometrics. However, the team missed applying the restriction that the security answer should not be the same as a password. The product was live with no takers or unhappy takers.

(3) Or you are building a health app, and the idea of 6 months of data sync with Apple Health Watch was sold. When the product went live, the app started data gathering post-pairing with the watch. The data was available only after signing on to your app. People “assumed”. No one knew about this caveat until users complained stating there isn’t any data.
This may hurt the value of your product as there is no historical data available to decide on the treatment! (Though, there would be other ways to get the treatment prescribed)

All this could have been avoided or better handled if as a team and as a company all the stakeholders had had a look at the product before releasing it to the users.

And this is an expensive way to fix the “undesirable” as it doesn’t only affect the business financially but the reputation is at risk as well.

How to ensure that the product is useful to users before going live -

Be involved at each milestone - Whether you are a salesperson, a product manager, a business analyst or an engineer, be involved at each step of the product/ feature. Know and discuss if this is what is wanted and if the same is getting built.

Work as a team - It sounds like such a routine thing, but it isn’t. The teamwork usually happens in groups of just engineers, just product, Sales have their own team and they come into the picture only before the business idea is broken down into a roadmap and after the product is live.

If every stakeholder works as a team - “a team of sales, engg, product, business” - this will ensure everyone starting from signing to releasing has a shared understanding of the requirement.

Periodic checks in the market and with the team - it may happen that the feature you are trying to implement, a competitor launches before you do and is selling well. Always keep an eye on the market and always take inputs from all the stakeholders on what they think about the feature. For e.g., What’s their viewpoint on designs?

Every stakeholder can have a different and great take on the product, design, errors, and risks.

Don’t overlook or be unheard of about the suggestions or the problems being pointed out. And if it’s a misinterpretation, work towards resolving any potential misinterpretations.

Working together will not only improve your product but the confidence clients have in you, cashing in more business.

Failure of Quality can be managed once (patching and taking preventive actions) but failure of a product places the business or the company itself at risk.