Product: Behind the Craft: LaunchPod

Building AI Products for the Other 95% | Brian McMullin, SVP Product (Network Solutions)

Jeff Wharton — Tue, 22 Sep 2026 13:19:08 GMT

Most of the AI products getting hype right now are built for people like us: the tech industry. But your customers don’t care how the AI works — they just want their problem solved in a way that’s easy for them.

Brian McMullin, SVP and Head of Product at Network Solutions, has spent 15 years building for small businesses at companies including HubSpot, ezCater, Wayfair, and SamCart. In that time, he’s yet to meet a business owner who wakes up thinking, “I can’t wait to use AI today.” For many of them, a prompt box might as well be a terminal window.

So his team doesn’t ship the box. They ship the finished work artifact, and all the user has to do is claim it.

In this episode, Brian shares:

Why doing the work for small businesses first, instead of handing them an empty prompt box, is what gets them to try AI
His warning about baking inference into the core of your product before token pricing settles — and the two models he’s testing to find out what small businesses will actually tolerate
And what SamCart taught him about churn: customers left because basic things were broken, not because features were missing

1. Nobody wakes up wanting to use AI

Brian’s customers get maybe a couple of hours a week for anything that isn’t serving their own customers (marketing, website updates, invoicing, etc.). Nobody in that position is going to spend it learning what a good prompt looks like. So his team skips the box, and even the menu of agents to pick from:

“Rather than showing them the prompt box, or even, ‘Hey, we have these agents, come use a marketing agent’ — we need to take one or two steps further and say, ‘We’ve used this agent to map out your next two weeks of social media posts. Go schedule them, and if you want us to keep doing this every two weeks, turn it on right here.’ Come and claim it.”

The customer’s only job is to approve something that already exists.

Product takeaway: Make the action you want to be the easiest one available. For non-technical users, that means doing the work speculatively and asking for confirmation, not instruction.

2. Proactive AI only works if it’s specific to that customer’s business

There’s an obvious failure mode here, and Brian names it first: if you do the work for someone and make it generic, then you’ve just built a spam machine.

“It can fall flat if it doesn’t feel personal… The tricky part there is what you need to drive that level of personalization is ultimately context.”

His argument is that this is where established software companies have a real edge. Everyone has the same models, but not everyone has years of history about how a particular business actually operates.

Product takeaway: Take inventory of what you already know about each customer that a competitor would have to learn from scratch.

3. Be careful about building inference into the parts of your product people already pay for

Serving one more customer used to cost almost nothing. Inference broke that — and telling a small business that the same outcome now costs more is a hard message no matter how you frame it. This leads to a caution you don’t often hear from someone shipping AI features:

“It’s actually almost a little bit of a warning of how deeply to embed AI into your core product and value proposition. Until we get to more stability in token pricing, the more you bake it into the core of what you do, the more you’re going to have to figure out how to have a predictable cost structure for your customers.”

Domain registration works fine without AI, so Network Solutions has some insulation. Products where AI sits inside the workflow people already bought have none.

Product takeaway: “AI-native” is a positioning decision with a variable cost attached. Work out which parts of your product would still be worth the subscription with the inference switched off.

4. Nobody has landed on the right way to charge for AI yet

Brian’s team surveyed customers on pricing and found no consensus at all, so they’re running both common models: tiered usage, which risks the problem of paying for credits you don’t use, and a flat monthly price per agent, which puts a paywall in front of something customers haven’t tried yet. Worth listening to his breakdown of the tradeoffs on each. But the sequencing argument underneath matters more than the choice:

“The biggest risk you have is that nobody actually uses the product in the first place. There is a temptation to build complex monetization models and put in tons of limits and over-engineer that aspect before you’ve truly found product-market fit.”

Product takeaway: Strict limits imposed early mostly buy you a smaller sample of the usage data you need to price correctly. Let people use it, then decide what to charge.

5. What SamCart taught Brian about churn

At SamCart, Brian’s team was building good monetization tools for creators, and marketing was excellent at selling them. Then they read the churn reasons:

“None of it was about these new features not driving them revenue. It was about, ‘I can’t get this basic thing to work. I need to add my team and I can’t do that. I can’t connect my payment processor in the way that I want to, and I’m not able to take payments.’”

He also found that customers often buy for optionality and never touch the feature they bought for, which makes the core experience, not the headline feature, the thing that keeps them.

Product takeaway: Retention is a lagging indicator, so argue for core experience work on frequency and breadth of usage instead. In the episode, Brian walks through how he makes that case to a CFO asking for ROI on a login page.

Chapters

00:00 Introduction
02:11 Brian's product journey from developer to SMB product leader
04:05 How small businesses went from distrusting AI to have AI FOMO
07:33 SMBs don't wake up excited to use AI, they want to close the deal
10:05 Stop showing the agent, ship the finished work
13:11 Inference costs break the old SaaS margin math
16:23 Testing free credits and tiered usage with small businesses
18:10 What usage-based pricing does to ARR and predictability
23:51 Churn is a pile of micro-annoyances, not one event
26:29 What SamCart's churn data revealed about broken basics
30:18 Conclusion

What does LogRocket do?

LogRocket’s Galileo AI watches user sessions for you and surfaces the technical and usability issues holding back your web and mobile apps. Understand where your users are struggling by trying it for free at LogRocket.com.

What Do You Do When AI Agents Replace Your Human Users? | Brandon Harris, VP of Product at Pantheon

Jeff Wharton — Tue, 15 Sep 2026 12:57:20 GMT

Listen on:
YouTube | Spotify | Apple

Every day, more of your traffic isn’t human. AI agents show up, grab what they need, and leave — and you pay to serve every visitor, whether they see your brand or not.

Today’s guest has seen this from both sides. Brandon Harris is VP of Product at Pantheon, the WebOps platform behind a huge slice of the WordPress and Drupal world. But before that, he was sending the bots — at Wiser, where his team scraped millions of pages a day to power retail pricing intelligence.

His take: agents aren’t killing the web. They’re just the new way information is traveling. And the companies that adapt are about to pull way ahead of the ones that don’t.

In this episode, Brandon shares:

How AI is turning the whole web into one giant CMS and quietly rewriting the job of anyone who publishes content
Why site visits are the new impressions, and what happens to hosting economics when the meter can’t differentiate a customer from an agent
Why trying to keep agents out is the modern-day version of blocking Google from indexing your site, and what to do instead

1. Agents aren't killing the web. They're just the next mode of transportation.

The “dead internet” theory assumes that this new wave of internet traffic is essentially eating itself; AI made to consume AI and AI made to be consumed by AI. Brandon has a different opinion, and he relates it to the history of transportation:

“We were walking, and then we found wheels, and carts, and animals, and then bicycles. We could do some self-powered things, and then trains, then cars. But each time that happens, there’s this sense that the new technology for transportation is gonna overtake all of the previous technology, and we’ll never use it. But the reality is, I still have to teach my kids how to ride a bike.”

If you replace the thing being transported from people to information, then agents are a genuinely new transportation method. As a result, browsing traffic is changing. But it’s not being eliminated.

“We’re gonna see a compression in the volume of human traffic, and we’re gonna see a compression in the volume of traffic that is intended just for browsing, but it’s never gonna go away. And in some ways, it makes it more valuable.”

Product takeaway: Falling human traffic isn’t an automatic sign of failure. The mix is changing underneath the number. As a result, you should segment your analytics by traffic type before you react to the topline. Because the humans who still show up are arriving with more intent than they used to, and that should change what you build for them.

2. Why site visits are the new impressions

Here’s the uncomfortable math: a bot and a buyer cost your CDN, host, and CMS the same amount to serve.

Brandon, who spent a stint as interim CMO at a previous company, sees the same correction coming that advertising already went through: going from counting eyeballs to paying for action.

"The visit will become kind of like impressions. They're valuable, but not the same value as a conversion. And we'll start to get better at tracking both."

The interesting part is that this isn’t a case for locking the gates, so to speak. Brandon’s point is that the industry posture is shifting from keep everything out to something more selective — closer to traffic grading, where a site decides what a given interaction is actually worth and both sides negotiate from there. Some large publishers are already building toward charging for access.

He relates it to sites in the past blocking Google from indexing them:

“Five years ago, everything was: how do we block bots, how do we stop them from coming? And it’ll shift to, well, we want some, but not all [agents].”

Product takeaway: If your economics are priced per visit but your value is created per conversion, you have a modeling problem that’s going to get worse every quarter. Start instrumenting traffic by value now — which agents drive real conversions and which are pure cost — so that when better grading and pricing tools arrive (Brandon guesses roughly a year, and probably from startups rather than infrastructure incumbents), you already know what you’d pay for.

3. Is the whole web becoming one giant CMS?

Traditionally, a CMS holds structured information and assembles it into a page on request. Now, that’s a pretty fair description of what an agent does to the entire internet.

Brandon watched an early version of this at Gannett fifteen years ago, where a project assembled news sites on demand from whatever content was available across hundreds of properties. The difference now is that the source pool is everyone’s site, not just yours:

“If the web is the CMS, if all this data is available very quickly in real time, I can assemble it into whatever I need it to be to either build a new product or a new page on demand.”

He’s clear that this produces slop, too, not just value — the same split we get across all platforms. Which is why the job of publishing content changes. It’s no longer enough to just have accurate information sitting on your domain. Your content now has to survive extraction and still be recognized as yours.

“How do you provide brand placement within the content that you create, so that when it is pulled, it is still representative of your brand or harkens back to your brand?”

Brandon frames this as inserting your brand’s “fingerprints” into your content the way broadcast used product placement. The industry’s done this before: Google forced an entire generation of teams to learn how to structure content for a crawler. This is the same thing, just maybe one level up in complexity.

Product takeaway: Audit your content for what survives being pulled out of context. Does a paragraph lifted into an answer still carry your point of view, data, name, etc.?

4. Look for the drift before it wrecks the tool

Unhappy users rarely file a ticket saying they’ve lost confidence in you or your product suite. They just start to drift, slowly, in a way that never shows up as an event.

Brandon’s framing for what to do about it comes in two parts:

First, know what you’re protecting:

“Understand your superpower and your kryptonite. Your superpower, amplify it — get your super suit, get the utility belt. For your kryptonite, protect against it, because it’s not just things that you’re weak at, it could be things that drain you and drain your value.”

Second, go hunting for change on purpose, because it won’t announce itself. He borrows the term from machining:

“If you’re not looking for the drift, you won’t see it until it’s messed up your tool.”

This means watching real user sessions, tracing where people fall out of the funnel and why, and treating behavioral shifts as information rather than noise. This loops straight back to agents: the mix of searchers and browsers on your site is changing right now. If AI handles the initial lookup, then maybe your search bar matters less, and your browsing experience matters more. You won’t know unless you go and check.

Chapters

00:00 Introduction
02:24 Brandon's product journey: From film school to Wiser and Pantheon
03:46 The dead web debate: Agents are just the next mode of transport
07:13 Why traffic-based pricing can break when the majority of your visitors are agents
09:37 Site visits are becoming the new impressions
12:08 Grading traffic and the identity arms race it will start
15:33 When the whole web becomes your CMS
18:02 Putting your brand's fingerprints in content that AI will pull without accessing your site
22:45 How people decide to trust a site
27:39 Watching sessions to catch user drift before customers quietly leave
32:31 Conclusion

What does LogRocket do?

Product Sense: What It Is and Why AI Makes It Vital | Kevin Sung, VP of Product (Life360)

Imane Rharbi — Tue, 08 Sep 2026 13:48:00 GMT

Listen on:
YouTube | Spotify | Apple

Everyone says good PMs have product sense, but how many people can truly define what good product sense is?

In this episode, we’re joined by Kevin Sung, VP of Product at Life360, where he runs ecosystem strategy, the foundational infra and developer experience group, and works alongside the AI platforms team. Before Life360, Kevin spent several years at Dropbox, leading the Usability team that owned performance, reliability, and CX.

Kevin’s worked in both the goal-seeking world and the customer-obsessed one, and he’s clear about which one AI is about to make obsolete.

In this episode, Kevin shares:

Why product sense is customer centricity
The difference between lazy product management and rigorous product craft (hint: it’s how strong your opinion is before you start)
How his team at Dropbox found $24M in ARR hiding in a cohort nobody was looking at
And how to get leadership to fund the unglamorous quality work that never wins a roadmap fight

