Rethinking Google's Famous LaunchCal
Share
Explore
Rethinking Google's Famous LaunchCal

icon picker
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?"
Create your own copy of this doc and build your own LaunchCal.
⁠
Copy this doc
⁠
⁠
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 (e.g. in
Launch step template
⁠
) 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 - e.g. see
Localization review
⁠
.

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 (e.g.
Localization Queue
⁠
and
My reviews
⁠
) 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 — they’ll love
Launch details
⁠
. Other stakeholders, like executives or external partners, may only want to see a high-level overview of all company launches. Send them to
Stakeholder center
⁠
.

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 in
Launch details
⁠
to gently nudge reviewers to approve their launch task. My personal favorite? The congratulatory email sent to stakeholders when the big red launch button is finally pressed 🚀.
⁠

Recreate LaunchCal for your team, with this doc.👇

That's it! Here's a quick map of the rest of the doc so you can get oriented:
⁠
Define your process
⁠
⁠
Welcome! Ready to set up your own LaunchCal? After copying this doc, add your teams, define the launch steps, and tweak your artifact templates:
⁠
Teams
⁠
⁠
⁠
Launch step template
⁠
⁠
⁠
Press release template
⁠
⁠
⁠
Dashboard template
⁠
⁠
⁠
Learnings template
⁠
⁠
⁠
Launch center
⁠
⁠
Are you a Launcher managing an upcoming launch? This is where you’ll spend your time.
Add, track, and execute with the pages below. Each page has a different view of the same
All Product Launches
⁠
table:
⁠
Add a launch
⁠
⁠
⁠
My Launches
⁠
⁠
⁠
Launched!
⁠
⁠
⁠
Launch artifacts
⁠
⁠
⁠
Review center
⁠
⁠
Are you a launch Reviewer? This is the section for you.
These sections should be defined by the launch steps that you set in
Launch step template
⁠
- one page per function. Each team / step should get its own page with an outline of what needs to be done. Many of these steps are reviews, so there's an explanation of how to manage the review process in the examples below. Then there's a space to track the process:
⁠
My reviews
⁠
⁠
⁠
Design review
⁠
⁠
⁠
Code review
⁠
⁠
⁠
Localization review
⁠
⁠
⁠
Privacy review
⁠
⁠
⁠
Support documentation
⁠
⁠
⁠
Finance
⁠
⁠
⁠
Marketing
⁠
⁠
⁠
Stakeholder center
⁠
⁠
Are you an executive or external partner? Get an aerial view of all launches, or dive deep into a single launch:
⁠
Launch calendar
⁠
⁠
⁠
Steps timeline
⁠
⁠
⁠
Launch details
⁠
⁠
⁠
Broken link
⁠
⁠
Here’s where we store a few important master tables. This section is usually best kept tucked away unless you need to tweak the underlying data for your LaunchCal - updating data here will reflect in the tables throughout the doc:
⁠
All Launches
⁠
⁠
⁠
All Steps
⁠
⁠
⁠
All Insights
⁠
⁠
⁠
Statuses
⁠
⁠
⁠
Broken link
⁠
⁠

Here’s a video that walks you through getting started with the LaunchCal:
⁠
⁠
⁠

FAQ

