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, and now Facebook. 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:
Launcherswho 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?
Stakeholderswho 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.
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
) 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.
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
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.
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
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:
(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.
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
- 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:
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:
Here’s a video that walks you through getting started with the LaunchCal:
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.
. 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
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
) 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
). 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
, 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.
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, Naveen Gavini, Surojit Chatterjee, Manik Gupta, Peeyush Ranjan, John Scrugham, Shishir Mehrotra, Phil Farhi, and Rick Klau.