# Walk me through how you’d plan and execute a major product launch from start to finish. What’s your timeline?
> A week-by-week plan for the major launch question, with what to lock early, where to keep buffer, and how to handle a date that moves up.

Source: https://mokk.ai/pmm-questions/cross-functional-scenarios/plan-major-launch-timeline (updated 2026-09-22)
Markdown: https://mokk.ai/pmm-questions/cross-functional-scenarios/plan-major-launch-timeline.md

Ask how firm the date is and what the launch has to achieve, then work backward. Lock the goal, tier, positioning, and pricing in the first third of the timeline. Build enablement, pages, and proof in the middle while beta feedback shapes the message, and hold a go or no-go review about a week out. Say where the buffer sits, what you would cut if the date moved, and when you will judge results.

## What a launch timeline answer has to show

The question has two halves, and most answers only handle the first. "Plan and execute" invites a list of phases. "What's your timeline" asks for dates, and dates force you to show which work depends on which. A timeline with week numbers shows you know which decisions block other teams.

Hiring managers listen for three things. Do you settle the expensive decisions early, do you know what each team needs by when, and do you plan for the date moving? The last one separates people who have run launches from people who have read about them.

## Two questions to ask before you draw the launch calendar

Ask how firm the ship date is and what the launch should change. If the size is left to you, twelve weeks is a defensible anchor for a major launch. A date tied to a trade show or a retail shelf reset can't move, so the plan protects it by cutting scope. A date set by engineering will probably slip, so that plan protects it with buffer. The goal then decides the tier, and the tier decides how many steps you need.

## A twelve-week launch plan, built backward from the date

1. **Weeks one and two, the brief.** Goal, tier, audience, owners, and how firm the date is, agreed by the product, sales, and marketing leads. The [launch brief question](https://mokk.ai/pmm-questions/gtm-strategy/build-a-launch-brief) covers what goes in it.
2. **Weeks three to six, the decisions.** Positioning, pricing, naming, and an early-access group whose objections feed the message. Anything a web page, sales deck, or press note depends on gets settled here.
3. **Weeks seven to ten, the build.** Sales training, support docs, the launch page, press, and customer proof. Enablement lands at least two weeks early so reps can practice.
4. **End of week ten, readiness.** A go or no-go review where product, support, and sales each confirm they are ready or say what is missing.
5. **Weeks eleven and twelve, launch.** A day-by-day run sheet, one channel for issues, and a named person for every escalation.
6. **After launch, the checkpoints.** Reviews at roughly two, six, and twelve weeks against the goal set in week one.

Put the buffer somewhere visible, usually between the decisions and the build, and say why it sits there.

## Worked example, a hardware launch with a fixed retail date

**Strong answer (invented example)** "First I'd ask how firm the date is. For a home rowing machine going into a big-box retailer, it's very firm, because the store resets its fitness aisle one weekend in January and we either make it or wait a year. So I'd plan twelve weeks back and protect the date by cutting scope. Weeks one and two are the brief and the goal, say eight thousand units through retail in the first quarter. Weeks three to six are positioning, pricing, and fifty beta units in homes, because what owners complain about becomes the FAQ on the box. Packaging copy locks at week four, since the factory needs it eight weeks before the shelf date. That's the real deadline, and plenty of plans miss it. Weeks seven to ten are store staff training, the product page, and units for reviewers, with the go or no-go at the end of week ten. If the app's new race mode slips, it ships as an update in February and the machine still launches. Then I'd check sell-through at two weeks, returns at six, and app retention at twelve."

## The trade-offs to name while you walk the timeline

- **Scope versus date.** Say which one moves when something slips. A fixed outside date means you cut features or channels. An internal date means you can hold scope and move the day.
- **Beta learning versus lead time.** A longer beta gives better proof and sharper objections, but every extra week of beta is a week less for enablement.
- **Press timing versus sales readiness.** An embargo can lift before reps know the product. A buyer who reads the news and calls a rep who can't answer is one of the most avoidable launch failures.

## Where launch-timeline answers lose the room

The most common miss is the phase list. Research, messaging, assets, launch, measure, with no dates attached. It sounds organized and says nothing about sequence. A second pattern is spending two minutes on kickoff and research, then running out of time before launch week.

The third is a plan where nothing goes wrong. Strong answers on the [rubric](https://mokk.ai/pmm-rubric) sequence work by impact and know what to cut. Exceptional ones name a second-order effect, such as a packaging deadline that arrives long before launch day, or a press date that pulls enablement earlier than anyone planned.

## Follow-ups on the launch timeline

Where interviewers usually push after the timeline
| If they ask | They're probing | A good response |
| --- | --- | --- |
| The date just moved up three weeks. What do you cut? | Whether you know which work is optional | Cut secondary channels and assets first. Keep positioning and sales readiness. |
| The beta found a serious problem in week five. | Whether you would delay or narrow | Say who decides, what you would ask engineering, and whether a launch to a smaller segment keeps the date. |
| Who makes the go or no-go call? | Ownership | One named person, usually the product lead or an executive sponsor, with any team able to raise a blocker. |

## More questions in this category

- [Cross-team launch coordination](https://mokk.ai/pmm-questions/cross-functional-scenarios/coordinate-launch-across-teams)
- [Influencing without authority](https://mokk.ai/pmm-questions/cross-functional-scenarios/influence-without-authority)
- [A launch that went wrong](https://mokk.ai/pmm-questions/cross-functional-scenarios/launch-that-didnt-go-as-planned)
- [Presenting to skeptical executives](https://mokk.ai/pmm-questions/cross-functional-scenarios/present-strategy-to-skeptical-executives)
- [All cross-functional scenarios questions](https://mokk.ai/pmm-questions/cross-functional-scenarios)

## Frequently asked questions

**Should I give exact week numbers if I don't know their process?** Yes. Numbers make the sequence easy to follow, and you can say you would adjust them once you knew the engineering cadence. Vague phases are harder to follow than specific numbers that turn out to be wrong.

**How long should a spoken launch plan run?** Aim for two to three minutes, then let the interviewer pick a phase to dig into. Covering every detail usually costs you the post-launch checkpoints.

## Practice

**Answer it out loud.** A Mokk session asks this question, follows up on your answer, and scores it on five competencies.