My Launch Lessons from 37 Minutes in an Amazon War Room

Before joining Twitter, Ibrahim Bashir led the launch of the third-generation Kindle at Amazon. Here, he reflects on his lessons from that release — and shares how to prepare to make hard decisions quickly when the unexpected happens.

Outline

In the late morning of April 11, 2011, hours before its planned launch, the third-generation Kindle—the first lower-priced Kindle with Special Offers—was leaked. Moments later, 20 people in a Seattle conference room jumped into gear. Thirty-seven minutes after that, the device was officially unveiled and available for purchase, and Jeff Bezos was getting ready to sing its praises in a press interview.

How is it possible to launch a new product line in less than an hour? For starters, the Kindle team was as prepared for surprises as they were for a regularly scheduled launch. With tech watchers sniffing around for details of the next Kindle and journalists holding onto an embargoed press release, there was a very real possibility that word would get out sooner than the team intended.

Still, preparing for an accelerated launch is one thing. Realizing that your product just became the hottest gadget in town — and you don’t have so much as a Buy button to show for it? That’s quite another.

Ibrahim Bashir—then senior manager for Kindle, now director of program management and engineering at Twitter—was at the helm that day. Now, with a few years of perspective, he walks through those 37 minutes and the hard-won lessons that’ll help startups counteract any trials or turbulence on launch day.

Lesson \#1: Don't Fight the Leak.

Faced with a leak, the most effective response will vary from company to company and launch to launch. In some cases, you might issue a denial; in others, an “any press is good press” approach is in order. Just don’t waste your time trying to plug a leak.

In this case, the Kindle team knew that they could, and should, capitalize on any early buzz, and the website traffic that came with it. “We wanted to steer into the leak,” says Bashir. “To help determine your approach, mark down the earliest possible date you’d feel okay — even if slightly uncomfortable — launching. Our Kindle sales team had determined a game-time window. If news leaked more than a week before the scheduled release, our team’s hands were tied. Launch too far before the product was available to ship, and customers would grow frustrated by the long wait. A leak after that point, though, would immediately trigger launch.”

As part of its contingency prep, the team had also determined how they would modify the master launch plan in the event of a leak. That’s lesson #2: build a plan for partial or rapid release into your launch strategy. There are any number of reasons a company might need to move quickly on a big announcement.

Lesson \#3: Plan Every Detail.

The project team had been sequestered in a war room for the last couple weeks of the project, preparing for launch (and running through contingency plans in case things didn’t go as planned). That day, the member of the Comms team tasked with monitoring social media noticed a clear spike in buzz. The PR pros jumped into gear, confirming what looked increasingly clear: this leak was the real deal. It was go time.

If you’re an early-stage startup, you may be thinking that it’ll be a while before the world is banging down your door for the latest product news. But the mechanics of a major product launch—the prioritization, painstaking planning, and clearly articulated delegation—have broad applications. Maybe you need to deal with a new competitor, for example, or a website outage.

A war room mentality is not just a mindset; it’s a muscle your startup must exercise — and not just for launch.

This particular war room had been set up in the Kindle building on the Amazon campus, and every detail was thought out to reduce friction. “We needed a space that other Amazon employees could get in and out of easily, which limited us to part of the first floor,” says Bashir. “We picked the closest room to the front door. And since it was on the ground floor, there was no elevator drama. I had heard that once, there was elevator drama—you can't have that.”

No detail was left to chance. There was even a table ready to load with food and drinks, and a plan for acquiring plenty of sustenance from the closest cafeteria.

Lesson \#4: Populate the Room Wisely — and Sparingly.

The people in the room had been carefully thought out, too. “There were decision-makers and people who had their fingers on buttons,” says Bashir. “Those were the only two types of people in the room.”

So how were they chosen? Bashir deferred to each department involved in the launch. “You tell those teams, ‘We're going to have this war room and these are the decisions and the types of problems we're going to face. Please elect one person to be in the room,’" says Bashir. “Sticking to one person per team is key; there isn’t time during a launch to risk disagreement. You want one voice.”

There are many factors to consider when selecting the right representatives. Here are key questions to ask:

Who has subject matter expertise?
Who has a sense of ownership?
Who doesn't crack under pressure?
Who has been through something like this before?
Or who do you want to have this experience?

Equally important is who’s not in the room. Every superfluous voice increases your risk of unnecessary distraction or disagreement.

Lesson \#5: Make Yourself Heard. Literally.

With not a minute to spare, Bashir, as senior manager for the new product line, assumed his role as the “launch manager” at the center of the action. “If you've ever seen Apollo 13, the NASA room, it looked like that,” he said.

In preparation for launch, the team had thought of everything, down to the practical tools they would need. Now, Bashir calmly put on his headset microphone. “When we practiced, everyone said, ‘You’re not a loud guy. You’re going to need a mic,’” he said.

Lesson \#7: Structure Launch into Phases with Clear Entry and Exit Criteria.

The room was up and running and key players were at their posts. Now, it was time to move. Bashir’s launch spreadsheet had been carefully structured to move from one key task to the next in clear, quick succession: In this case, here was the punch list:

Put the detail page up
Get the buy button working
Get search and campaign working
Get order confirmation working
Publish the press release
Lift the press embargo

Lesson \#10: Prep Second-Degree Stakeholders.

While the launch team proper was executing a sequence of tasks they could practically recite in their sleep, a much broader team was on standby, only vaguely aware that they might be looped into the action. “If your service or your app or your product is launching in today's world, there's a bunch of distributed systems that have to play nice,” says Bashir.

Lesson \#12: Be Ready, and Willing, to Hack Your Rules

That raises another important takeaway from Bashir’s experience sending Kindle with Special Offers into the world: launches, particularly the accelerated variety, may require that you bend your own rules.

Lesson \#14: Don’t Play the Blame Game.

Of course, launches and other major initiatives will almost inevitably surface issues you couldn’t have predicted, which no amount of pre-deciding could have solved.

Lesson \#16: Always Clean Up After Yourself.

In the end, the launch of Kindle with Special Offers beat expectations, going live in just 37 minutes. Yes, there was a moment to take a breath. Bashir took off his headset, and the team took a moment to appreciate what they’d accomplished. “As soon as it was done, I believe there were donuts or cupcakes,” he says.

Bringing It All Together

Before you launch, build in a rapid or partial release option should you need it. Pre-decide everything you can — especially those who will be in the room on launch day. Populate the war room thoughtfully and sparingly; everyone involved should have clear roles and responsibilities. Leading up to launch, do real-time, full dry runs with the team. When a leak happens, don’t fight it. The launch should be segmented into phases with clear entry and exit criteria — but there should be a series of switches as new scenarios develop.

“A hardware team declares victory when they have production-ready units. A software team declares victory when they have final bits that go to the factory. A launch team actually doesn't declare victory until after customers have devices in their hands,” says Bashir. “We sit with the customer service team and figure out every single issue that's coming up, and how to resolve it. Then we move on. There’s always another launch to prepare for coming round the bend.