‘We need to Improve our Quality!’, ‘We have bad Quality!’, ‘We sell a tool that measures Quality!’, ‘I’ll add some tests to improve Quality!’
These are just a fraction of sentences I’ve picked up over the years that make NO SENSE.
Quality is conflict
Quality is a word that creates divisiveness. It creates conflict and controversy. However, not all conflict is bad and this particular one is looming over our heads whether we face it or stick our head in the sand. You will pay a price.
Freedom, is a very similar word that lets us dream of utopic scenarios, yet suffers the same boundaries as Quality does. Both concepts find their limitations as soon as you bounce into someone else. When we permit ourselves a certain luxuary, it will more than likely impact someone negatively. Quality works similar.
Freedom, to me, is walking on a mountain without a care and nobody around me. How do I feel about someone claiming that piece of land for themselves and building a hotel there?
Quality, to me, is a smooth experience with no hassles, no passwords or extra verification. How do I feel about someone stealing, selling or even just viewing my data?
Trade-offs and Feelings
Both situations impact me directly, one way or another. A hotel can offer me comfort, lunch and ease-of-access. It also implies many more people can enjoy nature. It’s a trade-off. There is no right or wrong. There is only right or wrong in context. Additionally, what you base yourself on is a personal feeling. This feeling is influenced by your own personal values, principles, maybe even some data, but it remains your personal feeling.

Defining Quality
This is how I tackle Quality discussions. It is a step-by-step backbone that I will almost always follow. How each of these steps take form, how they evolve, who I include are very situational. However, this backbone is usually a firm pillar to lean on. This is also why my product RiskStormingOnline.com follows these steps and enables you to achieve the same in an interactive and structured manner.
- Gather stakeholders
- Understand your context deeply
- Break up ‘Quality’ into more defined Quality Aspects
- Visualise Quality Aspects as Journeys
Gathering Stakeholders
People who matter. These can be users, teammembers, people in Marketing, Salespeople, people who wish to make profit from the product, external experts,…
Pay special attention to diversity and empathy.

A diverse set of people with different skills, backgrounds, goals and dreams, demograpics, mindset,… will help you tackle your biases, blind spots and other points of failure. History provides us with many product failures due to biases. Example: Clippy, the ‘friendly’ digital assistant in Microsoft Office. During market focus groups, women who found the animations creepy and leering, were ignored.
Empathy is a seriously underestimated skill during these discussions. The ability to pick up when someone else would like to pitch in or feeling when someone else might have a better supported opinion than you might have is an amazing help. When discussions about Quality, or any discussions actually, become a shouting match, my advice is to walk out. Yet even then empathy can help diffuse the situation with calm explanations and reasoning.
Additionally, empathy enables someone to take the point of view from people outside of the discussion. ‘Oh, I don’t think Laura from opperations would like this.’
Understand your context deeply
Context is another word that is difficult to grasp due to its many, many facets. In Tech environments context usually means ‘everything around our product, project and happy team’. Lots of people are happy to work within the bubble of the project and leave the ‘working with the outside’ to managers, product owners, marketing or sales departments and do their own thing without truely understanding the ‘why’.
We’re not just building a product, we’re solving a problem. Someone, somewhere will be impacted by what we do. We need to understand our goals, failures and how we impact them personally within our context. If we don’t, we’re part of the problem.
This coin has a second side though, people on the outside can’t just treat the project as a black box and expect ‘quality’ to come out. This is one of the conflicts we need to resolve: Leaving our comfort zones and finding common ground, common language.

Breaking up Quality into Quality Aspects
In my experience as a Product Owner and working with other Product Owners I noticed a huge flaw. We are obsessed with functionality and have little patience for other quality aspects. Many people around us know this, but feel that their voice isn’t strong enough or that it isn’t their role to provide direction.
This results in a backlog filled with Functionality stories, with the occasional security, performance story or requirement.
This puts all discussions about important stuff that isn’t functionality on at least the second place. That is, until problems arrive… and they do.
With RiskStormingOnline.com, we provide a simple tool to select and prioritise Quality Aspects. We offer 25 Quality Aspects that are designed to initiate discussion. Functionality is only 1 out of these 25 cards.
We introduce a limit of 6 cards to be chosen to encourage stakeholders to make these trade-offs.

Visualise Quality Aspects as Journeys
The important thing about this phase is the discussion, the exploring of different points of view, elaborating on their importance and making decisions on what really matters.
I like to think of these Quality Aspects as journeys. The easiest one is probably Functionality, since we’re usually quite familiar with this one. We often break this Quality Aspect down to a Minimum Viable Product. Maybe we have ‘a finalised product’ in mind. What we can usually agree with, is that we’re not at our destination yet. We still have steps to take. This next step is often the topmost user story of our backlog.
We need to keep in mind a similar way of thinking for the other Quality Aspects. What does the final destination of Security look like? What is the next step we can take?
Very often, we don’t really know what the next step is, what the destination is or sometimes even how to begin the journey.
At this point, you might think that this isn’t helpful?
On the contrary. Knowing what you don’t know is often more important that what you do know. It gives you the opportunity to learn, adapt and evolve.
– Lard_Baron
What’s next?
You’ve just had a discussion on what is actually important to the success of your project and your product. People’s ideas were challenged and are hopefully more aligned. Questions were answered, misconceptions straightend. But…
There’s still more questions to ask!
Lucky you. You’re on a journey, you’re learning and you’ve found people who accompany you.
Adventurers of old applaud you! Yet they warn you:

No journey is without Risks.
Our next step will explore possible risks from as many angles as we can.
A well-informed and prepared (wo)men is worth two.
Read all posts made in this category here: RiskStormingOnline Knowledge Center
One thought on “How to Define Quality?”