Bret Taylor on Failing Forward: From Google Local to Google Maps to Sierra's Agents

Taylor starts with his first prominent mistake as a product manager. Joining Google around late 2002 or early 2003, he first worked on expanding the search index from one billion to ten billion pages, then was handed a new bet on local search by Marissa Mayer. The launch, Google Local, was in his own critical retrospective a "me too" take on Yahoo Yellow Pages, grafted onto Google Search.

It had a link on the Google homepage, which is about the best distribution a product can get, and it still did not do well. The product worked but gave no one a reason to prefer it over Yahoo Yellow Pages or the paper Yellow Pages. After a tough product review with Mayer and Larry Page, he was given a chance at a second version, though he felt dejected.

The rework started from a nagging irritation: the licensed MapQuest map beside the results was the ugliest part of the product, so the team asked what would happen if the map became the canvas. They brought in Lars and Jens Rasmussen, and the effort ended up merging mapping, local search and driving directions, which had been separate product categories. On launch day Google Maps drew about 10 million users, and when Keyhole satellite imagery was added in August 2005, about 90 million came on the same day.

His lessons: do not just digitize what existed, "disassemble the Lego set" and build something native to the new platform that a paper map could not be. Satellite imagery was the sizzle on the steak and created a viral moment, even a Saturday Night Live mention, but it is a different thing from enduring value. Host Lenny Rachitsky underlines that a better copy rarely wins.

Taylor says he takes pride in having worn many hats, and that colleagues from Facebook, Google and Salesforce each remember him as an engineer, a product person or "a suit". He keeps a flexible view of his identity and thinks of himself as a builder, which he says a founder needs in order to transform into whatever the company needs next.

The turning point came when he became CTO of Facebook and ended up running a platform and mobile group of over a thousand people. He was doing okay but not great, and Sheryl Sandberg pulled him aside after he was editing a partner presentation himself and gave him direct, uncomfortable management feedback. After stewing for a night he concluded she was right: he had been trying to conform the job to the things he liked instead of asking what mobile and platform needed.

Reframing the job, he found he enjoyed the results, such as healthier partnerships, more than the craft he thought he loved, and realized what he really liked was impact. Since then he starts each day asking what the most impactful thing he can do is, as if an external board were advising him. He now enjoys many things he previously would not have claimed as favorites.

He then adds a warning: the question is easy to ask and hard to answer honestly. Founders create incorrect stories, such as a lost deal being "too expensive" when the real issue was differentiation, and customers soften their feedback the way people do in a breakup. Each founder is also a single-issue voter for their own strength, whether engineering, redesigns or partnerships, so a good co-founder and leadership team are needed for real conversations.

Taylor gives FriendFeed as his hard-learned example. The company peaked at 12 employees, with a founding team that included Google Maps and Gmail people, and it invented concepts like the like button and the real-time feed. It was popular mainly in Turkey, Italy and Silicon Valley, was a follower-based network closer to X than Facebook, and was not a successful business.

When celebrities including Obama, Ashton Kutcher and Oprah joined Twitter in one summer, FriendFeed got "our ass kicked", as he puts it. Although Twitter was down half the time and FriendFeed had more features and full uptime, 11 of 12 employees were engineers focused only on polishing the product while Twitter put people worth following on the service. He thinks Google's AdWords-fueled success made it hard for product managers to learn about distribution.

The structural flaw, he says, was not seeking outside advice that would tell the team what it did not want to hear, which is why he believes in boards and advisors. Asked how to choose whom to listen to, he notes that confidence is not correlated with the quality of an opinion. He suggests asking who else you should talk to, and always asking "why" like a two-year-old, because people extrapolate from a few experiences and phrase them as rules.

Asked whether students should still learn to code, Taylor separates coding from studying computer science. He expects creating software to shift from typing into an editor to operating a code-generating machine, and operating it well takes systems thinking, which computer science teaches through ideas such as complexity, algorithms and cache behavior.

His example is Facebook's newsfeed. Designers' polished mock-ups showed perfect photos and tidy comments, but the real feed looked bad because content varied wildly and was out of the designer's control. The fix was to require designs to be shown with real, messy feed data, and he says the lesson is that you must hold a system in your head whether AI writes the code or not.

He thinks the famous story of him rewriting Google Maps over a weekend will become a vestige, like human calculators at NASA, and the skills he was good at may not stay valuable. Still, he compares dropping fundamentals to skipping math, since these disciplines teach how to think and will help in constraining something smarter than you that produces code you may not fully understand.

Taylor says he would call it a programming system rather than a language. He sketches the history of abstractions from punch cards to Unix and C to Python and TypeScript, and argues that many abstractions exist to make human programmers productive. If writing code approaches zero marginal cost, those choices should be revisited, and he calls Python, designed to read like pseudo-code for humans, a comically bad target for AI because it is slow and hard to verify.

What matters for machine-generated code is knowing that it did what you wanted and being able to change it easily. Rust is his example: a successful compile tells you the program does not leak memory, unlike a million-line C program. He adds that AI supervising AI, formal verification and unit testing can be layered on, with the goal of letting an operator produce complex software quickly and know that it works.

On vibe coding, he is excited but says generating a prototype has never been the limiting factor in software. Building increasingly complex systems and changing them with agility is, and he cites the Netscape 1 to Netscape 2 rewrite as a cautionary tale. We are, he says, in the very early phases of defining the new system for developing software.