1. If your job is running every permutation, AI already does it better

Kevin isn’t in the doomer camp on AI and PM roles. But his reasoning for why the job survives is sharper than the usual reassurance.

AI removed engineering headcount as the bottleneck on learning — you can prototype and validate in days instead of quarters. That doesn’t reduce the need for judgment.

“In a world where you can now ship lots and lots of ideas quickly, it becomes even more important now to have really strong product sense and customer centricity in order to decide that you are shipping the right things.”

He’s skeptical of the 10x-your-experiments crowd for a specific reason: someone is on the other end of all those experiments, and a product that changes on you every day makes them a test case. Then comes the line that should make a few PMs uncomfortable:

“If all you’re doing is facilitating maximalist tests, an AI will always outperform you, because they will be able to come up with every permutation and actually ship it. So then you are actually obsoleting your own job.”

Product takeaway: Audit what part of your team’s week goes to generating and coordinating options versus deciding between them. The first half is getting automated. If your PMs can’t articulate a customer-grounded hypothesis before an experiment runs, you don’t have a product function — you have a permutation engine.

2. Lazy product management vs. Product craft

Kevin has a refreshingly straightforward definition of product sense:

“What is product sense? It is customer centricity. It is understanding a customer’s painful needs and being able to translate that into business value [...] One of the big differences between the two is the strength of your opinion, and that opinion is based on your understanding of what a customer’s needs are.”

The rigorous version sounds like this: based on what I understand about this customer’s life, here is a painful problem, here is my hypothesis for solving it, here’s how their behavior should change, here’s the business impact. Then you find out whether you were right — and either way you get smarter.

The lazy version outsources all of that to volume. Kevin points out this predates AI entirely; it’s the same instinct that had teams running a hundred A/B tests a day and Google testing shades of blue. AI just made it cheaper.

There’s a second-order risk too. If everyone lets the same handful of models generate their ideas, everyone’s product converges.

Product takeaway: Make the hypothesis a required artifact, not an optional one. Before anything ships, someone should have written down what they believe about the customer and what behavior change would prove them right. That document is the difference between learning something and generating noise — and it’s the part a model can’t write for you.

3. Don’t let data quietly become a spreadsheet maximization game

At Smule, Kevin led growth in an environment he describes candidly as goal-driven: here’s a number, find twenty ways to move it. When a key metric dropped, they’d spin up a tiger team and build a list of hypotheses.

And then:

“Seven times out of 10 the culprit would be found by ultimately one of us running through the app itself, going through a flow, and being like, ‘Oh, this is clearly the thing that was broken.’”

His conclusion isn’t anti-data. It’s about what happens when data is the only input.

“If all you do is look at data and you use data to then double-check other data and form hypotheses on that, and you’re not talking to the customer, you’re not experiencing the product yourself, you can very easily just turn this into a spreadsheet maximization game.”

Dropbox showed him the other model — real-world Wednesdays, a large user research team, an expectation that you talked to two to six customers a week. He also makes a sharp distinction about growth work itself: growth is gasoline on a fire. If the product genuinely solves a painful problem, growth accelerates it. If it doesn’t, you get a pop and a drop.

Product takeaway: Put a standing constraint on your team that every metric investigation includes someone actually using the product through the affected flow. It’s the cheapest debugging step available, and it’s the one most often skipped — and if your instrumentation can’t tell you where users are struggling without a manual walkthrough, that’s the real finding.

4. Resentment compounds over time

At Dropbox, Kevin led a group called Usability, spanning key user journeys, service performance and reliability, and the entire out-of-product experience — because your relationship with a product includes every moment you’re outside of it trying to get help. The team spent a year making lots of small things better and produced roughly $24 million in ARR from churn reduction alone.

The hypothesis they pitched it on was wrong.

They’d argued that first impressions matter most, so the gains would show up in month-one and month-two retention. Those numbers didn’t move at all. What moved was month 13+ — fifteen years of accumulated customers, improving by roughly half a percentage point. At that population size, half a point was eight figures.

Kevin’s explanation for why is the part worth stealing. Their time-to-visual-complete metric averaged around 15 seconds globally, and every one of those slow loads was a small deposit:

“These things create moments of what I call moments of resentment. Like, man, all my files are stuck in here. I can’t remove them, but I’m frustrated, but I can’t leave you. And then it just builds up and builds up and builds up.”

Frustrated-but-locked-in users don’t churn on the day they get frustrated. They churn on the inciting incident — an outage, a trust-breaking event, a price increase. The price increase doesn’t cause the churn. It collects on years of resentment.

Product takeaway: Your loyal users absorb the most accumulated friction, and their churn stays invisible until something triggers it all at once. Before your next price change or migration, ask what the resentment balance looks like on your longest-tenured cohorts — a small lift on a very large denominator usually beats a large lift on a small one.

Chapters

00:00 Introduction
04:06 Defining "product sense"
07:45 How the PM role is evolving
10:20 Kevin's growth lessons from Smule
14:22 The $24M retention bet
18:29 Resentment builds until users snap
22:38 Selling a bet you can't model
24:36 Enshittification and paper cuts
27:51 Life360, where trust is the product
32:23 Conclusion

What does LogRocket do?

When to Add Product Friction & How to Reduce 12 PM AI setups to One Team OS | Kunal Thadani (Houzz)

Imane Rharbi — Tue, 01 Sep 2026 14:53:58 GMT

Listen on:
YouTube | Spotify | Apple

In this episode, we’re joined by Kunal Thadani, a product leader at Houzz, where he’s working on one of the harder consumer problems out there: helping people who have no idea where to start make high-stakes, expensive decisions about their homes.

Before Houzz, Kunal was Head of Product at The League, the dating app acquired by Match Group. He also writes Insider Growth, a newsletter that explores growth case studies from companies like OpenAI, Asana, and Uber.

In this episode, Kunal shares:

Why “remove every step of friction’ is a rule that only works for low-stakes, stateless products — and the three-bucket framework he uses to decide where friction actually belongs
The two ways friction goes wrong, including the one almost every company is guilty of and doesn’t notice
Why the personal AI setups product leaders keep posting about are fragile, inconsistent, and non-transferable — and what his team built instead
How a shared context layer in a single repo turns “five to 10 user interviews” into research at a scale PMs have never had access to before

1. Not all friction is bad: Why "remove every step" only works for low-stakes products

Product-led growth often says to strip out every step between the user and their “aha!” moment. Kunal’s experience working on fintech products taught him that this advice assumes a kind of product most teams aren’t actually building:

“What fintech has really taught us is all friction is not bad. Classic product and PLG thinking says, ‘Hey, remove every step.’ And that works well when the product is very low stakes and it’s stateless.”

Home decisions, loan applications, identity, money movement, fraud, underwriting — none of these are stateless. They have consequences in the real world, and often the user has to wait on something happening outside your product entirely.

His framework has three buckets:

Required steps can act as trust signals.
Delays can be turned into progress arcs.
Constraints can be commitment moments.

Product takeaway: Before you delete a step, ask what job that step is doing. Friction that signals trust, fills a wait, or marks a commitment is doing work that a smoother flow won’t do for free. The question isn’t “how few steps can this be?” — it’s “which steps earn their place?”

2. How splitting one ask into two decisions 10x'd our conversion rate

We told Kunal about how LaunchPod itself got validated. We put a modal on the LogRocket blog asking if people wanted a podcast and requesting an email. Conversion was atrocious.

We nearly killed the idea. Then someone suggested splitting it: ask for a yes/no first, then ask the yes’s for an email. Email conversion went up more than 10x — by adding a step.

Kunal’s read on why:

“What changed wasn’t the UI. It was more about the psychology. When you asked for the email up front, the user had to make two decisions at once: Do I even want this? And do I want to hand over my contact information to this company?”

Separating the two removed the cognitive load from the first decision — and once someone has said yes out loud, the ask lands differently.

But he was careful to bound the lesson. At The League, the team ran a live speed dating product where interest was easy to collect and attendance was not.

“If it’s a feature where you’re actually getting people to pay, I’m pretty bullish on: you still separate the decisions out, but how do you collect some sort of down payment?”

Their fix was a $4–5 ticket to join the waitlist. Low enough not to gate anyone out, but high enough that people actually showed up.

Product takeaway: Splitting a big ask into a small one and a bigger one reliably lifts top-of-funnel numbers. Just don’t confuse the lift with real demand. If the downstream behavior you care about is showing up or paying, put a small, real cost in the flow — otherwise you’re optimizing a metric that stops predicting anything.

3. The two failure modes: Friction that serves you, and friction that doesn’t

Kunal isn’t arguing that friction is always underrated. He has a sharp view of where it goes wrong, and it’s two specific failure modes:

The first is friction that’s dressed up as care but exists to serve the company. Cancellation flows are a popular case: hit cancel, get an offer, decline, get a discount, decline, get a downgrade option.

“It’s being framed as more like just making sure — versus, hey, helping you understand what you’re actually giving up.”

His version of an honest cancellation flow is one that tells you exactly which features, workflows, and automations stop working, and on what date. Same number of screens. Completely different intent.

The second mode is subtler, and almost everyone is guilty of it: friction that was legitimate once and never got dialed back after trust was earned.

“If I’m already a loyal verified user and you keep making me reprove myself, re-verify, re-KYC every time, it ends up being less protective and starts to feel more like, ‘Hey, you don’t trust me.’”

Product takeaway: Audit your friction on two axes: who does it serve, and is it still calibrated? Protective steps should decay as trust accumulates. If a verified two-year customer hits the same gate as a stranger, that’s not security — it’s a system that never learned anything about them.

4. Why personal AI setups don't survive an org and what a shared context layer fixes

Product leaders nowadays are asking, what are you actually doing with AI? A common answer is “I built my own personal OS.”

Kunal’s problem with that answer is that it doesn’t survive contact with an org.

“Everyone is building personal AI setups, but even at these dinners with product leaders leading the internal AI charge, very few are focused on what that operating system looks like at scale. When you start to build individual OSs, they’re pretty fragile, they’re inconsistent, they don’t have a centralized context layer — and a lot of the value just walks out the door when the person who built it leaves.”

So his team built a shared one. Claude Code, one GitHub repo, and non-engineers living in the terminal.

Product takeaway: The thing that makes an AI setup an asset instead of a personal habit is that the context lives somewhere other than one person’s laptop. And when you hit retrieval costs, reach for better routing before you reach for summarization — compressing your source material is how you quietly lose the details you built the system to find.

5. Research at scale, no handoff tax, and a feedback loop that compounds

The gains Kunal describes aren’t marginal speedups on existing work. They’re access to work that wasn’t previously possible.

The biggest one is research and validation. By piping Gong data into a database his agent can query, the team can sift every closed-lost conversation to find where deals died — and rank product gaps by how many sales each one cost. Same on the retention side, mining customer success calls for what churned users were vocal about.

“What we used to get was five to 10 user interviews. But now you’re getting it at scale and much quicker.”

The second change is to the shape of the PM role. Kunal frames the old model in terms of a tax:

“Every time you have to work with another cross-functional team, you’re paying that handoff tax of re-explaining that feature.”

When product marketing, sales ops, and data science all draw on the same context, that re-explanation mostly evaporates.

The third is a compounding effect that only exists in the shared version. When the AI drafts something and your judgment differs — a Slack message with the wrong point of view, say — you correct it in the system, not just in the message you send.

Product takeaway: A team OS isn’t a personal OS with more seats — it’s a different asset with a different payoff curve. The individual version improves at the speed of one person’s corrections. The shared version gets a feedback loop, and that loop is what turns a clever setup into institutional capability.

Chapters

0:00 Introduction
3:23 Why "remove every step" falls apart when the stakes are real
5:51 Three kinds of friction that actually help
6:39 Same verification steps, completely different framing
12:29 The two ways friction turns toxic
13:28 What a cancellation flow should tell you instead
14:39 When re-verification punishes your most loyal users
17:52 Everyone's building a personal AI OS, nobody's building one for the team
23:57 Using Claude Code to mine sales calls and cut the handoff tax
28:27 Why feedback loops get faster with every person you add
29:49 Conclusion

What does LogRocket do?

Just Say No to "Yes-Man Agents" & "Process Barnacles": How Miro Builds Post-AI | Jeff Chow, CPTO