I received some practical (and cynical 😉) observations from my peers. Here are the highlights:
There’s a lot of process here! 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 a soulless rite of passage.
Think about this as the backstage crew leading up to Product Hunt - it’s an opportunity to make a good launch awesome.
It’s also an opportunity to put important aspects of a feature first and afford the time to do things well. For example, too many teams are reactive about privacy, packaging, or product storytelling. Early visibility can turn otherwise rushed executions into thoughtful differentiators.
Diya Jolly raised a good point that a robust launch process is also a fantastic teaching tool, especially in high growth orgs with new people joining every week. Nikhyl Singhal shared his perspective that while there may be a bit more work to do upfront, a commitment to documenting launches helps answer questions that are too often distracting interrupts that are themselves a tax:
“What has X team launched?”
“There’s too much red tape - are we slowing down or losing creativity?”
“How are we balancing our portfolio?”
“Why do you need 10 more people now?”
“Do we have the right number of XFN folks supporting our efforts?”
These questions compound as you scale and become increasingly hard to answer.
Launches are only the starting point. What happens next is most important. What about that?
Rick Klau brought up the point that a foundation of great product teams is not only shipping with well-designed products at a healthy pace, but also learning from failed or bumpy launches in addition to successes.
You’ll notice that
Launch artifacts
⁠
have a field for
Broken link
⁠
and
All Insights
⁠
. It’s great to have one place where you can see how launches are performing, but also key insights on what happened when something went wrong - correction of errors, post-mortems, or simply a bet that didn’t work but is moment to learn from. Not only can teams come to one place to monitor impact, but new teams can learn about key lessons from the past.
What about the overall cadence for my product org? Is that covered here?
Personally, I like a rhythm of 6 week execution sprints (could be more frequent!), 6 month check-ins against annual goals and an opportunity to shuffle attention, people, or other resources, and a horizon of 1 year top level goal setting. I also like rotating product reviews across all teams on a good rhythm.
However, I think different orgs have different ideals and it’s important to take the time to think about what is right for you. Phil Farhi has shared thoughts on product operating rhythms
here
⁠
.
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. Clarifying earlier allows you to move faster.
Setting up best practices that help the Launcher set themselves up for success: For example, I see so many Product Managers get far through their launch process without writing a press release (see
Press release template
⁠
) that clarifies who we’re building for or the problems we’re trying to solve.
Reviewers aim to add Lift not Drag: As an example, is it actually a good idea to skip alignment with the marketing team? Will having the support team be less informed actually help your launch? It’s important to not view these as “taxes” — these teams are also empowered to help move the company forward, they are just matrixed across launches.
Acknowledging (and minimizing!) the system of reviewers: With a LaunchCal process, there’s an explicit decision to add a step to the process (see
Launch step template
⁠
). Without this, it’s easy for people to just suggest “hey, let’s have every launch go through new process XYZ”. Now we can decide as a group if that step is necessary at all, or whether it could be optional / targeted / etc.

I’ve seen teams resist having a LaunchCal in the name of “less process”, and end up with a secret whisper-wire of incantations to get things done, with a tangled mess that is actually much slower, not faster.
Naveen Gavini also suggested connecting your LaunchCal with other tools using Coda
packs
⁠
. Not only could packs enable some really cool workflows (e.g Figma for
Design review
⁠
, Jira for tasks/sprints, Github for
Code review
⁠
, etc.), but it also helps speed up the development process by connecting crucial data sources.
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. For some companies, I’ve seen criteria like: “any launch that will get a community post”, or “any launch that requires any level of marketing support”. I’ve also seen companies define the criteria by the reviewer matrix like: “any launch that requires at least one of the review steps”.
As a symptom: when done well, a good LaunchCal process should feel lightweight enough that Launchers prefer to have their launches on the calendar.
Is there a way to reduce the number of pages in the doc (Coda 3.0 update)?
Feb 23, 2022
Since this doc launched April 2021, hundreds of teams have copied and implemented LaunchCal in their org. While the feedback I heard was overwhelmingly positive, I consistently heard one complaint: page sprawl. Many teams noticed that as the number of launches grew, so did the doc’s page count. This is because every launch is accompanies by three separate launch artifact pages. Previously this meant that if you had 50 launches across the company, you ended up with 50 x 3 =
150
⁠
pages in doc.
In February 2022 Coda launched several new features as part of Coda 3.0. One game-changing feature from that launch was canvas columns, which are full pages inside a table cell. Now you can create the three launch artifacts directly inside the launch row. This is huge. Not only does this keep the doc trimmed and speedy, but it places the launch artifacts right next to the launch status, date, and other important information.
Now when you pop open a launch you can see everything important on a single page. It’s quite refreshing! Head to
Launch artifacts
⁠
to see the canvas columns in action.


⁠
A special thanks to everyone who took the time to review and provide feedback on the doc: Diya Jolly, Noam Lovinsky, Nikhyl Singhal, Nikhil Chandhok, Manish Gupta, Lane Shackleton, Justin Hales, Naveen Gavini, Surojit Chatterjee, Manik Gupta, Peeyush Ranjan, John Scrugham, Shishir Mehrotra, Phil Farhi, and Rick Klau.
⁠

Ready to get started?
Copy this doc
⁠
and
Define your process
⁠
⁠








Gallery
Share
 
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.