Переосмысление гугловского LaunchCal

Как каждая компания может воссоздать один из самых известных внутренних инструментов Google
Оригинал
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, 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:
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
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 of them:

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
) 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
.

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.
and
) 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
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:
(before launch): “Work backwards” by writing the press release
before
you begin building a new feature.
(during launch): The best launches are targeted at moving one or two metrics and include a dashboard to measure progress.
(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
. Other stakeholders, like executives or external partners, may only want to see a high-level overview of all company launches. Send them to
.

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
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:


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?
Launches are only the starting point. What happens next is most important. What about that?
What about the overall cadence for my product org? Is that covered here?
Does adding a system like LaunchCal slow down processes?
What kind of launches make it to a LaunchCal?

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.

Ready to get started?
Copy this doc
and













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.