Jeff Wharton — Tue, 25 Aug 2026 13:21:12 GMT

Listen on:
YouTube | Spotify | Apple

On a Friday, one of Miro’s architects pointed a bunch of agents at the company’s AI engine and rebuilt it. He demoed it Monday. There was a kickoff Tuesday. A few months later, it was the headline of Miro’s user conference.

What’s interesting is what Miro didn’t do in response. No reorg, no new framework, no AI-native process. Just the same three milestones they’ve always had: kickoff, solutions review, and pre-release review before launch.

Our guest today is Jeff Chow, Chief Product and Technology Officer at Miro. He leads product and engineering at Miro, which helps cross-functional teams work together, making it an unusually good place to watch what AI is actually doing to how teams build.

In this episode, Jeff shares:

Why he froze Miro’s process on purpose and replaced the artifacts instead
What problem with only working with an agent that agrees with everything you say (AKA the “yes-man” agent)
How “process barnacles” build up as you scale
And why saying “no” is about to become the hardest job in product

1. Don't change the milestones. Change what shows up at them.

Miro runs three milestones: kickoff, solutions review, pre-release review. Jeff has deliberately left them alone.

“A big part of our early tenets was we’re not gonna change that. It’s the shorthand of the organization. You can just say, ‘Oh, we have a solutions review next week’ and everyone gets it.”

What did change is the artifact. Jeff’s description of the old solutions review will feel familiar:

“The PRD plus maybe 50 art boards of a Figma file. Maybe you have a product manager reading off of slides, and then the designer goes through the art boards like it’s a flip book, and then 45 minutes pass, and we’re all a little bit dead in the eyes.”

Now, PMs show up with a working prototype on real data that a few teams have already tried, plus a vibe-coded fake landing page that forces them to tell the story.

Product takeaway: Before you redesign your whole process for AI, ask whether the meeting is the problem or the thing you bring to it usually is. The ritual is a shared context, is expensive to change, and is rarely the bottleneck.

2. Your agent isn’t a stakeholder. So don’t treat it like one.

Here’s a failure mode that didn’t exist a few years ago: someone spends a week building with an agent, walks into the kickoff, and is genuinely confused when the team still wants to debate it. They feel aligned. They’ve been collaborating for days — just not with any humans.

“Your agent’s like, ‘Great idea, Jeff. You’re a genius. Wow, why didn’t I think of that? You’re so wonderful.’ And clearly you didn’t put the contrarian skill in, so literally it’s just blowing smoke...”

The fix Miro landed on is being explicit about what a given conversation is for. The prototype is there to communicate why and what — not how. Early on, kickoffs kept turning into design crits, with people relitigating button placement in a meeting meant to decide whether the problem was worth solving at all.

“People are like, ‘Well, technically, is that the button you’d put there?’ And it’s like, wait, are we really doing this right now?”

Product takeaway: Easy agreement from a model isn’t validation. Build the disagreement back in — a critique step, a sub-agent told to argue the other side, a named skeptic in the room — and say out loud what you’re trying to decide before you show anything.

3. Most of your process exists to prevent expensive mistakes

Jeff’s read on why product orgs look the way they do is that almost every ritual is risk management wearing a rigor costume.

“Annual planning, OKRs, all the way down to certain roadmaps — it’s all about making sure that if we’re gonna really invest that much money on this project, it better work. Without realizing it, it becomes an optimization culture instead of an invention culture.”

That made sense when a bad bet cost a quarter of engineering time. It makes less sense now, but the process doesn’t update on its own.

“What we have to do is just embrace the fact that actually it goes so much faster. You should take more ambitious risks.”

The part Jeff seems most energized by isn’t ICs swinging bigger — it’s that his leaders are now pushing their teams to think bigger, which he says he never really saw before. The old default was five tweaks to a button because that’s what the conversion target asked for.

Takeaway: Go through your planning rituals and ask what each one was invented to protect you from, then check whether that thing is still expensive. Some of it is load-bearing. Some of it is a premium on a risk you stopped carrying.

4. The Friday refactor that became a keynote

Which brings us back to the story at the top. Miro’s big agentic push didn’t come out of planning.

“One of our AI architects just decided one day to get a bunch of his agents to work and refactor our AI engine, and then demoed it to us. It was basically a Friday. Monday, he’s demoed it, and we were like, ‘Okay. Here we go.’”

It unlocked something the team had assumed was years away. Ask Miro to run a retro now, and the agent pulls the full project history onto the board next to it — a week of human work — so the team can argue from actual data.

But Jeff is clear that the interesting part is the org’s response, not the tech:

“It’s not just technology helped create that, but an IC engineer invented it, brought it to the table, and then cross-functionally we were willing to yes-and that experience.”

He has a great name for what usually happens instead: process barnacles.

“You start developing the process barnacles where maybe it’s like, oh, here’s a big bet, and maybe it didn’t work the first time. And then your next thing is not to, like, let’s Apollo 13 and throw the scraps on the table and try to solve the problem. It’s to have a meeting and talk.”

Takeaway: Your constraint probably isn’t ideas — it’s whether an unfunded thing that already works has anywhere to go. When someone shows up with a demo nobody asked for, the useful question isn’t whether it was on the roadmap. It’s how fast you can get it a kickoff.

5. Saying “no” is the next organizational crisis

Here’s the flip side Jeff sees coming.

“If everybody can do something, how do you say no?

When building is cheap, everything looks one more push away from working. Someone has to call it.

His answer to who does that: he thinks of product orgs as fractals. An APM polishes one small rock. A GPM has more rocks. A director has more still. Jeff’s own job is the same shape, just at a bigger scale.

“There’s no, ‘Are you a top-down decision or a bottoms-up kind of organization?’ We’re collaborating at different altitudes.”

That’s why a solutions review at Miro isn’t a gate — the point is to let people cook. But when the answer is no, it comes with a reason a person can actually hear. Internally, they call it explaining it over beers.

“You need to have a human element where you’re explaining it to a normal person. No weird syntax.”

Takeaway: Scarcity used to do your prioritizing for you, and it isn’t anymore. Get explicit about who kills work, what evidence they need to kill it, and how that reasoning gets shared. A clear “no” costs you one uncomfortable conversation. A “no” that nobody's willing to give costs you the roadmap.

Chapters

0:00 Introduction
1:55 Jeff's product path: From founding three businesses, joining Google, TripAdvisor, InVision, and now Miro
4:20 Why Miro refused to rebuild its process around AI
7:20 What shows up at kickoffs and solutions reviews now
14:15 The false confidence trap: Say no to "yes-man" agents
16:30 From optimization culture to invention culture
20:20 How one IC's side project reshaped Miro's AI engine
24:30 "Product barnacles" and why saying no is the next crisis
29:30 Conclusion

What does LogRocket do?

This Product Leader Built Her Own PM OS with Claude Code: LIVE Demo | Parul Goel (ex-Indeed/PayPal)

Jeff Wharton — Tue, 18 Aug 2026 13:35:31 GMT

Listen on:
YouTube | Spotify | Apple

In this episode, we’re joined by Parul Goel, most recently Senior Director of Product Management at Indeed, where she led the orders and billing platforms behind a multi-billion-dollar business. Before that, she spent nearly nine years at PayPal, building a zero-to-one payments platform for marketplaces that landed clients like AliExpress and Facebook Marketplace.

About a year ago, Parul hit the same wall a lot of senior product leaders are sitting behind right now: reading everything about AI, absorbing none of it. So she started building. The result is PM OS: an open source system she and three other product leaders built with Claude Code to automate four core PM functions. This episode is also a LaunchPod first: Parul screen-shares and demos the OS tool live!

In this episode, Parul shows:

A live demo of the PM operating system she built with 3 fellow product leaders and the four-layered architecture behind it
Why the “context library” and codifying company identity, stakeholders, and voice is the layer most people skip, BUT the one that matters most
And how the system handles core PM workflows like exec updates, cross-functional communication, customer interview synthesis, and PRD drafts

1. The cure for AI FOMO is to start building with it

Parul’s entry into building with AI wasn’t a strategy offsite. It came after a year of obsessive reading that left her feeling worse, not smarter.

“When AI showed up, I was like everybody else. I would read every LinkedIn post. I would read every article obsessively. And then I realized it’s not giving me conviction – it’s giving me anxiety. It’s giving me FOMO.”

Her fix was to stop consuming and start shipping. She now spends time building almost every day — PM OS plus a handful of personal tools.

“The only way to really feel what AI can do, where your job would stay versus what parts would disappear, is to have hands-on experience.”

Product takeaway: You can’t read your way to AI fluency. If your leadership team is still debating AI strategy in the abstract, the fastest path to conviction is for the people making the decisions to build something. Start small, and use it on real work. The anxiety most leaders feel isn’t a knowledge gap — it’s an experience gap.

2. The idea started as grunt work, not strategy

When Parul’s co-builders proposed PM OS, she knew immediately which piece she wanted: the exec update. Because, thanks to her experience, she knew what it was like to write the same one over and over.

“I was just doing the same status update for different audiences. And I realized that I am just doing the thinking once. A lot of it is just re-projecting, changing the tone and the length and just going and talking about what they care about.”

Once she framed it that way – thinking once, re-projecting five times – it stopped being an unavoidable tax on the job and became something she could build an automated process for.

The team picked four core PM functions and automated most of each:

Executive updates
Cross-functional updates
Customer interview synthesis
PRD drafting

They built the first version over a weekend.

Parul also picked this problem for a specific reason:

“One of the reasons why I thought this was a good problem to solve via AI is it’s low risk. I’m always going to check before I send something out. It’s never going to be automatically sent.”

Product takeaway: The best first AI use case in your org is probably not your most valuable workflow. It’s the one where the thinking is already done, the output is repetitive, and a human reviews it before it goes anywhere. Look for tasks where you do the reasoning once and reformat it many times — those are where AI compounds, and where a bad draft costs you nothing.

3. The context library is the actual product

The PM OS has a four-layer architecture:

perception (what it knows)
execution (the four skills)
critique (how it evaluates its own output)
continuity (what it remembers)

Parul calls this the soul of the system, but she’s blunt about which layer matters most and which one people skip.

The context library is a folder of markdown files describing the company’s business model, target clients, past decisions, user personas, the company voice, and – most importantly – the stakeholders.

“This is an interesting one because it’s beyond just the name and role. It’s what do they care about? What are their pet peeves? Things you actually learn about people as you work for them, things you actually think about before sending them something.”

That’s why the same status update comes out differently for the CEO than for the CTO. In the demo, the system doesn’t just relabel the audience – it reframes it appropriately.

“If you’re building something like this, don’t skip [the context layer]. It is the most important.”

Product takeaway: Generic AI output is almost always a context problem, not a prompt problem. The unglamorous work – writing down what your stakeholders care about, how your company actually talks, which decisions have already been made – is the part that determines whether output sounds like your team or like a language model. Budget real time for it and treat it as infrastructure.

4. Make the AI critique itself before you ever see it

The most interesting moment in the demo isn’t the draft. It’s what happens after.

Parul defined three sub-agents — an engineer, a designer, and an exec — that review every update before it reaches her.

“These are your coworkers weighing in before you send something out.”

In the live demo, the engineer sub-agent flags that the team has already missed this date twice, and that claiming high confidence in the new date without explaining why will read as overstating. Which is exactly the question she’d have gotten in the meeting.

She also built in a hard constraint on the input side. The skill can ask clarifying questions only once.

“When you are in the process of working on something, the last thing you want is to get into a back-and-forth with an AI assistant. So we limited this. You can ask questions only once, and then you have to draft.”

Product takeaway: Adversarial review is a design pattern, not a nice-to-have. Instead of asking a model to write well, ask it to predict how a specific reader will push back – then fix that before you ship. And design your interaction budget deliberately: an assistant that interrogates you is worse than one that drafts something imperfect and flags its own gaps.

5. The build got easier, but the judgment didn’t

When asked how she thinks AI will affect the PM role going forward, Parul’s clearest evidence that PMs aren’t going anywhere came from an AI-drafted email she caught just in time – one that told the recipient the meeting had been more useful than she’d anticipated.

“Thankfully, I didn’t send it. But that’s where the judgment is so off. That gave me a lot of comfort that my job is not going anywhere soon.”

Her broader read: the engineering has gotten dramatically easier, but deciding what’s worth building and what’s safe to send has not.

