Reality before repair
A rescue engagement should not begin with a heroic rewrite. It should begin with a map: what users are trying to do, what breaks, what data matters, what workarounds operators use, and where the roadmap stopped matching reality.
Some problems are product problems
A system may feel technically broken because the product has no clear owner, no release criteria, no conversion target, or no agreement on what the first useful customer journey should be.
Some problems are engineering problems
Fragile architecture, missing tests, unclear API contracts, manual data patches, and slow deployments create release anxiety. Those issues need focused stabilization, not vague strategy.
Some problems are operating problems
If support, onboarding, QA, admin actions, incident response, and customer handoff are undocumented, the product will keep leaking confidence after every launch.
The rescue sequence
GCG creates a recovery map, chooses the smallest useful interventions, restores testable workflows, tightens the product story, and gives stakeholders clearer release criteria.