On what he teaches his kids, Taylor says the main thing is to make AI part of their lives. He compares it to graphing calculators on the AP calculus exam, which forced exams to be redesigned, and notes that much education does not yet presume a superintelligence in your pocket. An essay on a book is now easy to generate, so evaluation methods are broken for the moment, and he feels empathy for teachers.

On the positive side, he describes his kids using ChatGPT to quiz them before tests, his daughter photographing a Shakespeare page it explained better than he could, and his oldest daughter using it while learning to code. He calls it an amplifier of agency and a democratizing force: a child no longer has to be rich to get a tutor, and a math whiz at a school without advanced statistics now has access.

He cautions that the same tools make it easy to avoid learning, so students without agency may use them to dodge work. In response to Rachitsky's question about when to give a child a ChatGPT account, he separates it from phones, which he would delay for a long time, and likens AI to Google search: more a utility than an addictive, notification-driven device. His kids use the computer on the desk.

Taylor splits the AI market into three. Frontier models will be a handful of hyperscalers and big labs, like cloud infrastructure, because they are a function of CapEx and the models lose value quickly. Startups that tried, he says, have mostly been consolidated, so no entrepreneur should build one, with Elon Musk the exception because he can raise billions.

The second segment is tooling, the "pickaxes in the Gold Rush": data labeling, data platforms, eval tools and specialized models such as ElevenLabs' voice models. It is a real market but "close to the sun", because infrastructure providers keep moving up the stack, and the question is when, not whether, a large provider ships a competing product.

The third is applied AI, which he thinks will play out around companies that build agents, and he calls the agent "the new app". He names Sierra for customer service and Harvey for legal work as examples, and expects higher margins than model providers because the product sells a business outcome. Just as nobody asks which database a SaaS product uses, buyers will ask about workflows and outcomes, and he predicts a long tail of agent companies led by entrepreneurs who deeply understand a business problem.

Asked why he is so bullish on agents, Taylor cites economists such as Larry Summers, his OpenAI board colleague, on the big productivity jump from early computing, and gives the example of his father's engineering firm, where drafting vanished once design software replaced it. Later software mostly helped individuals be slightly more productive, he says, while agents accomplish a job autonomously.

He notes that productivity software is hard to sell because its value is unattributable: a vendor argues that if every salesperson sells 5% more, you should pay a million dollars. An agent doing a job is both real and measurable, which is why he believes the whole market will go toward agents and outcomes-based pricing, a shift he compares to the move away from perpetual on-premises licenses.

At Sierra, a customer's agent handles a call or chat, and a typical phone call costs roughly $10 to $20, mostly labor. If the agent resolves the issue without a human, there is a pre-negotiated resolution-based price, and some sales agents are paid a commission. He distinguishes this from usage pricing, and compares per-token pricing to measuring engineers by lines of code, since a long call that doesn't solve the problem adds negative value.

Outcome pricing makes a vendor a partner, he says, with an extremely customer-centric orientation, since you can't just throw software at the wall and still get paid. He says Sierra customers automate between 50% and 90% of customer service interactions, across industries from insurers and banks to retailers, DIRECTV and SiriusXM, and he cites CSAT scores of 4.6 and 4.7 out of five for two of the agents.

On skepticism about productivity, such as a study in which engineers were slower with AI, Taylor says he is bullish but the tools are immature. Reviewing someone else's code to find a subtle logical error is harder than editing your own, so an agent's incorrect output can cost cognitive load. He suggests having AI review AI, reasoning that if one agent is right 90% of the time and another catches 90% of the remaining errors, together they approach 99%.

At Sierra, one engineer focuses exclusively on the Model Context Protocol server feeding the team's Cursor instance, so that when Cursor produces something wrong they root-cause the missing context rather than just fix it. He frames this as context engineering and says people should stop waiting for models to magically get better. Rachitsky asks how it works, and Taylor, saying he is out of his depth, answers that it is essentially MCP and that a poor decision from a good model is usually a lack of context.

On go-to-market for AI apps, he lists three proven models and says to match them to the product. Developer-led, as with Stripe and Twilio, suits platform products sold to engineering teams. Product-led growth suits cases where the user and the buyer are the same person, such as small business software, and not expense software where finance is the buyer.

Direct sales, in the lineage of Oracle, SAP, ServiceNow and Salesforce, sells into large lines of business, and he has seen it come back into fashion with AI companies because many opportunities have different buyers and users. Founders stumble, he says, by choosing a motion without thinking through how the software is purchased and evaluated, and many should use direct sales more than they do.

In the lightning round Taylor recommends Competing Against Luck, the book behind Jobs to Be Done, though he jokes most business books should be articles, and Endurance, the story of Shackleton's expedition, as the best story of grit he has seen. He recently watched Inception with his kids, and names Cursor as a product he loves while calling it a transition product on the way to agents.

His life motto is that the best way to predict the future is to invent it, which he attributes to Alan Kay. On the like button, he explains that FriendFeed posts drew many one-word replies such as "cool" or "wow", so the original framing was a one-click comment meant to clear out acknowledgements so real discussion could remain.

The first version used a heart, but a colleague, Anna Yang, disliked the idea of hearts on every post, and a heart was wrong for a post about a tragedy. They settled on "like" as positive but as neutral as possible. He closes by pointing listeners to sierra.ai and its careers page, with offices in San Francisco, New York, Atlanta and London.