“AI can give you options, it can give you ideas, it can tell you the trade-offs. But the actual judgment, the actual decision, still needs to live with the person – because a lot of times these decisions are made based on company values or an individual’s values.”

She does expect the shape of the job to change. Teams will get smaller, the work will get higher-leverage, and writing the same status five times will disappear.

Product takeaway: The threat to your PM org isn’t AI doing the judgment. It’s your PMs spending so much of the week on re-projection and reformatting that they never get to the judgment. Automate the grunt work first, then measure whether the reclaimed hours actually go toward better decisions.

Chapters

00:00 Introduction
04:38 Why Parul and her collaborators built a PM OS using Claude Code
09:05 Exec update live demo
15:18 The importance of the context library
22:28 The future of PM with AI
23:36 Conclusion

What does LogRocket do?

Speedrunning $0 to $180M: The Intrapreneur's Playbook | Gaurav Jaiswal, VP Product (ex-Pearson, SAP)

Jeff Wharton — Tue, 11 Aug 2026 13:12:18 GMT

Listen on:
YouTube | Spotify | Apple

Everyone romanticizes the 0 → 1 founder who starts in a garage. But for most product and digital leaders, the more useful muscle is intrapreneurship: building something genuinely new inside an existing business.

Our guest today, Gaurav Jaiswal, has done this. Twice. He’s an engineer by trade who became a PM by pitching his own product idea to his first employer, then spent nearly a decade at SAP across several roles — all of them entrepreneurial in nature.

There, he co-founded SAP Digital, a B2B2C business unit built to let anyone in the world discover, try, and buy SAP and partner products. The unit scaled from 0 to roughly $180 million and did business in 130-plus countries.

Gaurav then took that playbook into a completely different industry. As VP of Digital Product at Pearson, he ran the global commerce P&L, scaled it to $350 million, and launched Pearson+ eText, the first subscription product in the 150-year-old publisher’s history, from ideation to market in about six months.

In this episode, Gaurav shares:

How he got individual SAP board members to approve an entirely new business unit in under seven months
The “four P” framework (product, platform, policy, people) he used to rewire everything from ideation to provisioning
Why the biggest surprise in a digital transformation is almost never the product, and almost always the process
The guardrails that made a 6-month launch possible at a 150-year-old company
Why top-down executive alignment is necessary — but nowhere near sufficient

1. “Why not?” — how a new business unit got board approval in 6 months

SAP Digital started with the company wondering whether it could reach the end users of its products directly. Gaurav, sitting in the office of the CMO, was offered the chance to co-found it.

The ambition was deliberately outsized. Gaurav’s team called it the BHAG (Big, Hairy, Audacious Goal). They wanted to be the Amazon of enterprise software.

“People can buy with their credit card, let’s say a digital CRM for a single user, $25 per user per month, three-month contract, $75. Who would have thought that you could buy an SAP CRM for 75 bucks?”

Getting there took six months of working across a 100,000-person company to define the customer segments, pain points, and pockets of opportunity. Then they built the business case and pitched it to each board member individually before the CEO signed off.

Product takeaway: Speed inside a large company doesn’t come from skipping the approval process — it comes from getting all of the stakeholders on board.

2. The four P framework: Product, platform, policy, & people

The team’s first realization was that picking sellable products wasn’t the job.

“It’s not just about figuring out what are the right products that we can sell digitally, but it’s also about changing everything soup to nuts in the whole product from ideation to creation to selling to consumption.”

That became the four Ps:

Product: Build or identify the SKUs that actually lend themselves to a digital GTM strategy
Platform: The surface that enables discovery and transaction
Policy: The digital processes covering pre-transaction, transaction, and provisioning
People: The digital skills and DNA to run it, inside the company and across the partner ecosystem

3. Top-down support is necessary, but it isn’t sufficient

Both of Gaurav’s biggest builds had enthusiastic executive backing — and he won’t pretend that’s optional.

“Having that top-down alignment from the C-suite — I cannot overemphasize the importance of it. But at the same time, having a groundswell of bottom-up and also sideways support also is very helpful. Oftentimes, that comes organically from many pockets, but oftentimes it has to be built.”

Which raises the part most leaders under-invest in: repetition.

Say the thing, say it again, and keep saying it. As Jeff puts it in the episode, by the time you’re sick of hearing yourself, you’ve only just started to scratch the surface of everyone else absorbing it.

Product takeaway: Executive sponsorship gets you permission, but lateral and bottom-up belief gets you delivery. Budget real time for message repetition across cross-functional teams.

Chapters

00:00 Introduction
02:20 Gaurav's path from software engineer to serial intrapreneur at SAP and Pearson
05:37 Becoming "the Amazon of enterprise software"
07:47 The four-year, non-linear path from zero to $180 million in ARR
11:32 The tradeoffs of building a new business inside a publicly traded company
16:33 Moving to Pearson and turning a 150-year-old publisher into a software company
18:12 Launching Pearson+ e-textbooks from idea to market in 6 months
26:39 Why both executive buy-in and bottom-up support are necessary
27:39 Conclusion

What does LogRocket do?

How DoorDash Turned Food Delivery into a Local Commerce Platform | Vassili Samolis, VP of Product

Jeff Wharton — Tue, 04 Aug 2026 12:59:46 GMT

Listen on:
YouTube | Spotify | Apple

In today’s episode, we're joined by Vassili Samolis, VP of Product at DoorDash, where he's spent the last five years turning a food delivery app into a commerce platform serving more than one million merchants worldwide. Before DoorDash, Vassili built and monetized products at Pinterest and Instagram, and he’s now applying those experiences to help local restaurants, bodegas, and shops grow.

In this episode, Vassili shares:

Why he thinks DoorDash’s mission has always been about empowering local communities, not just delivering food
How DoorDash built a true CPA advertising model that ties the company’s success directly to the merchant’s success
Why the best products almost always start with one very specific customer story, not a big strategic insight
Why he believes there’s never been a better time to be a product manager — not despite AI, but because of it

1. From delivery app to local commerce platform

To most people, DoorDash is a reliable place to get late-night food. But Vassili is quick to reframe this: the company’s real customer base is the local entrepreneurs who are trying to survive in a challenging industry — one that often demands they be experts in marketing, ops, and tech support.

“ I talk to local entrepreneurs every week, and I think the challenge is that these folks are being asked to be marketers. They're being asked to be operators. They're being asked to cook food in an environment that is highly dynamic. Being a local entrepreneur is, is a really hard thing.”

Vassili’s vision of DoorDash is to empower these local businesses and communities by giving them the tools to grow — and, increasingly, the tools to run their entire business, from online ordering and reservations to table management.

Product takeaway: The biggest platform shifts rarely come from a single strategic pivot. They come from staying obsessively close to a customer’s concerns and building outward from there. DoorDash didn’t wake up one day and decide to become a commerce platform; it kept asking what its merchants actually needed and let their product expand accordingly.

2. Building an advertising model that ties DoorDash’s success to the merchant’s

When Vassili’s team built DoorDash’s advertising business, they made a deliberate choice to set it apart from most ad platforms: DoorDash only gets paid when a business actually gets an order.

“That was a very big thing for me early on, which is why we built the true CPA model. We only get paid if we drive an order. That tied our destiny. Because, for me to get paid, I need to drive value for the customer.”

Product takeaway: Alignment isn’t a nice-to-have in a marketplace business — it’s what will actually earn you trust. If your monetization model can succeed even when the customer doesn’t, your customers will notice. Structuring pricing or incentives around the outcome you actually want your customer to have will change how your product roadmap gets built.

3. The best products start with one customer's story

Vassili has interviewed thousands of local business owners over his career at DoorDash. His take on where great product ideas actually come from is more personal than data or strategy decks:

“I think that all, most, if not all of great products start with simple customer stories. Start with getting on the phone with somebody and saying, ‘Hey, I bought too much beef and now, I need to figure out a way to sell more burgers.’”

Product takeaway: The specificity of one real customer’s problem is often more useful than an aggregate trend line because it forces you to build something concrete enough to actually solve it instead of something generic that just checks a box.

4. There’s never been a better time to be a product manager

Vassili is refreshingly optimistic about AI’s effect on the PM role.

“A big role of the product manager is to translate the customer needs into products and features that then, in partnership with engineering teams, design teams, data teams, turn into great product. There’s never been a better time to be a product manager because now you can spend a lot more time with customers and thinking about what to build.”

Product takeaway: As AI collapses the cost of building, the bottleneck shifts from “can we build it” to “should we build it, and why.” That’s a judgment problem, not a technical one, and it’s exactly the kind of problem product managers are best positioned to own.

Chapters

00:00: Introducing Vassili and DoorDash's mission to empower local businesses
02:29 Why local restaurants struggle to survive and grow
04:27: TL;DR into Vassili's product background: From Instagram and Pinterest to DoorDash
05:39: Turning a delivery app into a full local commerce platform
07:23: Product lessons and first principles thinking
12:00: The most unexpected customer insight Vassili and his team discovered
14:10: AI and the future of product teams
17:52: What AI deployment looks like on Vassili's team
21:27: Conclusion

What does LogRocket do?

Beyond AI Theater: How a Real AI Product Team Looks Now | Eric Anderson, SVP Product (Datasite)

Jeff Wharton — Thu, 02 Jul 2026 12:37:25 GMT

Listen on:
YouTube | Spotify | Apple

In this episode, we’re joined by Eric Anderson, SVP of Product at Datasite, the virtual data room platform trusted with some of the highest-stakes, highest-privacy transactions in business — M&A deals, divestitures, and multi-hundred-million-dollar decisions.

In this episode, Eric shares:

How the “The contract has changed” as the PM role has evolved. It’s not a layoff story, but product has collapsed back to subject-matter expertise, judgment, and taste
Inside their “iteration zero” process: Where PRDs are written live in the meeting, prototypes are wired to real data, and what the new bottleneck is now that building is fast
Plus how you build trust in your AI product when a billion dollars is on the line: citations for everything, correlation, not imperative statements, and why nobody lets the computer decide

1. “The contract has changed”

Deep into a product pilot, one of Eric’s senior principal PMs said four words that became the episode’s throughline — and, Eric says, one of the most undersold observations of the year:

“Eric, the contract has changed.”

What he meant: product work used to be process-driven, with templates, quarterly planning decks, PRDs wrangled into eight-point font. Now the idea itself becomes the center of gravity, and the process falls into line behind it. Eric described teams running an “iteration zero” meeting where a PM or designer talks through a problem out loud, and tools like Claude’s audio features draft the PRD live, in real time, while they’re still talking.

“The ability to move from idea to building a foundation to execution in minutes or hours is almost exactly why we like this job so much in the first place.”

Product takeaway: Don’t just ask “where can we bolt AI onto our existing process.” Ask what your process was compensating for in the first place. If AI removes the friction between having an idea and testing it, your rituals — standups, templates, sign-off chains — may be solving a problem that no longer exists in the same form.

2. The collapsed org chart

Eric has always talked about product careers in terms of “climbing up and down the ladder” — moving fluidly between whiteboard-level detail and boardroom-level strategy. That metaphor hasn’t changed, but the speed has — thanks to AI.

“Climbing up and down the ladder…now it’s more like riding a high-speed elevator. It’s really collapsed the org chart.”

He’s blunt about what this means for leaders who stopped doing IC work: they don’t get a pass anymore. And ICs who worried AI would replace them are finding the opposite: the busywork gets automated, and what’s left is the part of the job people actually wanted in the first place.

“If you were a leader who did no IC work, [you’re] going to have to do a lot of IC work to be successful.”

Product takeaway: Leaders need to stay close enough to the work to have real opinions on it again, and ICs need to get comfortable operating at a strategic altitude they might have deferred upward before.

3. The 2x2 that decides what AI actually gets to touch

Eric borrowed a framework from a previous LaunchPod guest, Descript CEO Laura Burkhauser: a simple 2x2 of what you love doing vs. what you don’t, crossed with what AI is actually good at yet. The goal isn’t to make people “the human harness for AI” — it’s to figure out what to hand off and what to protect.

“Look at where you can take the things that would be great to do with AI and you don’t love doing. And then look at the stuff that you love doing and needs a human to do — that’s the special stuff.”

The payoff, in Eric’s words, isn’t more free time — it’s more focus.

