A month ago, someone on Mykola Konrad’s team was still building prototypes by hand. Today, an agent does it.

That’s how fast the ground is moving under UX teams right now. And when we ask product leaders where design is headed, nobody agrees. Is it all agents from here? Does AI design everything?

Mykola has a more practical answer than most. He’s CPO at Euna Solutions, which builds software for government agencies. Before that, he spent 25+ years in product at companies like Microsoft, Avaya, and Brightcove. At Euna, UX reports directly to him, so the question of what happens to design isn’t theoretical. He’s making those calls right now.

In this episode, we get into:

• Which UX work is moving to PMs, developers, and agents, and the “If you can, then do” mantra Euna is using to get there

• Why customer contact, high-stakes flows, and accessibility still need a human making the final call

• Myk’s change management playbook for getting a team through AI adoption, and why token spend is a useful (if imperfect) signal

• How Euna is running two delivery flows side by side, AI-enhanced and full-AI, and why customer adoption may be the real speed limit

1. The UX work that’s already succeeding: “If you can, then do”

Myk doesn’t think all of UX is up for grabs. But some of it is moving out of the UX team

The work on its way out is the work that doesn’t need deep taste or customer context: design system upkeep, adding new components, first drafts, early exploration, and getting from a PRD to a prototype. That work still happens. It just happens somewhere else.

“The activity still happens, but it will move to a different persona within the organization. And right now we are actually having some product managers do that, and we’re also having some developers do that, ‘cause I’m not sure exactly 100% where it’s gonna land.”

Rather than deciding up front who should own it, Euna is letting people volunteer:

“If you as an individual believe you have the aptitude or the skill set or just the desire to try to prototype something using Claude Code or Claude Design, then do it. Don’t wait for the UI/UX team to help you out, just try it.”

Product takeaway: You don’t need to know exactly where every task will land before you let people start. Give anyone with the aptitude permission to pick up the lower-stakes design work now, watch who takes to it, and use what you learn to redraw the roles later. Just be upfront that “optional” won’t stay optional forever.

2. What stays human?

So what doesn’t move? For Myk, it comes down to three things.

1. Direct customer contact. Myk has been interviewed by an AI agent himself, and it was fine, up to a point.

For some of Euna’s customers, it’s not even a matter of quality. Several large state and provincial governments simply won’t work with an agent:

“They will not accept an agent interfacing with them. I wouldn’t even call it regulatory, it’s partly the way that that particular government entity needs and wants to operate. They want a human being doing it.”

2. The final call on high-stakes flows. Euna owns the rails on its payments product, and it builds compliance flows and audit trails. AI can give you a first pass, but someone with deep UX expertise needs to decide what actually ships.

3. Accessibility and regulated work. Even as AI improves and takes on more interviews and insight work, Myk expects accessibility and compliance to keep a human in the loop.

Product takeaway: Sort your UX work by the cost of getting it wrong, not by how hard it is to do. Low-stakes, easy-to-review work is where AI should go first. Anything involving money moving, regulators, or users with accessibility needs should keep a human making the final call (even if the AI draft looks good).

3. Getting your team through the change

How do you get an existing team ready for a future that looks this different? Myk starts with change management 101: almost nobody likes change. Some people just get through the skeptical phase faster than others.

From there, Myk’s approach is solid:

• Pick the tools: Euna’s design team is a two-tool shop right now: Figma Make plus Claude Design for prototyping. Everyone gets trained on both

• Map the new handoff: How does work move from design agents to product to the “software factory”?

• Reset expectations on time: If a design used to take three weeks, try three days and see what happens

• Watch for signals: Myk wasn’t trying to monitor anyone, but token spend made it clear who was jumping in and who wasn’t. It’s not a productivity metric on its own, but someone using almost nothing probably isn’t changing

He also recommends asking your team directly where the bottleneck is. When Euna’s product and dev teams went agentic, the answer that came back was UX. From there, the question is whether it’s a data-in problem (user research isn’t done because customers haven’t responded yet) or a data-out problem (the research exists, but designs aren’t moving fast enough).

Product takeaway: Be honest about your timeline before you design your change plan. The length of the window you can give people should shape how much training, patience, and support you build in. And don’t guess where the slowdown is: ask the team, then figure out whether it’s a process gap or a data gap before you try to fix it.

