Bret Taylor is no stranger to being the underdog. From a scan of his resume, this may not seem to be true: MS in CS at Stanford; joined Google in 2003 and helped lead the team that co-created Google Maps; co-founded and was CEO of FriendFeed, which was successfully sold to Facebook in 2009; became CTO of Facebook until 2012; and finally co-founded and is currently CEO of startup Quip, which recently raised $30 million from Greylock and Benchmark. In fact, to most people, it would seem like Taylor has had a career of working for some of the largest, most powerful tech companies in the world — a career of being a “Goliath,” you might say.
But to hear Taylor tell it, the more common thread within all of his experiences building products has been being a “David” — the tiny upstart trying to take down a very established competitor. He may have ended up building what are now regarded as incredibly successful and trendsetting products, but in almost every case, according to Taylor, each product started as series of failed experiments trying to dislodge well-established rivals. “I think I’m personally driven to ‘fix’ product experiences that seem backwards or antiquated, which seem to be by-products of industries with heavily entrenched competition,” Taylor says.
At First Round’s CEO Summit, Taylor distilled his key lessons and tactics from building many products in competitive markets and successfully taking on entrenched competitors.
Coming out of Stanford, Taylor deeply believed that product quality leads directly to market success, and his first job out of school at Google reinforced that view. “There was widespread skepticism about Google when it was released — sure, it was a better search engine, but would anyone care? There were tons of other search engines at the time. And why would people use a dedicated search engine when search was built into the the most popular portals on the internet like Yahoo and Excite? But sure enough, Google was a much better product, and it did win.” Google was a company built on the premise that the best product wins, period. For young product managers like Taylor, this cemented the idea that if you could build a better mousetrap, it would always win.
Unfortunately, Taylor says, “Most of us who have founded companies have discovered it isn’t quite that simple. In fact, I’d go so far as to say that Emerson’s quote is completely misleading — even in the cases where the better mousetrap wins, it’s rarely just because it is better. In fact,” he jokes, “there are more than 4,000 patents filed and thousands of denied applications for mousetraps, practically the most frequently invented device in US history.”
Taylor says that he has taken this path unsuccessfully multiple times in his career — focusing on building a better mousetrap when that alone was almost certain to fail. But as he examined the process of designing and building all the failed products, as well as the ultimately successful ones, he discovered a common pattern.
With rare exception, the better mousetrap doesn't win simply because it is better.
According to Taylor, the biggest problem with the “better mousetrap” theory of development is that it ignores the unique strengths of the incumbent's products that you're competing with.
1) Incumbents have entrenched distribution channels
The first problem you’ll face is that incumbents always have huge structural advantages in their distribution model. Taylor jokes, “While you’re the chump selling your mousetraps directly to consumers, the incumbent MegaCorp has a thousand distribution channels and partnerships. Most of the customers aren’t even sure what they pay for their mousetraps or even if they pay for them at all.”
“Whether it’s Yahoo Yellow Pages being built into the most popular web portal in the world when I was working on Google Maps, or Google Docs being bundled with the most popular webmail provider in the world now that I’m working on Quip, you can’t underestimate how far behind the eight ball you start when you’re taking on a strong incumbent,” Taylor says. “You’re often competing on drastically uneven terms — and your competitors’ business model may make it impossible for you to distribute your product head-to-head and actually win.”
2) Habits die way harder than you’d expect.
The second problem you’ll face is, as Taylor puts it, “people care a lot less about better mousetraps than Ralph Waldo Emerson did.”
In many ways, your quietest, most steadfast competitor is indifference.
To put a point on this, Taylor explains how complex this can be even for a product that everyone agrees is better: “I don’t think it is particularly arrogant of me to say that Google Maps was about two million times better than MapQuest when we launched in 2005. Yet by the time I left Google in 2007, Google hadn’t yet passed MapQuest in traffic. It took over three years, despite the fact MapQuest was frozen in time in the Internet stone age, and Google Maps had a link on the Google homepage, which is a heck of a lot more distribution than most startups have.”
It turns out that MapQuest was so entrenched, it was a verb for a broad swath of the population. For most people, the inertia was “if you’re just getting directions, and MapQuest doesn’t get you lost, why switch?”
3) Just being different isn't enough. Your customers have to care.
The main problem startups face when taking on a strong incumbent is differentiation. The hard part about differentiation is not making something different, but getting your potential customers to appreciate that it is different and better before they actually make a purchasing decision.
It turns out that it’s way harder than it looks.
“There’s a rule of thumb that you have to be 10X better, not 1X. But I think it’s actually more complicated than that,” Taylor says. “You might be 10X better, but your customers may not even understand why it’s important that you're better. Your customers might actually be judging your product on a completely different axis, and they won't even notice your differences.”
An Example of All Three Problems: Getting to Google Maps
Google Maps is Taylor's favorite example of all three of these problems, because it was actually the third product in a series of attempts that Taylor and his team at Google made to tackle the problem of Local Search at Google. In his words, “The first two weren’t very good, and no one talks about them, but they played a big part in why Google Maps came into existence.”
When Taylor first arrived at Google, his boss, Marissa Mayer, asked him to tackle a seemingly simple idea: Local Search. Local Search was different than Google’s well-loved web search engine. It wasn't just a search query, but a search query and a location. The things you wanted back were different — rather than just wanting a list of web pages, you might want the phone number of a restaurant to make a reservation, or directions once you found out where the restaurant was located.
The dominant product in the space at the time was Yahoo Yellow Pages. “Yellow Pages search engine really sucked,” according to Taylor. “They were basically a virtual version of the actual book, so they had no content whatsoever — just a name, category, and phone number for every business. If you searched for ‘baseballs’ it would return no results because the category was ‘athletic equipment.’ Your queries only worked if you memorized the categories of the Yellow Pages or clicked around for an hour.”
Google's insight was that the web was filled with content about local businesses, and Google was extraordinary at mining the data on the web. Taylor’s team decided to build a local search product around this concept.
Search by Location
“The first product Google launched was basically the most incremental thing we could build on top of our existing search technology that tried to prove the concept out. It was called ‘Search by Location.’ We geocoded every mention of a location in our entire Web search index. Using that, you could type in a query and your location, and we'd return web pages that mentioned places around that location, filtered by your search query.”
The grand theory was that Google would pick up great restaurant reviews and forum discussions buried deep in Google's web index that no one else had. “In practice,” Taylor says, “it was probably the least useful product Google ever released.”
With Search by Location, according to Taylor, you’d search for “coffee in San Francisco,” and you’d get a bunch of web pages talking about coffee, but no actual coffee shops. Worse, if you searched for “coffee near Menlo Park,” all you'd get was Sun Microsystems web pages. Sun happened to be headquartered in Menlo Park, and the company’s web pages were riddled with coffee puns thanks to Sun’s popular Java programming language.
Google Local
Google Local was, according to Taylor, “a slightly better second attempt at building around this core differentiator — getting local content from around the Internet — but crafted into a product that was actually useful.”
Taylor's team combined a structured database of Yellow Pages data with Google's extensive web index so that when you found a business, you'd see every web page that had ever mentioned it, including its homepage and a bunch of reviews. “You could even search for details like an item on a menu, and it would match the restaurant,” Taylor explains.
“Our search quality was at least 10X better than Yahoo Yellow Pages. We genuinely felt like we’d done it — we built a better mousestrap. We believed that if we sent a bunch of traffic to Google Local from the Google homepage, then the digital equivalent of ‘beating a path to our door’ was inevitably going to happen.”
But as you’ve probably guessed, it didn’t quite happen that way.
Google Local was better because it let you search for anything — not just the name of a restaurant, but details in its menu, and it would return great results. But, despite this power under the hood, on the surface, it actually looked a lot like Yahoo Yellow Pages.
“Google Local was really formative for me as a product designer because I knew it was better — not just in subtle ways, but in very meaningful ones — but people didn’t discover it,” Taylor says. Taylor says the reason is that people weren’t actually using the new features the Google Local team built. “Everyone was doing the same thing that they were doing on Yahoo Yellow Pages. They’d go to Google, type in the name of the business, get the phone number, and leave. They could have done fancier searches, but very few people actually did.”
Because users were so stuck in their habits from Yahoo, they couldn't tell that the product was better.
Because people’s behavior hadn’t changed, our differentiators didn’t actually matter.
For Taylor, Search by Location and particularly Google Local — the two predecessors to Google Maps — are perfect examples of the fact that even products that are better can fail in the face of strongly entrenched incumbent products with well-defined habits and expectations.
“In entrenched markets, you’re not the one defining what a product does. Incumbents and competitors are actually telling customers what your product should be. You’re trying to differentiate against that story, and often your potential users won’t understand or discover your differences.”
So, how do you win?
For Taylor, he has learned two big lessons from the ultimate success of Google Maps and from building products like FriendFeed, Facebook, and Quip:
1) Familiarity can be a fatal weakness.
As Google Local was struggling, a couple of engineers named Lars and Jens Rasmussen had created a demo of a native Windows mapping app they called Expedition. Taylor explains, “They created most gorgeous maps I had ever seen in software — an immersive and interactive experience I had never seen before. We played around with overlaying our local search results on top of the map, and we all had an ‘a-ha’ moment.”
By putting the local results on the map, it completely changed how you approached the search experience. “Instead of looking up a phone number, your immediate inclination was to explore a neighborhood. The process of searching was multidimensional and visual — you could see the restaurants lined up on Main Street rather than seeing a list of addresses in a table. As we showed it around Google and let them play with it, people were immediately zooming in on their neighborhoods and homes, and discovering things.”
In Google Maps, people were using all the features they ignored in Google Local.
Taylor says, “We originally viewed the familiarity of Google Local as a strength, but it turned out to be an insurmountable weakness. One of my biggest lessons from watching the early internal users of Google Maps was that we needed to present people with an unfamiliar experience to get them to change their behaviors.”
2) You have to make your users a little uncomfortable to make “better” matter.
The power of Google Maps wasn't that it was better local search, it's that it was completely different. “When you used the product, your expectations about the experience instantly changed,” Taylor says. “The map interface reframed the product category around the strengths we wanted our end users to discover — exploration and breadth. People instantly found things on Google Maps that they never even searched for on Google Local. We made our users a little bit uncomfortable, but in doing so we reset their expectations and new behaviors came out of it.”
The new interface encouraged the kind of exploration that the stagnant, incumbent competitors trained users not to attempt.
“To compete with Yellow Pages, we created a map. And the crazy thing is, it worked.”
The bottom-line is you have to build a lens to allow users to see a new world rather than features to help them see an old world better.
The Takeaway: Taking on 30 Years of Microsoft Office History with Quip
Taylor encounters many of the same lessons as he and his team build Quip. “Quip is a next generation productivity suite, and we’re taking on Microsoft Office. Office is a slightly more formidable competitor than Yahoo Yellow Pages. But just like Yahoo Yellow Pages was a bad experience despite its market share, we believe Office is outdated and deserves to be disrupted.”
Taylor and his co-founder, Kevin Gibbs, started Quip on the premise that the way people worked has fundamentally changed over the past decade — people aren’t opening up a Microsoft Word and writing memos on virtual 8.5 x 11 sheet of paper anymore, and teams are moving away from email to more modern forms of communication like chat.
According to Taylor, “Work has become more collaborative, more mobile, more social, and more informal. The experience of Quip is actually less about creating perfect content than it is about collaboration. Rather than writing in one product and sending an email attachment to actually talk about it, teams communicate directly inside Quip documents and spreadsheets as they edit and update them.”
As a consequence, Taylor says, the customers who really “get” Quip have documents that are completely different than the documents they had in the last generation of products: rather than memos and contracts, they're creating team checklists for project management, spreadsheets to track recruiting candidates and editorial calendars, and year-long documents full of weekly meeting notes.
But, Taylor laughs, “we constantly run into the same pitfalls that I encountered in Google Local. For example, when we first started experimenting with Spreadsheets, we added all these communication and social features — because that’s what Quip is all about — but we made the mistake of wrapping it up in a package that looked like Excel. We showed it to a few friends and family, and instead of collaborating, the response we go was, ‘Where are the pivot tables?’”
Taylor and the team went back to the drawing board to try to reframe the product in a way that distanced Quip from the old behaviors. Rather than making spreadsheets a separate type of document like it is in every other product, the Quip team made it a component that you can embed inside of any document — sort of like a really powerful table.
“All of a sudden,” Taylor says, “people’s feedback changed — because their expectations changed. When they opened Quip, rather than trying to recreate the experience they had in Excel, they were creating new experiences. We had a growth engineer embedding a mix of screenshots, analysis, and spreadsheets to track a growth experiment.” The same family member who had complained about the lack of pivot tables complimented Taylor on how powerful these new tables were in Quip for tracking RSVPs for an event.
“We turned an underpowered spreadsheet in a super-powered table, and people immediately understood not just why Quip was different, but why it was better.”
Just like with Google Maps, by presenting people with an unfamiliar experience and making them a little uncomfortable, their behavior changed, and they used all the differentiated features the Quip team built.
Taylor’s experience has changed his product design philosophy. “In the past, I was always trying to make products familiar first and then figure out where to deviate. Now, I try to start by thinking how to make a product as uncomfortable and as different as possible, but still maintain a path for people to go on that journey with me.”
“There’s always a tension as a product designer between how ‘new’ and ‘different’ you want your product to feel on that first day. Discovering where that line is is always a mix of intuition and experimentation,” says Taylor. “But if you are trying to disrupt an incumbent, I think it’s absolutely necessary.”