Product takeaway: AI adoption plans that start with “which tasks can we automate” miss half the equation. Start with what your team actually wants to be doing more of, then use AI to clear a path to it, not just to cut costs.

4. VDRs: From a room full of banker’s boxes to AI

Before it was software, a “data room” was literally a room — bankers’ boxes of documents, a rented conference room, cell phones locked away at the door. Datasite’s job has always been automating that physical process.

Now AI is compressing it further, but Eric is precise about where the line sits.

“You’re not removing the human as the source of judgment. Nobody with their finger on the trigger of a billion-dollar deal is gonna say, ‘I don’t know, Claude told me it was good, so we’re just gonna YOLO it.’”

Product takeaway: When you’re using AI for high-stakes workflows, separate the “first mile” (repetitive, low-skill-but-high-training-required work) from the judgment calls at the end. Automate the former aggressively. Never let AI quietly absorb the latter.

5. Trust isn’t a feature

Datasite’s users aren’t casually chatting with AI — they’re comparing hundreds of legal documents to decide whether a merger is safe to close. Eric walked through the two paradigms his team leans on to earn trust: citations for deep document interrogation, and disclaimers for more free-flowing chat — always inside a “walled garden” that never reaches out to the public internet.

“You’re very much in a walled garden... ‘We found that the leases in Portugal cited here tend to have this common thread you don’t see in Spain — looks like something you should probably check out.’”

Even word choice matters — Datasite frames insights as correlation, not instruction, precisely so the human stays the decision-maker.

“It’s not ‘the tool told me to’ — it’s ‘deals that successfully close tend to remedy differences like these.’”

Product takeaway: In high-stakes domains, the AI feature isn’t the differentiator — the trust architecture around it is. Citations, provenance, and careful language aren’t nice-to-haves you bolt on after the fact — they’re the actual product.

Chapters

00:00 Intro
04:43 How AI has changed the way Datasite's team works
05:32 The product org ladder has become a "high-speed elevator"
11:34 Inside iteration zero: PRDs written live in the room
14:57 Getting out of your comfort zone as AI removes scaffolding
22:44 The "four-box" framework for working with AI
26:55 Why the virtual data room is a perfect AI use case
31:31 Citations, correlation not imperative, and building trust
36:22 Conclusion

What does LogRocket do?

Feedback Is Just the Start: How Acting on It Increased Zipcar’s NPS by Over 50% | Nishaat Vasi, CPO

Jeff Wharton — Tue, 23 Jun 2026 13:06:26 GMT

Listen on:
YouTube | Spotify | Apple

Nishaat Vasi has spent eight-plus years at Zipcar – one of the original pioneers of the sharing economy – most recently as CPO. When he stepped back into the role after a stint incubating a startup spun out of Zipcar, he found a company that had done something easy to do and hard to notice: it had drifted away from its members.

Years of platform migration work had quietly pushed customer experience to the back seat. NPS was being captured the old-fashioned way through an email form after a ride, and barely 3% of members were responding. Nishaat’s mission was to change that, not just by capturing better feedback but by building it into the team’s operational processes.

The result?

Zipcar’s NPS jumped from 36 to 56, a +50% jump, driven not by a single feature, but by a sustained, cross-functional commitment to member obsession.

In this episode, Nishaat shares how he rebuilt that user-obsessed culture, what it looks like to turn unstructured feedback into operational change, and why most “AI strategy” is just theater.

1. Moving from post-ride surveys to in-context feedback (8:12)

When Nishaat returned to Zipcar, the feedback loop was broken in a predictable way: members were asked for their opinions hours after a trip ended, via email, and most ignored it entirely.

The first move was switching to in-context feedback – capturing it immediately after a trip, inside the app, while the experience was still fresh. The goal wasn’t just higher response rates. It was better signal.

“It was really about how do we get in-context feedback? Then what do we do with that in-context feedback? Outside of just getting feedback and leveraging it, it was also about how do we develop that DNA back into our product and UX teams.”

The shift paid off in ways that went beyond the data. When PMs, engineers, and operations teams could watch real session recordings and hear real user frustrations, they didn’t need to be convinced to care. The problem became visible.

Product takeaway: In-context feedback isn’t just a response rate trick. It changes what you learn and who in your organization feels accountable for fixing it.

2. Connecting NPS to P&L (16:31)

Plenty of product teams track NPS. Far fewer connect it to the business outcomes that give leadership a reason to prioritize it. Nishaat’s team did both.

After identifying their top three problem areas – car cleanliness, damage, and maintenance issues – they built out a financial model showing the cost of each. Damages don’t just hurt member experience: they accelerate asset depreciation and reduce resale value. Poor car condition drives rash behavior, which drives accidents.

“For every 100 such events, here is our hypothesis — all backed by data. We modeled this out. We look at different conditions. Here’s how many millions we’re going to lose. And this is why it’s not only damages, it actually leads to how people treat your cars, which could be accidents.”

Product takeaway: NPS is hard to act on when it lives in a product dashboard. The moment you can show leadership that moving it 10 points saves millions of dollars, it stops being a vanity metric and starts being a business case.

3. The pilot framework: Small bets, real data, then scale (21:07)

Not every problem has an obvious software solution. When Nishaat’s team decided to tackle damage detection, they took a two-stage approach: try a cheap pilot first, then build the business case for real investment.

One idea was to require photos of the car’s exterior at check-in and check-out. It was a technology solution that didn’t require a massive build, but the behavioral effect was immediate.

“Just the fact of making someone do it…changes the game, believe it or not. Whether I do anything with that data or not makes no difference. The big value is in the way people perceive the product at that point.”

When that still wasn’t enough, the team piloted off-the-shelf in-car devices with gyroscopes and impact detection – zero CapEx, no software investment, tested in two markets over three months. They expected to improve damage detection. They got a bonus: the same device also caught smoking, another major problem for Zipcar, saving the company millions of dollars.

Product takeaway: Design your experimentation model with two tiers – small pilots (sub-$100K, team-level authority, three-month timelines) and major investments (full business case required). The goal isn’t to democratize all decisions; it’s to make the cost of learning cheap enough that you don’t skip it.

4. From unstructured feedback to operational alerts using AI (32:53)

Nishaat has a clear-eyed view of AI.

His best example: a fleet manager in one market quietly removed the fuel cards kept in the visor of every Zipcar. No one filed a ticket. No one called to complain with a subject line that said “fuel card missing.” But users noticed.

Zipcar now pumps all of that unstructured signal into a single place and uses AI to identify week-over-week changes in emerging themes. When the fuel card issue spiked, the system caught it and fired a Slack alert to the right people in the right market in under 24 hours.

“It would have taken me or us at least three to four days to figure out what this problem was. This got solved, end to end, in under 24 hours. I’m like, okay, that was worth the cost of the tool itself.”

The key takeaway: The AI isn’t responding to members directly. There’s a human in the loop. But the time to detection collapsed from days to hours.

5. Why most AI strategy is “AI theater” (29:36)

Nishaat isn’t anti-AI. Far from it. But he’s skeptical of the way most organizations are approaching it – chasing the headline, not the outcome.

His framing splits AI investment into two distinct problems: getting AI into the product experience AND using AI to make internal teams more efficient. Both require the same foundation: clean, well-governed, well-documented data.

“At its core, you gotta have the data first…And so really it’s about ensuring we have the right data set up. People underestimate how much effort that takes to really create that walled garden – but that is crucial to get right.”

Product takeaway: Before you greenlight another AI initiative, ask what operating goal it’s connected to. If the answer is vague like “improve efficiency,” “enhance the member experience,” it’s probably theater. If it maps to a specific metric someone owns and is measured on, it has a chance of being real.

Chapters

00:00 Intro
01:07: Meet Nishaat Vasi, CPO at Zipcar
04:50: Zipcar and the customer experience wake-up call
05:50: Ditching the email survey for real-time feedback
08:39: Zipcar's user session watch parties
11:46: Turning NPS into OKRs
15:19: The top 3 priorities: Cleanliness, damage, and maintenance
19:13: The zero-cost pilot that now saves millions of dollars
31:03: How genAI spotted a hidden fuel card problem
35:57: Conclusion

What does LogRocket do?

From Hostile to Rewired: How Descript CEO Drives AI Adoption | Laura Burkhauser, CEO of Descript

Jeff Wharton — Tue, 16 Jun 2026 13:49:13 GMT

Listen on:
YouTube | Spotify | Apple

Before Laura Burkhauser was the Descript CEO, she was a customer first. She loved the product so much that she knocked on founder Andrew Mason’s door and asked to work on it with him.

Before Descript, Laura built her product career at Le Tote and Rent the Runway, a path that taught her that “what got you here genuinely won’t get you there,” especially when you’re suddenly the most senior product person in the room with no one left to learn from.

In this episode, we talk about:

Why fast-moving careers can leave you stranded at the director level — and what to do about it
The four-stage framework Laura uses to assess how every person on her team feels about AI (from “hostile” to “rewired)
Why automating a broken system just gives you broken results faster
And a two-by-two for AI adoption that starts with the most human questions first: What do you hate doing? And what do you want to do more of?

1. What got you here won’t get you there (05:49)

Out of business school, Laura joined Le Tote, a startup she was already a customer of. She excelled almost immediately both as a product manager and a people manager.

Then came Rent the Runway and the director title. She was good. But being a product director is a fundamentally different job than being a great PM — and she had no one around her to show her what that looked like.

“There was no one to kind of tell me, ‘This is what a product director does. This is how you think about resource allocation. This is how you think about influencing the business strategy. This is how you start thinking about working on the business and not just working in the business.’”

She was the most senior product person at the company, and there were no peers, no models of excellence nearby, and no map for her to learn from.

The lesson she learned: when you’re the most senior person in the org chart, your growth has to come from outside the org chart.

2. The four-stage tech acceptance framework (21:39)

Most conversations about AI adoption treat it as binary: people either get it or they don’t.

The framework Laura applies at Descript tracks four distinct stages:

Hostile — “I don’t want to use this. I think it’s bad.”
Skeptical — “I’ll try it, but I think it’s going to suck. Last time I tried, it did.”
Converted — “I believe. I know it works. I remember to use it sometimes, and I’ve got a couple of systems down.”
Rewired — You think AI-first. When a new problem lands on your desk, your first instinct is to ask how AI can help you.

When Laura and her team ran their company-wide AI hackathon last year, the goal wasn’t to move everyone from “zero” to “rewired” overnight. It was to honestly assess where people were and design the right intervention for each stage.

Product takeaway: Before you design an AI adoption program, map your team against these four stages. “Hostile” people need a different intervention than “converted” people. A one-size mandates help no one.

3. “Struggle with your art, not with your tools” (15:31)

Descript has been an AI-native product since before “AI-native” was a buzzword. The original concept — to be able to edit video like you edit a document — made LLMs a natural fit the moment they arrived. When you’re editing the text, you’re editing the video.

But when the team built Underlord, their AI editing companion, they grounded it in a belief Laura says has “aged like wine”:

“The purpose of AI should be to take the struggle out of the tools that you use — and not out of you thinking about what you wanna say. Thinking about what your vision is finding your voice.”

She adds:

“AI is definitionally a derivative technology. It works by taking a statistical average of what is most likely to happen next. Without a lot of input from you — without a vision, without a director who matters — you’re gonna get derivative content.”

Product takeaway: If you’re building with AI, be specific about which part of the struggle you’re trying to remove. Removing tool friction for your users should be your goal. Removing the creative struggle removes the whole point.

4. The durability problem: What happens when your AI processes aren’t operational? (26:31)

There’s a pattern Laura has watched play out across companies: someone becomes a beacon for AI. They figure out how to use the tool(s) brilliantly and become 5x, 10x more productive. Leaders notice. And then nobody can quite figure out how to transfer what that person did.

“If that person left, none of that is durable. None of that endures.”

Laura draws a sharp contrast with how human-built systems tend to work. Bring in a great head of product, they set up product review, design review, meaningful human processes. Even if they go on leave for five months, the systems outlast their absence.

But the way most companies are building AI right now?

“If the employee who created the AI system were to leave, the AI system just leaves with them. It’s gone. Because it’s their own personal setup.”

Product takeaway: AI adoption isn’t just a people change — it’s a systems architecture problem. Build for durability from the start. If your AI capability could disappear when one employee leaves, you don’t have an AI capability. You have an AI dependency.

