The old rhetoric of hiring an external QA team on the other side of the world to test your application is obsolete. A group of people with little technical depth, no knowledge of your product, your customers’ needs, or your internal development cycles will never deliver the validation and insight you actually need. This approach damaged the reputation of QA so much that many developers I know would rather avoid working with them altogether.
So, what makes a good QA?
The formula is straightforward: an in-house QA with full ownership of tests and automation, who validates features as they are actively developed, combined with responsibilities that traditionally belong to Product Managers: writing tickets, suggesting improvements, and taking ownership of new features and refactors. A deep knowledge of the product, its goals, and customer expectations creates the perfect ecosystem for delivering not only bug-free software, but also features that truly add value. This kind of QA bridges the gap between development and product, ensuring quality at every level and multiplying the impact of the entire team.
A good QA isn’t just a gatekeeper who says “this works” or “this doesn’t.” They are a partner in building the product. Someone who understands the vision, anticipates user needs, and ensures quality at both the technical and strategic level. One strong QA like this can provide as much value as a team of ten traditional QAs, because their impact is multiplied by product knowledge, ownership, and alignment with business goals.
When QA thinks like a PM, quality stops being a checkbox and becomes part of the culture. And when it becomes culture, quality scales with the product, not against it.