“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 is now at Apple, worked at Google Ventures portfolio company Shape Security, and 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.

_{Rajen Sheth speaks to Google Ventures portfolio employees}

I invited Google product management director Rajen Sheth to speak to our portfolio companies at the Google Ventures 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.

_{Tenzing Norgay with Edmund Hillary}

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

1. Categorize

Once he’d identified the big boulders, Rajen put them into one of four categories:

1. Committed with timeline: the team felt comfortable committing to dates for well-understood features or things that were currently under development.
2. Committed with no timeline: the team knew they were going to do it, but was not sure when. Rajen told customers, “yes, we’re going to do this: we just can’t share a date yet.”
3. Not committed, but probable: these were likely to get done, but they were not something the team felt comfortable committing to because so much could change.
4. Visionary: aspirational goals that the team had no idea how they would accomplish. In the early Google Apps days, these were tough, thorny innovative features that were blazing new trails, like offline Gmail in the browser.
5. Will not do: Rajen argues that specifying what you’re not doing is as important as what you are doing. He says sometimes you have to tell a customer, “We may not be the solution for you.”

2. Cluster

When sharing the roadmap, Rajen put all of his committed boulders onto a simple chart with four columns:

• Current Quarter
• Next Quarter
• Next 12 Months (e.g. Second Half 2013)
• Future (e.g. 2014 — and Beyond)

_{Rajen’s product manager template for customer-facing product roadmaps}

Naturally, the “committed with timeline” boulders slotted into the first three columns whereas the “committed with no timeline” and “visionary” boulders mostly fell into the last column.

3. Communicate

Now that Rajen had a roadmap he and his team felt comfortable with, they shared it widely. It was often hard for customers to visualize something new and innovative, so Rajen made sure to use screenshots and demos, especially for the visionary boulders that were well outside the scope of what enterprise software companies had been selling.

“When I’m spending time with customers, I appear smarter to the rest of the team. I’m getting a perspective that nobody else sees.”

Rajen made sure to listen at least as much as he talked. He also shared Google’s development process with those early customers. He told them how the company planned development, and how it worked. He turned Google’s agility into a benefit. Whereas traditional enterprise companies came to the table with a locked down three-year plan, Rajen explained how Google intended to have a constant dialogue with their customers, to react to their feedback, and change their roadmap based on what they learned. (As examples in hindsight, consider that the Google Enterprise site prominently features Chrome and Android features: two platforms that did not even exist in 2006.)

Most of us won’t get close enough to Mount Everest to look at it, let alone climb it. But the metaphor is useful for startup product teams who are summiting new peaks. Just remember that your customers are part of the expedition too. As Rajen reminded us, “Your customers are buying into a journey, they want to know where you’re going and not just where you are now.”

If you want to learn more about Neal Mueller’s adventures, visit his adventure website. (Oh, and have him tell you about that time he rowed across the Arctic Circle…)