5. The two-by-two that actually gets people on board (29:22)

When Laura ran her product team’s AI offsite, she didn’t start with tools or capabilities or a productivity pitch. She started with the most human question she could think of:

What do you hate doing?

Specifically: looking back at the last four weeks of work, what sucked? What do you wish you could do less of? And — crucially — what do you wish you could do more of?

That’s the first axis of the two-by-two: stuff you love doing vs. stuff you hate doing.

The second axis: is AI actually good at this yet?

Because here’s the problem with pitching AI adoption as “two X productivity” to your ICs: it sounds like twice the work.

Product takeaway: The missing ingredient in most AI rollouts is the dream. Before you talk about tools, get your team to separate what they hate doing from what they love doing. Then let that map guide where AI fits — and how you talk about it.

Chapters

00:00 Intro
02:23 Laura's career journey: From fashion startups to finding her path to product
05:49 The "what got you here won't get you there" moment
08:26 Finding peers and mentors when you're the most senior person in the room
15:31 "Struggle with your art, not with your tools" — Descript's AI philosophy
21:39 The tech acceptance framework: From hostile to rewired
26:30 Pitfalls of AI adoption: Cost, durability, and automating broken systems
29:22 The two-by-two framework for getting your team AI-pilled
32:24 Conclusion

What does LogRocket do?

How AI Helped Me Ship 9 Months of Product in 5 Days | Sriram Iyer, SVP of Product (ex-Salesforce)

Jeff Wharton — Tue, 12 May 2026 13:09:47 GMT

Listen on:
YouTube | Spotify | Apple

A program manager told Sriram Iyer it would take 6 to 9 months to ship the first slice of their new product. Sriram challenged the team to do it in just five days.

At first, they laughed. Then he rolled his sleeves up, dug in with the team, and they did it. 5 days, from Monday to Friday.

Sriram has spent his career walking into companies like Salesforce, Adobe, and Freshworks, and pulling timelines apart. He calls himself the Simplifier-in-Chief, and the secret isn't the AI tooling. It's everything underneath the AI tooling that most leaders won't actually do.

In this episode, we talk about:

Why most slow organizations aren’t suffering from a tech problem — they have a trust deficit
How Sriram shipped a new vertical in just five days that a program manager had scoped for nine months
Why the real constraint on AI adoption isn’t tools or budget — it’s mindset

1. Shipping in 5 days instead of 9 months

Sriram walked into a leadership meeting where 20 senior leaders were staring at a program plan with a first deliverable set to launch six to nine months out. He asked why not six weeks — then raised the stakes.

“I said, ‘I want this shipped in six days.’ And that’s when the pin dropped.”

First, three days before the sprint even started, the team identified the thinnest viable slice: not a prototype, not a POC, but “live production code” that was still “consumable” — like a slice of pizza that “still has all the toppings.”

Then came a key insight most teams skip: they didn’t need to find external customers to validate it.

“We have people in this company who are employees, but who are also potential customers, so why don’t we go ahead and talk to them?”

Those internal customer-zeros became part of the tiger team itself.

The sprint ran Monday 8 AM to Friday 5 PM — a co-located team, unlimited food, and a $1,000 bonus on the line. And woven throughout, implicitly, was the AI layer:

“The designer had Figma Make. The engineers had Cursor, and we came up with our own tool to write PRDs using Claude Code.”

By Friday, something real was shipped. It was hidden behind a flag, but in production, testable, and generating valid feedback.

2. The real AI constraint isn't tools — it's mindset

By 2026, the procurement debate is over. Most companies have already approved AI tools and written the costs into their budgets. The question being asked now isn’t which tool — it’s how we can prove the AI is working.

But Sriram’s observation is sharper than that. The bottleneck was never the tools.

“The real constraint is mindset. Imagine five hundred engineers, all of them with this tool to their disposal. Is every engineer using it the same way? The answer is clearly no.”

Some engineers are leaning in hard. Others aren’t. So the move isn’t a company-wide mandate or a training program — it’s finding the five who are already aggressive, already breaking barriers, and building the experiment around them.

“You have to find those five engineers... who have the mindset to say, ‘Yeah, let’s go ahead and break barriers, and let’s make this thing happen.’”

Then, let the results do the talking. Once the rest of the org sees what five people shipped in a week, something will shift.

“That energy, that enthusiasm is infectious. And once you show that this is doable in five days, others say, ‘Hey, I wanna be a part of that magic.’”

3. Why product managers still matter (and always will)

A lot of PMs right now are quietly asking whether their role is shrinking. If AI can write PRDs, generate specs, and prototype in minutes, what’s left?

Sriram’s answer is direct: you’re asking the wrong question.

“In the world of AI, someone’s got to answer the question, ‘Why are we doing this? What is the business rationale behind this? What is the thesis?’”

AI is exceptional at execution. It can’t tell you what’s worth executing on. And that distinction — between doing and deciding what to do — is exactly where product managers thrive.

The deeper point is about uncertainty. Every real business decision exists in a gray zone where the data doesn’t give you a clean answer. Someone has to read that room, synthesize the competing signals, and stake a position.

“There’s always gonna be a zone of gray in real life, in real business. So the product manager who can bring clarity to that room, define the why, define the thesis, and show direction is still worth amazing. No AI is going to be able to do that for you.”

The skills that made great PMs twenty years ago: clarity of thinking, customer empathy, the ability to define a thesis and defend it, aren’t becoming less valuable. They’re becoming the last defensible moat.

Chapters

00:00 Introduction
02:40 How growing up in a small business shaped Sriram's leadership style
05:14 Sriram's first principles thinking
07:11 The "thinnest slice of pizza" framework that kills scope creep
12:01 How AI tools like Cursor and Figma Make made the sprint possible
13:45 Why mindset (not tooling) is the real constraint in any org
16:32 Applying the same audacity to revenue: why not 100% growth?
20:25 Building a repeatable framework, not just a one-time stunt
22:59 Why trust and personal accountability are what make teams follow you
27:18 The product manager's role in a world where AI can do everything else
28:42 Conclusion

What does LogRocket do?

AI Agents Fail for 2 Reasons. Crowdsourcing Solved Both. | Julia Dalton, SVP Product (Capacity)

Jeff Wharton — Tue, 05 May 2026 15:43:45 GMT

Listen on:
YouTube | Spotify | Apple

Our guest today is Julia Dalton, the SVP of Product at Capacity, an AI-powered support automation platform. Before that, we spent years at OneSpace, formerly known as Crowdsource, a crowdsourcing company where thousands of freelancers executed microtasks for major retailers. Routing rules, task chains, instruction validation, and more.

Today, that’s known as multi-agent orchestration. And Julia was doing it before it was cool.

In today’s episode, Julia shares:

How a PRP (product request prioritization) system she designed herself in one weekend transformed Capacity’s CS feedback by replacing the chaotic “firehose” of requests with a ranked, data-backed list
What running a human API layer taught her about prompt design, long before LLMs existed
And the truth most teams skip — that AI agents are only as good as their instructions. AI doesn’t fix bad data; it amplifies it, and teams need to audit their data before writing a single prompt

1. The two reasons AI agents fail (22:45)

At OneSpace, Julia’s team managed thousands of freelancers doing microtasks for large retailers at scale. The lessons learned were hard and expensive: if you send out 500 product descriptions with unclear instructions, you’ve paid for 500 things you can’t use.

“You could have the best instructions on the planet, the best prompt, but if your data is wrong, you’re going to get really, really terrible results.”

The two culprits? Bad instructions and bad data.

The product takeaway: You’re not the one doing the task — you’re architecting it. That distinction changes everything about how you design agent workflows.

2. Validate your prompts before scaling (11:39)

One of the most underrated moves at OneSpace: before deploying a task to thousands of workers, they’d run a separate mini-workflow with workers whose only job was to evaluate the instructions — not execute them.

Why?

Julia says:

“What seems clear to you and what you’ve communicated is oftentimes very unclear or not as clear as you thought to the audience or to the recipients.”

Her fix? Use a separate agent (or person) whose only job is to evaluate the instructions — not execute them.

Julia does the same thing now with agents: agent-to-agent evaluation runs, logging and scoring conversations, and humans doing test passes. Recursive validation before you ever go live.

The product takeaway: What seems clear to you is often unclear to your recipient, so make sure to build a feedback mechanism for your instructions before you scale them.

3. The PRP: A weekend project that untangled the feature request firehose (22:30)

Julia’s product team was drowning in requests from CS and revenue teams. Each submitter was convinced their ask was the #1 priority.

So, she built a structured intake system herself over a single weekend.

The result?

Structured inputs, auto-classification, ARR and retention impact weighting, and a triage layer within Customer Success before anything ever reached Product. The same signals that prioritize incoming work also let the team communicate the ROI of what they shipped.

“AI only amplifies the data — so if your data is wrong, it’s going to amplify its wrongness in a major way.”

The product takeaway: Data doesn’t just help you prioritize what to build — it helps you prove the impact of what you’ve already built.

Chapters

00:00 Introduction
02:10 Julia's career path to Capacity
04:18 Microtasking at scale
05:59 Jula explains her workflow chains
08:36 Designing routing rules
13:15 Two failure modes
13:56 Simulating and scoring agents
17:22 Recursive prompting in practice
20:27 Data and knowledge orchestration
23:55 PRP Feedback triage system
27:02 Impact and ROI from signals
30:15 Conclusion

What does LogRocket do?

AI Isn't Breaking PM Teams. Overload is. Explained by Stanford PhD & CPO Jen Wang (Framework)

Jeff Wharton — Wed, 15 Apr 2026 13:11:11 GMT

Listen on:
YouTube | Spotify | Apple

Jen Wang holds a PhD from Stanford in behavior sciences, judgment, and decision-making. She built her product career at ThredUp, and now serves as Chief Product Officer and go-to-market lead at Framework.

That combination — behavioral scientist plus operating CPO — gives her a rare lens into the most urgent question in product leadership right now: how do you lead and build when the ground is shifting faster than anyone can follow?

In this episode, we talk about:

The decision-making behind why Framework scrapped their roadmap
Why iteration, not technical proficiency, has been the most important skill to drive AI adoption in teams
There’s actually a scientific reason why everyone’s so overwhelmed, and it’s called the “Zone of Absorption”

1. Why Framework scrapped its 2026 roadmap in February

Most product teams treat the annual roadmap as sacred.

When new model capabilities landed in early 2026 (particularly around how long AI agents could run independently), Jen went back to her team with an uncomfortable message: the roadmap they’d spent months building was no longer the right one.

The replacement wasn’t a new roadmap.

It was a new question: Imagine that the technology will get there (because it will). What are the core customer needs that will still exist after the technology gets there?

For Framework, that meant connecting to the physical, human moments that no AI model can change: helping customers understand, repair, and personalize a piece of hardware they actually own.

The product takeaway: Your roadmap is a bet on the future, not a contract with it. When the future changes faster than your planning cycle, the discipline is knowing when to scrap and restart, not how to protect what you already built.

2. The zone of absorption: Your team isn't resistant to AI; they're at capacity (6:30)

One of the most useful frameworks Jen brought to the conversation comes from leadership theorist Ronald Heifetz: the idea that people have an optimal zone of stimulation for absorbing change. If you’re under it, people will stagnate. Push them over it, and they hit a wall.

Before you diagnose your team as resistant to AI, ask whether you’ve simply exceeded their zone of absorption. The teams adapting fastest aren’t the most technically sophisticated — they’re the ones with a pre-existing culture of iteration and psychological safety.

3. Why AI makes core product skills more important, not less (17:00)

Jen draws a sharp parallel to the AB testing era. When Optimizely and similar tools made experimentation cheap and fast, teams tested everything — and gradually mistook the tool for the discipline. Backlash followed, and “product intuition” became a counter-trend.

AI is the same dynamic. You can now generate a dozen prototypes in minutes. But the speed of prototyping without clarity of the problem just produces more noise (and potentially more… slop).

“This actually makes the core skills around product even more important — really understanding what your user needs are.”

The product takeaway: In a world of infinite prototypes, the scarce resource is judgment and taste. AI raises the floor for execution, but it does nothing for the ceiling of knowing what to build.

4. Where AI is actually defensible as a product moat — and where it isn’t (23:00)

