QA bolted on at the end is how you ship anxiety. I'd treat quality as a product requirement from discovery through release—not a gate that appears the night before launch.
Practices I'd insist on
- Clear acceptance criteria before build, not after QA finds gaps
- Risk-based test focus: money, trust, and high-traffic paths first
- Automation where it pays; exploratory testing where judgment matters
- Severity language shared by PM, eng, and QA—so "blocker" means something
- Release notes and rollback thinking as part of done
Partnership habits
| Habit | Outcome |
|---|---|
| QA in refinement | Fewer "that's not what we meant" bugs |
| Shared dashboards | Quality visible, not tribal |
| Blameless incident reviews | Learning over theater |
| PM joins severity calls | Product context in triage |
I'd rather cut scope than celebrate a date with known landmines.
Technical PM craft helps here—see the Technical PM Certification and the newsletter.