What Google’s first enterprise product manager can teach us about product roadmaps
“I lost 50 pounds from exertion, helped carry the body of a fallen climber, and performed a high-altitude medical intervention to save a climber’s life,” recalls Neal Mueller of his experience summiting Mount Everest without a guide. Neal, who works at Google Ventures portfolio company Shape Security, is an experienced climber and serial adventurer.
As crazy dangerous as Everest was for Neal, it was even sketchier in 1953 when Edmund Hillary and Tenzing Norgay became the first to summit. The mountain has not changed in those sixty years, but the camp locations, the gear, the precise steps, and the weather windows have been carefully documented. Climbers in 2013 understand there’s a decent chance they will die on the mountain, but they arrive at the base camp knowing it can be done and how to do it. The risk has shifted from vision to execution.
I invited Google product management director Rajen Sheth to speak to our portfolio companies at the Google Ventures Startup Lab and he contrasted the Everest ascents of 1953 and 2013.
Rajen is a long-time Googler and was a founding member of the team that launched our enterprise business. His first customers, used to dealing with traditional enterprise software companies, asked for Google’s three-year product roadmap. Rajen quickly found that despite his team’s best efforts, he just could not provide one. How could he know what he would be doing in three years when he was not even sure what he would be doing in three months?
“Asking our engineers for a roadmap was akin to asking Hillary and Norgay when they would reach the summit… while they were still packing their bags.”
Building traditional enterprise software had become a repeatable endeavor — it was still extraordinarily difficult and hard to predict, but the basic steps were well known and predictable. The development environment, testing procedures, client environments, on-site deployments, and sales processes were mature. Execution, not vision. Google’s nascent cloud business, however, was covering new ground. The enterprise software incumbents were climbing Mount Everest in 2013, while Rajen and the team at Google were more like Hillary and Norgay in 1953, blazing a new trail for the first time.
SHOULD YOU EVEN HAVE A ROADMAP?
The temptation is to do away with roadmaps entirely and only share vague plans with your customers (and strong arguments have been made). Rajen contends that your customers, especially the earliest ones, are not just buying a product, they are making a bet, and they are entitled to something more tangible. He recalled that those earliest customers were not just buying the Gmail of 2006, they were pre-ordering the Gmail of 2016 — Google’s research showed that corporations will stick with an email provider for more than ten years on average. The employees at those customer sites were Google’s champions, they needed to know enough about the future to let them advocate for Google internally.
So if sharing nothing was out of the question, how much detail should you share?
BOULDERS AND PEBBLES
Rajen encouraged the audience to start with their Mount Everest—their product vision. Paint a picture of where you want to be, and make sure your customers share that vision. Even if you don’t know if it will take two, five, or ten years to get there. In the early Google Apps days, Rajen’s team communicated broad visions for how communication and collaboration would change with the cloud. We were selling the dream of cloud computing as much as we were selling a particular product offering.
On the way to the summit, you will step over countless boulders and pebbles. The pebbles do not matter yet, but try to identify the boulders and make sure they match the customer’s expectations. Early Gmail customers cared about features like retention policies and IMAP, so Rajen made sure they were included. (For more on boulders and pebbles, read my article Babe Ruth and Feature Lists.)