Every product leader is asking the same question right now: if AI levels the playing field, where does our advantage actually come from?

Jen’s answer is precise:

“Any sort of data that you have internally, or any sort of insights that are implicit to your organization — that is potentially defensible.”

Anything you can document is not defensible. If it can be written down, it can be replicated. What’s defensible is implicit institutional knowledge: the insights, data, and experiences unique to your organization that you previously couldn’t productize because it was too expensive or the quality wasn’t good enough.

The product takeaway: Stop asking “how do we add AI to our product?” and start asking “what do we know uniquely, and what can we now build around it that wasn’t possible before?”

Resources

ThredUp: https://www.thredup.com/
Anthropic: https://www.anthropic.com/
Leadership Without Easy Answers by Ronald A. Heifetz: https://www.hup.harvard.edu/books/9780674518582
The engineer's ring: https://www.nspe.org/career-growth/pe-magazine/july-2009/called-order

Chapters

00:00 Introduction
03:29: Why everyone thinks they’re behind on AI
01:32: From Stanford behavioral scientist to CPO: Jen Wang’s path to product
08:17: “The zone of absorption”: The science behind AI overwhelm
11:41: Why Framework scrapped their 2026 roadmap in February
14:28: Choosing your AI toolset: When to experiment vs. When to commit
16:15: Rethinking engineering resourcing to make room for “process debt”
17:49: The A/B testing parallel: Is AI history repeating itself?
20:35: AI prototyping: Productive or underbaked ideas?
23:52: Finding your product moat in the AI world
27:13: The learning possibilities that AI opens up
29:10: Should product leaders take a Hippocratic oath?
30:57: Conclusion

What does LogRocket do?

The Analytics Gap Most eCom Teams Don’t Know They Have | Raul Parquet, Dir. eCom (Princess Cruises)

Jeff Wharton — Tue, 07 Apr 2026 13:46:59 GMT

Listen on:
YouTube | Spotify | Apple

When you think about e-commerce, booking a cruise is about as complex as it gets. Our guest today has spent 20 years building analytics setups across the top companies in the industry, with the goal of making these transactions dead simple to understand.

Raul Parquet is the Director of e-commerce at Princess Cruises, where he’s helping to lead them into a more digital future where visa requirements, multi-destination itineraries, and endless customization options are something customers can actually complete online.

In this episode, Raul shares:

The unglamorous but vital elements of a complete e-commerce analytics stack, and the table-stakes things teams often skip
Why an Analytics team embedded inside product is a requirement, and the deployment discipline that comes with it
And how Princess Cruises is using AI behind the scenes to help their team work smarter — and why, when it comes to customers, simplicity will always matter more than technology

1. Why embedding analytics inside your product team changes everything (6:00)

When analytics lives outside the e-commerce team, data loses consistency and collaboration breaks down across UX, product, and merchandising.

Raul’s fix?

Embed analytics directly in the digital team and put them in every planning meeting — from strategy to development.

“When those analytics team members are within e-commerce and within marketing, everything flows together.”

The product takeaway: Structure before tools. Get the team right first, and the data gets better automatically.

2. The #1 deployment mistake product teams make (8:00)

Most teams instrument analytics after a feature ships, but Raul says that’s already too late.

Every migration, every feature, every release needs tagging built in before it reaches customers. Combined with a throttled rollout and A/B testing, this lets you catch problems early (when you can still iterate) rather than after a full launch.

“We don’t normally just launch anything. We test everything.”

The takeaway: Analytics isn’t a QA step. It’s part of the build.

3. How Princess Cruises is using AI right now (and where it’s still unproven) (17:23)

There are two sides to AI for any product team:

What you use internally to move faster, and
What you deliver to customers

Internally, Princess runs on Microsoft Copilot — automating reporting, surfacing insights, and building executive presentations. But every AI output still gets a human review before it drives a decision.

On the customer side, service automation is the low-hanging fruit. Questions like visa requirements can be answered on-site by an AI agent before they ever reach the call center.

But conversion inside the booking funnel? That’s still an unsolved problem.

The takeaway: Deploy AI where it’s proven, and be honest about where it isn’t.

4. The analytics gaps hiding in plain sight (18:00)

Raul’s most common diagnosis when he looks at an e-commerce analytics setup: teams that track A to B and C to D, but accidentally skip B to C — and unknowingly lose visibility into a large part of their funnel!

His advice for every product leader?

Understand analytics fundamentals yourself, and bring analytics SMEs into every new project at the start — before UX is finalized, and before development begins.

The takeaway: Completeness of coverage matters as much as depth of reporting.

Chapters

00:00 Simplicity Wins
01:44 Raul’s product background
03:50: Why cruises are one of the hardest ecommerce problems to solve
06:32 Embedding analytics teams into product
08:00 The #1 deployment mistake product teams make
13:29 Table Sstakes: What every ecommerce team should be monitoring
17:23 How Princess Cruises uses AI internally
18:00 The analytics gaps most teams don't know they have
19:47 The three-tool analytics stack for ecommerce
21:35 Simplifying complex bookings: The Tesla analogy
28:01 Where AI actually fits in the customer journey
32:35 Conclusion

What does LogRocket do?

How to Avoid AI FOMO like Patagonia | Angela Clark, VP Digital

Jeff Wharton — Tue, 24 Mar 2026 13:43:23 GMT

Listen on:
YouTube | Spotify | Apple

In this episode, we’re joined by Angela Clark, VP of Digital at Patagonia. Angela’s career spans 20+ years in retail and direct-to-consumer, from Pottery Barn and Levi Strauss to True Religion, and now one of the most mission-driven brands on the planet.

In this episode, Angela shares:

How her team is designing a customer journey that caters to the buyer on a 1:1 level, including Product Detail Pages that can speak effortlessly to either extreme of their customer base
Her playbook for managing AI-related “shiny object syndrome” and keeping your roadmap focused on the customer
And why Patagonia flipped the definition of “customer lifetime value” to align with their conservation-driven mission — even happily downselling you to a refurbished item instead of a newer, more expensive version

1. The PDP of one (3:10)

Patagonia’s Nano Puff jacket is bought by urban commuters and alpine climbers alike. And for years, both landed on the same static page.

Angela’s team is fixing that with layered “surface” pages that respond to what they know about you, from past purchases, browsing behavior, and how many times you’ve visited. The goal isn’t more tabs or filters; it’s a page that reorganizes itself around you.

“If I know that you’ve been to my site two times already and maybe the first time you actually read an article or you watched a video about something and the next time you did that, maybe then I can serve up storytelling content that might intrigue you more.”

Product takeaway: Don’t treat personalization as a feature toggle. Think in terms of surfaces: modular content blocks that can reorder, expand, or collapse based on user signals.

2. Circularity on the same page (10:30)

Patagonia now surfaces new and used versions of the same product side by side — a move most e-commerce teams would never risk for fear of negatively impacting full-price sales.

Angela’s team made the call anyway, and they’re learning how customers actually behave when both options are visible.

“We’re fearless about being able to put those two side by side. And it’s been really interesting to learn how people are interacting with those two things, next to each other. We don’t want people to buy something that they don’t need. Or if there’s something that’s already made, that’s better for us, and it’s better for the environment than buying something completely brand new.”

Product takeaway: Brand values aren’t a constraint on product decisions — they’re a strategic differentiator. If your product team is making tradeoffs that quietly contradict your company’s stated mission, that’s a product problem. Align your roadmap to your “why,” and you’ll often find that customers reward you for it.

3. Cutting through the AI noise (25:00)

Angela has one of the more grounded perspectives on AI adoption you’ll hear from a senior digital leader. She’s skeptical of the headline-grabbing claims and willing to say so out loud.

At the same time, she’s not dismissing AI entirely. Her view is nuanced: the winners will be the people who figure out how to use it to work better — not the ones who move fastest.

“I believe the statement that the people who are gonna win in the long run are people who figure out how to use AI effectively to help them be more efficient in their work. But in a lot of spaces, it’s going to take time.”

Product takeaway: The pressure from boards and leadership to “do AI” is real — but it’s often unfocused. Your job is to translate that pressure into a specific, scoped problem worth solving. As Angela puts it, most organizations are still at the “figure it out stage.” Build trust by being honest about where you are, educating upward, and showing deliberate progress.

Chapters

00:00 Introduction
01:43 Angela's career journey
03:30: The PDP problem: Serving elite athletes & urban buyers on the same page
07:00: Building personalization through behavioral signals
09:30: Personalization: it's not a tech problem, it's a customer journey problem
00:15:30 How Angela built the foundation of digital at Patagonia
20:30: How to navigate slow-moving organizations
23:00: Redefining customer lifetime value around Patagonia's mission
26:30: AI FOMO — and why you're not actually falling behind
31:30: Conclusion

What does LogRocket do?

The Anti-Headcount Billion-Dollar eCom Playbook | David Cost, CDO (Rainbow Shops)

Jeff Wharton — Tue, 17 Mar 2026 13:11:54 GMT

Listen on:
YouTube | Spotify | Apple

How many engineers does it take to run the ecommerce site for a retail company that does over a billion dollars in revenue per year?

Well, if you’re Rainbow Shops, the answer is just 2.

Most ecommerce teams assume scale requires more engineers, more tools, more complexity. Chief Digital Officer David Cost has built something many people in ecommerce would say isn’t possible — a lean, fast-moving digital operation that runs on vendor partnerships instead of a massive internal team. Two engineers, hundreds of programmers’ worth of output, and none of the overhead that comes with scaling the traditional way.

In this episode, David shares:

A detailed, under-the-hood look at the specific vendors they use to stay so lean
His playbook for using strategic partnerships with vendors as an external dev team
How being a testbed for new tech gives them a competitive edge
And why their choice of ecommerce platform was vital in enabling Rainbow’s digital strategy

1. The anti-headcount playbook: running a billion-dollar e-commerce operation with two engineers (4:13)

Most e-commerce companies respond to competition the same way: hire more engineers, build more in-house, scale headcount. David’s team is doing the opposite:

“We use our two full-time internal engineers and then we partner with a lot of technology vendors who, in some ways, are almost extensions of our staff.”

The lesson for any product leader operating under resource constraints: headcount isn’t the only way to scale capability.

The right partnerships — not vendor relationships, but genuine partnerships where you influence the roadmap — can give you access to incredible infrastructure without the overhead of building or maintaining it yourself. This applies whether you’re running e-commerce, a SaaS platform, or an enterprise product team with a constrained budget.

2. How platform choice can be a strategic multiplier (4:45)

Rainbow spent over a decade on Demandware (later Salesforce Commerce Cloud) before making the decision to replatform to Shopify in 2021. That decision wasn’t just about features — it was about ecosystem leverage.

If you’re going to build partnerships with vendors who extend your stack, you need to be on the platform they’re building for first. In this case, that platform is Shopify.

“If you’re gonna develop a new piece of tech that’s gonna work in the e-com world, you’re gonna build it for Shopify first.”

Being a large retailer on Shopify — where large retailers are relatively rare — gave Rainbow something valuable: the ability to be a launch partner for new technology in exchange for influence over how that technology gets built.

This is a model any product team can adapt. You don’t need to be the biggest player in the room; you need to be the right partner for the vendors who are solving the hardest problems in your space.

3. A native mobile app — with zero mobile engineers (22:09)

Rainbow has a native iOS and Android app. Yet they have no mobile engineers.

Using a platform called Fuego, Rainbow essentially mirrors their Shopify setup into a native app experience for both platforms, complete with push notifications, with minimal ongoing lift.

“We pick up native apps along with push notifications, and in a world where we’ve already hit peak email and probably hit peak SMS, push is the next frontier.”

App users at Rainbow convert at higher rates, repeat purchase more frequently, and carry larger average basket sizes. About 20% of Rainbow’s customers prefer accessing the brand via app rather than browser. David’s view is that you can’t move people between those camps. You have to serve both.

The takeaway: There’s a class of capability that looks expensive and technically complex from the outside but has been commoditized by the right platform partner. Native apps used to be one of those expensive, high-maintenance investments. For teams willing to find the right partner, it no longer has to be.

4. Checkout is not where you innovate (27:21)

One of David’s strongest convictions: checkout is the last place a product team should spend engineering resources trying to differentiate.