Chapters

00:00 Introduction
02:20 Myk's path from electrical engineer to CPO
03:21 Will AI replace UX?
05:07 UX work shifting to PMs, developers, and agents
06:35 Where UX still needs humans: Customer research, payments, and compliance
13:47 Myk's change management playbook and token spend as an adoption signal
17:20 Finding bottlenecks in an agentic delivery process
19:05 AI-enhanced vs. Full-AI workflows from product to dev
24:31 Customer adoption is the real speed limit
25:43 Conclusion

Links

• Myk’s LinkedIn

• Euna Solutions

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.

Here’s something nobody warns you about when you build AI into your product: you pay for the work every single time a user touches it. If you’re a well-funded team, that’s just another line item. But for a bootstrapped founder, it can sink the business.

Arjun Singh Jamwal sees both sides of that. He’s a Senior PM at Verizon, where he’s worked on Verizon Cloud and now Verizon Home. On the side, he’s bootstrapping Goodmuncher, an app that helps people cut back on ultra-processed foods, and where every token he spends comes straight out of his own pocket.

His fix is something he calls “giving the model a layup.” Rather than having AI analyze every ingredient from scratch whenever someone scans a label, Goodmuncher scores ingredients and products ahead of time and keeps them in a vector database. Users get the same answer, and Arjun pays a fraction of what it would cost to run the analysis live.

This one’s a little different from our usual episodes: it’s a live demo. Arjun shares his screen and runs Goodmuncher’s content pipeline right there on the call. One command, 30 seconds, and out comes a finished 10-slide social carousel. Then he walks us through how it’s all built.

Along the way, we get into:

• Why you should think of tokens as OpEx, and how a little upfront prep keeps your AI costs predictable

• How giving the model a “layup” lets cheaper models punch above their weight, and makes it easier to swap models later

• Why he hard-codes the rules he can’t break instead of trusting the model to remember them

• His step-by-step process for evaluating agents, from golden datasets to LLM-as-judge and observability tracing

1. Why Arjun treats every AI token like an operating expense

Plenty of companies are spending on AI simply because leadership told them to. Arjun doesn’t think that will last. Because those are real dollars, and sooner or later, that cost is going to add up.

Arjun thinks about it the way a finance person would: Every token you spend at runtime is a variable cost, and if you just throw raw data at a model and let it sort everything out, that cost gets hard to predict:

“Think of tokens as a variable cost. This is like your OpEx. When you just throw everything at it to crunch the numbers, you’re actually working with an unpredictable OpEx.”

The other option is to do some of the work up front, one time. Arjun thinks of that as CapEx.

And at some point, the math just stops making sense:

“There’s no point in spending $200,000 on tokens when I could just hire a great full-stack engineer who could do that for me.”

Product takeaway: Treat AI costs like any other cost on your P&L. If a feature uses tokens every time someone clicks, taps, or asks a question, your bill grows right alongside your user base. Before you launch, estimate what that feature would cost if usage grew 10x, so you aren’t caught off guard when the invoice comes.

2. How Arjun gives the model a layup by doing the hard work ahead of time

Goodmuncher has to come up with a processing score for every food item a user looks up. The obvious approach is to have users snap a photo of the ingredient label, send it to a multimodal model, and let it work everything out from scratch. That’s fine with a handful of users. With 10,000, it gets expensive fast.

So, Arjun does the heavy lifting ahead of time. He pulls ingredient data from open sources, scores it in advance, and stores it as embeddings in a vector database.

“What I’d rather do is pull in those ingredients, crunch that data, and already pre-attribute a processing score to it, so that when a user actually looks up the pesto sauce, for example, that score’s already ready.”

Now the model isn’t reasoning through a long chain of steps. It’s just finding an answer that already exists.

Those savings add up. Arjun puts it at at least a 30X difference at scale, and says it’s let him cut what he plans to charge users by more than half.

Product takeaway: Before you reach for a bigger, newer model, map out your workflow and ask which steps really have to happen in real time. Anything you can pre-process, cache, or look up ahead of time is work the model doesn’t have to do, and that’s money you can save yourself AND your customers.

