Why We Left QA Behind to Build Better Software

For years, I’ve felt that QA sells itself short by focusing only on bug-hunting.

Like many in our field, Lyon started out thinking of ourselves as a QA company. It made sense - we’re testing software, finding bugs, making sure everything works as intended. We naturally aligned ourselves with development teams because that's just what QA does, right?

But with that, we knew from day one that we operated differently than traditional QA. While most QA teams focus on testing against technical requirements, we've always found ourselves advocating for the user experience, pushing for clarity in product decisions, and thinking about quality far upstream from actual testing.

Over the past nine months, we've had the incredible privilege of building a community of folks across different roles, industries, and companies who care deeply about quality. Through countless conversations with CTOs, product leaders, developers, and fellow QA professionals, something started to crystallize. What emerged was clear: we're not just a QA company. And thus, the term Product Quality Studio was born. These discussions helped us finally put the right words to the work we've been doing all along.

What Sets a Product Quality Studio Apart

Defining Lyon as a Product Quality Studio isn't about changing what we do. It's about finally understanding how to define the work we've been doing all along.

Traditional QA is often aligned purely with development - you build something, then test it for bugs. But our work has always naturally gravitated toward the product side of things. We parter with Product teams upstream to think critically about new feature user stories and designs. We ask questions like:

• "Have we thought about how this will affect users who..."
• "What happens if someone tries to..."
• "How does this fit with..."

We've always been in there early, helping shape features, bringing the user's voice into every conversation. We've always approached quality this way, but lacked the terminology to articulate it.

Why This Clarity Matters For Your Team

How is this really different? Take a look at these two scenarios below and think deeply about which scenario saves teams time and money. Which scenario proactively stops bugs vs defensively catches bugs? Which scenario leads to greater user retention?

Scenario A: Your team brings in QA at the end of development. The feature passes all technical requirements. It gets pushed to production. Then the support tickets start rolling in - users are confused, workflows are broken, nothing works quite like people expected. Now your developers are pulled away from new features to fix problems that could have been prevented.

Scenario B: You work with a product quality studio. From the start, we’re embedded in your planning discussions, bringing a user-focused perspective to the table. While it requires collaboration early on, this approach pays off in the long run. We work alongside both your product and development teams, identifying potential issues before they become costly problems. By release day, your team feels confident because we've already thought through edge cases and user scenarios.

Which scenario would you rather work in?

Quality Runs Deeper Than Testing

Something that keeps getting overlooked in our industry is that quality isn't just about catching bugs. It's about building things right the first time. It's about understanding your users so deeply that you can anticipate their needs before they ever hit a problem.

As a product quality studio, we're not just testing code. We're:

• Bringing user perspectives into planning discussions
• Bridging communication gaps between product and development teams
• Documenting clear scenarios that prevent misunderstandings
• Identifying and preventing costly bugs
• Keeping releases on track by catching problems early

Lyon has always done these things - we just didn't realize that this made us more than "just a QA shop." By aligning ourselves with product rather than solely with development, we're better able to explain the full value we bring to the table.

What This Means For You

If you're tired of:

• Last-minute scrambles before releases
• Constant rework cycles
• User complaints about obvious issues
• Team burnout from firefighting
• Delayed launches due to quality concerns

Then maybe it's time for a different approach - one we've been refining since day one.

We believe software teams deserve better than the traditional QA model. You deserve a partner who thinks deeply about quality from a product perspective, who advocates for your users, and who helps you build better products from the ground up.

That's why we're now proudly calling ourselves a product quality studio. Not because we've changed what we do, but because we've finally found the right words to describe the work we've always done. We're done letting ourselves be boxed in by traditional definitions of QA. We're ready to embrace our role as the bridge between product vision and technical excellence.

Want to see what this looks like in practice? Let's talk about how our product-focused approach to quality can help your team build better software, faster.

‍