This podcast is a live conversation I hosted for Skip Coach, a community of senior product and tech leaders navigating career transitions together. Members get access to live sessions like this one, including real-time Q&A, before the content is shared publicly. If you’re a product or tech leader looking to maximize your career, apply to join Skip Coach — it’s free — to access this content and other exclusive resources.

Brought to you by:

Firecrawl: Power AI agents with clean web data—Use code: THESKIP to get 10,000 free credits today

Jira—Do the right work with Jira

Saswat Panigrahi tood outside an Airbnb in Phoenix and watched an empty car drive away with one of Waymo's first riders inside. His team had spent three weeks preparing this volunteer: the whole family gathered in the living room for the briefings, though only one of them was scheduled to ride. Saswat walked him through it one final time that morning. None of it kept the person from grabbing Saswat's arm when the car pulled up: "Hey, there's no driver." And once the car pulled away, the anxiety stayed on the curb. Multiple teams were monitoring the ride on multiple tools, and every one of them showed the rider was physically safe. What no dashboard could show was what the product team actually needed to know: was this person anxious in there, relaxed, enjoying the ride, or just waiting for it to be over? Four minutes in, they called into the car. The answer: "This is magical. Don't worry about it. I'm relaxing here. Chill out. You should chill out as well.

There is no playbook for solving problems of this scale: no experiment to run, no dashboard to watch, no way to learn except to ask. And the results are mind-boggling: over the ten years since that team formed, they solved driving.

I sat down with Saswat, now Waymo’s Chief Product Officer, for the third conversation in our Inside PM series, after Meta in June and Stripe in July. He joined in 2016, back when Waymo was still the Google self-driving car project and the product team was fewer than five people. He has spent ten years on the same product, through the first fully autonomous rides in Phoenix and the San Francisco launch. Today the service has driven over 220 million miles with no one in the driver’s seat, cutting severe injuries, he says, sixteen-fold versus human drivers.

Today, AI gives you an arsenal of tools that can be pointed at far bigger problems than anything we’ve tackled in the past decade. Many of you are already working on products that were science fiction a dozen years ago. But big problems don’t yield to the playbook that defined traditional product management, where everything ships this sprint and gets measured next week. Waymo never had that option. It was an AI product ten years before the rest of us were building them, the stakes were physical, and the feedback loop ran in years. So the job itself had to shift: some things deleted, some things added, some things re-emphasized. That’s what this hour maps, and it changes your career calculus too. Some of what follows is a completely new way of working. Some of it is the greatest hits of product management, pulled back to the center of the job.

Below are the insights I keep coming back to. The full episode has dozens more.

Measuring “Good” Became Its Own Product

The car either crashes or it doesn’t, but “is it driving well?” had no metric. Waymo built one, and staffed PMs on it.

Most product teams get their measurement for free. Ship the feature, watch the metrics, let users grade the work. Parts of that held even at Waymo: reality tells you when a car crashes. What reality couldn’t tell them was whether the driver was good, and the reason is almost philosophical:

Saswat’s translation for everyone outside autonomy: say you’ve built an AI agent that handles accounting for small businesses — people who wanted to run a pizzeria, not study bookkeeping. How do you know it’s good enough? You can’t fully specify correct behavior in advance, because if you could, you’d be done. Every team shipping an AI product is now living inside that loop. Waymo has been living there since 2016: “transformers were driving the car back in 2017 for us.”

Their answer was to treat the evaluator as a product in its own right. The pattern he describes is a leapfrog: make the evaluator harder, push the driver to catch up, and when the driver improves, upgrade the evaluator so it stays “a good amount of a challenge or a critic.” The engineering this demanded was genuinely strange. Suppose you’ve proven the car detects a kid jumping out “just when their first finger is entering the scene” — superhuman response time, on a clear day. Is it still true in rain? In San Francisco fog? Waiting for the right fog and a kid at the same moment is, in his words, “another 10 years.” So they learned to inject realistic rain into previously observed scenes: “frontier challenges five, six years ago, for which we didn’t even have the vocabulary,” and now the world sees the same class of problems when building world models. At the extremes, they were measuring failures so rare that “statistical methods begin reaching their boundary.”

And Waymo staffed for it: the org has pure eval PMs. “Their entire job is to increase the fidelity of the metrics so that the other teams can be held appropriately accountable. Not just accountable, but they have something to hill climb on.” Product headcount dedicated to keeping the measurement honest — because tests drift out of date and flag failures that aren’t real, and someone has to keep fixing the test itself. His hygiene bar for any team’s dashboard is the same idea at smaller scale: know whether each number can be trusted, and whether higher is actually better.

Saswat thinks this is where product careers are heading:

“Specifying what good looks like remains a very challenging skill that I think product leaders should lean into whichever domain they are in. What does good look like in healthcare? What does good look like in providing counsel? What does good look like in accounting and legal? Super hard problem, and I think huge amount of runway for anybody who wants to dive deep into that.”