3. Not every job needs a frontier model

You don’t need the newest, most powerful model for everything. Frontier models shine on complex, multi-step reasoning. You can use them for simple tasks too, but you’re paying for horsepower you don’t need.

Keeping your workflows lean pays off in another way, too. When a better model comes out, you can swap it in without re-testing a long, tangled chain of steps:

“When you have to swap out that model, the fewer steps you have in the workflow, the fewer steps of evaluations you need to run. So your evals will have a better time, your change management team will have a better time, your devs will have a better time.”

Product takeaway: Picking a model is a product decision, not just an engineering one, and the only way to know which one fits is to try a few. Get in the habit of testing the smaller, cheaper option first, and only move up when it can’t keep up.

4. How Arjun hard-codes the rules his AI should never break

Goodmuncher is all about helping people eat less ultra-processed food, but it can’t claim to cure diseases or lower anyone’s medical bills. The FDA would have strong words for Arjun if it did.

During his live demo, Arjun shows how his Goodmuncher content pipeline checks every output against a “tripwire” file, a running list of banned phrases like “prevent dementia” or “save medical bills.” That’s not a call he leaves up to the model.

“It’s important to make this deterministic in nature because we don’t want to compromise on this. These are the red lines that you cannot cross.”

He also made a point of keeping that check separate from the step that writes the content, instead of baking it into the prompt:

“I could have easily put my tripwire check into the content generation file, but I didn’t because I want it to be a different process, and I know this will build out over time.”

Product takeaway: Models follow the rules most of the time. But “most of the time” doesn’t cut it for compliance, safety, or anything that could hurt a user. Figure out what’s non-negotiable for your product and enforce it in your code, as its own step, so you can test it and add to it over time.

5. Arjun’s step-by-step process for evaluating agents

Arjun mentors startups through the Cornell Tech community, and he keeps running into the same blind spot:

“It’s so easy just to throw an agent at any problem. But what we’re not being mindful of is the eval aspect of it.”

For Goodmuncher, this isn’t abstract. If a recipe recommendation ignores someone’s nut allergy, a real person could get hurt. Here’s how Arjun approaches evals:

1. Run an exploratory data analysis (EDA) on your production data to understand its categories and shape

2. Build a golden dataset of 10–50 examples you know are 100% correct

3. Reverse-engineer a rubric from that dataset (e.g., “Do the ingredients respect the user’s allergies?”)

4. Create a staging database that represents production, with PII anonymized and de-identified

5. Run evals against the rubric, using a mix of human evals and LLM-as-judge, with 5–10 examples per category

6. Add observability tracing to pinpoint exactly where a workflow breaks

7. Build a dashboard of those traces, if you can

Product takeaway: Building a golden dataset and rubric takes some work up front, but like everything else Arjun builds, that investment pays for itself every time you swap a model or chase down a bug.

Chapters

00:00 Introduction
02:03 Arjun’s product background
04:18 Treating tokens as unpredictable OpEx vs. a One-time CapEx
08:34 Pre-processing data so smaller (and cheaper) models can do the job
13:28 Arjun's Demo: Turning one command into a 10-slide social carousel
19:05 Inside the pipeline architecture and its agents
26:22 Arjun's framework for evaluating AI agents
32:07 Conclusion

Links

• Arjun’s LinkedIn

• Goodmuncher

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.

Ask a CEO how their AI rollout is going, and 81% will tell you they’re highly confident. Ask the people doing the work, and that number drops to 56%.

Today’s guest sits right in the middle of that gap. Annan Patel is VP of Product at Tricentis, a leader in enterprise software testing, where he builds AI products for companies where one bad release can cost tens of millions of dollars. Before Tricentis, he spent more than 15 years in product across ad tech, Microsoft, and WP Engine.

Tricentis recently surveyed more than 2,500 people across the tech industry. 83% of companies said they trust AI agents to make release decisions, yet 60% admitted they ship untested code. The top reason? Pressure from leadership to move faster.

Annan’s view: AI gets sold as a tool you plug in. In practice, it’s a new operating system for how work gets done.

In this episode, Annan shares:

