What is a Pre-Launch Futurespective?
A Pre-Launch Futurespective is a planning session you run before a product or feature launch, not after it. Your team pictures launch day and the weeks that follow, then works backward to what has to be true for it to go well. It's easier to find a missing rollback plan or an untrained support team now than at 2am on launch night. The board has four areas. Critical Preparations is for the tasks, checks and sign-offs the launch can't go ahead without. Boosters covers what would help the launch land: a beta customer's testimonial, timing with an industry event, an early briefing for sales. Monitoring & Signals asks how you'll know whether the launch is working, from error rates to support ticket volume. Risks & Unknowns is for untested assumptions, outside dependencies and the scenarios nobody has planned for. Run it one to two sprints before launch, so there's still time to act on what you find. It works best with everyone who touches the launch in the room, from engineering and product to marketing, sales and support, because the gaps usually sit between those groups. You'll leave with a prioritized list of actions, each with an owner, instead of a general feeling that things are probably fine.
Pre-Launch Futurespective format
Critical Preparations
What must be done before we can launch?
Critical Preparations are the tasks, checks and sign-offs that must be finished before the launch can go ahead. Ask what would delay or break the launch if it were missing, from technical prerequisites and documentation to approvals and support training. Be strict about what counts as critical: push the team to separate "must have" from "nice to have."
Boosters
What will accelerate our launch success?
Boosters are the actions, assets and conditions that would help the launch land and drive adoption or revenue. This is the opportunity side of the session, so ask about marketing, internal champions, partnerships, timing and product features that could build momentum. A useful question: what would make this launch go better than planned? It keeps the team from spending the whole session on risk.
Monitoring & Signals
How will we know if the launch is succeeding or struggling?
This area covers the metrics, alerts, dashboards and feedback channels the team will use to track the launch as it happens. Agree on what "good" looks like and check the instrumentation is in place to spot problems early. Ask about technical signals like error rates, latency and uptime, and business signals like activation, support tickets and NPS. Then ask: if something breaks at 2am on launch night, how will we find out? The answer often shows gaps in alerting that need fixing before go-live.
Risks & Unknowns
What could go wrong or catch us off guard?
This is where the team names what keeps it up at night: assumptions nobody has tested, dependencies outside its control and scenarios it hasn't planned for. The aim is honesty, not pessimism, so the team can act early. Ask about technical risks, third-party dependencies, team capacity and customer or market unknowns. For each risk, ask what the mitigation is and who owns it.
When to use this retrospective
- When your team is 1–4 weeks from a significant product or feature launch and wants to check nothing critical has been missed
- When a launch involves engineering, marketing, sales and support, and you need everyone to agree on what "ready" means
- When a past launch went badly and the team wants to prepare more deliberately this time
- When you're launching into a new market or to a much larger audience, and getting it wrong would cost more than usual
- When you want a repeatable readiness check to run before every major release
Suggested icebreaker questions
- If your launch were a rocket, what stage of the countdown would it be at right now, and is everything go for launch?
- What's the most memorable product launch you've ever seen, good or bad, and what made it stick?
Want a warm-up your team plays, not just answers out loud? Browse free icebreakers →
Ideas and tips for your retrospective meeting
- Run it 1–2 sprints before your target launch date: early enough to act on what you find, close enough that the details are real
- Invite engineering, product, design, marketing and support. Blind spots tend to sit at the boundaries between functions
- Use dot voting on Critical Preparations and Risks & Unknowns so the team deals with the highest-impact items first
- Don't let it turn into a status meeting. If someone raises an item that's already done, note it and move on; you're looking for gaps
- Give every action an owner and a due date before you close. Without follow-through, a futurespective is wishful thinking
- After launch, return to the Monitoring & Signals items for a quick post-launch review, and add what you learn to your launch playbook