A reinforcement-learning system can climb toward anything you can articulate (with eval). Articulating it is the new skill.

Head in the Clouds, Feet on the Ground

A semi-spiritual mission carries you through a decade. Checkpoints carry you through the week.

In 2016, telling people that cars would drive people “felt pretty crazy.” New joiners got asked why Waymo made any sense as a career move, since the growth path was so much clearer elsewhere. What holds a team through that, in Saswat’s telling, is a mission that is “almost semi-spiritual.” His bar for it is specific: it has to pull people past the rewards that normally run out. Past “making it into L6 or L7 through the performance review,” past the next benchmark win, past the VP title.

For Waymo that pull was never abstract. Forty thousand people die on US roads every year — 1.2 million globally — and most of those collisions are preventable.

That’s the cloud half of the job — a mission with no ceiling.

But he’s just as clear that vision alone fails. Fill people with energy and give them no structure, and you get “Brownian motion” — his physics-grade term for a team vibrating with purpose and going nowhere. “Great product leaders always have this capability of inspiring vision, but then very quickly channeling that energy into three tracks, four tracks.” Then the line that inverts how most ambitious teams behave: “pure visionary types often struggle at that second part,” so the bigger the vision, the more crucial the breadcrumbs you lay along it.

The checkpoints are brutally concrete. Want five thousand autonomous vehicles someday? Fine: “Let’s remove the test driver from just one car.” Work backwards from that single milestone and it unpacks into checkable facts — the computer has to stop crashing every three hours, the sensor has to clean itself, pedestrian detection has to hit a specific accuracy. “What do you need to get done by next week? What do you need to get done by next month? So that it’s not a vague, arbitrary path.”

If your team is running on AI-flavored promise right now, a hypothetical future half a decade out that justifies today’s grind, this is the discipline that transfers. Saswat spent ten years motivated by a theoretical product. What kept it honest was never the dream. It was next week’s checkpoint.

Titles Don’t Make People Follow You

An impossible problem strips leadership down to three traits: competence, courage, and compassion.

Saswat spends most of his day in meetings where, in his words, “people far more qualified and competent than me in a specific field are presenting.” The question he keeps asking himself: “Why should these people follow?” Why should they take his decision and accept it — or disagree and still commit? Titles don’t answer it. “You can give somebody a title, you can promote them to a level… but people need to follow them for your objective to be achieved.” What builds followership, in his ordering: competence, courage, compassion.

Competence has a test you can run on yourself this week. When specialists present to you, “are they a little bit surprised that you know that stuff? Or are they starting from 101 in that field?” The same test follows him into rooms full of regulators and policy staff, where the homework is their world, not his.

His sharpest observation: any organization, ten people or ten thousand, already knows its biggest problem. Ask the lunch line what the biggest frustration is: “they’ll tell you.” What kills companies isn’t ignorance. It’s that the known answer “goes through a crazy multi-quarter OKR planning process… ‘Well, you know, we are tapped out for this quarter. We can get to it in Q5 of next year.’” The leaders people follow are the ones who run at the biggest problem relentlessly, without waiting for a planning cycle to bless it.

Compassion is the third trait, and it’s what makes the other two survivable. Killing a bet takes courage: “I know we put a lot of effort in this kind of lidar or this kind of simulation technology, and it didn’t work out. It’s time to kill this bet.” But how the cancellation lands matters just as much, because a mission this long needs a team that stays “elastic with failures.” The example he walks through: a PM books a long-lead component three years out after studying the best supply chains in the world, and gets it “miserably wrong.” They stand up in front of the whole product org: these were my inputs, this is what I learned, I apologize for spending your time. Saswat’s question: “Would I trust that person to make the next prediction? Or would I trust the person who hasn’t gone through that misery?” The failure gets celebrated — “each failure should be an opportunity to call out the heroes” — because delivering the same correct cancellation without compassion shrinks the team’s appetite for the next bet.

One more thing worth noticing about his list. Earlier this year I wrote that the profile winning this market is the executive builder: the hands-on build muscle combined with executive presence. Saswat’s three traits map onto it cleanly. The competence test is the builder litmus, and courage and compassion are the executive half. Waymo couldn’t sort its leaders by traditional milestones — there weren’t any for years at a stretch — so it screened for executive builders a decade before the market turned that way.

Train to the Point of Failure

Insane curiosity, compounded daily: one percent a day is thirty-seven times in a year.

Waymo’s problem kept changing species: a research project became a hardware program became a live service, and a playbook mastered in year one didn’t describe year four. Saswat’s hedge is not a strategy but a daily habit, and he describes it the way a trainer would: push some skill or some piece of knowledge to the point of failure, every day. Scrolling Twitter and a new AI chip piques your interest? Don’t scroll past — follow it until you’re genuinely out of your depth. “There may not be a straight line from that,” and that’s fine.