• Why plug-and-play AI only gets you about 60% of the way, and why the rest is context your team has never written down

• Why Tricentis’ first AI products stalled after a strong start, and how the team rebuilt them around one principle: the AI is never the one held accountable

• Why tokens spent and lines of code shipped tell you nothing about whether your AI initiatives are adding value

1. AI isn’t a new tool. It’s a new operating system.

When AI companies pitch to executives, they speak the language executives already use: ROI, efficiency, cost reduction. This pitch is compelling, and the vision is real. But Annan thinks it misses what makes AI different from every SaaS product that came before it: it changes the work of the humans doing the work.

“It’s not as straightforward as just adopting a new tool. In some ways, it’s adopting a new operating system. It’s a new way of working.”

Teams that have worked together for years build up habits that don’t map neatly onto an agent. Annan says,

“People develop ceremonies, cultures, practices in the way they work that don’t always easily translate to agentic or AI-driven systems.”

That’s where the gap comes from. It’s not that anyone’s acting in bad faith. When you’re leading from 10,000 feet, you just don’t see the dozens of little fixes your team makes every day to keep things on track.

Product takeaway: If your AI rollout plan looks a lot like a plan for buying new software, you’re probably underestimating it. You’re changing how people actually do their jobs, so give yourself time for the messy parts: rethinking processes, helping people adjust, and earning their trust. And when the folks closest to the work tell you something isn’t working, take them seriously. Because they spot the gaps long before you do.

2. The missing 40% is context nobody wrote down

On paper, this sounds easy: write down your process, hand it to the AI, and let it do its thing. But the stuff that really matters on most teams was never written down in the first place.

When you work with a team for a long time, there are shorthands you develop. Annan saw this firsthand with Tricentis’ own products. Customers said the AI was doing good work, but it only got them part of the way there:

“What the AI is doing is good, but it maybe solves for 60% of what I need. Because that remaining 40%…comes from information about my business, my team, my industry, the way that we work, the history we’ve built up over time.”

You can’t fix that by pointing an agent at a repo or a SharePoint folder. That context lives in people’s heads, so the system has to learn it from them.

Product takeaway: Before you scale an AI workflow, sit down with your team and get the unwritten stuff out of their heads. This includes the edge cases, the incidents everyone still remembers, the compliance rules, and all the other habits. If your AI output keeps coming back generic or almost right, it’s probably missing context, not a bad model.

3. Start with one job to be done, and treat it like CapEx

Annan has noticed a pretty clear pattern in which companies make AI work and which ones end up frustrated.

“Where organizations get a bit frustrated is when they try to do too much at once… Because that’s when you start to identify the skeletons in the closet.”

What works better is starting small. Pick one job, figure out how an agent can help speed it up, and then put the time you get back toward something else. Tricentis did this internally with security fixes, which let the team move fast in one area without blowing up its whole development process.

The catch? Those early wins usually won’t match the big ROI numbers executives hear in sales pitches. You only get those by changing your core business processes, and that takes more money, more time, and a lot more care.

“Sometimes you have to slow down to move fast.”

Product takeaway: Keep your first AI projects small enough that they can work without overhauling everything. For the bigger transformation, think of it as a long-term investment. You probably won’t see the full payoff in the first year, but you’re laying groundwork that pays off later. Just make sure leadership knows that going in.

4. Tokens and lines of code are the wrong scoreboard

When teams felt pressure to prove their AI spend was worth it, a lot of them reached for whatever numbers were easiest to count.

“We’re not always measuring the right thing… What you saw a lot of a year ago was the tokenmaxing, the ‘Hey, how many lines of code am I shipping?’”

The problem shows up later, in code that gets rolled back, ships without being tested, or never makes it to production at all. Testing teams are feeling it most. They have fewer people and, in some cases, 10x more code to check.

And as Annan points out, leadership doesn’t really care about those numbers anyway:

“At the end of the day, the executives don’t care how much AI was used, they care, ‘Did I get to the outcome that I needed?’”

Product takeaway: Counting tokens or lines of code tells you how busy everyone is, not whether anything got better. Measure AI against the things your business already cares about, like quality, revenue, and whether customers actually use what you ship. As Annan puts it, building faster makes good product judgment matter more, not less, because you can build the wrong thing really fast.

