Critical Preparations

What must be done before we can launch?

We still haven't completed load testing for the new checkout flow. If we launch without it, we risk the whole system going down on day one.
The support team hasn't been trained on the new feature yet. They'll be fielding calls blind.
We need legal sign-off on the updated terms of service before we can go live.
Boosters

What will accelerate our launch success?

We have three power users who've been in beta, and getting their testimonials published before launch day could drive a lot of early sign-ups.
If we coordinate the launch with the industry conference next week, we'll get way more visibility.
Our email list is primed. A well-timed drip campaign starting 5 days before launch could build real anticipation.
Monitoring & Signals

How will we know if the launch is succeeding or struggling?

We need a real-time dashboard showing activation rates, error rates, and drop-off points in the onboarding flow.
I want PagerDuty alerts set up for any spike in 5xx errors above 1%. We can't be finding out about outages from customers.
We should be monitoring support ticket volume and tagging launch-related issues so we can spot patterns fast.
Risks & Unknowns

What could go wrong or catch us off guard?

We're dependent on a third-party payment provider for the checkout flow. If they have an outage, we have no fallback.
We've never launched to this scale before. I'm genuinely not sure our infrastructure will hold up under peak load.
Half the team is on leave the week after launch. If something breaks, we won't have the capacity to respond quickly.

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

Frequently asked questions

What is a Pre-Launch Futurespective?
It's a forward-looking session held before a big launch. Your team lists the critical preparations, the boosters that would help, the signals to monitor and the risks still open, so nothing important is missed before go-live.
How is a futurespective different from a retrospective?
A retrospective looks back at work that's already done. A futurespective looks ahead: the team imagines a future event, here the launch, and plans for it while there's still time to change things.
When should you run a Pre-Launch Futurespective?
One to two sprints before a major product, feature or campaign launch, once the plan is set but there's still time to close gaps and set up monitoring.
Who should take part?
Everyone who touches the launch: engineering, product, design, marketing, sales and support. Many launch problems come from handoffs between those groups, so you need them all in the room.
How long does a Pre-Launch Futurespective take?
Plan on 60–90 minutes. A cross-functional launch with many dependencies may need longer, especially for Risks & Unknowns.
Ready to run this retrospective?Try this retrospective live