Go-to-market strategy
The product you’re launching has a critical bug found 48 hours before launch day. How do you handle it?
Get the facts first, meaning how severe the bug is, who it affects, and how long a fix takes. Then lay out the options with the product and engineering leads, which are delay, narrow the launch to unaffected customers, or ship with a workaround, and give your view of the market impact of each.
The owners decide. You bring the recommendation, honest messaging for every option, and an early heads-up to leadership.
5 min read
Free 10-minute mock
Practice “A critical bug before launch” free
Your first mock interview is free (10 minutes). No card needed.
What forty-eight hours of pressure reveals
This is a judgment test on a clock. Do you protect customers or the date? Do you know whose call it is? Can you get five teams to agree within a day?
Product marketing rarely owns the ship decision. Your influence comes from framing the options and the customer impact so clearly that the owners can decide fast. Answers that claim the decision sound naive. Answers that hand everything to engineering sound passive.
Who needs what in the next two days
| Stakeholder | Their worry | What gets them moving |
|---|---|---|
| Engineering lead | An honest fix estimate without blame | Specific questions and time to investigate before any public commitment |
| Product lead | Shipping something that works | A narrowed option that keeps the release alive |
| Sales | Promises already made to named customers | A list of affected deals and a script for each option |
| Support | Not getting blindsided | A known-issue note and an escalation path before launch |
| Leadership | Revenue, reputation, and any press exposure | Options, a recommendation, and a decision time in one short message |
| Press and launch partners | Whether the embargo and date hold | Early notice if anything moves |
A recommendation for a clinic scheduling app
“First I’d get the facts from the engineering lead. Imagine the launch is group booking in a clinic scheduling app, and the bug double-books appointments for clinics with locations in more than one time zone. I’d ask how many clinics that is, whether there’s a workaround, and how long a fix takes. Say it’s about six percent of clinics and the fix is a week. Then I’d sit with the product lead and lay out three options. Delay for everyone, launch to single-time-zone clinics and hold the rest, or launch to everyone with a warning. I’d argue against the third, because a double-booked patient costs the clinic money and trust. My recommendation is the narrowed launch. Engineering can switch the feature off per clinic, and the story holds for the other ninety-four percent. Leadership would get the options within two hours and a decision by end of day. Then I’d rewrite the announcement so it doesn’t promise every clinic, brief sales on the affected accounts, and give support a plain explanation for clinics that ask why they don’t have it yet. After launch I’d ask for a short review of how the bug got past testing.”
Framing delay, narrow, or ship with a workaround
Three facts decide which option fits. Severity comes first. A bug that touches customers' data, money, security, or safety is a different class from a cosmetic one. Reach comes next, meaning everyone or one identifiable segment. The last is reversibility, whether the damage can be undone after the fact.
- Severe and broad. Delay. Protect trust and move the date with a clear reason.
- Severe and narrow. Launch to the unaffected segment if engineering can gate it, and hold the rest.
- Minor. Ship with a documented known issue and a fix date.
The narrowed launch is the option people most often forget. Raising it shows you’re looking for a way to keep the launch alive without gambling with customers. For the related case of pushing back on a date before a bug forces it, see pushing back on a launch timeline.
Where late-bug answers go wrong
“We’ve promised the date to customers and the press, so I’d push engineering to fix it in time and have a patch ready to go out the day after launch just in case.”
Date commitments are real, and plenty of experienced PMMs feel this pull. The answer still loses points. It overrides the people who own the decision and trades customer trust for the schedule. “Push engineering” also tells the interviewer you move people with pressure instead of information.
The opposite reflex fails too. Delaying everything before knowing who is affected wastes the launch and the press window over a bug that may touch a small slice of customers. Facts first, then options.
Follow-ups after the late-bug answer
| The follow-up | What it tests | A good answer |
|---|---|---|
| Who makes the final call? | Role clarity | The product owner with engineering, leadership informed. You own the recommendation and the messaging |
| The CEO insists on launching anyway. | Upward influence | Put the customer harm in money terms, offer the narrowed launch, and commit once it’s decided |
| How do you tell customers who were promised the date? | Customer communication | Early and direct, from their account owner, with a specific new date |
| How would you prevent this next time? | Process thinking | A launch gate with a bug bar, and a feature switch on every launch |
More questions in this category
Frequently asked questions
- Should my answer recommend a delay?
- Only after you’ve shown how you would assess severity and reach. A recommendation that follows the facts reads as judgment. One that comes first reads as a reflex.
- What if the product can’t be launched to only some customers?
- Then the choice narrows to delay or ship with a warning. Weigh the harm the bug causes against the cost of moving the date, and say which way it tips for this bug.
Guides that help with this question
All guidesFree 10-minute mock
Practice “A critical bug before launch” free
A Mokk session asks this question, follows up on your answer, and scores it on five competencies. Your first mock is 10 minutes, scored like a full interview. No card needed.
Your first mock interview is free (10 minutes). No card needed.
Practice “A critical bug before launch” free
10 minutes · no card needed