This is not the competence of the last section — that was depth in your own domain. This is voracious curiosity about everything adjacent to it, and it matters most now that knowledge itself has become a service. When any fact is a prompt away, the edge belongs to the person who has pulled enough fields together to combine them in novel ways.

His formula for the habit: “1.01 to the power of 365, to the power of 20.” Run the arithmetic and one percent a day compounds to thirty-seven times in a year — then he runs it for twenty. Two candidates tell you they have twenty years of experience. One has “done the same experience repeated 20 years over and over.” The other has “accumulated a greater breadth of skills to be able to adapt if the input parameters changed.” Same résumé line. Utterly different leaders.

His own proof case is almost comically small. In the early days, while cleaning lasers, he noticed the moisture accumulating on sensors in Mountain View was different from San Francisco’s. It was not immediately clear how that knowledge would be useful, but it helps build empathy and understanding when a hardware engineer, a supply-chain planner, and a software lead are pulling a long-horizon decision in three directions. He reaches for an old Edwin Markham poem to explain the habit: “For all your days prepare. When you are the anvil, bear. When you are the hammer, strike.”

Waymo made this curiosity a cultural value rather than a private virtue. The product org sometimes skips all-hands, but once or twice a week, a leader presents with almost no prep on a single topic: “This is what I learned last week.” Goals shift and setbacks land, so learning is the one constant the team celebrates in public. And Saswat holds himself to it: he admits he feels “constantly inadequate” about keeping up with AI, and treats that feeling as fuel.

It’s also the hiring screen. The interview question is “describe the hardest thing you have done” — listening for grit on the mission paired with “a flexibility of adopting whichever tool is necessary.” Tool fluency can be taught. Hunger can’t. Hire the hungry, and next year’s tools take care of themselves: the curious will have tried them before anyone asks.

PMs by Choice, Not by Necessity

No one person spans photonics, supply chains, and this week’s release. The team does.

The last piece is who Waymo hires into product in the first place, because the team was assembled the way you’d provision an expedition — for range. There are PMs with PhDs in photonics who went on to run businesses. The bar Saswat describes: enough bedrock skill that “you could be dangerous in other fields as well. But you chose to become a PM.” It was not a necessity. Individually, nobody covers the whole problem — “maybe individually we are not strong enough to span hardware, software, five-year forecasting versus this week’s release. But together as a team,” reinforced by that weekly learning ritual, they do.

The same range shows up in the cultures Waymo deliberately collided. Ex-NASA and aeronautics safety people work alongside internet-era product people. One camp wants to push software every two years, the other every day — “the answer, of course, lies somewhere in between,” and building the process that finds the in-between is the actual work. Worth remembering the next time your company hires its cultural opposite.

And underneath all of it sits a discipline Saswat brought from his pre-Waymo career: feel the customer’s pain directly. He has listened live while an angry customer called, phoned back customers he’d let down, visited the site of an outage he caused. “Everybody agrees product managers need empathy for the customer. But over time it has gotten diluted… You got to actually feel the wrath of the gaps that your product has.” Early Waymo PMs hand-carried software releases down to the cars in the garage — which is why “this won’t scale to a thousand cars” was never theoretical to them. A team picked for range, collided across cultures, and grounded in the product’s rough edges doesn’t need its problem to be easy.

The Playbook

Waymo set out to tackle a mind-bogglingly hard problem — and the lessons from the team that pulled it off transfer to anyone taking on an ambitious problem today. Six things worth acting on from the conversation:

• Write down what good looks like — for your product, in your domain. Precisely enough that a team (or a model) could hill-climb toward it. This is the skill Saswat says careers will be built on, and almost nobody owns it today.

• Give your metrics an owner and a stress test. Someone on your team should be accountable for whether the numbers can be trusted — the eval-PM idea at whatever scale you can afford. Start by asking, for each number on your dashboard, whether higher is actually better.

• Match your vision with checkpoints. If your product runs on promise, name what must be true by next week, next month, next quarter. The bigger the story, the shorter the checkpoints.

• Run at your org’s biggest problem. Everyone already knows what it is — ask the lunch line. Start before the planning cycle blesses it; underequipped is fine, unaddressed is the failure mode.

• When you kill a bet, kill it with compassion. Name the heroes and what they learned, publicly. You’re not closing a project — you’re setting the price of the next risk anyone takes for you.

• Feed your curiosity daily, for years. Insane curiosity coupled with tenacity, run consistently: one percent a day compounds to thirty-seven times in a year. That’s the difference between twenty years of experience and one year repeated twenty times.

The thread under all six: the biggest problems yield to a different kind of product management — Waymo’s decade proves it, and AI just put problems that size within your reach. Borrow the head start.

Have your own career question? Get personalized guidance at Nikhyl.AI. It’s where the questions keep coming, and where I’ll keep sharing what I’m learning.