Rethinking Google's Famous LaunchCal
Copy one of Google's most renowned internal tools for our own product launches.
Shiva Rajaraman
Launching new products is hard.
I spent eight years at Google and YouTube, and since then I’ve been lucky enough to run some of the best product teams in tech at Spotify, WeWork, Facebook, and now OpenSea. One common tool I’ve tried to recreate in every chapter is one we relied on at Google: the LaunchCal.
Building a great product is hard, but a great launch requires teamwork well beyond the builders. So, before you start building, ask yourself: what does your team actually need for a successful launch? Define the goal, and then create the solution.
This Coda doc is loosely based on the best parts of LaunchCal that some of us used during our time at Google... with added features that we wish we had! It's our hope that this doc will help everyone on your launch team stay up-to-date with the diversity of launches your team manages, helping to answering and/or get ahead of questions raised by a range of players:
- Launchers who ask: Hey, before I can launch this, what do I need to check for and who else do I need to chat with?
- Reviewers who ask: What are the launches that I need to approve next?
- Stakeholders who ask: What stories can we share to ensure clarity? What does success look like for our ideal user? What are we going to launch next? Which launches should we know about?
To answer the questions above, this doc focuses on a few key insights and assumptions.
INSIGHT #1
Launching products requires an intentional matrix. Actively manage the matrix between reviewers and launchers.
As an organization grows, it is inevitable that a matrix will emerge. Marketing and communications will want to know the stories to tell. Your legal team and PR team will want to look at certain launches. You'll start a localization pipeline for your international audience. The mobile apps may have their own queue. Enterprise go-to-market teams may want to bundle launches together. And the list goes on.
These tasks generally get decided and added to the process independently, and sometimes without a clear view on which ones are required and/or how much overhead they are adding to each launch. So this doc starts with a Launch step template area to make sure you actively choose which reviewers are required vs optional.
INSIGHT #2
Reviewers are busy humans. Help reviewers add lift to launches.
Before getting to the launchers, let's talk about reviewers. They are often in a tough spot and this doc addresses a few ways to make their lives easier:
Move from "Tax" to clear reasoning and priority
First, reviewers can be viewed as "tax," even though their function is often critical to the success of the launch. So having the official blessing of their priority can be helpful. This can also help capture/remind everyone of the reasoning for why this review step is required. In other words, lift, not drag.
Reduce re-education
Second, reviewers think about their function exhaustively, but often the launchers don't - so they spend a lot of time on education, and re-education on every launch. This doc allows each reviewer to provide the relevant documentation.
Clear reviewer queue
Third, reviewers are often spread across many launches that they lack context in, so judging where they should focus can be difficult. This is particularly troublesome because if they are slow/unresponsive, then it can exasperate the feeling of them being a "tax" rather than a "lift". So giving each team a clear queue can help them stay on top of things.
INSIGHT #3
Launchers are spread across reviewers. Empower them with clear instructions.
As the matrix grows, launchers can be left feeling lost - who else was I supposed to check with, what are the steps for that review, etc. Two key things this doc does:
Clear launch tasks
The key step here is in the Add a launch section. Try clicking the button to create a new launch and then clicking the Add Launch Steps button. This generates a set of work that the launcher can use, but also inserts these steps into the relevant reviewers review queue.
Product development artifacts
In my experience, the best product launches are paired with Launch artifacts that keep stakeholders informed and aligned. I’ve included templates for a few I’ve found to be indispensable for a successful launch, and each can be easily added to a launch with the push of a button:
- Press release template (before launch): “Work backwards” by writing the press release before you begin building a new feature.
- Dashboard template (during launch): The best launches are targeted at moving one or two metrics and include a dashboard to measure progress.
- Learnings template (after launch): Key insights often come in bits and pieces in the days following a launch. Having one place to capture and synthesize those learnings bakes reflection into your launch process.
INSIGHT #4
Stakeholders often have less context than you think. Over-communicate from the start.
Finally, there are a number of people in the company who would like to keep track of what's happening across launches. These stakeholders - executives, external partners, etc - are often left in the dark unintentionally. There are a few tools you’ll want to use:
A view for every altitude.
Some stakeholders are in the weeds of the launch and want access to detailed launch steps and review statuses. Other stakeholders, like executives or external partners, may only want to see a high-level overview of all company launches.
Comments, people mentions, and notifications.
Layering on additional communication as the launch progresses is also crucial to stakeholder visibility. This doc makes that easier with comments, people mentions, notifications, and buttons to gently nudge reviewers to approve their launch task.
FAQ
I received some practical (and cynical 😉) observations from my peers. Here are the highlights:
Is this necessary? Will we just end up with a culture of approvals where people fear taking healthy risks?
I feared the same thing as a new PM when I was first introduced to the concept of a Launch Calendar - especially “approval bits.” Any time you need approval, it can be seen as a negative.
To make this successful, one cultural foundation is to ensure that launch teams, including all reviewers, view any new launch entry as a catalyst for enthusiasm and creativity. Each launch is an opportunity for a team to have impact and should be viewed as a rallying cry for collaboration, not a soulless rite of passage.
Does adding a system like LaunchCal slow down processes?
As Noam Lovinsky pointed out, the whole LaunchCal process is often incorrectly viewed as a tax - an end of the “good times.”
The key principle is moving faster overall, not just faster in the moment. A good LaunchCal process helps this in a few ways:
- Highlighting issues early: The worst feeling is to try to launch something and get the “last minute review feedback” that requires going back to the beginning.
- Setting up best practices that help the Launcher set themselves up for success.
What kind of launches make it to a LaunchCal?
Manik Gupta suggested some guidance on what kinds of launches need launch calendars, as not every launch needs to have the same visibility and approval.
It’s hard to answer this generically, since every company is quite different. My sense is that over time, teams naturally arrive at a granularity for which launches need to fit here and pick a simple litmus test for it.
Ready to get started?
Copy this doc and Define your process.