A few weeks ago, I had the opportunity to both attend and speak at the Ministry of Testing’s Leading with Quality event and MoTaCon 2025 (formerly TestBash) conference in Brighton. A recurring theme across both events was unmistakable: quality, and the need to give it the strategic attention it deserves.
During my workshop and talks, I kept returning to a familiar point: that organisations, teams, and individuals alike must begin to see quality not as an afterthought, but as a strategic priority – one that enhances the value proposition of software products. I wasn’t alone in this perspective. Other speakers at the event echoed similar insights, which deeply resonated with the audience, as I reflected in this LinkedIn article.
Since then, the focus on quality has stayed with me, prompting deeper reflection on what quality truly means in today’s software development landscape. What shapes our perception of quality? How do end-user expectations define it? And what does this mean for how we deliver value; approach testing and product development?
In this blog post (and in others to follow), I’ll be sharing my thoughts on quality. For this iteration, I’ll focus on quality as a perception of value, and how understanding quality through the lens of end-user experience can transform the way we build, test, and deliver software.
Quality isn’t a final outcome; it’s a shared perception of value, shaped by every decision we make throughout the product development journey.
Product Quality Insights
The fluid nature of quality
Quality is a fluid concept. Its meaning shifts depending on who you ask and in what context.
Within software development, quality is sometimes describe as:
Value to someone, at a given time.
This definition, popularised by Jerry Weinberg, grounds an otherwise abstract idea in something tangible: the user’s perception of value.
Without that grounding, quality becomes slippery. It becomes an idealised concept that’s difficult to define, measure, or agree upon. But when we understand quality through the lens of value, it becomes human, contextual, and purpose-driven. It moves from something we assure or control to something we co-create, interpret, and shape based on how users experience what we build.
So, what does it really mean to understand quality through the lens of value?
Quality as value: a matter of perspective
When building software, we face an abundance of user needs and expectations. Some are loud and urgent; others are subtle or conflicting. The reality is, there are always more needs than we can ever satisfy at once.
So, we make choices, about what to build, what to test, and what to leave behind. Each decision reflects how value is perceived by key stakeholders, and by extension, how we define quality.
To a software tester, quality might mean correctness, reliability and confidence in performance.
To a developer, it might mean readable, efficient, and maintainable code.
To a product manager, it might mean user satisfaction and business impact.
And to the end-user, it might simply mean a product that feels effortless to use.
Recognising these differing perspectives is the first step toward understanding that quality is relational, not absolute. It’s not a fixed state. It is a collective interpretation shaped by the stakeholders, context, constraint, and purpose.
So, when we think about delivering value to users, embracing this relational view of quality is a powerful starting point. It helps guide our actions and clarify the trade-offs we must navigate – all of which influence the decisions that shape how quality is built into our products.
Quality as a choice: navigating trade-offs
Every product team lives in the rhythm of prioritisation. With limited time, shifting goals, and complex systems, we constantly decide where to focus our energy and attention. We test where we believe the most risk or value lies, accepting that not everything can be delivered or tested equally – a key product development and testing principle.
In the product development space, this act of prioritisation isn’t merely technical. It is deeply human.
Prioritisation is an intentional process, where sacrifices are made for (and against) what rises to the top of the product backlog.
Every decision to build or test one thing is also a decision not to build or test something else. Every release carries both the results of our focus and the remnants of what we left behind. In this way, prioritisation becomes a reflection of our perception of value to the end-users.
Meaning, end-users don’t always receive everything they might want. They receive what the product team has collectively determined represents the best balance of user needs, the system’s constraints, the team’s capabilities and the business priorities at that moment.
So, when we talk about quality, it’s important to ask: whose perception are we really prioritising?
Quality as perception: why testing matters
Perception is not passive, it requires effort. In software product development, delivering value based on our perception of user needs demands attention, interpretation and action. Testing, plays a crucial role in this sense. It helps the product team focus attention on the users’ perception of value, helping the team prioritise what matters most to users.
In testing, what we “see” as quality is, therefore, shaped not only by what’s in the product (it’s functionality), but also by our intent, focus, and curiosity – our willingness to explore and experiment with the product.
Where we chose to look defines our findings.
Our motivation for looking defines our impact.
Testing is not just about observation. It is about learning and interpretation. Skilled testers turn uncertainty into understanding. They translate user needs and risks into actionable insights that guide informed decisions about product quality.
So, if quality is perception, then testers and others responsible for building quality into software systems, must be seen not just as validators, but as interpreters of value. They help teams see quality more clearly by weighing it against risks, user needs and the applied context.
And that has real implications for how we approach the entire product development journey.
Quality as a journey: driving value through testing
Framing quality as perceived value reshapes how we approach both testing and development. It reminds us that:
- Quality evolves alongside user needs and expectations, it is never static.
- Testing is a process of discovery and feedback, not just assurance.
- Building quality software means balancing correctness, usability, and relevance.
- Quality depends on strong communication and collaboration across the product team.
- Quality is a journey, not a destination – and testing helps us navigate it with purpose.
This reframing expands the role of testers from validators to interpreters of value. It reminds us that:
Testers are no longer the gatekeepers of correctness alone.
Instead, they are partners, collaborating with others in the pursuit of value.
With this understanding of quality, the testers role becomes akin to a map in a vehicle, guiding the team to ask sharper questions that steer efforts toward meaningful, efficient value delivery. While others may be energised by the excitement of a new feature, a tester’s perspective invites deeper reflection. An effective tester prompts the team to ask:
- Are we solving the right problems?
- Are we prioritising what truly matters to our users?
- Are we seeing quality only through our lens – or through the users’ lens too?
Throughout my experience, I’ve found that testers bring a distinct and valuable perspective to product development. They sit at the intersection of design, development, and delivery. They operate where user experience meets system behaviour. Their work helps translate abstract goals into tangible quality outcomes that users can truly feel: correctness, reliability, usability, accessibility, security, and more. This makes testing a foundational pillar of quality delivery.
Testers coach the team to understand quality as perceived value. And when quality is understood this way – by everyone on the team – it becomes a shared responsibility. It becomes a shared goal that guides delivery and ultimately drives organisational success.
Quality as a glue: building quality in through awareness
Building quality software is not a linear process. It’s a practice of constant awareness. Awareness of what truly matters to users.
It requires recognising the trade-offs we make, the assumptions we hold, and the perceptions that shape our decisions.
In an industry that evolves rapidly, this awareness becomes our anchor. It helps us navigate uncertainty with purpose and intent, not by chasing perfection, but by seeking alignment between what we build, what we test, and what users genuinely value.
Understood in this way, quality becomes a kind of glue, subtle yet essential. It binds teams together through shared understanding, connects decisions across disciplines, and holds the development process in sync with user needs.
This glue is not applied at the end, it’s built moment by moment, through conscious prioritisation, reflective action, and a willingness to challenge our own perception of value. It’s in the conversations we have, the questions we ask, and the choices we make throughout the product development cycle.
Final thoughts: seeing quality differently
Once upon a time, quality was measured by the number of test cases executed or the absence of bugs. Today, that view is outdated.
In modern software development, quality is less about metrics and more about alignment, between intention and perception.
Between what we set out to deliver and what users actually experience.
Creating this alignment requires deeper evaluation of the entire product development cycle – beyond just testing. It calls for continuous reflection not only on the product itself, but also on the people, processes, and tools that shape it. This intersection is what we often refer to in this namespace as The Quality Innovation Triangle – a framework for building quality into software products.
So, as you plan your next feature, testing mission, or quality-focused initiative, consider asking:
- What do our users truly value right now?
- How do we know we’re focusing on the right things?
- And how might our perception of quality shape, or limit, what we create?
Ultimately, building quality software isn’t about controlling outcomes. It’s about deepening our understanding of value, and continually aligning our work with the people who define it – the users, whose experience of our products matters most.
As you continue your product development journey, prioritising quality should be at the heart of your efforts – so that your end-users experience not just a functional product, but one that truly delivers value. And remember …
There is always a difference between having an experience of a product, and having a quality experience of it.
Product Quality Insights
Reflect and reframe!
Before you go, take a moment to pause and reflect. Building quality software isn’t just about tools and techniques. It is about how we think, what we value, and how we show up in our teams. Take some time to reflect on the following:
- How do you perceive quality in your work?
- What trade-offs do you make when balancing value, speed, and risk?
- When do you help your team view quality – not as perfection, but as perception?
Share your reflections below. Let’s keep shaping how our industry understands and defines what building quality software truly means.
Enjoyed this post? Join the conversation on LinkedIn!