Chapters

00:00 Introduction
02:17 Annan's path from ad tech to enterprise testing at Tricentis
03:44 Why executives and teams see AI's capabilities differently
09:59 From coding assistants to agents to fully unattended workflows
13:07 AI hype on LinkedIn vs. the real risks enterprises face
18:10 Why tokens and lines of code are the wrong ROI metrics
19:59 How Tricentis adopts AI internally, from security fixes to PM work
25:43 What "think like a CEO" really means for product leaders
30:16 When velocity matters and when quality wins, depending on your market
32:47 Conclusion

Links

• Annan’s LinkedIn

• Tricentis

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.

Most advice about a leader’s first 90 days is written in hindsight, after the dust has settled and the mistakes have been solved. This episode is different — when we recorded this, Maya Keekattil was ending her third week as CPO at Cin7. She was working through her first 30 days in real time.

Maya started as a software engineer and DBA before she moved into project management, taking on product leadership at Smarsh, where she spent nearly five years as VP of Product Management. Now she’s learning a new vertical at a PE-backed company, where the board, leadership, and her team all have high expectations.

In this episode, Maya shares:

• Why every product leader’s first 30 days should be reserved for listening and learning, and the three questions she asks in every one of her cross-functional one-on-one meetings

• How to find fast operational wins without accidentally ripping out something load-bearing

• How she’s restructuring product teams around outcomes, not products, in the AI era

1. The first 30 days are for listening and learning

Maya understands that new leaders feel pressure to bring change quickly and to prove results and ROI — this is especially true in the PE world. But Maya emphasizes the importance of learning how things work before you shake anything up. In three weeks, she scheduled 51 one-on-ones across her org, and she’s aiming for 75. Those meetings go beyond her own team, into sales, marketing, finance, engineering, and operations. She told us she started booking conversations a few weeks before her official start date.

Every conversation comes back to three questions: What’s working? What’s not working? And what do you expect product to do for you?

“The company has been here for a decade and more. So there has been stuff that is successful. Coming in and thinking that I’m going to change it all is probably a big mistake a lot of leaders make.”

Product takeaway: Product means something different at every company, and you can’t meet expectations you don’t understand. Before you change anything, learn what each cross-functional partner expects from product. That should be your first scorecard.

2. Patch the holes in the boat first

How do you get quick results without pulling out a beam that’s holding up the building? Maya’s answer is to start with operational efficiency: the small process gaps that slow everyone down.

Often, she says, other people noticed these gaps long ago. They didn’t fix them because they lacked the operational expertise or they simply didn’t have the authority to do so. A new leader with fresh eyes and the mandate to act can rally people quickly around the right fixes.

“Most of the time, others would have observed it. They probably either lacked the expertise to do something about it, were hesitant to do it, or their role did not allow them to do it. Where I stand today, my role allows it, I have the authority to do it, and I come with this fresh perspective.”

Product takeaway: Your fastest credible wins usually aren’t new features. They’re process fixes that your peers have quietly wanted for a long time. Ask where things get stuck, fix what you can in the first 30 to 60 days, and you’ll build the trust you need for bigger bets down the line.

3. Strategy can’t wait for onboarding to end: Don’t wait until day 61 to think strategically

Many 30-60-90 plans treat strategy as a phase you reach once onboarding is finished. Maya warns that this creates a gap between your arrival and your first real impact. Strategic changes need alignment, investment, and often board involvement, so they take longer to show results.

“I don’t think it’s a switch. You start rolling on this innovation and strategy perspective even through the 30/60, but it is not apparent to the cross-functional teams.”

Product takeaway: Run operational and strategic work at the same time. Fix things in the open, and start the slower alignment conversations with your executive peers in the background.

4. Every mandate should go back to the customer

Every new leader arrives with a mandate. Maya argues that the mandate itself is too short-sighted to plan around. Her starting point is two things: why customers buy, and why they leave.

“We are not looking at just numbers. We are looking at why is the customer buying us today and why is the customer leaving us today. Just those two things will get you to the gist of where you are succeeding versus where you are not.”

She says even customers who have already left are worth talking to:

“Even a customer who has left is very happy to talk to you, and they spend the time because they are invested. They’ve used your product.”

Product takeaway: When the board hands you a target, don’t work backward from the number. Work forward from churn. In Maya’s experience, building around the customer’s view beats the mandate. Building to the mandate rarely does.

5. Structure the team around outcomes, not products

Maya saw Y2K and the move to the cloud, and she says now is the fastest she has ever seen technology move — thanks to AI pushing companies to organize around outcomes, which shows up in everything from team structure to outcome-based pricing models.

Instead of splitting PMs by product line, Maya thinks in layers. Platform-focused technical PMs build the foundation. AI product managers operationalize AI across the organization. Growth PMs are tied to customer outcomes.

Before assigning anyone to a role, she starts with an honest look at each person’s strengths. And on whether to hire for new skills or develop the team she has, Maya puts a high value on domain expertise:

“Even if you hire for a talent gap, you need to bring someone up to speed on the domain. So I would rather trust the teams that you have on the domain expertise and build that up. You are influencing and not just using your authority. That goes a long way.”

Product takeaway: Before you reorganize for AI, separate true talent gaps from skills your current team can learn. Hire for the first, then invest in the second. Domain knowledge is the hardest thing to buy and the slowest to rebuild.

Chapters

00:00 Introduction
02:07 Maya’s path from software engineer to chief product officer
03:38 Why your first 30 days should be for listening and learning
06:10 Three questions to ask in every cross-functional one-on-one
07:59 Finding quick operational wins without breaking what works
11:09 When to shift from operational fixes to long-term strategy
16:09 Defining success by why customers buy and why they leave
22:17 How AI is reshaping product team structure around outcomes
27:17 Developing the team you inherited vs. hiring for talent gaps
29:29 Conclusion

Links

• Maya’s LinkedIn

• Cin7

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.

AI has made building faster and cheaper than ever. That leaves product leaders with an uncomfortable question: if engineering isn’t the bottleneck anymore, what is? And do we still need product managers?

Today’s guest has a clear answer. Naomi Lariviere is Chief Product Owner at ADP, where she oversees a roughly $4 billion mid-market portfolio for a company that pays one in six Americans. Her career path is unusual for a CPO: she started as a business systems analyst in financial services, then stepped away from product to run an IT PMO, professional services, and even pricing and sales ops before coming back.

Her take: much of the PM job over the past decade drifted toward tickets and standups instead of customers and markets. AI is finally a chance to hand that work off and get back to the real job.

In this episode, Naomi shares:

• What happened when ADP’s dev team tried to deliver without a product team, and why they came back

• How ADP studied what its PMs actually do all day to find the busywork AI can take off their plates

• Why she’s skeptical of the push to turn every PM into a product builder who ships code

• How ADP keeps innovating when a single mistake could mean thousands of people don’t get paid

  ---

1. The experiment: Shipping without product

At ADP, the question of whether product was still necessary didn’t stay theoretical. When the idea came up that product could be eliminated, Naomi handed the dev team the challenge and told them to figure out how to deliver something on their own.

It didn’t take long for the gaps to show.

“Ultimately we ended up, ‘Oh, wait. We need the product person to tell us, like, well, what are the rules? What is the compliance regulation?’”

Naomi’s explains why this happened:

“AI makes building cheaper, but it doesn’t make choosing things any easier.”

Product takeaway: Speed without direction isn’t progress. As AI compresses build time, the scarce resource becomes knowing which problem to solve, under which constraints, for which customer. If your org is debating whether product is still needed, the fastest way to answer is to look at what breaks when nobody owns the rules, the regulations, and the “why.”

2. How PMs got “Scrumful, not Agile”

Early in her career, Naomi spent her time with clients and prospects, doing market research and studying the competitive landscape. Then Agile arrived, and the expectations quietly shifted. PMs were now expected to write every requirement, run the backlog, and direct each sprint.

The cost of that shift was everything PMs stopped doing:

• Talking to clients

• Understanding the market

• Reading the macroeconomic picture

And that’s exactly why AI looks like a threat to some. If the job is writing PRDs and user stories, AI can do it.

But that was never the actual job:

“What product actually is doing is synthesizing multiple inputs and then going, ‘Here’s the best opportunities that we have to solve a problem, and here’s the ones that are gonna make you money.’”

Product takeaway: If your team’s value is measured by how well it runs ceremonies, it’s vulnerable. Look honestly at where your PMs’ hours go. Process should exist to drive decisions, and every recurring meeting should earn its place by unlocking one. Three standups across three teams is busywork, not product management.

3. Innovating when a mistake means someone doesn’t get paid

Startups can push code multiple times a day. ADP, with over 1.1 million clients, operates with much higher risk. They pay 1 in 6 Americans, and as Naomi says:

“When you think about somebody’s pay, they could be counting on that check to make their rent or, you know, pay for a vacation, or they’re getting married and they need to put a deposit on an event space. You know, if we do something that means they miss that, that is, that’s not okay.”

That doesn’t mean ADP doesn’t move. It means it moves deliberately:

“We innovate actually all the time, but we do it very thoughtfully and in a very controlled fashion.”

Product takeaway: “Move fast” isn’t a universal virtue. The right release cadence depends on the cost of being wrong for your users. In high-stakes domains like payroll, finance, and healthcare, the product team’s job includes keeping the user’s real-world consequences at the center of every innovation decision, and building the controls that let you ship confidently.

4. Product managers, not product builders

There’s a growing push to turn every PM into a builder who ships code with AI. Naomi thinks that misreads what the role is for.

“Yes, I do know how to code, but do you trust me at launching feature and functionality into a platform like one of ADP’s? Probably you shouldn’t do that.”

The skills that actually make a PM effective are the ones that coding doesn’t touch. Interviewing a client without introducing your own bias. Understanding what pushes someone to buy. And above all, telling the story:

“When someone asks me what would be the one surprising thing about my job that most people don’t understand, it’s the storytelling, it’s the influencing that we do. And, you know, coding doesn’t help me do that.”

Naomi does expect roles to become more fluid, but she wants developers doing what they’re great at and product people doing what they’re great at.

Product takeaway: Before requiring that every PM become a builder, ask what you’d lose. The PMs everyone in an org seeks out, from sales to engineering to execs, are rarely the best coders. They’re the ones who read the room, carry empathy for the user, and articulate why something matters. Protect and invest in those skills; they’re becoming the core of the job.

Chapters

00:00 Introduction
02:24 Naomi's path from business analyst to ADP product leader
04:19 Is AI the end of product management?
06:12 AI makes building cheaper, not choosing easier
08:22 How product teams became "Scrumful, not Agile"
12:58 Why ADP has to innovate carefully at its scale
15:32 Process with a purpose vs. process for its own sake
17:30 Should product managers become product builders?
20:22 ADP's jobs-to-be-done study of the PM role
22:13 Fluid roles and why less technical PMs can deliver more
25:43 Storytelling, empathy, and the human skills AI can't replace
28:23 Conclusion

Links

• Naomi’s LinkedIn

• ADP

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.

Every product team is shipping AI. But for many companies, very few users are adopting it. The people who try the feature love it, and adoption stalls anyway.

Charanya Kannan thinks that’s because teams obsess over building AI and barely think about adoption. As VP and GM of Navan Anywhere, she puts Navan’s AI travel and expense tools inside Slack, Teams, and Gemini, where people already work, instead of asking them to open yet another app. She joined Navan when it was still called TripActions and doing under $50M in revenue. Now it’s well on its way to $1B!

Her core belief: if customers have to work harder to use your AI, it isn’t actually better.

In this episode, Charanya shares:

• How Navan Anywhere was built distribution-first, bringing booking and expenses into the tools people already use every day

• Why Navan’s margins went up in the AI era, while the rest of SaaS braces for compression

• And why she believes PMs who mostly manage process and Jira tickets will fade away, while those who can actually drive user benefit and business outcomes will matter more than ever

1. Building is easy. Getting users to adopt is the real problem.

These days, you can create an AI prototype in about a weekend. But getting anyone to actually use it? That’s where most teams get stuck.

Charanya’s fix is to skip the “please come try our shiny new thing” step entirely. Navan Anywhere lives inside Slack, Teams, and Gemini, where people already spend their day. They don’t have to download a new app or form a new habit because, as she says:

“If they have to put in extra effort to do something because AI is superior, then AI is not really superior.”

Product takeaway: Plan for adoption as you plan the feature. The easiest product to adopt is the one that shows up where your users already are.

2. Not everything needs to be a chatbot

Six months ago, Charanya told her designers to start brushing up on evals, because chat was going to eat everything. Then users actually tried picking a hotel from five paragraphs of text. It turned out that people booking hotels wanted to see photos of the hotel.

So, Navan mixes and matches. Chat handles the “here’s what I want” part and the UI handles the “let’s compare” part, while payments stay firmly on the reliable deterministic rails.

“The real judgment or discernment is: Where do you bring in AI? Where does it make sense to bring in your agentic systems versus where do you fall back to your deterministic systems?”

Product takeaway: “AI everywhere” isn’t a strategy. Use AI where it removes friction, use UI where people need to see things, and be skeptical about AI related to anything that moves money.

3. The two kinds of PMs & why nobody’s irreplaceable because they write great Jira tickets

Charanya has mentored dozens of PMs, and she sees two types: Those who spend their days running standups and shuttling messages between sales and engineering, and those who ask why the team is building something at all, and whether it’ll still matter in five years.

Only one of those jobs survives the AI era.

Navan runs a travel business doing over $3B in bookings with fewer than five PMs, and engineers write a lot of their own tickets.

“Everybody knows there’s a problem, but how do you frame that problem? Give the problem eyes and ears and a figure that people can go after and solve it… If you’re just thinking about processes 80% of your time, that’s not what we want.”

Product takeaway: Process should be about 20% of the job. If it’s 80%, AI is coming for that part first.

4. How Navan’s margins went up in the AI era

While most of SaaS is sweating over inference bills, Navan’s margins are growing. The trick is letting AI do what it’s good at: it now resolves about half of support conversations, up from a third back in the pre-LLM days.

The truly messy stuff still goes to human travel counselors.

“When you’re stuck in a plane for five hours on the tarmac… no AI can come and solve the problem for you.”

Product takeaway: Let AI handle the repetitive stuff, save your humans for the hard stuff, and treat your model choices like the budget decisions they are.

Chapters

00:00 Introduction
04:17 Why AI features don't always get adopted
06:30 Building Navan Anywhere distribution-first
10:13 When to use AI vs. deterministic systems
12:01 Conversational cognitive load and why good UI still matters
15:57 Evals, distilled models, and the AI reliability pyramid
20:14 Product owners vs. product managers in the AI era
26:10 How Navan is growing margins while SaaS faces AI compression
31:40 Conclusion

Links

• Charanya’s LinkedIn

• Navan

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.

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

Links

• Brian’s LinkedIn

• Network Solutions

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.

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

Links

• Brandon’s LinkedIn

• Pantheon

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.

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

Links

• Kevin’s LinkedIn

• Life360

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.

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:

1. Required steps can act as trust signals.

2. Delays can be turned into progress arcs.

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

Links

• Kunal’s LinkedIn

• Insider Growth Group

• Houzz

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.

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

Links

• Jeff’s LinkedIn

• Miro

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.

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

Links

• PM OS GitHub project

• Parul's LinkedIn

• Parul's collaborators:

  • Vidya Sarangapan

  • Priyanka C.

  • Bhagyashree Prabhakar

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.

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

Links

• Gaurav’s LinkedIn

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.

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

Links

• Vassili’s LinkedIn

• DoorDash

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.

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

Links

• LinkedIn

• Datasite

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.

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

Links

• LinkedIn

• Zipcar

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.

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:

1. Hostile — “I don’t want to use this. I think it’s bad.”

2. Skeptical — “I’ll try it, but I think it’s going to suck. Last time I tried, it did.”

3. Converted — “I believe. I know it works. I remember to use it sometimes, and I’ve got a couple of systems down.”

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

Links

• Laura’s LinkedIn

• Descript

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.

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?

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.

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.

Links

• Julia’s LinkedIn

• Capacity

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?

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.

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?”

Links

• Jen's LinkedIn: https://www.linkedin.com/in/wangjennifer/

• Framework: https://frame.work/

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?

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.