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

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

In this episode, Raul shares:

• The unglamorous but vital elements of a complete e-commerce analytics stack, and the table-stakes things teams often skip

• Why an Analytics team embedded inside product is a requirement, and the deployment discipline that comes with it

• And how Princess Cruises is using AI behind the scenes to help their team work smarter — and why, when it comes to customers, simplicity will always matter more than technology

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

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

Raul’s fix?

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

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

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

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

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

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

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

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

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

There are two sides to AI for any product team:

• What you use internally to move faster, and

• What you deliver to customers

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

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

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

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

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

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

His advice for every product leader?

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

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

Links

• Raul’s LinkedIn

• Princess Cruises

Chapters

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

What does LogRocket do?

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 our conversation, Jason shares how his engineering background shapes the way he evaluates AI-generated solutions and anticipates downstream UX impacts. He talks about how LLMs are reshaping experiences like search, research, coding, and design, and why discoverability and intentionality matter when building AI-powered products. Jason also discusses the role of human judgment in an era of AI-generated content.

The AI design perspective

Reflecting on your professional journey, how did your early start as a full-stack engineer and web developer shape the way you currently evaluate and work with AI-generated solutions?

One thing that really helped shape my perspective is that I’m able to see the scaffolding. I can see the outcomes that we’re trying to drive through design, and also the systems and architectures that are making that happen — all the things under the hood. While I might not be an expert in all those things, I still have a strong understanding of how they fit together and how they influence that eventual outcome.

This enables me to look at downstream consequences, especially those that may be second- or third-order — things that others might miss, especially through a UX lens. A change within the architecture might impact the experience down the road or affect a seemingly unrelated area of the experience. Having that grounding in engineering helps me see and predict those scenarios.

Within AI, especially, one of the defining factors compared to web or mobile is that the experience and the architecture are very closely coupled. A change within the architecture usually means a change within the experience and vice versa. That gives me a different perspective when designing experiences or leading teams. We don’t necessarily have to think within the constraints of what is possible. New designs can influence how the architecture needs to change. There’s a symbiotic relationship between the two.

Especially as design and product management teams evolve how they work day to day, technical foundations like working with Git repositories are becoming more and more visible — and necessary — for non-engineers. That shift is one I’m very familiar with, so I’m able to help shepherd other people to it.

How LLMs are reshaping digital experiences

You described a symbiotic relationship. Is there ever a sort of reverse, where LLMs can actually make an experience worse due to a lack of context or something else?

Yeah, this is a fascinating thing to think about. There are a lot of different lenses for how LLMs have improved experiences. Even more broadly, they’re influencing the technology landscape that we interact with every day. There’s a lot of AI going into infrastructure and architecture — how things get analyzed and how connections are made behind the scenes. Even if you’re interacting with something that doesn’t have AI in its interface, chances are there’s some AI connecting dots behind the scenes.

When we look at experiences that LLMs have changed, the first one that comes to mind is search. Search has completely changed over the past couple of years. Whether you’re using ChatGPT or Claude to ask questions and get answers, the experience of searching is fundamentally different now compared to using a traditional search engine.

The same thing is true for research, which is sort of the next order of search. Let’s say you have one thing you’re looking for, and you want to examine multiple sources and then make a decision. Now you can gather those sources together, synthesize them, summarize them, and find a through line. Yet, while search and research have fundamentally changed, it’s not necessarily just the end-user experience. The experience of coding has fundamentally shifted as well.

Engineers might not be writing code all day anymore. Instead, they’re prompting tools like Cursor or Claude. The same is happening in design. Designers who might have spent all day in Figma are now working more agentically in tools like Claude Code or SigmaMake instead of focusing on pixel-perfect work. Where these things fall down often isn’t the product itself, but how the LLM is integrated. There might not be enough context or guardrails. Sometimes the system is simply hard to use because people don’t know what to do with it.

Discoverability, therefore, becomes really important. If you’re creating a product, you need to teach people how to use it. That’s one of the biggest downfalls of conversational systems. There’s also the shiny-object syndrome, where teams say, “We’re going to throw AI at this problem, and everything will be better.” Chances are it won’t be, because you’re focusing on the solution instead of the problem you’re trying to solve.

When LLM-powered experiences fail, it’s usually because AI is treated as a silver bullet rather than something intentional.

How do you think AI’s speed and efficiency affect the messy discovery phase of zero-to-one product development?

Zero-to-one is a fantastic space, and the mess is really important. I’ve seen situations where people jump to the first thing an AI produces. They’ll say, “Great, I have this idea,” put it through an LLM, and whatever comes out becomes the solution.

AI can collapse the time it takes to get from zero to one. But what’s missing is the divergence that needs to happen during that process. It’s less about how quickly you go from zero to one and more about how you use AI to accelerate divergence. Instead of taking for the first output, you might ask, “What are 10 other examples that are different? What are the bright points and failures of those examples?”

That helps you form judgment and move toward a stronger zero-to-one outcome. There’s a lot of value in that messy middle rather than jumping straight to polished output.

Designing intentional AI experiences

When teams are excited about agentic or conversational AI, what experience-based questions do you ask before approving the work?

There are a number of considerations, and the first is discoverability. When a system can do an unknown number of things, people don’t know what to do with it. That’s been a challenge with conversational systems for a long time, and it’s compounded with agentic experiences because they’re more powerful.

Teams need to make the capability discoverable. If you build something, it needs to be obvious that people can go use it — you’re not simply placing a button somewhere in an interface. Once people discover it, the next question is how to make it sticky. How do you make it valuable enough that people keep coming back? How do you make it memorable and easy to return to?

Another important consideration is precision. LLMs are very good at broad strokes — they can help you do a lot of work quickly — but they’re not very precise. When you need precision, the experience often slows down, and it feels like AI isn’t doing what you want it to do. So teams need to be intentional about where an LLM provides value.

You might use it for broad strokes, then provide an easy off-ramp into a precision mode where someone can fine-tune something manually. After that, they may jump back into the LLM again. Designing that back-and-forth is really important.

Is some of that lack of close precision with an LLM due to insufficient context? For example, when an LLM is on a particular project, would the precision improve over time?

It depends on a number of factors, especially the underlying architecture. How the system handles context matters a lot. If you’re working on larger or ongoing projects, you can start experiencing context rot as context windows fill up. That reduces precision. It also depends on how the user provides context. If you provide too little, you won’t get the precision you need. If you provide too much, you might get precision in the wrong places. So there’s a balance, and it’s very dependent on the situation.

Do you have an example to share of a discoverable, memorable AI experience that stands out to you?

I’ve seen a lot, but one example that stuck with me was early ChatGPT. When I first started using it, one thing that really surprised me was the “regenerate” feature. I had done a lot of work in Alexa and chatbot systems, and the idea of regenerating the same prompt to get a different response blew my mind.

There was just a small recycle icon under the response. I clicked it, and it regenerated the answer. What was interesting was that it also maintained the previous responses, and I could tab through them. That simple interaction really highlighted the difference between deterministic systems and generative systems. It was discoverable, delightful, and powerful — all through a single small feature.

Human judgement and managing expectations

Are there certain aspects of beautiful user experiences that you believe can only be learned and can’t be generated?

Sure — just ask any designer about beauty. In AI, especially, a lot of this comes down to taste and judgment. It’s authenticity. We’re living in an era of AI-generated content where the bar for creating something has gotten very low. You see a lot of polished output, but there’s often something hollow about it. They’re built under constraints, and they have to be able to survive the complexity that goes into them rather than something that can be generated at scale.

Also, what has to be learned is the judgment of when to restrain yourself versus when to lean in. That’s what allows something to feel authentic and personal. Even if AI understands your preferences and produces things you like, you still have to apply human judgment and ask, “Is this authentically something I believe? Is this something I would put out myself?” That kind of judgment has to be learned.

How do you manage prioritization and stakeholder expectations in AI work without over-promising?

It’s largely dependent on the situation that you’re in and the people that you’re working with. What I’ve seen is that experience with AI-enabled systems is very uneven. Not everyone has the same knowledge about designing or building with AI. Because of that, you need to lead with a level of grace. Not all teams working with AI will move at the same velocity as they would with more established technologies like mobile apps.

You have to have honest conversations about complexity, timelines, and what still needs to be figured out. Once everyone understands that baseline, it becomes much easier to prioritize and move forward.

Early career and leaning into excitement

A lot of early-career PM work is now being automated. What advice do you have for those who are earlier in their product careers on how they may gain experience?

I don’t know how long this advice will last because things are moving so quickly, but the apprenticeship model of junior roles is fundamentally changing. Those roles were traditionally execution-heavy, and that execution work is compressing because we can go from zero to one much faster. So it becomes less about craft execution and more about judgment.

How are you framing problems? How are you navigating ambiguity? How are you creating clarity from that ambiguity? Those are the durable skills. You have to lean into building judgment. It’s like working out — you have to put in the reps and experience the friction of failure in order to grow.

One thing that helps is using peers and AI as thought partners. I do that myself. It helps you think through different scenarios. And when you’re choosing where to work, ask yourself: is it a problem you’re excited about? Is it a company you’re excited about?

That excitement will help you lean into the work and the challenges. You have to get comfortable with ambiguity and with not being perfect. Apprenticeship-level work is about learning and growing — even when the focus shifts away from execution.

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 conversation, Lucila discusses how cultural nuance shapes customer experience design, why discovery must start with frontline employees, and what it takes to scale a global CX team while maintaining shared values across regions.

Building hyper-localized CX in a global market

Could you start by describing your core customer base?

We work with organizations across multiple industries and regions, with a strong focus on companies that have large deskless workforces such as manufacturing, retail, and logistics. Our customers typically operate in complex environments where communication, adoption, and operational alignment are critical to success.

What makes our customer base unique is not only its geographic diversity, but also its wide range of digital maturity levels. That diversity shapes how we design adoption strategies, onboarding journeys, and long-term engagement models. Our users are really different. We don’t only work with people who work from home or from an office with a computer — we have a variety of users, and that’s something interesting.

How do you adjust the CX journey across regions?

We don’t adapt the journey only by country. We tailor it to cultural context, industry dynamics, and user behavior. We consider high-level factors such as digital maturity and small operational details that shape adoption, like device preferences.

In Latin America, customers tend to value close guidance and hands-on support. So we emphasize proximity, clarity, and continuous support.

In the US, it’s different. We prioritize asynchronous preparation. We share materials before meetings, and during meetings we focus more on strategic discussions such as benchmarks and change management rather than configuration details.

In Europe, security and compliance conversations often need to happen first. At the beginning of onboarding, we talk a lot about security and compliance before moving to other topics. That helps customers feel more comfortable and aligned from the start.

In parts of Asia, executive teams are deeply involved at the beginning. We start with conversations with leadership to get aligned on the company’s main goals before moving forward.

In practice, we continuously adapt each stage of the journey and every type of interaction to what works best in each region — even communication channels like WhatsApp or email can vary.

Designing for real users, not assumptions

How does “customer delight” look in an HR ecosystem?

Customer delight comes from deeply listening and solving real problems. We talk a lot about generating value. It’s not about sharing good news — it’s about finding solutions.

Sometimes that means helping customers beyond the platform itself, such as connecting them with peers in the same industry or sharing relevant ideas.

One practice we have is that every week, each member of the customer experience team blocks the first hour to answer one question: What else could make this customer’s experience better? It’s a moment to stop and think intentionally about how to improve the relationship.

In practice, delight shows up through transparency and fast communication. Customers feel supported when they understand the status of their projects. Over time, that builds trust. Adoption grows naturally, and retention becomes part of the dynamic of the relationship.

How do you conduct discovery to ensure you’re solving for employees’ reality rather than HR assumptions?

We have two stages in our discovery process.

First, we do user persona discovery. At this stage, we focus on employees — not HR goals. We map workforce realities: which devices they use, their digital literacy, their environment, and their daily routines. We want to understand who the users are before talking about processes.

Then we move to process discovery. We learn about workflows, communication flows, operational challenges, and how the company actually works. But we do this after understanding who is using those processes.

Whenever possible, we complement this with on-site visits and direct conversations with employees. Observing how people actually work — their context, constraints, and habits — often reveals insights that wouldn’t surface otherwise.

A key part of discovery is validating assumptions early. When you understand the context before starting configuration, you make better decisions.

Have you learned anything surprising during discovery?

One example that stayed with me was a large healthcare organization in Argentina. HR leaders were initially concerned that employees wouldn’t engage with a social-style platform because they might feel observed or uncomfortable sharing.

The week we launched, we saw more than 10,000 active users, and many activated their accounts on the first day. During the first week, there were more than 1,000 posts from teams sharing moments from their workplace. It was completely different from what we expected.

Six months later, during a visit, I spoke with a nurse who told me, “I really feel like my voice is part of the organization now.” Before, recognition was private. Now, acknowledgement was visible to everyone. That showed me how meaningful public recognition can be.

How do qualitative insights translate into concrete product decisions?

Qualitative discovery influences rollout decisions.

In one mining company operating in Mexico and the US, leadership wanted to implement 15 modules in the first month. During discovery, employees shared that too much change at once had created problems in the past.

We recommended a gradual rollout instead. Communication features were introduced first. Three weeks later, time-off tools were added. Later, service modules were introduced.

The onboarding took a little longer, but engagement was stronger in the long term. Sometimes moving more gradually at the beginning creates better outcomes.

Scaling personalization without losing nuance

Are you seeing a global mobile-first movement?

In many markets, it’s not just mobile-first — it’s mobile-only. Some workforces don’t regularly use computers. Their main interaction with technology is through a smartphone.

For these users, the experience needs to be simple from the beginning. We often start with basic functionality and introduce additional features gradually.

Mobile environments also bring advantages like push notifications and accessibility. But the key is designing around how people actually work, not how we assume they work.

Hyper-personalization can be difficult to scale. What frameworks help make it repeatable?

To make personalization repeatable, hiring standards are important. Teams need to understand context and make good decisions.

We also rely on modular playbooks and automated feedback loops like CSAT surveys and metric alerts. If engagement drops unexpectedly, we investigate quickly.

Automation handles the baseline monitoring, which allows the team to focus on more personalized guidance when it’s needed.

Building a global CX organization

How do you keep a 100-person global team aligned?

Retention is our North Star metric. We talk about it constantly, and we repeat the goal of zero churn.

But alignment is not only about metrics. Customer obsession is a company-wide value. We reinforce this through rituals such as monthly learning reviews, where we discuss what worked and what didn’t.

When a customer leaves, we conduct postmortems to understand what happened and define actions. If we don’t change something after a churn, that’s a red flag.

Repetition, shared language, and regular reviews help keep distributed teams aligned.

What communication practices support this alignment?

We hold weekly customer experience meetings and rotate training times across regions so no single team is always inconvenienced. Sessions are recorded so everyone can access them.

The expectation is continuous learning. If someone ends a month without learning something new, that would be a concern.

What are the advantages of local teams serving local customers instead of centralizing support?

Having local teams allows closer relationships and deeper understanding of cultural differences.

Small behaviors — greeting norms, tone in meetings, communication style — can influence trust. When working in new regions, local feedback helps teams adapt more quickly.

Local presence also shortens the learning curve in new markets and allows teams to anticipate challenges earlier.

What lessons have you learned about building a global team?

One of the biggest lessons has been the importance of understanding a country’s culture and market dynamics before hiring.

