Case context
Shipped product- Formal role
- Product Lead / Product Manager
- Scope
- Web, iOS, and Android release readiness
- What I owned
- Acceptance criteria, QA process, release gates, and readiness decisions
- Collaboration
- Engineering, external development partner, and dedicated mobile testers
Problem
When I arrived, releases were ad hoc — a production deploy had gone out without QA sign-off. In a health-equity platform built on community trust, a broken release is not a bug; it's a trust event.
What I built
An end-to-end QA process, live by August 2025, later formalized into a 7-phase QA process: pre-development planning → dev validation against shared acceptance criteria → QA readiness gate → plan-based testing across web, iOS, and Android with regression → dedicated bug tracking → TestFlight beta validation on real devices → a documented Go/No-Go release gate.
The standing rule: no release goes to production with critical or major bugs open. I stood up dedicated iOS and Android testers running acceptance-criteria-scoped test plans, and made the deployment/QA gate a hard requirement.
Impact
This engine shipped a full year of dated releases — from the leaderboard and wellness launch (July 2025) to the Story-Centered Feed (September 2025) to the Walking Challenge, Global Search, and in-app calling stack (2026). Bugs were caught before release instead of after, including critical fixes for an onboarding API failure and web login. The ROI is cost and risk avoided: fewer production incidents, less rework, and protection of the community trust the entire product thesis depends on.
A consequential decision
Options
Preserve feature velocity with informal checks, or establish a release gate that could delay launches.
Evidence
A production deployment had shipped without QA sign-off, creating avoidable reliability and trust risk.
My call
Institute a seven-phase QA process and a hard Go/No-Go rule with no critical or major bugs open.
Result
The team sustained a year of dated releases while catching critical onboarding and login defects before release.
What I learned
“QA is a feature. Shape the work, then protect the gate — nothing advances on optimism.”