The QA Mindset That Makes Speed Sustainable

By Isabela Rosolen

On almost every product team, there’s a phrase that surfaces at some point: “We’ll fix that after launch.” And there’s a specific moment when this phrase appears—when deadlines close in, the pressure builds, and quality starts to feel like someone else’s responsibility.

That moment is a turning point. How a team navigates it determines not just what ships now, but what gets built next, and how much trust remains in the room when it does. At Work & Co, hundreds of launches have revealed the predictable moments when product quality is most at risk. AI-accelerated product development has not eliminated these moments—it’s compressed them, pushing risk earlier, in a new cycle that most teams have yet to structurally adapt to.

These are a few of the strategies we’ve found effective to help teams adapt to this new pace without sacrificing the quality that defines industry-leading products.   

Start by negotiating the scope with clarity

On projects with an accelerated lifecycle, there’s a temptation to compress what seems “optional.” Testing coverage, edge case reviews, risk discussions—these are the first things to get pushed. And the cost rarely shows up immediately. It shows up two sprints later, in a client escalation, in a bug that reached production, in a team that’s now firefighting instead of building.

The alternative isn’t to ignore these essential components of good product development — it’s to negotiate scope with clarity. That means mapping risks before development begins, prioritizing the most critical flows, and presenting the team with a conscious choice: what do we ship now, and what do we protect for later?

I experienced this directly on a long-running project where scope grew significantly while team size remained constant. The volume of features increased, and the window to cover them didn’t expand to match. Accepting the gaps wasn’t an option. Neither was simply working faster.

What changed was the approach to quality itself. AI-assisted automation became the foundation — not a workaround for bandwidth, but a new operating model for how quality gets maintained when the pace of delivery no longer allows for purely manual coverage. Repetitive test scenarios that would have been impossible to execute at that scale were systematically handled, freeing the team to focus where human judgment actually mattered. Over several months, each squad learned to run automated tests independently, identify critical paths before handoff, and stay deliberate about what deserved their attention most at each release. Nobody became an automation expert. They became more intentional — and that intentionality is what kept quality from becoming an afterthought in an environment where everything was moving fast.

That’s the same shift every discipline is navigating right now — just with different tools and different tradeoffs.

From a QA conversation to a product conversation 

Today, features that once took months are being scoped, built, and shipped in weeks. And that acceleration doesn’t compress just one discipline — it compresses everyone simultaneously.

For PMs, it means prioritization decisions carry more weight and less time to make them. For designers, it means edge cases get cut not because they don’t matter, but because there’s no space to resolve them. For engineers, it means technical debt accumulates quietly while the next feature is already in progress. And for QA, it means the role has shifted from validating what was built to actively shaping what gets built and in what order.

This is no longer a QA conversation. It’s a product conversation.

And it’s one that AI-accelerated development has made urgent in a way that previous cycles of pressure didn’t. When speed was a goal, teams could choose how far to push it. When speed becomes the baseline — the default operating condition — the margin for absorbing quality debt quietly disappears. Issues that once surfaced internally, with time to fix, now surface faster and closer to the people using the product.

That changes what every discipline is responsible for. Not by adding new roles or new processes, but by raising the baseline expectation: that quality is considered earlier, by more people, with more shared context about what’s at risk.

Three opportunities to ensure product quality—regardless of your role

The following aren’t checkpoints to add to a process. They’re habits that the strongest product teams have already built into how we work—and that become most valuable precisely when the pressure to skip them is highest.

Create space for cross-functional risk discussion. In AI-accelerated product development, by the time the build starts, the cost of changing course has multiplied. The risks that could have been caught in a conversation become bugs caught in staging — or worse, in production. Creating space for cross-functional risk discussion before development begins isn’t a QA ask. It’s a product team habit that compounds over time.

Establish shared accountability. When accountability for quality isn’t shared, it quietly falls to whoever is last in the process. That’s not a sustainable position for any discipline to hold alone. The teams that ship with the most confidence are the ones where developers flag critical paths, designers think through error states, and PMs build quality criteria into the definition of “done.”

Be precise about where speed is safe, and where it isn’t. “We don’t have time to slow down” is a well-worn phrase among product teams. This is the hardest one, because it’s usually said in good faith. The answer isn’t to slow down—it’s to be precise about where there’s room to move faster with guardrails, and where doing so would present serious risks—to the product or the business.. That distinction, made clearly and early, is one of the most valuable things any product team member can bring to a release conversation.

In the era of AI-accelerated product development, quality is what determines whether the process was worth it—for the team, for the client, and for the people using what you built.

More than ever, that conversation belongs to everyone at the table—the PM who owns the roadmap, the designer who made the edge case call, the engineer who flagged the dependency, and the QA lead who mapped what a failure would actually cost. When it happens early and with shared data, it changes the dynamic entirely. The right question to ask isn’t where can we sacrifice quality for speed, it’s how can we adapt so that we never have to? 

About the author

Based in Sao Paulo, Isabela Rosolen is a Quality Engineering Manager at Work & Co where she leads product quality with a strong focus on AI-powered testing, automation, and agile practices across mobile and web products. Passionate about building reliable digital experiences, she brings together technical rigor and strategic leadership to ensure that quality is embedded throughout every stage of product development. Her cross-functional perspective and hands-on approach have driven successful partnerships with Pfizer, BTG, Epic Games, PGA Tour and others on complex, high-impact digital products.