Scaling globally doesn’t mean replicating a single model everywhere. It means building consistency through shared values while allowing local adaptation.

Hiring people who align with those values is critical. The right people help you understand the market faster and grow in a sustainable way.

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 Angela Clark, VP of Digital at Patagonia. Angela’s career spans 20+ years in retail and direct-to-consumer, from Pottery Barn and Levi Strauss to True Religion, and now one of the most mission-driven brands on the planet.

In this episode, Angela shares:

• How her team is designing a customer journey that caters to the buyer on a 1:1 level, including Product Detail Pages that can speak effortlessly to either extreme of their customer base

• Her playbook for managing AI-related “shiny object syndrome” and keeping your roadmap focused on the customer

• And why Patagonia flipped the definition of “customer lifetime value” to align with their conservation-driven mission — even happily downselling you to a refurbished item instead of a newer, more expensive version

1. The PDP of one (3:10)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Links

• Angela’s LinkedIn

• Patagonia

Chapters

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

What does LogRocket do?

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.

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

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

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

In this episode, David shares:

• A detailed, under-the-hood look at the specific vendors they use to stay so lean

• His playbook for using strategic partnerships with vendors as an external dev team

• How being a testbed for new tech gives them a competitive edge

• And why their choice of ecommerce platform was vital in enabling Rainbow’s digital strategy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Links

• David’s LinkedIn

• Rainbow Shops

Chapters

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

What does LogRocket do?

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 our conversation, Laure talks about how to run high-velocity experimentation limiting risk on the core product experience — and why protecting that core must come before monetization. She explains how OfferUp distinguishes between features that belong to everyone and paid accelerants designed for its most active users and business customers. Laure also reflects on the hidden risks of “winning” experiments and how AI is reshaping PM work.

Monetization for different user groups

When you’re building a platform product, how do you distinguish core features from paid features?

I think one of the most important things is really knowing the core of your business and your business model, and being able to say, “Hey, this feature belongs to the core experience, we cannot really put it behind a paid gate. The people who have been using the app for a long time are going to have a degraded experience if we do that.”

That’s how we think about introducing subscription products. How do we protect the core of the experience for our users, making sure that people who have been successful this whole time as buyers or sellers continue to be successful? Then, what are the things that we can provide to them to make them even more successful? That’s what you would put behind a paid product.

User segmentation is another way to look at monetization. For example at OfferUp we work with businesses and dealerships, they are great partners we want to enable success for, but they are not the majority of our user base. Our core use base is made of casual buyers and sellers like you and I. Businesses pay us and we owe them dedicated features that do not apply to everyone on the platform.

Do you think about users as one group, in the sense that your goal would be to make everyone a paid user? Or do you think you always need to create an experience for that unpaid group?

I think about this a lot, because as a user myself, I’m generally anti-subscription. My thought is that you should always keep a part of your product that’s unpaid, because a lot of people are like me and pay close attention to that, and even more in the current economy.

I’ve found that users who are willing to pay are usually your most active and loyal users, and they have a very different behavior than somebody who’s just casually coming in every quarter or so. The paid features are geared toward this segment in particular, because they’re using the app so much that they want even more. To me, it’s different user segments with different needs and your product needs to support them in different ways.

Testing intelligently

What observations came out of using tools like Statsig that shifted the way you were thinking about your product roadmap?

It was a bit of a journey. One of the big gains with moving to a platform like Statsig is analytics. It makes you much faster in understanding what the experiment is producing, the results you analyze, and how fast you can analyze and move to the next phase.

We went from running just a couple of experiments to really ramping up that process. But we got to a point where the experience itself became disjointed for our users. We had a test to change certain elements on the page, and all of those things separately had a positive impact, but from an overall user experience, it made it more complicated for users to be successful on our app.

The second shift in how we look at experiment results happened more recently. Yes, a test could be a winner with those short-term KPIs, but you absolutely need to look at long-term retention and understand the impact of features, especially altogether. We came to that realization because our users were saying, “Your experience is so complicated nowadays.” If we had looked more at funnel analysis, how it changed the journey, and how it changed retention, we probably would have made different calls on some of those experiments.

On the topic of experimentation, what trends or challenges are you seeing among product managers and leaders in trying to run more effective experiments?

With all the tooling that we have right now, there’s a tendency to want to test every little thing. But it’s hard for product managers to come up with so many fully baked hypotheses and tests. If you don’t have a solid hypothesis and you’re so low-level as to test the shapes of on-screen buttons, it might not be worth it. What are you actually trying to drive with this?

At the same time, someone might say, “I’m just changing this copy. I’m not going to test it.” These tests can be the most impactful because changing copy might lead the user in a completely different direction. It’s an ongoing practice of: what are you really trying to learn? Try to isolate the test, too. You cannot test all of it at once because then your result’s going to be muted.

If I had one piece of advice, it’s to take the time to define what you want to test and what the goal is, clearly define your main KPIs, and make sure you have more long-term KPIs as guardrails. That’s what makes an experiment successful — not necessarily a winner test, but a test where you learn what your next steps should be from there.

How do you encourage a culture of experimentation in your team and your company without testing everything all the time?

There are two things I always do. One is to set really clear goals. What’s the problem you’re trying to solve for the user, what’s your hypothesis, and why did you build this thing in the first place? Be aligned as a team on what you’re trying to solve.

Second, I’ve seen organizations where, as part of PM goals, you have to run however many experiments per quarter. This is not the right goal. The right one is a win percentage or ratio. It doesn’t matter how many you run. You might run only three, but two are really strong winners. That changes the business.

The role of AI in accelerating PM work

It’s impossible not to see how AI comes into play in product organizations, so where do you see AI accelerating PM work — and where does it overstep?

The base of our work as PMs takes a lot of time — user research, competitive research, digging through all your app reviews and customer care reports, etc. And with layoffs throughout the industry, this type of work has been on PMs more often. It’s been hard to transition to that.

With AI, the research piece is a tremendous accelerator. You can research things that would take one or two weeks, and today it takes 15 minutes. You ask Gemini to look at competitors, what they’re doing for this type of feature, scan app reviews, and summarize how people feel.

The other part is how the role evolves. The lines between UX research, designers, product managers, and engineering start to blur. You can take insights, form a hypothesis, and build a bare-bones prototype without working with your designer. That’s accelerating, though it’s not quite there yet, and there’s a lot of rework to make it match to your business outcome. Even if we have to re-write things, it shaves a lot of time off the pre-work.

Where it’s not quite there yet is similar to experimentation. If you don’t define clearly what you’re trying to solve and your probable ideas or hypotheses on how to solve it, AI will not tell you that. If you don’t prompt it properly, you’ll get an answer that’s maybe not aligned with what you’re trying to accomplish.

With all that said, are you putting guardrails in place for internal AI use? And do users specifically want or ask for AI in the product?

Internally, we want everyone to be exposed. There’s no process per se — it’s more like go and experiment, but within company guardrails. We’re using Gemini as our approved AI tool, and it’s not using our data to train its model outside of us. Everyone talks about the excitement around AI, but there’s also fear. When I ask if people have tried new prototypes, most of the time the response is, “No, not really.”

So I keep pushing it a little. Every time we’re starting something new, the first question I’m asking is, “Did you use Deep Research to look at what competitors are doing? Where do we sit compared to our competitor for this particular feature or for this particular problem?”

On the user side, AI is not new. On trust and safety, it’s always been the number one thing we work on. And on the backend, we’ve been using these techniques to augment listing data. If someone posts that they’re selling a black chair, great, but there’s not enough info for search to find it. So we extract and augment data, and make our systems work properly.

More recently — and maybe more critically — we’ve started to look into whether users want AI. To me, it’s more about whether they need it and, if so, where they need it the most. For example, about a year ago, we built an AI-assisted posting experience. Users can take a picture, and we’d auto-fill everything. We tested it, and one hypothesis was it would drive retention through increased frequency of use. People will post more because it’s so easy. That didn’t show, though — people posted quickly, but it didn’t change their fundamental behavior. They still only came to our product to sell things when they needed to.

With that said, we did see a lift on items — buyers were finding them more easily and buying them. But with the price recommendations we created, people didn’t really accept that, and even with AI-powered descriptions, people were going back in to change things. The trust wasn’t there at the time. But AI is at a different state now, and users’ states of mind are always changing as well.

In general, the main thing is not to ship a feature with AI just because it’s called AI. You need to think about your users and where they need it most.

When PMs transition from backend work to doing things that are more customer-facing, how do you get them to build that empathy for customers? Is that a difficult thing to coach people on?

I’ve always tried to think about the user. Even for backend changes, you need to think about who your core user is. What are the things that you could do, even if they’re not UI related, to help solve their pain points?

To me, the transition is not necessarily difficult, but the attention to detail is. When you work on big backend stuff, it’s very straightforward. The databases and APIs need to be a certain way, and we’ll serve this data by doing X. On the UI side, it’s more difficult because you have a lot of opinions. Plus, your opinions are not necessarily always right because your users are not you. In the experience itself, it’s important to try it and see how it feels before you move on with a feature. You also have to be OK with being proven wrong.

Empathy, data, and effectively coaching PMs

Did you find that this is similar to having to shift from quantitative to qualitative insights? How do you strike that balance after having worked with one extreme for so long?

You need to merge quantitative and qualitative feedback. One tendency for PMs on the UI front is to go with qualitative feedback because that’s what people see and complain about. When you read feedback that says, “This is not efficient for me — I hate it,” you think, “This is my product. I don’t want people to talk about it like this.” But you have to look at the data. How many people share this sentiment? Is it actually preventing people from converting — from buying something?

Sometimes, it’s a case where one user says notifications aren’t intuitive. But let’s see if there are more — and if we have data that tells us if that’s a true blocker for a lot of users.

Ultimately, needs and wants are different. People might say, “I want this feature because Facebook has it.” That’s not necessarily solving their actual problem. It’s really important to dig into what the actual problem is.

To wrap up, what guidance would you give to someone who is new to product management about navigating what the field looks like now?

The way I see the PM role evolving with AI in particular is that AI will do a lot of junior-level work, whether that’s product, engineering, or design. The advice I’d give to younger PMs going into the field is to keep being curious and really dig into things. That’s what’s going to get them to a faster level of seniority. Ultimately, that curiosity and ability to dive deeper will help them be successful in this new world. Critical thinking and strong business acumen and knowledge coupled with AI will likely shape the product of the future.

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.

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

In this episode, Chinmay shares:

• How he thought through leaving YouTube at its peak to join a moonshot company that could have civilization-level impact

• Waymo’s actual AI eval process, using massive simulations based on millions of real-world driving miles to maximize edge cases, ultimately turning trust into their real product

• And the misleading, but common, metrics Chinmay and his team learned to spot that could have seriously derailed Waymo’s progress

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Two answers, both surprising:

• Unprotected left turns: Massive negotiation happening in real time between cars, pedestrians, and intent. There's no one rule that resolves it cleanly. It's negotiation in real time

