Go-to-market strategy
Describe how you’d handle a GTM launch where the product team is still finalizing features two weeks before the launch date.
Get an honest status from the product lead and sort every feature into done, at risk, or unlikely. Agree on the smallest set that supports the main message, set a scope freeze and a dated go or delay decision with a named owner, and write materials that can lose a feature without a rewrite.
Then tell sales exactly what to sell now and what to call upcoming.
5 min read
Free 10-minute mock
Practice “Late-changing launch scope” free
Your first mock interview is free (10 minutes). No card needed.
What a late scope change tests
Late changes happen on almost every launch. So this is less about the crisis and more about your habits. Do you stay calm? Do you negotiate with product using specifics? Does your work survive a feature disappearing?
Product marketing has no authority over what ships. Your influence comes from tying each feature to the launch story, so the product lead can see what a slip costs and make the call.
What each team needs two weeks out
| Team | What they need protected | What gets a yes |
|---|---|---|
| Product manager | Shipping as much as possible and keeping the date | A clear launch minimum, so every extra feature is a bonus |
| Engineering | Not being held to promises they can’t keep | Being asked how confident they are instead of for a date |
| Sales | Knowing what they can promise | One page listing what to sell now and what to call upcoming |
| Support and docs | Accurate help articles on day one | A freeze date after which content stops changing |
| Leadership | Hitting the date without embarrassment | A go or delay decision with written criteria |
A spoken answer from a creator video app launch
“I’ve been in a version of this. We were launching a set of AI editing tools in a video app for creators, and two weeks out, engineering said two of the five headline features were at risk. I sat with the product manager and we sorted them. Auto-captions and silence trimming were done. Background removal was solid. Multi-camera sync was at maybe seventy percent, and the voice cleanup model still failed on noisy audio. I asked what the launch story needed. The claim was that creators cut editing time in half, and the first three features carried it. So we agreed on a freeze at ten days out and a go or delay meeting at day four, with the product lead as the decider. I rebuilt the page with those three features up front and put the other two in a section I could pull without redesigning anything. Creator partners got early builds with only the stable features, so their videos wouldn’t show something we might cut. Voice cleanup slipped and multi-camera sync made it. We launched on the date, and the page changed by one paragraph.”
Launch materials built to lose a feature
- Lead with stable features. The headline claim rests only on what is done.
- Keep at-risk features modular. Separate sections, slides, and email blocks that can be dropped cleanly.
- Show only finished work in demos. Partner content and videos last longer than the launch week.
- Set language rules for upcoming features. Direction without dates or commitments.
- Keep one status sheet. Everyone reads feature status from the same place.
The freeze is a trade you negotiate. You offer flexible materials, and the product lead agrees to a firm date after which changes need a named approver. Framed that way, it reads as help. For changing course once a launch is already running, see adjusting launch strategy mid-execution.
Failure modes when scope keeps moving
“I’d stay closely aligned with the product team, keep a running doc of what’s changing, and update the messaging and enablement as things shift, making sure everyone hears about each change.”
This is what many PMMs do in practice, and it sounds cooperative. It still loses points, because nothing gets decided. There is no freeze, no launch minimum, and no owner for the go or delay call. Sales hears five updates and trusts none of them.
Two other failures are common. One is announcing at-risk features to keep the story big, which creates a promise the team may break in public. The other is escalating to leadership before talking to the product lead, which burns the relationship you need for the next launch.
Follow-ups on unfinished launch scope
| If they ask | What it is testing | What to say |
|---|---|---|
| Product won’t agree to a freeze. | Influence | Show what each late change costs in materials and support, and ask for a freeze on the lead features only |
| How do you brief sales on a feature that may not ship? | Honest enablement | Tell them to leave it out of deals and give them roadmap language with no dates |
| Would you ever recommend a delay? | Judgment | Yes, if the launch minimum isn’t solid by the go or delay date |
| A feature ships broken. | Recovery | Pull it from promotion, tell users what’s known, and update sales the same day |
More questions in this category
Frequently asked questions
- Is pushing back on the product team part of the job here?
- Yes, with specifics. Tie each late change to what it does to the launch story and the materials. Then it becomes a trade-off the product lead can make.
- Should customers hear about features that might slip?
- Keep firm claims to what has shipped. If you must mention direction, do it in general terms with no dates attached.
Guides that help with this question
All guidesFree 10-minute mock
Practice “Late-changing launch scope” 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 “Late-changing launch scope” free
10 minutes · no card needed