At Rainbow, Shop Pay now accounts for nearly half of all transactions — a number that dwarfs Apple Pay (sub-10%) and has eroded PayPal from 20% to 10%.

The broader PM lesson here is about knowing where not to compete.

For every problem your product faces, there’s a version of that problem that someone else has already solved better than you ever will with your current resources.

The key is in identifying which those are — and getting out of the way. Shopify’s checkout is nearly impossible to replicate, and the teams that have tried to build proprietary checkout flows have paid for it in engineering debt and conversion rate underperformance.

Chapters

00:00 Introduction
02:14 David’s product journey
03:18 How Rainbow runs with only two engineers
04:13 Rainbow's decision to migrate from Salesforce Commerce Cloud to Shopify
10:16 How Rainbow uses AI to support a lean team
13:31 Rainbow's partnership with Lica for AI-generated product images
19:34 The future of personalization in ecommerce
25:14 Shop Pay and Rainbow's checkout features
28:32 Conclusion

What does LogRocket do?

The World’s Safest Driver Isn’t Human. Can Waymo Stop Traffic Deaths? | Chinmay Jain, Dir. Product

Jeff Wharton — Tue, 10 Mar 2026 13:34:58 GMT

Listen on:
YouTube | Spotify | Apple

40,000 people a year die from traffic accidents in the US. Our guest today is Chinmay Jain, Director of Product Management on Waymo's Driving Behavior team, who is working to make that number 90% smaller.

In this episode, Chinmay shares:

How he thought through leaving YouTube at its peak to join a moonshot company that could have civilization-level impact
Waymo’s actual AI eval process, using massive simulations based on millions of real-world driving miles to maximize edge cases, ultimately turning trust into their real product
And the misleading, but common, metrics Chinmay and his team learned to spot that could have seriously derailed Waymo’s progress

1. Leaving a sure thing for a startup with the power to change the world (3:06)

When Chinmay joined Waymo in 2018, the outcome was genuinely uncertain. This wasn’t a calculated bet on an obvious winner — it was a leap into the unknown.

“I always have tried to go back and work on something going from zero to one and be more present with that great opportunity to take it from zero to one.”

For Chinmay, Waymo’s mission tipped the scales: 40,000 people die in US traffic accidents every year. Waymo’s goal is to reduce that by 90%.

The lesson for PMs in any vertical: don’t just optimize for stability. The products that change industries, whether in healthcare, fintech, logistics, or consumer tech, are usually built by people who were willing to bet on something before it was obvious.

2. What to do when AI evals are high-stakes — or even life-or-death (5:50)

When Chinmay was at YouTube, a bad A/B test meant a feature didn’t ship. At Waymo, a bad eval could mean someone gets hurt. That difference fundamentally changes how you think about testing.

This is increasingly relevant across all of product management, not just autonomous vehicles. As AI becomes embedded in medical diagnostics, financial decision-making, and construction infrastructure, the stakes of evaluation are rising everywhere. The question isn’t just “did the metric go up?” — it’s “do we actually understand why, and are we measuring the right thing?”

For this reason, Chinmay’s team runs massive simulations — built on millions of real-world driving miles — to stress test edge cases before anything touches the road.

For PMs building on top of ML — whether in consumer apps, B2B SaaS, or physical AI — this is the core discipline. You can’t rely on traditional A/B testing intuitions when your system is probabilistic. You need to define what “good” looks like before you can measure it.

3. The misleading metrics that could have derailed Waymo (14:52)

One of the most underappreciated PM skills is knowing which metrics to stop trusting. Vanity metrics are a well-known problem in consumer apps — DAUs that don’t reflect real engagement, NPS scores that mask churn risk. But in complex, high-stakes systems, the danger is more subtle.

The broader PM lesson: metric selection isn’t a setup task you do once at launch. It requires ongoing interrogation, especially as your product scales and user behavior evolves. Whether you’re running a marketplace, a fintech platform, or an enterprise SaaS tool, the metrics that got you to product-market fit may not be the ones that keep you successful as you scale.

4. What are the hardest things to teach a self-driving car? (24:41)

Two answers, both surprising:

Unprotected left turns: Massive negotiation happening in real time between cars, pedestrians, and intent. There's no one rule that resolves it cleanly. It's negotiation in real time
Pulling over: Looks simple, but requires the kind of human intuition that drivers must learn over years. Experienced Uber drivers learn pickup nuance over years (think the person hovering at the corner, the building entrance that's technically on the side street, etc.) It's tacit knowledge, built from thousands of micro-observations humans don't even consciously register

“It’s the same reason why can’t a robot can’t just fold a shirt — there are some aspects which are very easy for humans that machine learning systems have to really learn well.”

What seems obvious to your team — "just click here to get started" — may require years of learned context for your ML systems. The gap between your mental model and theirs is almost always larger than you think, which is why taking the time to comprehensively train your models is crucial.

Chapters

00:00 Introduction
02:01 Chinmay’s career journey
03:06 Chinmay’s decision to leave YouTube for Waymo
05:50 How does Waymo test its AI in the physical world?
07:59 Waymo’s layered evaluation system
12:07 Simulations and ML gains at Waymo
19:23 Waymo’s metrics for safety
21:59 Can Waymo make roads 90% safer?
24:36 What driving choices make training AI drivers the hardest?
27:10 Conclusion

What does LogRocket do?

The Cortisol UI: How We Fix FinServ’s Empathy Problem | Melissa Douros, CPO (Green Dot)

Jeff Wharton — Tue, 03 Mar 2026 14:15:06 GMT

Listen on:
YouTube | Spotify | Apple

Most financial products are optimized for transactions, not human emotion. For many people, this transforms an already fraught topic into pure anxiety.

Our guest today is building banking for what she calls the Cortisol UI.

In this episode, Melissa Douros, CPO at Green Dot, shares:

How finserv companies can design for the “Cortisol UI“ by building trust and experiences that reduce anxiety before the transaction
An experiment she ran for Discover’s 5% cashback program where test users collapsed under decision paralysis — proving that more choice can actually increase financial stress
How she flipped Great Wolf Lodge’s booking model from 70% call center to 90% digital while enhancing the human experience
And how Green Dot is navigating AI and agentic commerce without breaking the one thing banks can’t afford to lose: trust

1. Shame is a terrible retention mechanism (3:41)

Melissa’s career began in collections, where she learned something foundational about financial behavior.

“People generally don’t even have $300 saved. They’re one health scare away from complete financial ruin sometimes. So being in collections really helped me understand and try to help people prepare for these financial moments.”

Design financial products (or any high-stakes product) assuming users are anxious, underprepared, and trying their best. Empathy isn’t a brand layer — it’s core product strategy.

2. Design for de-escalation, not just transactions (9:49)

Melissa describes how many digital experiences accidentally increase stress — especially in finance.

“Every moment that we have with a customer is an opportunity to either delight and connect with the customer or to erode from a trust perspective.”

Too often, companies optimize for transactions (balance checks, payments, transfers) but neglect the emotional layer of trust. She calls this designing against “Cortisol UI,” interfaces that spike stress instead of reducing it.

3. AI should lower stress — not increase it (11:03)

Melissa is bullish on AI — but only when deployed responsibly.

“The research is still showing that in finance, people trust AI to do simple tasks for them, but not necessarily complex.”

At Green Dot, AI transcribes calls, analyzes sentiment, and reduces handling time — but humans remain accountable.

The goal isn’t flashy AI. It’s faster resolution, fewer mistakes, and proactive issue detection, ideally before customers even notice.

The takeaway:
The best AI experiences feel invisible. Lower friction. Faster resolution. Fewer surprises. If customers are noticing your AI too much, you may be doing it wrong.

4. Building to prevent decision paralysis (21:56)

In a previous role at Discover, Melissa helped explore giving customers the ability to choose their own 5% rewards categories.

Customers said they wanted it. But in practice?

“They were completely paralyzed by what to pick. Customers asked, ‘What if I don't choose the right category… What if my plumbing breaks, and I should have chosen home improvement after all?’”

The program was eventually scrapped.

The takeaway:
When money is involved, hypothetical feedback isn’t enough. User research needs to include real consequences, and sometimes, reducing choice increases confidence.

Chapters

00:00 Introduction
01:00 Melissa's finserv background and how she landed in product
05:10 How Green Dot builds trust as a financial services product
07:29 Building for the "Cortisol UI" to lessen user stress, especially in finance
9:55 Quietly fixing customer issues while not inundating them with feature releases
14:35 Green Dot moving compliance from the backend to a key part of the product team
16:20 Launching AI features in a high-risk industry
18:36 Decision paralysis and Discover's failed attempt at a 5% cashback reward program
24:57 How Melissa digitized Great Wolf Lodge's customer experience
30:51 Conclusion

What does LogRocket do?

The $500M Lesson from Amazon’s Homepage Redesign | Rahul Chaudhari (ex-Amazon, Kohl’s)

Jeff Wharton — Tue, 24 Feb 2026 14:34:47 GMT

Listen on:
YouTube | Spotify | Apple

How do you redesign the most visited e-commerce webpage in the world? Rahul Chaudhari helped reshape the Amazon homepage during his years as a product leader there, before becoming VP of Product and Technology at Kohl’s.

In this episode, Rahul shares:

Amazon’s “customer backwards” approach - and how he used it to unlock half a billion dollars of value on the Amazon homepage
The secret to product adoption: leverage existing customer habits to unlock new opportunities
And how Amazon and Google raised the bar for digital experiences so high that now every other product pays the price

1. Why customers expect Amazon-level experiences everywhere (05:10)

Rahul shared a simple but powerful insight:

“Why should I, as a consumer have different expectations from my digital banking or my insurance company or my fitness app, as compared to when I shop e-commerce.”

The bar doesn’t reset. If you force customers to relearn workflows and build different habits than they’re used to, that adds a tremendous amount of friction to their digital experience.

Takeaway:
Your competitors aren’t just in your category. They’re every great digital experience your customer has had this week.

2. Why “customer backwards” beats “solution forward” (8:40)

Rahul explains the difference:

“Customer backwards really is you start from the customer and then work backwards of that for anything that you wanna solve for. Instead of saying, ‘Hey, I have an idea and I wanna do this’, which is solution forward.”

When teams start with a solution, they get attached to it. When they start with the customer, they stay solution-agnostic.

The Amazon homepage shift required rethinking eligibility, exposure limits, shared measurement, and governance — all focused on customer signals, not internal priorities.

Takeaway:
If you’re optimizing surfaces around what your company wants users to do (instead of what users actually signal they want), you’re already creating friction.

3. How Amazon reclaimed 41% wasted impressions (12:20)

Rahul’s team at Amazon discovered that overexposure was killing impact.

“We reclaimed some 41% impressions that were wasted because of over exposure that led to, you know, hundreds of millions of dollars of incremental business impact for all of these programs.”

Different Amazon programs were optimizing for their own metrics — Prime subscriptions, Alexa units, Grocery adoption — but without shared guardrails.

The team introduced:

Common measurement across perception, habit, and economic impact
Exposure caps to prevent “hero blindness”
Governance to prevent any single team from monopolizing the placement

They also focused on adoption — not just first clicks.

“What we care about is not the one first action. First Action is great. But what we care about is, does that get you enough into being engaged with that program so that you’re adopted.”

Takeaway:
Define adoption precisely. If you only measure the first click, you’ll optimize for false positives and waste resources chasing short-term wins.

4. AI doesn’t change the problem — it changes the business model (19:10)

Rahul’s biggest AI insight wasn’t about tools — it was about business design.

Instead of asking “What AI tool should we buy?”, Rahul suggests asking how your business model changes in an AI world.

He also warns that AI needs structure before it needs models. If your data is scattered across systems without shared schemas, ontologies, and relationships, you don’t have an AI strategy — you have translation debt.

And as agentic shopping rises? The homepage may no longer be your homepage.

Takeaway:
AI isn’t about bolting on features. It’s about rethinking value creation and data foundations.

Links

Rahul’s LinkedIn

Chapters

00:00 Introduction
01:38 Rahul’s journey from marketing to product
07:41 Why you shouldn't aim to re-educate users after they've already developed shopping habits
09:13 Redesigning the Amazon homepage: The ‘customer backwards’ approach
21:00 How AI will change retail business models
24:46 Agentic commerce & what happens when ChatGPT becomes the homepage?
29:07 AI needs containers, not just models
37:02 Conclusion