• Pulling over: Looks simple, but requires the kind of human intuition that drivers must learn over years. Experienced Uber drivers learn pickup nuance over years (think the person hovering at the corner, the building entrance that's technically on the side street, etc.) It's tacit knowledge, built from thousands of micro-observations humans don't even consciously register

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

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

Links

• Chinmay’s LinkedIn

• Waymo

Chapters

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

What does LogRocket do?

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 our conversation, Alyssa talks about her leadership approach, which is driven by her Four C’s Framework — context, clarity, coaching, and consistency — and how it builds sustainable team performance. She discusses how she identifies and develops emerging leaders through visibility, intentional coaching, and real management opportunities. Alyssa also shares how she leads with empathy during periods of reorganizations and burnout.

Converting potential into organizational impact

To start, could you talk about your approach to leadership and how it informs the way you work with your teams?

Looking back on my experience, the throughline in how I lead comes down to what I’ve named my Four C’s Framework — context, clarity, coaching, and consistency.

The first C is context, which is all about grounding teams in the “why.” These are the business objectives, user needs, and market realities that shape every product decision. Without context, even talented teams can’t prioritize effectively.

Next is clarity, which is about defining what success looks like: expectations, outcomes, and ownership. It removes ambiguity so teams can focus on impact instead of interpretation. It’s also about ensuring teams know how their work ladders up to measurable outcomes.

Coaching is where leadership scales. I don’t want to just give answers, so I try to ask questions that help people develop judgment, confidence, and expertise. Last is consistency, which is what turns those ideas into culture. This is about showing up the same way in all situations, including reviews, 1:1s, highs, and lows, so that people know what to expect and feel supported over time.

This framework has guided me through very different environments and keeps me anchored in both performance and people.

You mentioned that coaching specifically scales leadership. One important component of creating a culture of growth is to identify and nurture emerging leaders. Can you talk about your method for that?

Emerging leaders are often the ones who volunteer for ambiguous problems, ask the right “why” questions, and elevate their peers. In many instances, those individuals will naturally make themselves known through their work and actions. With that said, converting that potential into organizational impact requires intentionality. I take a three-step approach.

First, I create visibility for them. Things like stretch projects and cross-functional working groups are all great opportunities. Second is coaching — it’s one thing to put people in those spaces, but it’s another to support them through it. Specifically, I invest in holding coaching conversations that are focused on growing their impact.

With coaching, it’s important to empower these folks to make the decisions, give them the right context, and help them through it, while also creating psychological safety. You have to be careful to make sure your high performers don’t feel they need to do everything themselves.

Third is creating management opportunities. Getting this experience is one of the hardest steps for young leaders — and even more so for women and people of color, who often face disproportionate scrutiny or lack access to these opportunities. I’ll often work with my team to offer experiences to build that skill, whether it’s leading a project or perhaps managing an intern for the first time.

To give an example of what this looks like in practice, at Hallmark, I had a project manager who was interested in product management. She was a high performer who would often come up with ideas outside of her own remit, specifically that she thought had potential for the business.

When the opportunity came up to own a major body of work, I made sure she was set up for success, and when a role opened up on the product side of the team, we were able to transition her to that new position. Right out of the gate, she successfully led an impactful feature launch.

Creating scalability across an organization

At both Hallmark Media and Dow Jones, you inherited teams operating at different levels of maturity. What was your approach to quickly determine whether a team needed structure, autonomy, or new expertise?

I always try to listen and diagnose first and foremost. I listen to the team and their stakeholders to understand where individual strengths and interests align with the business’s needs. What’s working in the team, where are opportunities for efficiencies, what’s not working, what projects might have blockers, etc.? All of these questions help me get a sense of what’s working — both functionally across the team and for the individuals — right when I come in.

For example, at Dow Jones, I inherited a six-person team immediately after a reorganization.

People were demoralized and unsure of their roles. I spent my first 30 days rebuilding trust through 1:1 conversations with every team member, mapping their motivations, and identifying where they saw opportunities. Then, I introduced a clearer strategy, defined success metrics, and made decision-making more transparent. Within a quarter, both morale and team velocity noticeably improved.

At Hallmark, though, the challenge was different. Scaling the team meant evolving from an “all hands on deck” launch model to a subject matter expert one. I wanted to help give people clearer ownership and greater empowerment. That all started with listening, identifying where teams and stakeholders felt the biggest gaps, and aligning structure and new roles to business goals. I don’t take for granted the ability to add headcount, so always make sure there is a clear need and business case before moving in that direction.

When working with an org that is scaling quickly, are there certain practices you rely on to help create a sense of ownership and a culture of continuous learning?

Creating a strong infrastructure for a team is really important because if you’re not intentional, you can fragment teams. I think about creating scalability through strong foundations, leadership, and clear KPIs. Foundations are things like establishing clear, repeatable processes and systems that the team can rely on. Even something as simple as a clear PRD format can make a huge difference in enabling alignment and efficiency.

Also, hiring and developing the right people is crucial to growth. Depending on the team’s lifecycle, you will need different types of hires, but at an early stage, I like to prioritize hiring versatile talent. These are people who thrive in ambiguity, can remain impactful in different contexts, and, in particular, will either fit or add to the culture. I try to determine their communication style, their ability to learn, their approach to collaboration, etc., because those traits will determine long-term resilience.

It’s also important to mention that maintaining focus when you’re growing is crucial. Teams can often get distracted, so things like regular KPI reviews, ensuring a clear understanding of the market, and other things like that help teams adapt to the reality of where they are and sustain the momentum.

At Dow Jones, you led teams that built AI-powered personalization and pricing models. How did you upskill teams or instill confidence in those working with AI for the first time?

I actually co-led a class at Dow Jones about finding AI opportunities, and in general, education is really important when you’re looking at incorporating AI across the broader org. My approach was to focus on demystifying AI and connecting it to meaningful use cases. For example, with generative content, it was important to show reporters that AI could automate the more routine aspects of their work, which would free them to focus on deeper reporting and analysis. It also opened up entirely new kinds of investigation that wouldn’t have been possible just a few years earlier. Once people saw those possibilities and we had a few early wins, adoption accelerated pretty quickly.

Like any technology challenge, it starts with understanding the problem before jumping to a solution. The “black box” nature of AI can feel intimidating, so transparency about how models work and where they’re most effective helped build trust. During the class I co-led, we started with a meme about how AI is essentially just math underneath all of its layers and interfaces.

Helping people understand the basis of what it is and where those opportunities are was fundamentally important.

I’d also emphasize the importance of finding evangelists, who are people interested in working with the technology and who are open to experimentation, and finally, I always make sure to create psychological safety. When people feel comfortable asking questions and admitting what they don’t know, they’re much more likely to engage with new technology and build confidence through experience.

What it means to ‘lead by example’

Many leaders talk about leading by example, but that can look very different at the VP level. What did that mean in practice for you at Dow Jones when you integrated R&D and newsroom teams with different cultures?

As a leader in those contexts, the best thing you can do is listen and help translate. When you have two different teams that don’t speak the same language or use the same terminology, friction can build fairly fast.

Of course, I didn’t expect the newsroom to adopt product language or the data science team to grasp editorial nuance overnight, but it was important that I showed up in those places and helped translate between the groups until they could do so themselves. In this case, “leading by example” isn’t necessarily about doing the work, but enabling different experts to collaborate.

You’ve led through intense moments — from newsroom restructures to broader media shifts. What’s something you learned about leading with empathy that you didn’t fully appreciate until after going through layoffs or reorganizations firsthand?

Early in my career, after a reorg, I tried to be positive, but I didn’t fully realize that people don’t want cheerleading after their teammates lose their jobs. They want honesty about what’s sustainable and what’s not because with layoffs, ambiguity is the scariest thing. People don’t know if more rounds of layoffs are ahead and if they’ll be affected. And you often can’t answer those questions, so being empathetic is really important.

I also struggled a lot with survivor’s guilt. I’ve since learned to be really careful not to center yourself in that conversation. As a team leader, after RIFs, it’s first important to focus on a few things with the teams and individuals that remain. People need to hear leadership say clearly, “Here’s what we’re still building, here’s why it matters, and here’s how your role connects to that.” Leftover ambiguity after layoffs can create toxic cultures.

Second, I create space for people to process change. The idea is not to slow momentum, of course, but to re-anchor them in what’s next. Lastly, I redistribute work thoughtfully. What do we stop, defer, or simplify? This also helps to clarify expectations and ensure ongoing accountability. Overall, if you’re approaching the situation with empathy, listening to people, and trying to massage the work, that can help move people forward.

When teams are anxious or burned out, what signals tell you it’s time to slow down or reprioritize?

Our understanding of burnout has changed over the last few years. Not to minimize burnout resulting from just too much work, which is a real thing, but academics have been able to bring in nuance as well. We’ve learned that burnout can result from psychological dissonance in the workplace. People feel they aren’t working on something meaningful, or being pulled in too many directions, etc. Sometimes, what people need isn’t less work but more meaning.

However, sometimes people may be too deep in the weeds to be thinking about it like this, so I watch for early signals as well. I look for other cues, like if they’re messaging at 11 p.m. regularly, for example. Has their behavior shifted meaningfully, like being less vocal in meetings, for instance? When teams stop debating or volunteering ideas in meetings, it can often be a sign they’re in survival mode. If that happens, we revisit goals, drop or defer work that’s not mission-critical, and reconnect the team to the most important work.

Generally, I like to ask people in a 1:1 how they’re doing. Are they feeling overwhelmed? Are they feeling like they’re working on the right things? I trust them to tell me when they’re feeling overwhelmed, burnt out, or if they don’t feel they are working on value-added projects. If the tone is more that they don’t believe in this work anymore, it leads me to figure out if it’s because the work has drifted away from the strategy and the vision. If so, we need to course-correct or evaluate if this is potentially not the right fit anymore.

In other cases, I appreciate it when my team members say, “Hey, I’ve actually just been working too hard.” I’ll say, “Great, go on a vacation.” There are a lot of things that people need to do to recalibrate, and I’m a proponent of making those things available.

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 our conversation, Laura shares how she approaches experimentation with a pragmatic, outcomes-driven mindset. She discusses how modern buyer behavior, shrinking attention spans, and low-commitment preferences are reshaping B2B journeys, and reflects on the role of leadership in building sustainable testing cultures.

Defining what’s worth testing

With extensive experience in different forms of testing and product performance, how do you decide when an issue is a good candidate for an A/B test?

The biggest thing to think about is whether we have a strong hypothesis. If we do this, then we think this will happen, and is there a clear way to define that it did or didn’t happen? That’s what I try to stick to. If someone brings me a test, I ask: Are we clear on what we’re testing? Are we testing this because we want this outcome versus that outcome? And can we actually measure the result properly? If it’s too nebulous or gray an area, then it doesn’t really make sense as a test. We need to rethink how we’re testing and what we’re testing so we end up with actual data-driven analytics.

For example, I was working with someone who wanted to test changing an H1 on a page. His goal wasn’t engagement, but to see whether paid campaign dollars changed based on the different H1. We initially ran the test through VWO, but he wasn’t seeing any change.

Once I understood what he was really trying to achieve, I realized the issue was that the variant was being delivered through the A/B testing tool on the frontend. Search engines likely weren’t seeing it. So we flipped the test: the variant became the default header on the page, and the control became the alternate.

So we had six weeks of control data, and then six weeks of variant data. We still had engagement metrics in VWO, but now we could also see whether ad spend and pricing metrics changed on his side. Once I understood the goal better, we evolved the test to something we could actually measure with the tools available.

When you run a test and you have multiple options for the user, how great a discrepancy in results do you need to see to consider it significant?

Tools like VWO can help by telling you when there’s enough participation and a clear enough winner to end a test. But I’ll say that probably 50 percent of the tests I ran last year never hit that threshold, either because that page didn’t have enough traffic or time to hit it, or there wasn’t a clear winner overall. We can still look at the results, though, because they at least tell us if we got somewhere.

If a page gets 2,000 visits and one version performs 5% better, that might not be statistically flagged as a winner, but in B2B, that can still matter, especially for lead gen. Any little bit can count.

If I see enough of a signal, even if the tool doesn’t formally call it, we might still choose to adopt or invest in it. But I wouldn’t leave it there. I’d then say, “OK, we either keep the winner or stick with the control. Now what’s the next thing we test?” If something didn’t move much, that tells us we need to rethink what lever to pull next.

How do you encourage continuous learning and retesting without creating an environment where you’re never settling on anything?

What works for us is having clear ownership. If I lead A/B testing, then I can decide what we test, how long we test, and when we stop.

If something is a clear winner and it doesn’t introduce risk or negative business impact, I can end the test and implement it immediately. We all agreed it was worth testing, and now we act on it.

In terms of iterating on tests and finding next steps, I prioritize a regular review of every A/B test that we’ve done and what the outcomes have been, and then we also review those outcomes as a team. This creates space for collaboration. Someone might say, “We tested that, but have we tried this? ”I like some democracy in the process. I’ll usually take those ideas, refine them into proper tests, and slot them into a future plan.

You need collaboration, but you also need a leader who can take action. Otherwise, it becomes too collaborative, and you stop making progress.

Personalization and the user experience

You mentioned your work on predictive personalization. When you’re working on that kind of algorithm or generating that predictive personalization, how do you ensure that you have data that’s actually going to create quality personalized experiences?

At Golf Channel, it was trickier because we were doing it more ad hoc. We didn’t have a formal testing tool. Later, with Akamai, we used Adobe Target, which helped measure how different variants performed across audiences. At Sisense, we hadn’t fully implemented personalization yet, but tools like VWO support similar approaches. For example, if someone comes to the homepage and we’re featuring case studies, we might show a financial case study to someone in finance, a media case study to someone in media, and so on.

If you’re using something like ZoomInfo, you can see the inferred industry for a particular user. Then we can tailor the experience so it’s relevant to each person. Especially in media, I learned that FOMO is powerful. If you see your competitor is using a product and getting results, it can be very motivating.

With some of these tools, you can see how many people from each segment clicked and how they engaged. If one audience responds strongly to personalization and another doesn’t, that informs where you invest next.

You’ve worked across different industries and different verticals in B2C and in B2B. Does the process change for how you design and measure the journey and the engagement in B2C vs. in B2B?

A lot of the tools are the same, what changes is how you use them. In B2C, especially media, you can introduce more variation and personalization. At Golf Channel,for example, users could favorite players, and there were dozens of potential variations.

In general, in B2B, you’re not going to have 50 variations. You’re usually focused on conversion, lead generation, and adoption. Maybe you have two or three paths you’re optimizing.

It also comes down to goals. B2C is more experience-focused. You want people to enjoy it and come back. B2B is more conversion-focused. If someone leaves without converting, they might not return. Apps also play differently. B2C benefits a lot from mobile apps. B2B marketing sites are still very web-centric. No one needs a marketing app for a B2B site.

With so many unique digital consumption habits pervasive across users, how do you accommodate different preferences while still serving people the version of a product experience that you feel is optimal?

The page length and the depth of content on any page has to keep getting shorter and shorter. Paragraphs could maybe have been tolerated a few years ago, but now, landing pages need to be succinct and clear. You need bullet points, scannable content, and easy-to-skim items with clear CTAs to the next action.

SEO wants more words, but users don’t. And now AEO complicates it further by trying to predict what people want before they even get to your website. Last year, some tests I ran showed that users weren’t engaging with long-form content on the homepage. They just weren’t reading it. We did a test to yank all of it out, and engagement didn’t drop at all. That told us people just want an easy next action.

We’ve also tested CTAs. Sales prefers “schedule a demo,” but that’s not top-of-funnel behavior. New visitors don’t want commitment. They want low-energy actions like watch a video, take a tour, or learn more. Free trials are interesting, but even those require effort. People want information without energy or commitment.

Adapting to low-commitment behavior

When it comes to a B2B journey where you’re trying to get people to go through the funnel and make a purchasing decision, does the reluctance to engage accelerate that process or slow it down?

I think the first step has to be low-commitment. If someone watches a demo and thinks, “This might solve my problem,” they’re more willing to invest next. From there, it could be a free trial. Free trials are compelling because no one wants to talk to sales. But then you have to think about what happens after the trial. If someone invests time, uploads data, and sees value, PLG becomes interesting. Maybe they just want to buy right away. Especially for SMBs, immediate gratification and satisfaction matters.

But I don’t think people are looking at 20 tools anymore. From my own experience, it’s more like three. You narrow quickly and move forward.

How do you decipher what users say they want from what they actually respond to in practice?

Especially in my experience, all the B2B companies struggle with information architecture. That then translates into your navigation on your site. When I was at Akamai, we had a mega menu battle where we had to fight to reduce it heavily. We wanted users to be able to easily find what they’re looking for, but we’re offering them 50 choices at once, and people can’t navigate it. The challenge is in creating options while skimming them down to a manageable user journey without so many choices.

When we redid the whole Sisense website last year, I was a big advocate for “less is more.” Too many options overwhelm users. Give them a path and a journey. Above the fold still absolutely matters. People do not scroll at all.

Do the different goals of the industries change the way that you’ve gone about testing and optimizing the experiences? Do you think about the tests differently in those two settings?

It comes back to content strategy in general. I don’t think just about the test, but about the strategy as a whole, and about the experience. B2C is experience-oriented, while B2B is conversion-focused. On a B2B site, nobody’s there to play a game on the homepage. And they definitely don’t want a video as their first experience.

On B2B sites, having a really clean presentation is important. That’s where branding is so pertinent. As a customer, you definitely notice if a site is well done in terms of branding, layout, colors, and more. Users shouldn’t have to think about the interface. It should just make sense.

AI is reshaping the search landscape

What impact is AI having on some of these processes, with automating testing or predicting personalization?

AI is really changing execution. Tools now suggest tests or variations, and AI can help generate alternate copy and speed up ideation. That’s useful because it can surface ideas you might not have thought of, but there’s also a challenge that AEO means users may never reach your site. We have to give search engines enough to surface us, but not so much that users never click through.

Personally, I trust AI for some factual things, but not everything — I’ve seen it get basic math wrong. And now, SEO agencies are trying to figure out how to game AI responses for their clients to show up in the results. That can be really good for a business, but it’s not so great for us as consumers. The answer we’re getting is not always the best and correct one, but the one that gamed the algorithm.

Hopefully, we’ll all learn to not take these results as the sole truth. We’ll still need our critical thinking skills, and that will continue to be important for consumers to make the right decisions for themselves.

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 our conversation, Aurelia describes how the customer experience function is an intentional discipline that acts as a decision filter. She talks about how CX has a 360-degree, end-to-end view of the customer’s experience, and how that helps inform product decisions. Aurelia also shares the importance of framing ideas or concerns in a way that’s appealing to leadership.

Creating value and identifying friction

You’ve mentioned that you are not a ‘fixer’ or a service desk. Could you share how you define customer experience and how you articulate that definition internally?

I say I’m not a “fixer” because I think of “fixing” as being a reactive function, and CX is anything but reactive. For me, it’s more like a discipline, and it’s very intentional. Customer experience is all about designing journeys and aligning teams around different touchpoints that will deliver on brand promise and, ultimately, customer expectations.

CX creates that value for both the customer and the organization. It’s not that the customer experience team doesn’t fix things sometimes, but that it’s not its core function. I see CX as an internal decision filter. When we’re making a decision about a process, experience, or even a product, I ask the same two questions: is it good for the customer, and is it good for the company? If the answer isn’t yes to both, then something’s not right. CX needs to bring value every time for both the customer and the company; it cannot be detrimental to one or the other.

Thinking about customer experience across discovery, purchase, and post-purchase, how do you help leaders from different disciplines distinguish between what qualifies as a growth lever vs. a support problem?

First, I look to identify friction and see where it’s coming from. What is it? How often does it happen, and what behavior does it affect? If you are talking about discovery or pre-purchase, this clearly might impact conversion. In this case, CX is a growth lever — you are affecting demand and conversion, and all this good stuff!

For me, CX is about identifying those patterns, quantifying them, and deciding on the right response. You don’t have to treat each problem the same way, but every problem is an opportunity. If the situation is an edge case, it’s a support problem. You don’t want to send in the whole cavalry for a one-off issue — you want to help the customer, but you also need to define and prioritize where to spend your time.

Looking at the end-to-end experience

Where do the boundaries between CX blur relative to product, marketing, and ops — or, do you feel they are completely distinct?

This is a very interesting question — the boundary exists, but CX lives in that “messy middle” area. Customer experience is the dot connector, we don’t own a distinct function like marketing — instead, we look at the end-to-end experience. CX has a 360-degree view of both the company and the customer. Because of that unique viewpoint, customer experience is positioned to say whether something meets the requirement for the brand promise.

CX also deals with escalation when customers are affected by something significant. It’s really about the whole vision, not just one function. This is the main difference between customer experience and functions like marketing, product, and ops — there’s a clear boundary, but CX operates in the entirety of those functions as well.

You mentioned that CX influences the end-to-end experience. How do you leverage data to pinpoint friction in ways that go beyond surface-level voice of customer sentiment?

Sentiment is great to better understand the pain a user is feeling, but it doesn’t necessarily connect those findings to any action. The customer felt something, but what are we doing about it? I usually use three different approaches to understand what’s going on.

The first one is really easy — take a test drive of your own experience. This involves things like mystery shopping and other actions that help you understand what customers actually experience, not what you think they experience. There’s often a gap between what you think you’re giving them and what they’re actually experiencing.

Second, look at data. This includes operational behaviors like clicks, conversions, sales, visits, and more. These are useful for understanding where friction exists and where we have customers dropping off the experience.

Last, listen directly to customers, whether it be via calls or online reviews. When you hear directly from the customer, you can quickly identify emerging patterns — recurring friction points that people talk about. Of course, people may use different wording to describe what they’re frustrated by, but it all stems from the same pain point.

Translating signals into priorities

Once you have all that data, how do you translate it to the broader organization?

When you connect all those signals, it’s easier to translate them into clear priorities and decide if you want to redesign the journey or go through an ops change, for example. Looking at customer impact and frequency, you can decide if you want to take action or leave it alone.

Then, when it comes to business value, how does it impact the business? Are we losing sales? Are we losing retention? How much effort and time will it take to address those issues? How do you match the company’s priorities with the friction points you have identified? It’s important to always put these in the same frame as the company’s priorities and roadmap.

Essentially, the role of CX is to identify those friction points and then frame them in such a way that leaders can understand the implications of either addressing or delaying addressing the situation. We can make those intentional decisions so that they’re no longer reactive.

The leaders you’re presenting to certainly have their own perspective based on the area they’re running. What’s your approach to framing what needs to be addressed so that they can’t ignore it?

That’s where some of my sales background comes into play — you have to frame it in a way that’s appealing to the leaders. It has to resonate both financially and operationally. For example, you might ask, “What is it going to cost if we don’t move forward? What is the opportunity cost?” Or perhaps, “We’ve already put so much resourcing into this opportunity, why don’t we finish it?”

There are many different ways of framing the situation around churn, wasted spend, or missed growth. That way, the conversation is not about whether we should fix this, but rather how fast we can fix it. A leader on the receiving end of the conversation will need to understand how the recommendation is going to impact the bottom line.

In your experience scaling loyalty programs, what early signals tell you that solving a friction point will also unlock a new growth loop?

You can always go back to the basics, which, in the case of a loyalty program, are the customers. In the end, you want people to come back more often or spend more with you.

If those metrics keep growing, then you’re on the right track. But, if you see that they tend to stall, then there might be something you need to unlock. It might not be the program itself, it could be a friction point that you haven’t identified yet. Maybe the discount doesn’t apply correctly, for example. That’s why it’s always good to look at the data and then test your own experience. You can’t just say, “Oh, people don’t like this program anymore.” That’s probably not the case. Rather, there was a friction point that was preventing them from using the program.

The importance of intentional framing

Earlier, you mentioned the mystery shopper as a strategy to uncover or better understand friction points. Are there other methods that you leverage to help teams experience a particular friction themselves so that the priority becomes self-evident?

You have to be creative, which is not always easy. I’m fortunate that at CarParts, our CEO often takes a test drive on his own. It can be challenging to get busy executives to take the time to do this. I invite them to listening sessions that are catered for them. For example, we can create pre-create orders for them so they don’t have to go through every single part of the experience, just the one that we need them to care about.

Recently, I created two videos with AI — one showing the happy path and the other the not-so-happy path. I made it humorous because that’s often helpful for getting a point across. A large number of people experience the happy path, but there’s also a large number that experience the other path, and seeing that first-hand made an impact on the viewers. I believe they all remember that video because now, they’ve seen it with their own eyes. It’s really important to find different ways to put them in the customer’s shoes so they can understand what they feel when certain actions happen in the experience.

How do you escalate issues that may not look urgent on a dashboard, but are quietly eroding loyalty or repeat purchase, in a way that compels action?

Those situations can be difficult to handle, but it goes back to framing them in a way that reflects business impact. You need to translate those signals into a clear risk, and then show that there’s a decision to be made. My role is to frame the options and consequences clearly enough that a decision becomes unavoidable.

When I worked in sales, we were told not to present more than three products at a time to someone at a time or they would get confused. If you wanted to present a fourth, you had to take one out. The same thing applies here. You cannot just say, “Hey, this is broken, this doesn’t work. Oh, and the customer doesn’t like this and that,” and then just throw everything at them at once. You have to pick your battles carefully and frame your recommendations effectively.

You already worked through the prioritization, so when you present your recommendations, you’ve already landed on the friction point that you want to address. When you speak in terms of ROI, revenue, bottom line, AOV, or retention, all of a sudden, the doors swing wide open.

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 financial products are optimized for transactions, not human emotion. For many people, this transforms an already fraught topic into pure anxiety.

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

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

• How finserv companies can design for the “Cortisol UI“ by building trust and experiences that reduce anxiety before the transaction

• An experiment she ran for Discover’s 5% cashback program where test users collapsed under decision paralysis — proving that more choice can actually increase financial stress

• How she flipped Great Wolf Lodge’s booking model from 70% call center to 90% digital while enhancing the human experience

• And how Green Dot is navigating AI and agentic commerce without breaking the one thing banks can’t afford to lose: trust

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Customers said they wanted it. But in practice?

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

The program was eventually scrapped.

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

Links

• Melissa’s LinkedIn

• Green Dot Corporation

Chapters

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

What does LogRocket do?

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 our conversation, Anni shares how she reframes digital initiatives as revenue stories, not just feature roadmaps. She explains how to develop the right hypothesis, test the market without getting overly committed to a solution, anchor product conversations in margin and P&L impact, and recognize when a pilot is truly scalable. She also discusses the cultural conditions required inside large enterprises for innovation to generate durable growth and why product leaders must resist the urge to simply build.

Starting with the problem, not the solution

Throughout your career, you’ve turned digital initiatives into clear revenue stories. What’s the first question you insist your team answer before building a roadmap?

There’s an old saying that a well-defined problem is half solved. Once you’re clear on the problem, the direction starts to reveal itself. Early on, though, things aren’t always perfectly defined. Sometimes what looks like a problem is really just noise, so part of the job is separating real signals from assumptions.

For example, a few years ago we were developing an IoT solution when the market was heavily leaning toward subscription-based models — similar to how devices like the Apple Watch combine hardware, embedded software, and recurring services. As a manufacturer, we believed a subscription model could open a strong new revenue stream for us, so we formed that initial hypothesis and tested it with customers.

The feedback was clear: customers liked the solution, but they weren’t willing to pay even a small subscription fee. Instead of forcing the original model, we pivoted. We offered the solution at no cost, but in return gained access to anonymized usage data. That data allowed us to optimize our broader ecosystem, improve product performance, and ultimately create value in other revenue-generating areas.

So the key lesson for me is this: start with the problem, develop a hypothesis, test it quickly in the market, and stay flexible. The biggest mistake teams make is falling in love with the solution too early. If you stay committed to the problem instead, you’ll almost always find a path to real business value.

Building a culture that allows you to pivot

In parallel with testing, how important is stakeholder alignment inside a large enterprise?

It’s absolutely critical. In a large enterprise, you’re not operating as a standalone entrepreneur — you’re working within an interconnected system, so progress depends heavily on alignment.

That’s why I say culture matters. You need an environment that supports testing, learning, and pivoting — one that allows teams to experiment, invest, sometimes fail, and then try again without penalty. When stakeholders share that mindset, innovation moves much faster and with far less friction. In my experience, that combination of leadership alignment and a test-and-learn culture is what really enables teams to succeed at scale.

Reframing digital from cost center to revenue enabler

Many enterprises still frame digital as a cost-saving lever. How do you get executives to see it as more than just efficiency?

Across my career in marketing, digital, and IT, one recurring challenge has been the tendency to frame technology teams purely as cost centers; as overhead required to run the business rather than as strategic enablers.

Now, it’s perfectly fine if digital isn’t always a standalone revenue engine. In many industries, especially manufacturing, the core product is still physical. But the real opportunity is to position digital capabilities in terms of the business outcomes they enable. A simple way to do that is to ask: What happens if this capability doesn’t exist? Does revenue drop? Does customer experience suffer? Does the brand take a hit?

Once you translate those impacts into revenue, margin, or P&L terms, the conversation changes. Now you’re able to say, “This is a partnership. We’re going to create digital capabilities that are going to help the business run better, run efficiently, run smoother — but it’s all anchored in revenue.”

That mindset shift is what gives technology teams a true seat at the table.

Testing early to build credibility

Can you share an example of creating a revenue story that was credible to executives early on?

Several years ago, online purchasing was quickly becoming the norm. Companies like Carvana were already proving that customers were willing to buy even big-ticket items online, and globally we were seeing markets — especially in Asia — move even faster. In places like China and Japan, brands weren’t just selling online; they were selling directly through social platforms such as WhatsApp, where customers could discover, order, and pay within the same channel.

When we assessed where we stood, it was clear we were a few steps behind, so we focused on catching up quickly. We piloted a small-scale digital commerce initiative with a handful of partners and started seeing incremental revenue almost immediately. Customers who “never knew we existed now knew that we were out there,” and we also began to shift the perception that our brand was “premium and unaffordable” to one that was accessible and on par price wise with other brands.

That gave us a credible executive story. We were able to go back to stakeholders and say, “Here’s the revenue generated in just one year, and this revenue wouldn’t have existed if the platform hadn’t been in place because these customers didn’t even know us.” Once leaders could clearly see the implemented revenue tied directly to the capability, scaling the model to other regions became a much easier decision.

Partnerships as accelerators

Where have partnerships helped you turn internal innovation into scalable revenue faster than you could have alone?

Large companies naturally tend to move slower. There’s governance, bureaucracy, and some level of “red tape,” and much of that exists for the right reasons — you want to protect the core business and avoid unnecessary risk. But partnerships can create the kind of ecosystem where new technology has room to thrive and grow much faster than it could internally.

In one instance, we had developed a strong homegrown virtual software solution that we believed could eventually evolve into a digital twin capability. The core technology was solid, but we didn’t yet have the internal resources to build the advanced analytics engine needed to fully unlock its value. By forming the right partnership, we created an avenue for the solution to mature into something with real commercial potential, ultimately opening up a new revenue stream for the company while also creating value for our partner.

We called those “triple wins.” The company benefits, the partner benefits, and customers receive a more advanced solution. When you build that kind of ecosystem, innovation doesn’t just move forward — it scales, and everything thrives and grows.

When a pilot is truly scalable

How do you know when something is scalable and not just a successful pilot?

The first step is simple: talk to the customers. Customer insights are incredibly valuable because they tell you whether the solution is solving a real, repeatable problem — or just performing well in a controlled pilot. And the second step is just as important: book some sales.

In one situation, we considered partnering with a startup but ultimately decided to bring the capability in-house and build the product ourselves. Once we launched it, we took it directly to market and secured actual customer sales. At that point, we had both the insights and the revenue signals, and that told us we were already halfway there in proving scalability.

Another key lesson is not to over-engineer too early. Even in its early, nascent form — without all the bells and whistles — if the product can demonstrate real value through paying customers, you now have the confidence to scale and invest further. Then you can say, “OK, now I know I can add additional features and unlock even more value from this product.”

Ultimately, scalability comes down to financial proof points. You don’t want to launch something overly complex or expensive only to discover it doesn’t generate revenue. The commercial dynamics have to work first; once they do, scaling becomes a much more predictable decision.

What challenges are often underestimated in early testing?

Building the technology is certainly difficult, and often expensive, but the really hard part is changing customer behavior. Humans are creatures of habit. We tend to stick with what we already know, even when it’s inefficient, because over time we create workarounds and mental shortcuts that become part of how we operate every day. We don’t always look for new ways to solve those problems.

That’s why, when you’re launching new products — especially ones customers directly interact with — it’s critical to design experiences that are truly intuitive. If a solution isn’t easy to understand and use, adoption simply won’t happen. And if adoption doesn’t happen, revenue doesn’t happen. This is where design thinking becomes so important in the digital world: the goal is to create products that feel natural from the very first interaction.

Another challenge comes after the pilot phase. Launching something once is one thing; operationalizing recurring revenue is much harder. Inside large organizations, you have to work within established processes while still operating in a lean, agile way. If the new offering inherits too much organizational overhead, the economics quickly become difficult to sustain.

So success isn’t just about building the right technology — it’s about driving behavior change through intuitive design and ensuring the operating model can support scalable, recurring revenue over time.

Knowing when not to build

How do you decide whether to expand a product with more features or keep it tightly scoped?

In the product world, one thing we try to do consistently is anchor everything in business value. Upfront, we establish the margin and revenue potential the project can realistically deliver. Then, for every incremental feature, we ask: What does this cost, and what’s the return? How does that value actually show up on the P&L?

There’s always a trade-off conversation with stakeholders. People naturally gravitate toward the “shiny new object.” New platforms and added functionality are exciting. But before adding all the bells and whistles, we pause and ask, How is this feature going to generate value? If we can’t clearly tie it back to revenue, margin, or a defined business outcome, it’s probably not the right investment — at least not yet.

It takes discipline. It’s much easier to build something new and launch it than it is to continually pressure-test whether each enhancement drives measurable impact. That’s why ongoing iteration, tough value conversations, and strong OKRs are so important — they keep the product anchored in outcomes, not just output.

If you were advising a product leader trying to create a new revenue story inside a legacy enterprise, what would you tell them to stop doing?

There’s a good book called Escaping the Build Trap, and the core idea resonates deeply: product teams love to build. We’re wired to create. So my advice would actually be — stop building, at least for a moment.

Instead, start with business value and growth. Especially now, with generative AI accelerating development cycles, you can build faster and cheaper than ever before. But speed doesn’t matter if you’re building the wrong thing.

Anchor everything in three questions: Does the customer truly want it? Will the business benefit from it? And how does it measurably help the company grow?

Building will come. The real discipline is making sure you’re building the right thing.

One approach I’ve found very effective is running structured workshops with business leaders to guide how the conversation happens. There are many frameworks you can use, but I lean heavily on design thinking because it helps break decisions into three simple dimensions: desirability, feasibility, and viability.

• Desirability: Do customers actually want this?

• Feasibility: Can we build it — do we have the infrastructure, talent, and resources?

• Viability: Can we make money from it?

When those three intersect, that’s the real value stream — that’s what you want to focus on.

How do you make stakeholder conversations more productive?

Often, stakeholders come in trying to prescribe the technology. They’ll say, “Build this platform and make it work exactly like this.” But when you shift the conversation and ask, “Help me understand what problem we’re trying to solve, who we’re solving it for, and why this capability matters,” you begin to uncover the real underlying needs.

Using a simple framework like this keeps discussions grounded in outcomes. It moves the conversation away from features and toward value, which ultimately makes stakeholder alignment much more productive.

Bringing a business lens to product leadership

How has your unconventional career path shaped the way you think about leading product teams?

I have a non-traditional product background. I started out in IT as a Six Sigma Black Belt and later moved into an innovation accelerator, where the focus was on core and adjacent innovation and developing go-to-market strategies. The goal was always the same: stay lean while driving top-line growth or improving the bottom line.

Those experiences and frameworks really shaped how I think about product and technology. It’s never just about building something — it’s about creating value and ensuring what you build makes a measurable impact. That’s why I love product management so much — it sits at the intersection of strategy, innovation, and execution, and it’s all about driving real business results.

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 our conversation, Sam talks about what it really means to design for trust and impact in a highly regulated industry like healthcare. He talks about how constraints can sharpen — rather than limit — imagination and why friction alone doesn’t necessarily equate to a negative user experience. Sam also shares signals he looks for that can indicate when an organization is truly ready for digital transformation.

Regulation and designing within constraints

How did your early career in academia change the way you frame problems, ask questions, and evaluate success in digital experiences?

It was quite an adjustment. In academia, you typically walk into a meeting prepared for an intellectual battle, so to speak. In business, that’s often not the case. There’s much more collaboration. Often, the right solution emerges through the discussion itself. That’s very different from walking into a meeting with the solution already formed in your mind.

I had to adjust the way I frame problems. In academia, I might come into a meeting and say, “I’ve thought this through, and here’s what I think we should do.” In a business setting, that approach can be counterproductive — and even overwhelming — for people who want to actively participate in the discussion.

You’ve said that the most enduring creations come from working within constraints instead of escaping them. In large, highly regulated organizations, such as healthcare, is there room for imagination in design or is it about working within constraints?

Some of the designers we hire come from a tech or startup background. They’re very imaginative, and they have wonderful portfolios — we’re excited to bring them on board. But they can sometimes get frustrated with the slower pace of work in healthcare, especially given the number of reviews we have to undergo. Securing reviews from multiple stakeholders can feel like a constraint to some. But often, stakeholders like doctors bring insights into the patient experience that we, as designers, simply don’t have. Their “constraints” can often improve the experience, as they understand what patients would find uncomfortable or unhelpful.

We’ve had to adjust how we evaluate what great design talent looks like in a highly regulated environment. There’s simply less visual freedom in healthcare than in non-regulated industries. We have to comply with a wide range of laws and regulations while still designing for user trust, and not everyone has the patience for that kind of work. Something that’s highly imaginative in healthcare may not look as visually striking or creative when compared to consumer products in the tech industry.

So, how do you decide where it’s appropriate to lean into imagination? What does that look like in practice?

A lot of healthcare design work is rooted in discipline and standardization, especially in a larger company. We recognize that we’re working as a corporate author. We don’t want a design or piece of content made by one person to stand out from something another person created. We’re working for the same organization, and we need to speak from a consistent company voice.

Another way of thinking about it is: how do we come together to create a shared, collective imagination of who we are as a company? That means going deep on brand presence and personality and truly making it your own. There’s still imagination at the individual level — it’s about getting comfortable with the persona you’re stepping into as a designer and then delivering consistently on that corporate brand message and brand persona.

Readiness for digital transformation

A company may think it wants a digital or product experience transformation, without fully understanding what that entails. How do you determine if a company is actually ready for that step?

To truly deliver on digital transformation, you have to be prepared on multiple levels. In one of our transformation journeys, we realized that our platforms, systems, and processes were less mature than we thought. And while the transformation is, by definition, changing those things, you still need to reach a certain level of readiness first. You can’t do everything all at once.

We had to migrate to a more stable state first before we could move toward what we ultimately wanted to build. We spent the first two years focused on that work so we could eventually take the leap. You can’t go straight from complete chaos to an ideal future state — there’s always an interim phase. That’s a critical factor in determining whether an organization is truly ready for a digital transformation. You can’t do that work while you’re constantly putting out fires. In practice, that means you can’t pause the basic business while the transformation is underway.

What signals do you look for to tell if a company is in that stabilization phase?

The biggest factor is honesty. To take that next leap, an org has to accept where it’s at and have a sober understanding of its own maturity. Some companies overestimate their capabilities and aren’t willing to fully reckon with the technical debt they’ve accumulated. If you don’t go in with a very honest assessment of where things stand, as well as what limitations may exist, you won’t be prepared.

When constraints improve the experience

Do you have an example you could share of a time when a deep technical constraint directly improved the digital experience?

When I was at Kaiser Permanente, we were always trying to be faster and more efficient, but we often felt constrained. One area where we couldn’t move as quickly as other companies was identity management and entitlement — verifying who the customer is when we interact with them. Many people point to the financial services industry as the gold standard for identity management, but we felt that the bar was actually higher in healthcare. Trust plays an enormous role in the work that we do.

In financial services, if we get your identity wrong and you lose some money, we can give you that money back. If we get your identity wrong in healthcare, we might give you the wrong advice, the wrong medicine, or reveal sensitive information. That can instantly shatter a user’s trust. We can’t give you your privacy — or your health — back.

At Kaiser Permanente, we were working on optimizing account validation. At first, we thought the goal was to move as fast as possible, but we later realized that speed alone was not actually what users wanted. Rather, they wanted validation that felt fast — but within cultural expectations. For example, if you ask your bank for a dollar and they give it to you immediately, that feels right. But if you transfer $1 million and it happens instantly, you’d be worried. In that situation, you expect friction and additional validation.

Our account creation process felt a bit more clunky and awkward than we wanted, and we spent a lot of time trying to figure out how to make it simpler. To create an account that would provide access to medical data, we had to first definitively verify the user’s identity. So, we asked multiple questions that went far beyond collecting a name and email. We even offered the option to request verification via mailed postcard with password — even in this digital age. The process was complicated, but the users we surveyed appreciated these precautions. We realized that the friction that slowed down the validation process actually helped users feel secure and confident that they were taking the right steps. So, what we originally thought was “too slow” ended up being a good thing.

How do you measure the success of digital experience projects? Are there certain metrics that you look at?

Ideally, in healthcare, we’d measure success with our members’ health outcomes. The real challenge, though, is attribution. How can we connect a digital action someone takes today to their health outcomes, especially when the impact may not be visible for 10–15 years?

At Kaiser Permanente, we created personal action plans — things like reminders for mammograms or colonoscopies based on clinical guidelines, statistics, and a member’s demographics. These screens won’t prevent cancer, but they can detect it early and improve survivability. But how do you attribute that impact years down the line? You end up relying on interim measures like adherence, uptake, and engagement. You extrapolate impact from those signals, but it’s hard to predict how today’s actions will affect someone’s health 20 years from now.

The overlooked side of digital transformation

From your vantage point, is there something that enterprises often misunderstand about digital transformation even after investing in it for many years?

It’s less about misunderstanding and more about prioritization. Most enterprises treat the cost of digital transformation primarily as a technology investment. They focus on the expense of migrations, new flows, new UI, and similar work, but they tend to underinvest in people and processes.

A lot of support is required after the experience itself has transformed. The customer service representatives, whom people rely on when they call in with questions or errors, need to be properly trained. The processes, routing, and support models need to be updated to reflect the new experience.

Inevitably, the platform portion of the digital transformation gets funded, while the people and processes do not. Change management, communication, and retraining are all areas that typically receive less attention. I think that’s what holds organizations back from realizing the full value of digital transformations. They see the platform work as “done,” but they don’t continue investing in the people and processes required to make it successful.

How are you seeing AI impact the digital experience space?

AI is going to be transformative to product and design, and I think this year may be a turning point. In the past, AI tools felt more like toys. They could come up with impressive-looking image generations, but they couldn’t adopt the brand standards and design systems required by large Fortune 100 companies. Today, these tools are much more mature. They can ingest a design system, understand brand standards, and even generate outputs that are consistent with what brands had delivered before.

When it comes to appropriate use, leaders need to know where AI replaces work and where it augments it. There’s a lot of conversation about replacement, and that’s where a lot of fear comes from — especially from individual contributors who worry about their roles being automated. Right now, we’re seeing the most value in augmentation — making people more effective and freeing them up for strategic and more interesting work.

At Centene now, we have several efforts underway where we’re using AI technologies not to replace people, but to augment their skills and to make their jobs easier. So far, the results have been quite effective.

So, given the heightened presence of AI, what skills do you feel have become more important for digital experience folks who are earlier in their careers?

Early-career workers, especially in design, are mostly hired for their hard skill sets. They spend their days heads-down in tools like Sketch or Figma, and they can increasingly leverage AI to make themselves more efficient at that work. Later in their careers, designers who are true partners in the business need to understand how the business actually works and think critically about what’s really needed.

A product manager who owned search once came to me and said, “Sam, can you help me think about how we can enhance the search experience so we can get more searches?” For her, success was measured by the number of searches performed. But from a human perspective, no one wants to search — you search because you’re confused or you haven’t found what you need. In that case, wouldn’t a better success metric be a reduction in the number of searches?

That shift in thinking is what comes with time and maturity. Later-career leaders need to focus less on optimizing features and more on essential human and business needs. That’s the difference between execution and leadership.

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.

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

In this episode, Rahul shares:

• Amazon’s “customer backwards” approach - and how he used it to unlock half a billion dollars of value on the Amazon homepage

• The secret to product adoption: leverage existing customer habits to unlock new opportunities

• And how Amazon and Google raised the bar for digital experiences so high that now every other product pays the price

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

Rahul shared a simple but powerful insight:

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

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

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

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

Rahul explains the difference:

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

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

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

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

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

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

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

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

The team introduced:

• Common measurement across perception, habit, and economic impact

• Exposure caps to prevent “hero blindness”

• Governance to prevent any single team from monopolizing the placement

They also focused on adoption — not just first clicks.

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

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

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

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

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

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

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

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

Links

Rahul’s LinkedIn

Chapters

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

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 conversation, Sean breaks down how product teams can re-engage users by adding new functionality that collapses time to value. He shares how to distinguish KPIs from outcomes that actually drive the business, how misaligned funnels can hide massive opportunity, and why the most effective re-engagement often happens when users are given immediate access — not just approval. Sean also explores the realities of competing in crowded checkout environments, designing frictionless experiences in borrowed UI, and shipping quickly in highly regulated systems without losing sight of the customer.

Sean is the author ofAutonomy Lost: The Silent Crisis in Product Management, which explores how product teams can reclaim ownership, clarity, and impact in complex organizations.

Defining engagement that actually drives the business

Can you give us a high-level overview of what KPIs, OKRs, and a North Star metric look like in your product ecosystem?

When I think about KPIs, I actually start at the very beginning. At a high level, Shop Your Way lives at the intersection of a few different markets. You have BNPL, express payment, credit, and rewards solutions, and we’re trying to offer prime credit at fintech speed.

There are two things I look at with KPIs and OKRs. OKRs are the outcomes the business needs to see and how it ultimately makes money. KPIs are the signals that tell us how the app is behaving from a user engagement standpoint.

We have a very narrow window at checkout to educate users. There’s a lot going on in that moment. A KPI might tell me that someone saw something or clicked something, but an OKR is about how many people applied, got a card, and actually used it — because that’s how we make money.

None of this matters if the business doesn’t make money. For most companies, clicks cost money, so we measure them. KPIs tell you how the system behaves. OKRs tell you whether the business is winning. Our North Star is collapsing time to value: you see it, you click it, you become a cardholder, and you start using the card.

What’s your process for identifying that North Star?

It’s very much driven by how the business makes money. Engagement and member statistics are important because they show trends in usage from our most loyal customers, but the business ultimately thrives or dies on someone seeing an opportunity to apply and actually getting the card.

There are two sides to that. My side is more card acquisition. My job is to get your attention and get you a credit card. Then your lifetime value to me is how often I can get you to pull that card out of your wallet, whether that’s a digital card through instant provisioning and tap-to-pay, or when you eventually get the physical card.

How do you help teams distinguish between interesting KPIs and the ones that actually drive business outcomes?

KPIs can be separated into what’s vocally interesting and what’s globally impactful.

You might have someone in marketing who’s very interested in how often people are exploring the experience, learning about the product, or reviewing terms and conditions. But what really matters is whether someone makes it through the entire funnel.

You always start from the business outcome and work backward. Any KPI that meaningfully increases the number of people who even get a chance to convert usually creates more leverage than squeezing incremental gains at the very bottom of the funnel.

When metrics lie: finding the real opportunity

Can you give an example of when KPIs and OKRs were misaligned?

This is a real example, but I’ll keep it general. One of the most impactful moments for us was realizing we weren’t fully connecting the dots between KPIs and the actual magnitude of the business outcomes.

We were starting the story in the wrong place. Our analytics stack began with users landing on our homepage, which meant we only knew about people who had already clicked. That became our assumed addressable audience. From there, we knew our conversion from landing to applying for a credit card was around 60%, which is excellent in the credit card industry.

Because of that, we became very focused on how to capture the remaining 40%. But when we took a step back, we realized impression volume was massive. Our click-through rate was around half a percent. To be competitive with a credit product, you want checkout conversion around one to one and a half percent, which means your click-through rate needs to be closer to two to five percent.

Conversion is bounded. If you’re at 60%, you can only get to 100. Even in a best-case scenario, you’re looking at maybe a 35% increase. Meanwhile, the upside from increasing click-through was enormous. Improving that number could drive tens of thousands of new applicants, compared to only a few thousand from conversion gains.

That’s when we realized it wasn’t that there was a hole in the net — it was that we didn’t realize how wide the net could be. Conversion felt loud and obvious, but click-through was the real problem. Checkout is a crowded space, and when you connect the right user with the right value proposition in that moment, that’s where you can really differentiate.

How did you reframe that conversation with your team?

We used a visualization. The funnel started very narrow with the number of people who were approved and got a card. Then it widened to include people who applied, whether they were approved or declined. It widened again to include people who completed the first login of the application.

From there, it widened to the people landing on our homepage. And at the very top, it showed impressions.

That top section was massive; it looked like the Earth next to the sun. You could see this enormous population of users who were there but never entering the funnel. We had been focused on keeping people once we had them, instead of realizing that for every one user we captured, there were tens of thousands more we were never reaching.

Winning back users at checkout with new functionality

In a crowded checkout space, how do you translate acquisition OKRs into something actionable?

There’s a lot of economics that go into building a credit card. Some acquisition costs can be absorbed by merchants, some by the credit card company, and sometimes by an intermediary offering membership or co-branded credit. Ultimately, you need to find the balance between how much value you can give the consumer based on what they’re buying while still remaining profitable.

When you’re competing at checkout with PayPal, Apple Pay, Google Pay, and BNPL providers like Affirm, Klarna, and Afterpay, they all have instant brand recognition. Most people have used them recently, and they’re comfortable with them. But those products are primarily about simplifying payment.

If we can offer a streamlined way to access credit, present a compelling offer, and move through checkout without friction, that’s how we compete. For a big-ticket purchase like a $1,500 sofa, extended financing or a stronger credit value proposition can be far more compelling than a simple pay-in-four option.

Where we stand out is accessibility. Many regional or middle-market retailers don’t have access to prime credit. By offering an alternative with a stronger value proposition than BNPL, and by provisioning the card instantly, you can win at checkout.

How do BNPL and express pay shape user expectations?

BNPL is an intrinsic competitor to credit, and it has disrupted the space significantly.

Younger consumers in particular have been conditioned by express pay and BNPL experiences. They expect speed, simplicity, and immediate access. When you build your roadmap, you have to account for that conditioning. People expect checkout to be fast, intuitive, and nearly effortless.

Designing frictionless experiences in borrowed UI

What are the unique challenges of operating on third-party checkout pages?

You don’t control the space — you rent it.

You need something generic enough to scale across partners, but natural enough to fit into their checkout experience. Consumers are conditioned to ignore anything that looks like a third-party ad. If it feels like an ad, no one touches it. But if it’s too custom, you lose speed and scalability.

So you operate on a very fine line. You have to move quickly while still looking native. That constraint forces discipline and creativity at the same time. At the end of the day, they own the UI. You’re borrowing attention in a very crowded space.

How does observing real behavior change how you think about engagement?

Traditional analytics tools do a good job of telling you what happens after someone clicks. They show you what people engage with, where they linger, and how quickly they move through pages. But watching users in real time is completely different.

It’s like the difference between reviewing a report and watching CCTV footage. You can interview users, which is critical, but watching real behavior lets you see hesitation, pauses, and breakdowns in the experience. That’s how you build a truly customer-centric product team.

Collapsing time to value with functionality

How does functionality like instant provisioning or passwordless flows change outcomes?

Approval isn’t the same thing as value. Access is.

If someone gets approved for a card but can’t use it easily, the experience breaks down immediately. If you ask them to type in card numbers or jump through extra steps, you’re going to lose them.

We’re competing in an environment where people are already logged in, already trusted, and already paying in one click. Asking users to do anything more than that just isn’t going to work.

You also lose trust. If I go to checkout today and it asks me to enter card information without Apple Pay or Google Pay, that feels outdated. Those experiences have become the baseline.

When you build software, you’re not just competing with direct competitors. You’re competing with the best experiences people use every day — Netflix, Instagram, Airbnb. If your experience isn’t intuitive, users won’t come back.

What signals tell you that time to value has actually collapsed?

You need to know exactly where users drop off. Which fields cause hesitation? Where do people stop and think?

Social security numbers are a big one. Nobody likes entering them. Field freezing, where users pause and sit, is another strong signal.

Pre-qualification makes a massive difference. Nobody likes getting declined. When you allow pre-qualification and clearly communicate that someone’s credit won’t be impacted, you see major lifts in engagement and meaningful reductions in drop-off.

Operating under regulation without losing velocity

What have you learned about building products in regulated environments?

Credit cards are heavily regulated. There are rules that determine what you can and can’t say and how much you need to disclose. BNPL and express pay providers don’t deal with all of those constraints, which means you have to build a runway.

As a product person, you need to understand the regulations as well as the customer. Your job is to advocate for the customer while working within legal boundaries. That means doing the work upfront, building systems that can evolve, and minimizing rework for development teams.

Regulation isn’t friction — it’s the cost of durability and consumer safety.

How do you position your product relative to infrastructure players?

We’re a platform with a prime credit offering. We’re not the creditor ourselves; we distribute a co-branded card on a partner bank’s behalf.

That distinction matters because we’re responsible for the end-to-end member experience. We’re not just facilitating payment — we’re accountable for access, trust, and ongoing usage.

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 Maryam Ashoori, VP of Product and Engineering at IBM’s Watsonx platform.

With a background that includes 2 master's degrees in AI, a PhD in Systems Design Engineering, and named on over 30 patents at IBM, she’s been on the bleeding edge for over a decade. Currently leading the charge on Agentic AI and AI Governance at IBM, Maryam is a bridge between the theoretical frontier of AI and the messy reality of enterprise deployment.

In this episode, Maryam shares:

• Why AI has been stuck in pilot purgatory for longer than expected, and what you need to do today for a successful enterprise deployment

• Shenanigans on the “biggest, best model” crowd, and why often a smaller, more focused tool is the right choice

• How to build an agnostic architecture that can handle the realities of an AI world where models advance faster than anybody can keep up

1. From AI as experimental “toys” to enterprise products (3:30)

When ChatGPT went mainstream, companies rushed to fulfill their boards’ demands for an “AI plan” — whatever that meant. But few companies started with the right question.

“They basically picked an application, a solution looking for a problem that it solves versus it has to be the way around: how can I benefit from this technology?”

Why this matters: AI excitement doesn’t equal value. The shift from experimentation to production starts with defining the business problem, not retrofitting AI onto your roadmap.

2. Who’s accountable when an agent goes rogue? (7:10)

Where enterprises previously had a FOMO (fear of missing out) if they didn’t have an AI strategy, now they have a fear of messing up. They’re worried about being on the front page of the news for AI mishaps.

Maryam shares a question her client advisory board raised. It’s the one product leaders should be obsessing over:

“Something goes wrong in front of the users. Who is accountable here?”

Agents introduce autonomy, which introduces ambiguity. And ambiguity introduces risk.

Before shipping AI agents, leaders need clarity around accountability, guardrails, and governance workflows.

3. Latency will kill your AI product faster than cost (20:40)

It’s tempting to obsess over model cost. But Maryam reframes the conversation such that cost is a signal, and latency is the real user killer.

She shared an example of an insurance chatbot that added LLMs behind the scenes. The new response time?

40 seconds.

It was practically unusable.

Why this matters: No customer wants to wait 40 seconds for a chatbot response. Optimizing for compute isn’t just about margin; it’s about user experience, energy consumption, and architectural design.

4. The role of the product manager is changing (16:20)

Maryam describes how the traditional PM → PRD → engineer workflow is already blurring:

“The product manager with AI assisted coding, they code, they build. They have an army of agents that is at the prototype level now, but is gonna keep getting better every day.”

With that shift comes a new mandate:

“We need to do more thinking than doing because doing, we can pair it up with AI.”

Takeaway: The next generation of PMs won’t just write PRDs. They’ll design for agents, think in abstractions, and orchestrate systems.

Final thoughts

If you’re a product leader building with AI today, the question isn’t:

“Which model is best?”

It’s:

“Is our system designed to evolve?”

Links

• Maryam’s LinkedIn

• IBM

Resources

• Reinventing SaaS: Zuora’s AI Transformation | Karthik Chakkarapani and Shakir Karim (Zuora)

• Linear’s Secret to Building Powerful AI Products | Nan Yu, Head of Product (Linear)

Chapters

00:00 Introduction
02:27 Maryam's product and AI journey
04:08 AI pilots, ROI, and the rise of agents
08:01 Production fears, security, and accountability
10:49 Agent reliability
16:35 AI PMs & observability: Measuring outcomes in non-deterministic agent workflows
20:12 Why compute optimization matters
24:49 IBM's model-agnostic architecture
29:14 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.

In this conversation, Dani shares what drew her to Alamo’s alternative-style, creative DNA, how she approached digital transformation under real constraints, and why culture — psychological safety, team autonomy, and healthy feedback loops — is the foundation for sustainable execution. She also unpacks how Agile (done without dogma) can function as a human system, not just a delivery system.

Bringing a culture-first lens to transformation

What drew you to Alamo Drafthouse and what did you sense about the humans there before you ever touched the tech stack?

Two things drew me. One, I have been a long-since-its-inception-term guest at Alamo. I’ve been going here since the first location on Colorado Street when it looked like a little abandoned building.

I have this false memory — and I know that it is false — but I think it paints a good picture of what Alamo was back then. I remember walking inside this concrete building with ragtag rows of cinema seats, and the founder Tim League serving my parents a beer, and everyone running around frantically. That’s real.

The false memory is that it felt so slapped together when it opened that I remember there was a bedsheet as a screen. And that’s not true at all, but I’ve implanted that image because it speaks to how scrappy it was to make this dream come alive.So the first reason for being drawn to Alamo was because I was a part of that. When Alamo randomly reached out three and a half years ago, it was an immediate, “Yes, I want to talk to you.”

Through my long interview process, I got to meet tons of humans from all over. Every conversation was a round-robin with lots of folks, and everyone just got to chime in and talk and ask questions. It was like this collaborative-interview experience.

After I accepted the role and I came here, I got to see that collaboration in action. I was extremely taken with how passionate this entire company is. Never have I worked at a company that is filled with creatives, and that creativity is infectious. Once I came through the door, I was like, “Oh, my gosh, this place is special, and it deserves cultivation.”

You were CTO at your previous company and were brought in to Alamo as director of engineering. How did you strike the balance between the right career move and right cultural fit?

My interview process was three months long. That gave me a lot of time to think and reflect about whether or not this was the right role for me. It was a very difficult decision leaving where I was, because I had been there six or seven years. I’d built a culture and friends — some I consider family. I cried for a week leaving that place.

I remember the moment where I made the decision. I came to meet everyone in-person. I got to go to the Alamo headquarters, the Baker Building. It’s an old school that was built in 1905.

The entire experience of driving up to this building, walking through the front doors, seeing the hodgepodge of artifacts everywhere, photos along the wall of all these moments in Alamo’s history, walking past these scary wax statues — it was surreal.

It was several hours of conversation. When I left that building, I had this overwhelming feeling that I knew that if I did not accept this role, even though it was a gamble and taking a lower position, I would regret it if I turned it down.

Modernizing under real constraints

You came in post-COVID with a mandate to modernize, but not the millions typically required to do it. How did that constraint shape your digital transformation strategy?

After COVID, the company was healing or trying to heal. It definitely was a time of healing. There was real interest in investing in technology, but there were a lot of questions. Afterwards, you’re already super lean because you’ve restructured everything, and everyone’s very focused on “is this the right thing for our business,” asking that question on every single initiative.

My approach was to first spend time getting to know how the company functions, how the business operates, what’s most important to the business. It was very obvious that it’s the venues. It’s the operations teams. It’s what makes the venues run.

When I spent time in the venues, it was fascinating to watch. When you see all the venue humans and teammates running around to make a day at Alamo happen, it ends up looking like a hive mind or an organism. The entire place functions. The servers and the staff in the kitchen — nobody talks to each other. They’re just doing it, and they’re making it happen.

Alamo does the thing that they say not to do — the cardinal rule of, when you open up a restaurant business, never seat everyone at once. So what does Alamo do? We put on movies and we seat everyone at once. So it’s waves of intensity as every movie starts, and the pre-show starts, and the orders start coming in.

When I stepped back and I looked at technology and how it needed to transform, where we would invest, the most important thing was very obvious: focus on the venues and ensure that any technology we change or inject does not disrupt that organism. It needs to enhance it.

So, help the venues now with everything that we do while also, in the background, work on subsystems and foundation. Spend the first couple of years focusing on the venues, and then we’ll also replace the website architecture.

How many venues are there?

Forty-four.

In the beginning of that transformation, how did you assess what needed to be fixed first?

That was easier for me because my background is in web development and cloud infrastructure, and architecture. My entire career has been on that side of the world. Naturally, I gravitated to: “Oh, I know this like the back of my hand. Oh, we’re using Angular 1.X. That is a problem.”

The web app experience and the native app experience are problematic if the frameworks that we use are antiquated and not flexible or extensible. They’re no longer secure because they’re several versions behind.

That story wasn’t just the web and app. It was pretty much all over the org in various permutations. In our venues, we were using an old version of Aloha in many cases. I think it’s pretty common for a lot of businesses post-pandemic: lack of investment leading up to it, then putting everything on pause.

Culture signals and psychological safety

When you step into an organization, what are the cultural signals that you look for?

The first thing I always look for: do people ask questions in meetings? Do they ask them in large meetings? Do they admit when they don’t know something in a public setting? Do I observe pushback? Are people challenging others in a healthy way?

I pay close attention to who speaks first in meetings, who stays quiet, and try to understand why. I also look at how failure is treated, especially in the technology org. I look at the mediums we use for communication and what the tone is. How do other leaders behave? Do they own mistakes or do they deflect them?

I don’t know that I have a list when I come into a company. It’s more that I’m sitting in meetings and observing to understand culture. Once I have a good grasp, I’ll start to dig in more and ask more questions.

I imagine bubbles around humans — how much influence they have and exert over their workplace or their team. Some people have big bubbles and some people have little bubbles. There’s no right or wrong. It can vary day-to-day. My role is to help those bubbles grow for those that want it, or at least feel happy and content and in control of their bubble and their sphere.

Culture always comes first. Psychological safety comes first: ensuring everyone feels comfortable speaking up, challenging each other, being radically candid with one another. If they’re not, that’s a big red flag, and then I dig in and work closely with people or teams to understand why.

Agile as a human system

What does Agile look like inside of Alamo today, and why is it so important from a human standpoint?

My team is so sick of me saying the word “Agile.” They have a dollar jar for every time I use a buzzword like that.

The focus, for me, is to not be dogmatic. Agile has gotten a bad rap, and you see countless posts like, “Agile is dead.” For me, they’re missing the point. It’s not scrum. It’s not Kanban. It’s not SAFe. It’s about building a process and embracing iteration that works for your organization. Not just iteration, but iteration and reflection. That’s the key.

At Alamo, it’s intentionally not dogmatic. We focus on principles, not necessarily process. We have multiple teams, and each team has a slightly different process. You could cherry-pick something and go, “Well, this team does Scrum,” but it’s not actual textbook Scrum. It’s some organic version.

Real retrospectives are extremely important to me. Every team should be talking about what’s not working well, what’s working well, and appreciating each other at some regular cycle. We embrace that roadmaps change. Alamo is very dynamic. This industry is very dynamic. We have to maintain an ability to change and agency for teams to make decisions and chase that thing without wading through tiers of approval.

One thing I’ll add: retrospectives and reflection tie into spheres of influence. Every iteration and every time they do a retrospective, everyone on a team is enabled and empowered to make a change to the process.

They may start as textbook Scrum on day one, but on day 365, through iterations worth of change, they have a completely different process that is wholly theirs. They all contribute and create it themselves. That’s the most important part.

Autonomy, morale, and a concrete example

How does giving engineers and product teams real say over their work change the quality of the work they do?

In terms of quality, I believe with my whole heart that morale equals quality. Happy and healthy humans equal quality. When I look at what an organization needs, I gravitate towards: are the humans happy and healthy? If not, how do we build something such that they’re happy and healthy?

People care more when they’re happy and healthy. There’s better decisions. When there is stress and crunch time, there’s more of a can-do, we-can-climb-the-mountain attitude that doesn’t exist if you don’t have happy and healthy humans and good morale.

Negative examples are fear and top-down pressure and rushed decisions. No company is impervious to that. What matters is not the moments but overall how it’s going, because we’re humans. Humans are messy.

Can you share a real-world example where the culture shaped the thing that was being built?

During our Toast migration, we moved from Aloha to Toast last year. We had an old version of Aloha. It wasn’t meeting our needs. We needed something more extensible and flexible and cloud-based, and we chose to go with Toast.

We started the project fully Agile. We broke it down into sprints. We planned iteratively and focused on learning as we went. Midway through the planning phase, the team pushed back. Honestly, I was surprised. I sometimes don’t like getting pushback unless they’re right, because I want to be right. I feel strongly: “This is the way.”

They were like, “Absolutely no, Dani.” They said, “For venue rollouts, what we need is something closer to waterfall.” The word “waterfall” is triggering for me. I get very “Ugh” when I hear it. But what they explained landed: 90 days out, these things need to be done. Sixty days out, these things need to be done. Thirty days out, these things need to be done. They wanted clear markers in the sand as they approached go-live dates.

My instinct was “small chunks iterate forever,” but they were right. The operational reality of the venues demanded structure and predictability. If they hadn’t challenged me in a public way, I would’ve forced them down the wrong model. I truly believe the rollout wouldn’t have gone as smoothly. It ended up being the smoothest technology rollout I’d ever been a part of, and I directly credit the success to that moment where the team spoke up and changed my mind.

That’s what I mean about culture. Psychological safety isn’t just a feel-good concept. It literally changed the outcome of a multimillion-dollar program.

Preserving what makes Alamo Alamo

How would you describe Alamo’s culture when you arrived? What did you preserve, and what did you reshape?

It was passionate. It was scrappy. It had a very strong identity. Alamo knows who they are for the most part. I thought it was important to preserve those pieces. It was also important to preserve the weirdness. Alamo is kind of weird. And weird can be really cool.

In our offices at Baker, there were wax statues everywhere and people would move them. I would come the next day and there’d be a new one in a new place in the basement or something.

Someone on one of my teams had these arcade machines filled with video games. I was told the manager at the time would hold kung fu game challenges. People would rally around these games to fight each other for the leaderboard. That kind of stuff was important to preserve — and anything that could lead to the creation of that kind of stuff.

Film first was really important to preserve. What I reshaped was ownership clarity. I wanted to make sure that everyone was empowered and they had correct ownership of their spheres — influence, control, trust.

I wanted everyone to get really comfortable with feedback. Psychological safety — I know I’ve said that a half a dozen times — and process and documentation.

Communication we’re still working on. When you’re super scrappy and creative and passionate, usually communication doesn’t get a grade A because you’re moving so fast. I try to publicly talk about the feedback I receive and what I’m doing to address it to set an example: “Hey, you can give me feedback.” And I will respond and act based on that.

Bottom-up culture and leadership influences

Can you build culture from the bottom-up instead of top-down?

This will be another put-a-dollar-in-the-jar moment: I learned all this through Agile principles early on in my career.

Beyond the mechanical pieces, what struck me was going through retrospectives: give feedback on how something is going, make a change, and realize I can change this thing over time. It’s shaped by thousands of little tiny cuts over time. That struck me as incredible back then.

As a team leader, you’re bottom-up. You can’t influence a company at a big level like that. But if you get multiple teams working in concert to do reflection and change things over time, then you effectively can change culture in a positive way for a company from the bottom up at a team level.

The first time I got to put that theory to the test was at my previous company. Culture was blaming, fear-based, toxic, pointing fingers. Since I’m not an executive leader, how can I shape culture? I focused on establishing reflection, spheres of influence, and cultivating those from the bottom up.

Over time, two years, I noticed a huge shift. That came with hiring new folks and empowering some of the humans that were there. Those that weren’t here for the model of happy and healthy humans, they left on their own. They noped out of it.

That’s how I feel anyone at a management level can influence culture: make sure teams can shape their own cultures over time, and they have senses of ownership and influence in their daily life.

What are the major influences that have shaped your thinking about leadership?

Radical Candor by Kim Scott. I try to make everyone that reports to me read it.

The other one that shaped the bottom-up idea was The Advantage by Patrick Lencioni. It was required reading when I was at Autodesk. I remember sitting on a plane and reading it, and it all clicked: vulnerability, emotion, organizational health, retrospectives, spheres of influence, ensuring happy and healthy humans.

The biggest takeaway was the culture vulnerability part. All teams need vulnerability, not just executives.

Knowing the system is working

How do you know when the system is working?

The biggest thing is that people begin to speak up, and they feel comfortable speaking up, and it’s not toxic. There’s a shared understanding of assuming positive intent. When someone says, “I think that’s a bad idea,” people aren’t afraid of hearing that. There’s less insecurity. People come away not feeling targeted.

When I know it’s working is when people challenge me more and they’re not upset when they are wrong, and I’m not upset when I’m wrong.

Other indicators: mistakes are surfaced easily. There’s a real understanding of, “Oh, no, that was a mistake. Let’s all go this way instead,” and you’re not spending a lot of time on the mistake. The mistake doesn’t get regurgitated multiple times. Honest retrospectives and a diminished hero culture are also signs the system is working.

The biggest marker for me is when the company is moving at a sustainable pace. That one is really hard. That’s years of maturity. That’s the north star.

“Slow is smooth, and smooth is fast.” I believe in that. If you can slow down enough to be smooth, then you will always go faster.

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 our conversation, Prasun talks about how he leverages AI to add genuine value — focusing less on hype and more on clear ROI, adoption thresholds, and time to value. He shares how product leaders can evaluate where AI belongs in a company’s roadmap, and walks through real examples shaped by usage data and customer behavior. Prasun also outlines how to prioritize AI investments and use those resources effectively.

Evaluating AI opportunities through ROI

What’s your approach for evaluating an opportunity — specifically one involving AI? Which metrics do you want to see before you actually approve it?

For me, the AI revolution is real. The trend is evolving — it’s not linear, it’s exponential. Day to day, newer models are coming in, and there are real opportunities to leverage AI with significant advantages.

That said, when there’s hype around a technology like this, you hear people say, “Let’s put AI in everything we’re trying to build.” That’s a faulty concept. There are still limitations, so my advice is to not go in blindly. For me, it’s more about time to value.

When you start thinking about integrating AI into products, you have to remember that it takes time to build. There are significant time and monetary investments involved. The question is: what real value is this going to bring? Is it workforce efficiency? Will the user actually save time? You have to compare the work that goes into it with the outcome — the ROI gain for the user.

The second step is building a minimal viable product. Today, with prototyping tools like v0 by Vercel, you can build a prototype in a matter of hours and then validate it with customers. Is this something they want? Is it something they’ll actually use?

Lastly, instrumentation from day one is critical. When you deploy an MVP, you need to ask: is it providing value? How are customers using these AI capabilities? Are they seeing the benefits you predicted once it shipped to production?

When you perform this initial evaluation, is there a certain threshold that you look for to confirm if it’s worth the effort?

Yes. Every time you build something, you’re testing a hypothesis. In my opinion, you need a clear threshold upfront. For example, if we say the adoption threshold is 30 percent, and we ship an MVP, but adoption stays below that, then it’s probably not worth continuing. When you look at the ROI — the effort to build and maintain it versus how much it’s being used — it just doesn’t make sense to keep investing.

But if the hypothesis is that we’ll reach 30 percent adoption, and we actually hit that, and we can clearly see paths to grow further to 50 percent, then there’s real excitement. That’s when we should invest further — add features, iterate, and push adoption higher. The goal is always to move from 30 percent to 60 percent, then to 90 percent, or more.

Everyone needs a threshold because building anything costs money, time, and effort. If the data says adoption is low or customers don’t want the feature, we should stop. You might talk to 40 customers during early research, and maybe 30 of them say, “Yes, I love this. This will help our automation or accuracy.” But if you ship the MVP to a wider audience and adoption is still under 30 percent, then we should can it. The market is telling you something, and you have to listen.

How do you decide whether an AI capability belongs in a customer-facing product vs. internal tooling?

I think about this in two parts. AI can be internal-facing, customer-facing, or sometimes both. At the end of the day, the question is: what efficiency gain are you trying to achieve in each case? When you’re building internal tools, the lens is whether this helps your teams work more efficiently. For example, there are AI-native tools you can use for engineering teams — automatic code reviews, test case generation, and even GitHub Actions that help with automation. These are purely internal, but the output is measurable.

You can self-report some of it, but ideally, you measure it with data: how much time engineers are saving writing unit tests, documentation, or doing manual code reviews because these tools are mature enough to handle that work. That’s one aspect of it.

Then, when you’re building customer-facing products, it’s about understanding what problem you’re trying to solve and why. You still start with a quick MVP, based on market research, then put it in front of users and measure adoption. You ask, “Is this helping our customers? Is it expanding our customer base? Is it driving revenue, retention, or efficiency?” Those metrics are critical for me on both sides — internal and external — to decide whether an AI capability is actually successful.

Letting data challenge assumptions

Can you share an example of a time when you reversed an AI decision after seeing real usage data?

Early on, when large language models first emerged, we had an idea for a SaaS product we were building. The question was: how can we use LLMs to give better insights to consumers based on the data they’re seeing? One of the offerings was providing highly qualified, highly filtered leads. The idea was to give consumers a smaller number of these vetted leads so they didn’t have to sift through a large volume of low-quality ones. We believed this would result in higher conversion rates.

We built machine learning models and added RAG capabilities so that when a lead came in, the model evaluated things like user behavior, demographics, and time spent on the site. Based on that data, we classified leads as highly convertible or low quality and sent only the best ones to customers.

We implemented this quickly, but we had to pause it very soon after. The feedback was essentially, “You’re sending me fewer leads.” They cared more about volume than quality. They wanted to make more calls, even if conversion rates were low. What they weren’t factoring in was the time cost — calling 20 leads to convert one versus calling five leads and converting four. But that value wasn’t communicated well. We assumed people would immediately understand it, and that was a mistake.

So we paused, talked about it more, and rolled it out to a small group of more progressive customers first. They used it and saw the results. In some cases, they saw conversion rates of 80 percent, and then became advocates. They shared their success stories, and that helped us slowly reintroduce it to our broader customer base.

The lesson was that with new technology, you need pilots, proof points, and education. You can’t just roll something out because you think it’s great. Without that groundwork, you’ll get pushback.

What’s the smallest AI-powered change you’ve ever shipped that you felt really delivered an outsized impact, something maybe you weren’t even expecting?

I can share an internal example with coding agents. When these tools first came out, I thought, “This will immediately boost productivity.” We rolled it out to engineers and basically said, “Here’s a force multiplier. Productivity should skyrocket.” Well, that was a fallacy. My assumption was that our engineers had heard about the hype, played around with AI tools, and were so already comfortable with them that they’d start implementing the tool we developed.

That assumption was wrong. Honestly, I was dumbfounded when people started rejecting it — it’s a tool in your arsenal that you can use, so where was the hesitation? Adoption was extremely low — 1 or 2 percent. People didn’t trust the tool. Some directly said, “This is a bot. I don’t trust the quoted price.” Some tried it and felt they spent more time debugging AI-written code than writing it themselves.

So we stopped and listened. We asked why people weren’t using it. The feedback was consistent: lack of trust, fear of job replacement, and poor early experiences caused by weak prompts and lack of context.

To fix this, we focused on education. We formed a small pilot team — a “tiger team” — that believed in the tool. They documented best practices on how to write prompts, how to provide context, what a good cloud.md file should look like, and how to avoid garbage-in, garbage-out scenarios. After a couple of months, they had real results showing they were spending less time writing boilerplate code and more time designing systems, thinking about scalability, reliability, and security. They shared concrete examples and metrics.

Next, we did a roadshow across teams. The pilot team demonstrated how they used the tool, shared prompt templates, and explained what worked and what didn’t. That changed everything. Adoption went up to almost 50 percent. We also saw a big increase in AI-generated code successfully making it into production.

That was the biggest “aha” moment for me. Engineers weren’t coding less — they were just doing higher-quality work.

When AI stops being a differentiator

What specific signals tell you when an AI capability has shifted from being a competitive advantage to more of a commodity?

There are three signals I look for. First, is when open source catches up to about 80 percent of your capability. Once tools exist that can deliver most of what you built internally, your differentiation and competitive advantage evaporate really quickly. For example, an AI-powered search feature might have been a genuine differentiator in 2022. It could understand contexts, handle synonyms intelligently, and rank the results well. Suddenly, anyone can build a program 80 percent as good with modern AI tools. We might have spent years trying to build our algorithm, and now, it’s plug-and-play.

Second is when customers stop mentioning it in sales conversations. Early on, customers ask about the AI feature and lean in. Later, they just assume it exists. When they stop asking because it’s expected, it’s become a commodity — like having a mobile app today.

Third is when marginal investment produces diminishing returns. Early improvements are noticeable: accuracy jumps from 70 percent to 85 percent, workflows change, and users feel it. Later, you spend months going from 85 percent to 87 percent, and no one notices. That’s a clear signal that the capability has matured beyond the point where additional investment creates a competitive advantage.

At that point, we make a specific playbook shift and change the roadmap. We invest less in the core capability and more in the moat around it — integration into workflows, personalization, data flywheels, and vertical use cases. The value shifts from the AI itself to how it’s embedded.

You’ve mentioned that you’re an advocate of KISS prioritization. If you had to remove 70 percent of AI features from a roadmap tomorrow, how would you decide what stays?

I’m a big metrics and data guy, but I’d say it’s first important to be data-informed rather than purely data-driven. If adoption is flat — below the threshold we set — and there’s no clear path to grow it, we kill it. If a feature is at 40 percent adoption and trending upward, that’s something we double down on. Sometimes, data keeps you blind because you’re purely looking at numbers without context, so that perspective is important.

There’s also a qualitative side where we talk to users. We listen to sentiment. If adoption looks good but feedback is overwhelmingly negative, that’s a signal that something is wrong. I like to use the example of Word or Excel. Those products have hundreds of features, but most people use maybe five. Maintaining low-adoption features is expensive and often not worth it. The same applies to AI. Every feature should have a clear outcome, clear adoption, and clear value.

When you prioritize quantitative data, the numbers track very easily. But when you mix in qualitative data, how do you balance those signals?

Numbers alone don’t tell the full story. Adoption rates don’t explain why people love or hate a feature. That’s why I’m a strong believer in the voice of the customer. You segment users, talk to them directly, and understand sentiment. If adoption is high but sentiment is negative, you need to investigate. If adoption is moderate but sentiment is extremely positive, that might justify further investment.

Data can blind you if you don’t add context. The combination of quantitative metrics and qualitative insight is what leads to better decisions. As a product leader or engineering leader, that’s very important to me.

The core of an AI strategy

What’s your simplest mental model you employ to explain AI strategy to a group of executives who you need buy-in from?

I use a three-layer framework. I literally draw it out on a whiteboard, and I’ve done this at multiple companies. I draw three circles. The inner circle is what I call “fix the plumbing.” If your data quality is poor or your infrastructure isn’t ready, AI won’t help. Garbage in, garbage out. About 40 percent of your investment should go here.

The middle circle represents the core workflows. This is where about 50 percent of your investment and energy goes, because this is where you get ROI — better efficiency, better customer experiences, better monetization.

The outer circle is experimentation. That’s 10 percent. Most experimentation will fail, but just one success can be transformational. Even if only 1 percent of users convert, that could be the change the company needs.

Executives or boards of directors often want to “sprinkle AI everywhere,” but strategy starts at the core. Without a solid foundation, nothing else works.

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 Deepika Manglani, VP of Product and Program Management at the LA Times. Deepika’s career in media spans over 15 years, culminating in her current role, where she’s bringing the 140-year-old institution into the future.

In this episode, Deepika shares:

• How her team is using AI to preserve a unique trove of historical data, over 12 million pages of news archives from as far back as the 1800s

• What this digital archive and maturation of AI enables for future storytelling, media innovation, and news personalization

• Why combining product and program management was critical to navigating massive transformation at the LA Times through a period of heavy M&A activity

1. Rebuilding a 140-year-old institution from scratch (3:10)

When the LA Times was sold in 2018, the newsroom stayed, but the technology backbone didn’t.

That meant rebuilding everything: networks, HR systems, billing, platforms, and products, while publishing daily.

“Imagine what that means. No network, no infrastructure, no products, no platforms, no people. And yet the newsroom has to run 24/7 for a 140-year-old company.”

To make it work, she merged product and program management into one organization — aligning vision, execution, and delivery under a single mission.

The takeaway: transformation isn’t about shiny tools. It’s about building operational foundations that let journalism survive and scale.

2. Why generative AI wasn’t good enough for history (10:45)

The LA Times has more than 12 million archived articles, many trapped in low-quality scans and microfiche.

Early estimates to re-digitize them ran the team millions of dollars before a multimodal AI solution arrived.

Even then, however, the team needed an AI tool that wasn’t “too smart” for this use case. Because when they “thought,” the tools hallucinated or altered facts:

“The problem is when these AI models start understanding the context, that’s when they start thinking. And if you don’t want them to think, you gotta eliminate that part.”

So her team deliberately chose a non-generative, OCR-style model that just copied text.

The takeaway: Picking the right model doesn’t mean choosing the shiniest new tool on the market, but the one that will best fit your use case.

3. Turning archives into living storytelling tools (15:30)

Today, the LA Times has already digitized 300,000+ articles, with a goal of 500,000 in the near term.

Once complete, these archives won’t just sit in storage — they’ll power modern journalism.

Deepika explains how historical context can reshape coverage of major events:

“If we can stitch that together… what happened back in [the 1994 World Cup] versus right now in 2026, that would make the story more interesting.”

Instead of researchers spending days digging through records, journalists will be able to search decades of history instantly.

With semantic search, archives become an active reporting tool, not just a museum.

4. The future of personalized news (25:10)

Beyond preservation, Deepika is thinking about how news consumption itself should evolve.

She wants media to learn from platforms like Spotify and TikTok without sacrificing credibility.

“I would love to have an app that reads news to me based on my history of reading.”

The infrastructure being built today — archives, metadata, personalization systems — makes this future possible.

Links

• Deepika’s LinkedIn

• LA Times

Chapters

00:00 Introduction
01:49 Deepika's career journey in media and product leadership
03:03 Building from scratch at LA Times
07:19 Digitizing historical archives
10:34 Challenges and innovations in AI and OCR
22:29 Future prospects and personalization in news
26:52 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.

In our conversation, Jose shares how his agency background shaped his approach to digital product strategy inside large corporations — especially when the “customer” paying for the work isn’t the end user. He also breaks down what it takes to build 0-to-1 ventures inside legacy organizations without losing trust, and what he’s seeing from a new cohort of PMs and builders who have never prototyped without AI.

From agency work to corporate product strategy

How did your early career design agency experience benefit you when you transitioned to managing and leading product within a corporation?

I wasn’t personally expecting to be in the advertising world or to be a creative. But one reflection I have from that question is that everybody’s path is different. Product is almost like a constellation of things connecting — some are not super connected — but it’s this constellation of experiences that amalgamate into you wanting to build products. And even though it doesn’t exist, and I think some schools are trying to do it, there’s no product school. Product school today is the street. You’ve got to go and do it.

Agency life taught me what it did was it gave me speed and agility and this kind of consulting approach. You’re partnering with your customer who owns a brand, and you’re delivering an experience — hopefully an experience — in my case digital experiences for users or consumers on the other side.

So in some ways you have to deal with the complexity of getting paid by somebody that is not your end user. When you’re in a corporation or an enterprise, it’s very similar. One of your business leaders is partnering with you for a solution that will impact their end consumer or their end user.

You’ve got to do it fast and you’ve got to be agile and you’ve got to be very metric-oriented because they’re giving you money and they’re expecting a specific result. It’s a statement of work kind of relationship.

If I were to summarize it, agency life taught me how to ship work that’s both excellent for the user and efficient for the customer. And that muscle memory, it’s hard to forget once you have it. When you go into an enterprise and a complex corporation, you understand who are the middle layers, what is important to them. These are your customers, but you understand also that there’s a user that is going to receive the benefit. And if you don’t think about it that way, your ecosystem of value creation is messed up.

You mentioned that you were kind of surprised that you ended up in an agency. How did that come about?

I’m kind of surprised I’ve ended everywhere that I’ve ended. Right out of undergrad, I ended up at a research institute and then I went to an agency and then I went to Goodyear. If you would’ve asked me, 12-year-old Jose riding his bike in Costa Rica, where do you want to work, I don’t know what I would say.

I used to think of agency work as very transactional and very specific to one point of the roadmap or one point of the user journey. I’ve always wanted to go across the user journey.

What I was seeing was very communication-driven, very marketing driven. It was a point in time. The customer would come in with a need, you would execute on that need and deliver an experience and then they would move on. But the customer was controlling that user journey, that experience, that business. I wanted to be part of it.

Was there anything that you felt you had to unlearn when you shifted to owning long-term product value inside a corporation?

It wasn’t necessarily unlearning. Agency tends to be such a creative place. It’s incredibly fun, and it’s incredibly a pressure ecosystem where you have to deliver quickly — tight deadlines, tight budgets — and they’re paying you for creativity.

Something I carried with me is: how do you get to be calm, cool, creative in a pressure oven? It’s critical.

I’d say the other thing is it wasn’t about unlearning something from agency life so much as bringing those things — and also re-bringing what I learned in undergrad while I was building my media company. It was this blog that became one of the top two or three blogs in Latin America while we were in undergrad. Building all of that from zero to one, talking to readers, working with them, understanding how to make something bigger out of their feedback — those things were important.

I would probably unlearn a little bit of the transactional aspect of an agency. Start, finish. But when you’re building product, you’re shipping your next version, your next product. In some ways it has an end and a beginning and then you redo it. So there is more that I carry from agency into corporate than I leave behind.

Building 0-to-1 inside a large organization

What feels surprisingly similar between a startup and a “startup within a company?

The constraints are surprisingly similar and at the same time fundamentally different. Similar buckets, but very different ways of activating them.

First, you need money. In a startup, you need fundraising. When you’re building a new venture from within, you need funding too. You’re not going to show great results in the first few quarters.

Second, you need a compelling vision and narrative. In a startup, you need an elevator pitch. What is that vision of a different future? You use it for recruiting talent, for fundraising, and to drive your team’s work. The same happens at a corporation. In my previous life: how does the future of mobility shape the tire and automotive industry — cars being shared, electric, autonomous — and how does that change become an opportunity? You still have to craft your narrative and bring people along.

Third, you have to show critical value aligned with results. In a startup you’re aligning with your board. In a corporate world, you’re still responding to a group of people. You can’t say, “Give me all this money and let’s check in every couple years.” That’s never going to work.

What changes most when you’re building 0-to-1 inside an enterprise?

I use an analogy: when you do a startup within a company, your startup is like an asteroid going around the sun, and the sun is your mothership. If your asteroid gets too close to the sun, it disintegrates and becomes the sun. But if it moves away from the gravitational pull, it drifts off, gets cold, and dies.

So you manage that gravitational pull. Sometimes you need to get closer to the sun — tough quarter, strategy change. Sometimes you have freedom to move out. The closer you get, more brand power, more ability to go to scale, but it slows you down on exploration. The further you go out, the more exploratory you can be, but there is risk in terms of trust from the corporation and the people in it.

Differences: in a startup you’re navigating different investors through the journey; in a corporate venture I dealt with the same investors for five or six years.

Another difference is strategic unfair advantage. At Goodyear, it’s 125-plus years. You show up and say Goodyear, and they know it. If you start a new startup tomorrow, nobody knows you.

And then there’s the scarcity mindset. Startups talk about runway — “I have X months.” That pressure is different in a corporation.

‘Moving fast’ without breaking trust

Could you illustrate this with an example, like AndGo?

One of the most fun periods of my life was studying early-stage startups. My mentors are CEOs of startups in the Bay Area. I brought those lessons back to Goodyear and to my board and said, “This is how they do this. I understand that might be too crazy for us, but this is how we could do it. What do you think?”

One example: hiring and compensation. A startup is willing to do things with sales that an enterprise would never do. One mentor said: remove the ceiling for incentives. If they sell $10 million, they make $1 million. In a corporation, you can’t do what startups do, but you have to meet them halfway.

More strategically, for us it was: this is the ambition and the vision from our narrative. We wanted to go into a well-established marketplace with a SaaS component. And we kept asking: are we going to spin it out or spin it in? The answer was: we do not know. We’ve just got to keep trying and see where it fits. We asked it every other month: spin out, spin in.

What did ‘venture governance’ look like in practice?

We created a board. We had our CTO, another executive at Goodyear, and an independent external person who was an expert in software sales. They became my board. I met with them every four to six weeks for an hour and a half, and I treated them exactly how you would treat your board at a startup.

I would send the board package ahead of time. We would run it like a startup board: ask questions, ask for alignment, move on, come back and show results. All the way to the point of, at times, asking: am I the right CEO to be doing this job?

There was a moment where we needed founder-led sales — the CEO needed to be the head of sales. I asked: am I the right person? We agreed: yes and no. Yes, I’ll stay in the role, but no, I need training. So we got training.

How did you handle strategic decisions — markets, models, and reporting — inside a legacy company?

We used the board for strategic questions: business model, revenue model, markets. Let’s say a customer asks us to go to the UK — should we? If we open the UK, what conflicts with other Goodyear businesses? What relationships do we need?

And then: educating the board. We started measuring gross merchandise value as an online marketplace. That’s common in Amazon or Airbnb. For us it was new. I worked with a consultant inside Goodyear and brought back their financial perspective: how it makes sense, how you account for that, how you report it back into Goodyear.

For product leaders building 0-to-1 inside large organizations today, what’s the one illusion about “moving fast” that causes the most damage?

Speed isn’t velocity. It’s trust through structure that you need to build.

If you drift too far from the mothership and start doing things on your own too much, you’re taking a reputational risk. The people doing day-to-day jobs are creating value so you can come and do what you’re doing. Innovation is thanks to the labor of all these people. Do not disrespect the people you might find to be blockers or traditionalists. They’re there to keep the lights on.

The illusion is moving too fast in ways that create resentment: “Why do they get special treatment? Why can they hire? Why can they use that tool?” Those exceptions are potentially damaging the long-term reputation of your startup inside the company.

Better communication and better rotation — bring people from the company into the startup so they can experience it — helps. If I break things too quickly in areas the company is sensible about, I’m damaging trust.

How do you decide what “risk” is acceptable when you’re trying to move quickly?

I think about risk like a normal distribution. On the left: risk that’s mostly fear — ignore that risk. In the middle: risk you can digest — hard, but you build safeguards. On the right: risks you’re just not willing to take. You define with your board what those are.

Then there’s a structured hierarchy for how you operate: operations first — mission, strategy, operating procedures, how you build product. Then HR — new job families, pay scales. Then legal — entities, contracts, terms of service. Then procurement — how you evaluate and buy tools. Then accounting and finance — how you run a P&L on a different business model.

You have to do it in a way that the leaders of those areas feel comfortable about the steps you’re taking, in the context of that risk framework.

What AI-native builders change about product work

You teach at Case Western. How are your students framing AI instead — as a collaborator, a prototyping medium, a business model, or something else?

Teaching at Case is one of the most rewarding things I’ve done. Twelve students get handpicked every year from hundreds of applications. It’s a one-year entrepreneurial fellowship.

I teach the fall semester and help them build products from zero to one. Mostly computer science, but some biomedical doctors and business folks too.

What I guide them through starts with what I call the logic line. Connect the line between a person, a user, and what you’re trying to do, with the right ingredients. A person is doing something in a context and experiencing something — most of the time it’s a pain point. Then: how can I make that better? That’s your vision. Then: if I created value, how do I extract some of that value? That’s your viability and business. At any point, you check your logic line. It changes as you bring data.

Now, here’s what I’ve seen: once they know what they want to build, they go and build it. The speed of prototyping has increased by 10-20x. When they show me what they’ve built. I tell them: even just three years ago, this wasn’t possible with the time you invested.

So what does that tell you? It’s easier to create things, but the more things there are, users can select for more of those things, and you have to hone in on your logic line to create something that really creates value. Tools like Lovable and coding with Claude make them so much faster. But now they’re facing a more existential product question: how do I make this work?

What are they doing with the time they used to spend on prototyping?

Before, you would spend 80% of your time coding a prototype, then try to make it work. Now you spend 20% coding and you have all this time to think: how do I get product market fit? How do I go to market?

So you have computer scientists worrying about product market fit and revenue models earlier. Some of my students have their own startups outside of the lab. I met one of the students in San Francisco for coffee — they started a company six months ago, and one of their customers is a hospital in Ohio.

Those students are able to make strategic decisions like product market fit much earlier. How do you see that impacting their outcomes?

They’re maturing faster. They’re being asked the basic questions of creating value: desirable, viable, feasible. Technology has unlocked them to focus on those sooner.

And you already see product bifurcating — technical product managers, product growth, product ops, product marketing, product specialist. I think that continues. You’ll have more tools and solutions being created, and the need to find fit quicker, keep track of the logic line, experiment faster. I’m seeing computer scientists acting like product managers earlier than they thought.

Leading AI adoption inside legacy companies

What’s the single most important mindset shift you recommend product leaders at legacy companies make to avoid being outpaced by teams who learned product building with AI from day one?

For incumbents, “figuring it out” means an operational governance way to implement AI at scale, transform their business from the ground up, and prepare for the acceleration that quantum computing promises to bring by 2030. This requires a fundamental shift in capabilities, values, and habits.

If your company is 40 years old, then for 40 years you’ve been building processes for humans — accounting, operations, supply chain. You have a 100-step process. Now you have agents coming in and they don’t need those 100 steps. You have to throw it away and re-imagine it for agentic AI, then decide when humans are in the loop and what they do.

Agentic workflows are more decision trees — yes/no — than complex processes we built for ourselves.

Where does AI competition show up first for incumbents?

I think there are three types of competition: incumbents moving faster; new competitors coming from the bottom up using AI; and your internal competition.

Internal competition is the death trap: incumbent teams saying, “Now, why are you going to redo my product or sunset this?” Or, feeling that the company has more time to transform. This inaction erodes value for shareholders, customers, and employees. I don’t think companies have months or years to figure it out. They need clear vision: “This is how we’re going to do it.”

Why is ‘comfort’ a liability in AI adoption?

When I built AndGo, I built three types of AndGo. The first, throw it away. The second, throw it away. The third is alive right now. That’s going to keep happening.

AI adoption speed is a business risk and a business model existential question. It is not a tech initiative. AI isn’t a feature to add, it’s really a whole reason to transform companies and build new experiences that just a year ago were unimaginable.

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.