In our conversation, Roger shares his perspective on how AI is fundamentally reshaping the product management role, including the increasing pressure on PMs to operate at higher speed and scale. Roger discusses how his time in the US Navy has influenced his approach to leadership, and also talks about his prediction that the PM role is splitting into “builders” and “peopleers.”

How AI is redefining product management

How would you describe the disruption AI is bringing to the PM role right now?

It’s nothing we have ever seen in technology. AI is a monumental shift in the way that we work, in the output that we have, the outcomes that we can achieve, and everything in between. It is both empowering and disempowering at the same time. It depends on how deeply you go down the rabbit hole. Those who embrace AI and utilize it without it being a crutch are going to succeed. Those who buck the trend and refuse are going to get out of the industry or be forced out one way or the other. I don’t think there’s an in-between — the status quo is over.

There’s a lot of focus on the technical skills and tools PMs need to stay relevant in this AI era. What skillset do you think is being overlooked?

Language. Technical skills are still being played out. You don’t need nearly as many technical skills to build as you once did. A couple of years ago, if you wanted to build a website, you’d go the WordPress route, get a template, and hope nothing broke. If it did, you’d call a friend because you couldn’t understand what was going on.

Now, all you have to do is talk to tools like Claude, Perplexity, or Codex. They’ll troubleshoot, or you can pit them against each other. There’s a lower barrier to entry into technical realms because it enables the layperson to create technology with just an interface, and it’s only getting better exponentially.

On the flip side, if you want to take something to market yourself — be an entrepreneur or PM pushing code to production — you’ll need to be more technical, but in different ways. You need a better sense of architecture, deployment methods, and how all the moving pieces work together so you can bring a product to market and be part of that release cycle. You’re not replacing a cog — you’re becoming a new one, a more efficient one. Some technical skills are waning, others are ramping up.

You mentioned language as an overlooked skill. Can you elaborate on why you feel that’s the case?

Some people rely on AI, especially large language models, as a crutch. Like anything, if you don’t use a skill, you lose it. But if you hold onto language, what you feed into AI becomes better, and what you get out of it becomes more useful and more interactive.

Language is also the key to people’s interactions, which are absolutely necessary to stay relevant in this new world. We have to be able to interact — in conversation, in writing, in everything. Language is still a key and evolving part of our society. And evolving is key — language changes, and we should embrace that.

The new expectations for product managers

PMs have always had to navigate competing pressures, like sales, engineering, and customers. How do you think about that negotiation dimension as the role of AI tools maximizes the volume, speed, and quality of outputs as a whole?

Those pressures aren’t going away. If anything, they’re becoming more demanding because of the pace of technology. AI is everywhere. You can’t swing a cat without hitting an AI banner or billboard. So the pressures are more fierce. But you can use these tools to your advantage. I recently bought a car and used AI to figure out what a good deal was. I used it to contact salespeople, pushed everything into text or email, set up a profile with my goals, and had it interact. I reviewed everything, so I was the man in the middle, but it was a much better experience.

If we apply that to PM work, it gives us an edge. A product manager is often an internal salesperson. We have to convince stakeholders. AI can help us make that case, justify decisions, and practice skills we may lack.

As those roles are getting more blurred, and PMs start to both prototype and negotiate internally, do you think people skills, as part of the PM role, are changing?

Absolutely — I believe that the PM role is forking right now. My prediction is that we’re going to have builders and peopleers. Peopleers will be comfortable networking, being on site, and interacting. Some people naturally walk into a room and leave with contacts and new friends — that’s a talent. Others can learn it, but it takes effort and overcoming discomfort. AI can help with tips and tools there.

Builders will be interpreters of feedback, analyzers of data, builders of requirements. They’ll experiment, break things, and try new tools. Organizations are still catching up, but builders who prototype and experiment will be critical. If you can’t build and prototype, there’s not going to be a big future for you in product management.

Leadership lessons from the US Navy

Switching gears from basic people skills to leadership, your path into product leadership runs through the United States Navy. What did that experience teach you about leadership skills that still show up in how you operate today?

Fear no one. My first day in boot camp felt traumatic at the time, but now I look back at it and say, “Wow, that was hilarious.” Everyone arrives around midnight, and they wake you up at four o’clock in the morning the next day. You don’t sleep a wink that first night, and first thing in the morning, they bring you in for a haircut. I remember a buddy of mine had told me, “Roger, make sure that they don’t know your name in boot camp. Just be quiet, do your thing, and you’ll get through it just fine.” Standing in that line, I’m like, “I’m not going to be known for anything.”

I was thrown into leadership. I was shy, scrawny, not someone who stood out. But I was put in charge. From that day forward, it was about trust. The people around me didn’t know me, but they trusted me. And I learned: even if you fall, your team has your back. That still applies today. I’m not afraid to throw product managers into deep waters and say, “You can do this.” And if they fall, I’ll be there. I have their back.

Some argue that people skills are innate — you either have them or you don’t. Based on your experience, do you find that to be true?

Some people are born with it, but others can certainly be taught. Like with anything, you have to be a willing participant and open to practicing. For example, I didn’t know how to be a teacher. I was a shy teenager, and even though I used to study the piano and felt like I was a musician deep down, it took a push for those skills to come out. Natural talent helps you accelerate, but others can get there too.

For PMs whose strengths are more analytical or technical, what’s your advice for building the relationship and influence side of the skills spectrum?

Be comfortable with the uncomfortable. Don’t wait to be pushed into the deep end — jump in. Fear holds people back. They think, “I can’t do that because something bad may happen.” Now, I’m not saying throw caution to the wind. We have to make data-driven decisions, but making a decision is key to progress. You need to put yourself in front of people, observe, and listen with the intent to understand.

Listening is such a key skill, and I mean true listening — listening with the intent to understand, not the intent to respond. I see this often, where people come into the conversation with an opinion on something. They come in wanting to say something, and they can’t wait for the person talking to be done so they can say the thing they want to say. So, even though they hear the person and process the words, it’s not retained. If you put those predispositions away and just listen — even if you don’t agree — you have that understanding, which then allows you to make a better decision.

Staying relevant as technology changes

Older professionals face real discrimination when any major technology wave hits. Do you see anything that bucks the ageism trend in this AI transformation age that we’re in?

Yes — empowerment. AI can act as a tutor, teacher, chief of staff, and an assistant wrapped in one. Before, someone might dismiss you or not take the time to explain. Now you can learn at your own pace. It applies to both older and younger people. My stepson struggled with lessons, but AI tutoring changed that. It’s individualized. The key is mindset. If you’re rigid, you won’t move forward. If you stay open and use these tools, it’s a game-changer.

For a PM early in their career, watching AI absorb tasks they expected to spend years mastering, what’s the most important thing they can do to position themselves well for what comes next?

It depends on the path that they come here from. You have to have curiosity and be able to go all-in on new technology. Don’t be afraid to experiment. That’s something that I’ve always been a proponent of and a practitioner of, even outside of a professional setting. I have used a combination of Codex and Claude to evaluate real estate, for example, run models on the best price per square foot, crawl different tax rolls, and more. All of these things are things that would’ve taken me an entire weekend to do, but it only took a few hours.

Overall, you have to have that curiosity, and that needs to start when you’re young and able to be flexible. Things are changing so fast that if you remain rigid, they’re going to break you. But the more flexible you are, the more you’ll be able to be successful.

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, Kim talks about what it takes to build people-first ecommerce teams in an increasingly data-driven and AI-enabled world. She discusses why context, human judgment, and cross-functional collaboration still matter just as much as analytics and automation, as well as how her early merchandising experiences shaped her leadership philosophy.

Balancing data with human judgement

You started your career in retail merchandising long before modern analytical tools existed — decisions were made by instinct and observation. How did that environment shape the way that you think about judgment, accountability, and decision-making today?

What’s interesting is — and I’m going to age myself here — that I remember the first time a company handed me a laptop and said, “You need to share this with your assistant.” There wasn’t any data flying around. We all used the same reports in the form of big, thick paper piles, and every Monday, we’d drag them into face-to-face meetings with management.

We were all looking at the same data. We weren’t making different dashboards or pulling from diverse sources. These were the reports, and you needed to just understand how to read them, review your numbers, and use intuition to make decisions.

Beyond that, we were out talking to people face-to-face. It was pre-Internet. That’s how I got into this field in the first place. When I was a little girl, my mother hated shopping, but I’d ask to go to the mall so we could people-watch. I don’t know why — I just thought it was exciting. I’d go into stores, talk to associates, watch customers shop, and interact with them. I was gaining something that reports wouldn’t give you — a deep understanding of customers. That’s where you realize there’s a lot of context that can be missed.

I remember when I was at Talbots, and the unfortunate events of 9/11 happened. Our numbers were down, nobody was buying, but the stores were full. Women were coming in to connect with the associates. They just wanted to talk — there was no pressure to buy. If you looked at the metrics today, you’d say, “There’s traffic — why aren’t they converting? The merchandise must be awful.” But you wouldn’t know the human side of what was really happening unless you were there — unless you had context.

What gets lost when organizations over-rotate on data and drift away from the human judgment behind it? Can you share an example of a time where the data pointed in one direction, but your instinct led you to make a different call?

It’s that context — that human piece. And you can miss opportunities you never would have thought of. When I was at The May Company, we were all given the same reports across divisions. You could compare performance and contact peers to understand differences. I was then buying special occasion dresses, and the whole company was doing well with beaded dresses — except me. It was a sore point. I bought into what the data said was working, but I couldn’t sell it.

Then I looked around, and I noticed my floor was filled with younger women — there were lots of colleges nearby. These women were going to formals and socials, and we were doing well with non-beaded dresses — cocktail dresses, little black dresses, that sort of thing. As a merchandiser, you can only bring in so many black dresses, so I added color.

The colorful dresses started selling faster. I talked to my managers and learned that people were buying them for their bridesmaids — typically eight at a time. Instead of going to a bridal store, they were buying from us. So, from that, we built a bridesmaid special-order business. That opportunity wouldn’t have happened if we had just followed the data. We had to dig deeper into what was actually happening in our market rather than blindly following the data.

Making decisions in cross-functional environments

Building a successful ecommerce business requires getting people with different priorities to move together toward a common vision. How do you create alignment across functions when everyone is optimizing for something different?

That unifying aspect is so hard. You think it’s going to be easy and that everyone’s going to align, but when you’re working on an ecommerce platform, so many things can go awry in a given day. It’s all interconnected, with systems and data feeding other systems. You might go to tech and say, “We want to add this vendor,” or “Customers are calling — is something broken?” But there’s only so much bandwidth and budget, so you have to decide which decisions or paths forward create the greatest value for the company and the customer.

Sometimes things get prioritized because they fit into work already in progress. It’s a jigsaw puzzle. Tech isn’t serving just one group — they’re a shared service. So, teams come together, talk it out, and make decisions for the greater good of the customer and of the business.

As AI becomes more embedded into how teams operate, from analysis to planning, where will human judgment and leadership still matter most?

AI does amazing things. I use it all the time — business, personal, “how do I fix this?” It gets work done in minutes that used to take days. But with that, it can’t navigate an organization. It doesn’t understand context. It can’t understand how people work together or how data is being interpreted across teams.

For example, I recently asked customer service for tracking call data. I looked at the data and started drawing conclusions, but after reviewing it, I realized it wasn’t a full year-over-year comparison. I was about to make a business decision based on incomplete data. I had to go back to the analyst and ask follow-up questions to understand what I was actually looking at. The point is that you always need context. You need to connect different inputs from different sources and experts to move the business forward. Otherwise, how do you work as a unified enterprise?

Servant leadership in practice

Aside from your professional accomplishments, you also have a Master’s degree in organizational leadership and a coaching concentration. What does servant leadership mean to you in this context?

When I first learned the term “servant leadership,” I felt validated. It was how I’ve always led. It’s always about your people, and I am very supportive of them because I truly care.

To me, servant leadership is removing roadblocks so people can operate at their best, both professionally and personally. How you approach your work bleeds into aspects of your personal life. We want employees who are happy and engaged. We spend more time with these people than we do with our own family. You want to be able to laugh together, celebrate each other’s wins, and support each other when times are tough.

For me, servant leadership is the easiest way to get people to feel empowered. I think it’s deeply important that people feel heard, are invested in their work, and feel good about what they do every day. And much of the time, that means getting out of the way. Some people won’t raise their hand or set boundaries. As a leader, it’s your responsibility to check in and make sure they’re not overwhelmed. Teams are getting smaller, work isn’t going away, and even with AI, someone has to validate the output.

So it’s about regular check-ins and stepping in when needed. If I can make a five-minute call that removes pressure for someone, I’ll do it. That’s serving your team.

You talk a lot about leaning into people’s strengths. Most leaders talk about developing people by closing gaps, but you approach it from the opposite direction. What does it look like to build a team’s strategy around what energizes people rather than what they’re missing?

I’m very big on using people’s strengths. I’m certified in the Strengths Profile methodology, which is an assessment tool that breaks down your strengths into three different categories: some things you’re naturally good at and energize you; other things you’re good at but drain your energy; and skills you haven’t tried yet but might love.

And then there are weaknesses. If writing is a weakness, like it is for me, make peace with it and find someone who’s great at it. I have a friend who’s a beautiful writer. When I need a bio for a professional publication, I ask her to take a cut at it for me. Even within friendships, that’s your team who can help the cause.

Teams work the same way. One person is great at product selection, another at analytics, another at vendor negotiation. They all work together to fill gaps.

Can you share an example from your background of a time when the culture either made or broke the conditions for a people-first leadership style to actually work?

I have a hard time in environments where autonomy is not nourished. A culture where I struggle is one where I lose a sense of decision rights and empowerment. I am fortunate to work for a leader and a company who value my independent perspective and approach to my work.

Flexibility and autonomy are really important, but people also need to own their decisions that exist within a greater framework. I had a boss who was a great mentor to me, and we’d sometimes disagree. However, we’d eventually align on a decision, and both stay invested in the agreed-upon outcome. We’d review the results together and learn from them. We were able to grow and bond with our shared outcome, and that’s what’s important to me in a work culture.

As organizations become increasingly data-driven and AI-enabled, what do you think will distinguish truly great ecommerce and product leaders from the rest?

It comes down to being nimble and being flexible. None of us knows what’s coming around the corner — whether it’s AI, a new business direction, or a situation in our personal lives. Teams need to be able to adapt. Everyone should be brought along so they can step in when needed. That happens through constant communication. We don’t work in silos. It’s about working well together so we can support each other in the best way possible.

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, Alex talks about the nuances of scaling a two-sided marketplace, including solving the inherent tension between supply and demand. He also discusses the human side of marketplaces and shares how Saatchi Art approaches complexities like network effects and tradeoffs between buyers and sellers.

The unique power and complexities of marketplaces

You’ve spent a significant part of your career in marketplace environments. At a high level, what makes marketplaces such a uniquely challenging and powerful business model compared to traditional ecommerce?

Marketplace businesses, if done well, drive a lot of value to customers, especially in a world with so much information overload. A good marketplace resolves friction and helps users navigate choices. Marketplaces typically thrive in fragmented industries where there is no dominant player and where there is friction or information asymmetry. For example, if I’m buying expensive artwork, how do I know I will not be scammed? How do I know whether it’s real? How can I be confident it will be delivered without damage? The transaction has risk. Marketplaces can reduce that risk and friction.

In a two-sided marketplace like Saatchi Art, you effectively have two businesses in one. You have demand and supply, and both need to be satisfied for the business to work. Another challenge is that marketplaces generally don’t own inventory. The core assets are liquidity, discovery, trust, and match quality, rather than unique inventory. The real asset is the network effect.

This leads to inherent challenges, especially the cold start problem. You have no demand without supply and no supply without demand. Typically, new marketplaces focus on demand first and “fake” supply — using contractors or internal resources — and then transition to real supply. If done well, all of this creates a moat around the business because these systems are difficult to replicate.

Measuring durable network effects

What leading indicators suggest you’re building durable loops and network effects rather than short-term liquidity spikes?

The idea that “when you have it, you will know” tends to be true. You really need to understand your business and market, but generally, traditional e-commerce metrics still apply — conversion, retention, repeat purchases, and the balance of paid versus organic traffic. There are also marketplace-specific metrics like GMV, supply liquidity, buyer-to-seller ratios, and how your top sellers are trending over time.

The strongest signal is when both sides grow together. The “holy grail” is cross-side growth — when buyers promote the marketplace, sellers promote it, and sometimes users participate on both sides. Eventbrite is a good example — in the same marketplace, you can post an event, and you can attend events. It becomes a closed-loop ecosystem where everyone can contribute to both sides. Our artists do that as well — they shop for art on our platform.

How do you make those tradeoffs without just shifting friction around the system?

Tactically, tradeoffs exist, but long-term, it shouldn’t be a zero-sum game. Both sides need to see value, otherwise the business won’t work. For example, we had issues with inaccurate inventory on our website. A listed artwork may have already sold elsewhere, like at a gallery or through friends or family. A buyer would purchase it on our site and then find out it wasn’t available, which is a terrible experience. You can imagine how much frustration the scenario causes a collector.

So, we introduced stricter listing management rules, which created more work for artists. Some pushed back, but others understood that without buyers, there is no marketplace. This is one example where we had to be more strict on the artist side to benefit collectors. On the flip side, we allow buyers to make offers, but we set a minimum threshold to protect artists from extremely low offers. That limits buyers, but ensures fairness.

A rough model we use is: if a change improves one side by X, how much does it hurt the other side by Y? You try to find the balance. If you’re forced to choose, you prioritize the side that is most constrained. Everyone will know what’s best for their own business. At Saatchi Art, the demand side is definitely more challenging.

There must be so many nuances in searching for artwork on a site. How does that break traditional thinking around discovery, matching, and conversion?

Each artwork is unique, which creates challenges for product discovery and recommendations. Traditional recommendation systems rely on popularity, but if something is popular, it’s already sold. Every new artwork also faces a cold start problem because it lacks historical popularity metrics a traditional SKU would accumulate over time. But even if a recommendation engine is able to identify a popular artwork, purchasing decisions are highly subjective, which presents an additional challenge.

We also see more browsing than searching. It’s difficult to describe an artwork in words, so users prefer to browse and discover rather than search for something specific. Constraints like size or price still matter, but beyond that, browsing is more valuable, as many of our customers say, “I’ll know it when I see it.”

Technicality and complexity in digital marketplaces

Artists aren’t typical sellers. Where do standard marketplace assumptions, such as level of technicality, fail with this audience?

Artists are very creative, but are not often as technical or business-savvy, and those skills are important for successfully selling online. More importantly, they’re not always motivated by sales. Recognition matters a lot in terms of how their work is perceived and seen. For example, all artists want to know how many views their artwork got. They want to know that someone saw what they created.

We see decisions that don’t always make business sense. An artist might cancel a sale because they want to keep the piece, or offer a discount because of an emotional connection with a buyer. We often see artists give discounts just because they want to make people happy. Their motivations are not necessarily financial — they go beyond that.

At the same time, artists who are more business-savvy and understand how to present and sell their work tend to be the most successful. We’re trying to educate them and provide them with tools to be more successful, but there’s only so much we can control in that sense.

You mentioned earlier that Saatchi Art does not hold inventory. How does that add to the unique complexities of the marketplace?

This manifests in a couple of ways. First is listing quality. All listings are user-generated, so listing quality is critical. Images, descriptions, accuracy — all of it affects buyer experience and can lead to returns and friction. On fulfillment, we rely on artists to package and ship correctly. We provide a return policy to remove financial risk for buyers, but there is still time and operational cost.

Logistics are particularly complex. We ship high-value, one-of-a-kind artwork globally from a residential address to another residential address, with packaging handled by non-professionals. You can imagine how many things can potentially go wrong here. Some countries have very strict regulations for art exports. There are many points of failure — packaging, pickup, customs, and delivery. We’ve had orders that included shipping large sculptures internationally, requiring custom crates, multiple transport methods, and special equipment for delivery. Some shipments take months.

This complexity is part of the value we provide. Without a marketplace facilitating it, many of these transactions wouldn’t happen. Our logistics and operations teams are outstanding. And this creates defensibility as well as value, because this complex operational capability is difficult to replicate.

Where AI comes into the arts

There’s a lot of talk today about AI and its impact on creative fields. Where are you cautious about using AI, especially when it comes to trust?

Accuracy and authenticity are the biggest concerns. There’s always a risk of losing the artist’s voice or producing something generic, so we have to be thoughtful about how AI is applied. AI-generated art itself created a lot of fear in the artist community when tools like Midjourney appeared. People thought artists would be replaced, but in many ways, it had the opposite effect — handmade artwork became more valuable and more appreciated.

AI-generated and human-created work can coexist — they serve different use cases and audiences. AI-generated images might work for certain contexts, but for something like a living space, people often want something authentic with a story behind it.

We do allow AI-generated artwork on the platform because the lines can be blurry, especially with photography and mixed media. It’s hard to define where AI starts and stops. Our policy is that artists must disclose what tools they used. As long as buyers know what they’re purchasing, they can decide for themselves. What’s not acceptable is misrepresentation — presenting something as handmade when it’s actually heavily AI-generated.

On the flip side, where are you seeing real value from AI in marketplaces, and particularly at Saatchi Art?

I try to operate from the principle that we should try using AI until it’s proven not to add value. It may sound a bit riskier, but I think there is a lot of potential. With that said, accuracy and authenticity are very important to us, so we are very careful and intentional about how we use it and whether it makes sense for our business and our users.

One example is description enhancement. Authenticity and artist voice are very important, so rather than giving a blank check to an AI tool, we require artists to write their description first. Then, with a strict prompt, we allow AI to enhance it while preserving the artist’s style and tone so it still sounds like them. An AI-written description is better than no description, and it also helps non-native English speakers create strong descriptions and be more competitive. They can still edit it and make it their own, but it levels the playing field.

We also use AI for styling — room visualizations to help buyers see artwork in a space. It can be inaccurate, so we take a conservative approach, focusing on higher quality outputs and making sure we don’t misrepresent scale. It gives us flexibility and cost savings compared to traditional photoshoots. The highest-impact use cases for us are personalization and search — creating user affinity scores and surfacing more relevant artwork.

We also use AI for fraud prevention, listing quality checks, and categorization. We have about 1,500 new artworks uploaded every day, all user-generated, and AI is instrumental in spotting quality issues, flagging spam, and enhancing attributes. AI unlocks capabilities that would be too expensive to do manually at scale.

What does LogRocket do?

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

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

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

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

In this episode, we talk about:

• Why most slow organizations aren’t suffering from a tech problem — they have a trust deficit

• How Sriram shipped a new vertical in just five days that a program manager had scoped for nine months

• Why the real constraint on AI adoption isn’t tools or budget — it’s mindset

1. Shipping in 5 days instead of 9 months

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Chapters

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

What does LogRocket do?

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

In our conversation, Hammad explores the mindset shift from project delivery to product thinking at scale. Drawing on his experience leading global product portfolios and driving digital transformation, first at NielsenIQ and now at Dallas Fort Worth International Airport, he shares how he balances global standardization with local needs, aligns technology with people and culture, and designs products for diverse user communities.

Developing products across global and regional markets

Earlier in your career, you led a global product portfolio. What was it like to balance local and regional decision-making while managing products across so many different countries?

I supported 110+ countries, and one of the objectives was to make sure that we scale these products across markets. That’s always a challenge because different markets have different dynamics. There’s always some local customization required, but at the same time, you have to keep a level of standardization across the board.

When you’re operating at a global scale, it’s about finding the sweet spot between consistency and flexibility. What we did was anchor everything on a few non-negotiable principles — things like data integrity, security, and platform architecture. Those should remain universal.

Beyond that, we gave room to the regions to adapt since one size cannot fit all. For example, something that works well in Singapore cannot be a copy-paste model in Brazil. They have different cultures and communities within them. So, we built products with a configuration layer so local teams could tailor the experience without breaking the global backbone and principles.

It’s essentially about designing a strong foundation but letting each house have its own personality. From a structure, tools, and principle standpoint, everything remains the same — but the experience can look different.

When working on a data-heavy product like you were in that role, how do you decide between improving infrastructure vs. improving data inputs?

It depends, and it varies. There are data regulations and quality metrics that come into play, and those influence the strategy. In more mature markets, you’re often in a speed and optimization mode, where you don’t need heavy infrastructure investment. In emerging markets, though, reliability and trust take priority. You’re deciding whether the market needs speed and optimization or trust-building first. That decision shapes whether you invest more in infrastructure or data quality.

From project management to product leadership

Across your career, you started out more in project management and transitioned into product leadership. What has that transition been like?

Early on, success was all about hitting deadlines and budgets. That’s very project-focused. Product leadership is different — it’s all about a lot of stakes on the table. You’re looking into how the product would be evolving, so the real success is measured more on adoption, the behavior chain, and long-term business outcomes. It’s not just about pushing the features; it’s more about sustainability and bringing more value to it.

In terms of my career transition, I was always focused on how I could step in and bring additional value. While working on programs, I realized that there is a vacuum where I could learn product development and leadership while working closely with commercial and client-facing teams. That moved naturally over time.

Even in project and program management, product teams are heavily involved, so you get exposure to how products are built. I realized project management is very structured — following timelines and delivering what’s required — but it doesn’t always question why something is being built or how it will impact users. That questioning came naturally to me, and that’s what pulled me toward product.

What parts of project management are best applied to what you do in product now? And on the flip side, what have you had to unlearn from project management that doesn’t work as well in product?

Project management is essentially structured planning, stakeholder alignment, and risk management. What doesn’t translate, though, is rigid scope. Product is about flexibility, learning, and adaptation. I had to shift from delivering predefined outputs to validating certain outcomes.

We brought in the MVP model, then, so that you’re pushing a concept, testing it out, continuing to improve it, and so on. It’s all about the change mindset, which is huge from project to product.

Effective change management and leadership

In your view, there are 2 pillars of digital transformation: tools and products, and personnel management. How do you approach both pillars simultaneously so that they’re working together and not against one another?

I learned this the hard way. When I was more on the software development side, I focused too much on features and not enough on adaptability and behavior change. But to be honest, tech and people have to evolve together. It cannot be that the people are changing, but tech is not changing. Having a shiny new tool doesn’t create value unless there’s a behavior change as well. Every major product rollout has to pair with clear roles and responsibilities as well. That’s where change leadership comes in, which is all about creating a new way of working that feels natural, not forced.

If you’re meeting resistance in the digital transformation process, how do you determine which pillar is the issue?

There’s no kind of standard governance structure, but transformation requires more than just technology — it needs cultural readiness as well. When there is a shift in willingness to make decisions and prioritize outcomes over activity, which is a product mindset, digital transformation steps in. But if you don’t see those signals, then it’s likely time to start with modernization of the tool and the process, and then take slow steps toward development.

So, when I’m assessing things for a leadership report, I’m evaluating how well leadership is rallying behind the concept of experimenting. Because when you’re stepping into product development, you sometimes do not know how this will be done.

What do you see as true digital transformation for an organization, and what do you look for as a signal that an organization is actually prepared to undergo that transformation?

Say, for example, in an aviation environment like I’m in now, you’re looking into doing a digital transformation via airport navigation improvements. At the same time, you have certain guardrails in place by specific entities, so you have to follow these guidelines and still create a good passenger experience. For this example, you want to add this tool to let people know where they are and how to navigate the airport, but you also have to place it strategically in the physical space so people can access it easily. This is where transformation comes in, and it essentially marries with the digital version of wayfinding.

On the flip side, if you’re just pushing this wayfinding tool on an app but not guiding users through how to use it, it’s going to be too complex for the average person. Essentially, with digital transformation, there are certain ways you can use innovative technologies, but at the same time, you have to optimize the entire experience around the process itself.

Designing for diverse users at scale

You have a unique challenge in that you serve a very dynamic user group made up of people who vary in digital savviness. How do you design for users with vastly different digital comfort levels?

Our passenger demographics are very different. So, when designing products, you have to look into the mix of customers and account for all demographics.

For us, that means offering multiple channels. That means apps for tech-savvy users and in-person support in critical areas for others. This product development also requires both quantitative and qualitative research. Quantitative data is all about data, but qualitative research is where the rubber meets the road — it shows usage and how people actually experience the product.

Our goal is to meet every traveler where they are, so no matter their background or familiarity with technology, they can navigate the airport confidently and comfortably.

How do you troubleshoot an issue to ensure, for example, that the way you address an in-person wayfinding challenge doesn’t interfere with the digital wayfinding solution? How do you keep those avenues complementary, not combative?

It’s an ongoing learning process. You have to go back to the MVP model, where you push certain features, test them, and improve as you go. That’s all part of learning. Through that, you can make a decision. Developing a customer experience is important for the product in that case.

Driving a product mindset inside organizations

In your role at DFW International Airport, you’ve joined a team driving the shift from a project mindset to a product mindset. How are you contributing to making this transformation impactful?

The biggest signal is redefining ownership around persistent products instead of temporary projects. With a temporary project, there’s a start and an end date, as well as clear timelines. But when you change success metrics to focus on the outcomes, the real signal is that success is about what to build and why. That’s the kind of curiosity that showcases that you’re moving in the right direction from a mindset standpoint. When teams move from asking “When will it be done?” to “What should we build and why?” that’s real progress.

In terms of user reactions, the biggest surprise to us so far has been how much small improvements mattered. Internal teams focused on big technical wins, but passengers clearly valued clarity, predictability, and reduced effort. This was a great reminder for the team that user experience is more emotional, not just functional.

This is something we’re incorporating more into our product development as well — that we have to think through from a user’s perspective completely and emotionally, rather than just viewing it as a tech upgrade on our end.

Looking back at your experience in global organizations and now owning this shift from the project to product mindset, what do you think organizations most often misunderstand about product management and digital transformation? What are people still getting wrong?

The first big misconception is that product management is only about roadmap execution. It’s not — it’s also about continuously problem framing and decision-making in uncertainty. You do not know what lies ahead as you move a step forward.

The second is that digital transformation is like a one-time program or tech upgrade. It’s actually about ongoing capabilities that you nurture over a period of time. And if you treat it like a traditional timeline-based project, they’ll miss the point that transformation is not about a one-time change — it’s about continuous improvement. Three things go together here: digital transformation, innovation, which is part of product development, and continuous improvement.

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, Marcos shares hard-won lessons in 0→1 product leadership. He makes the case for trusting intuition over data in early-stage work, explains why big bets generate stronger signals even when they fail, and walks through what it actually takes — in terms of team structure, PM qualities, and organizational sponsorship — to protect a new product inside a large company. Along the way, he tells the story of how a small, focused team unlocked a new category in the Brazilian fintech market.

The 0→1 mindset: Intuition, big bets, and diverse teams

When you think about what makes 0→1 product work genuinely different from growth or optimization work, what’s the most important mindset shift a product leader needs to make?

The main one is giving space to intuition over data. It’s not an easy one — data means confidence, and it’s really hard to trust your intuition. Some people can trust their intuitions easily, but not everyone. If you have a lot of experience, you need to trust in your intuition. And given that in 0→1 you don’t have enough data to optimize, you need this idea that I like to call big bets.

When I say big bets, I don’t mean building something unnecessarily big. I mean something that solves a meaningful problem and is differentiated enough. Big bets have two main benefits. One is that even if it fails and you don’t have much volume or data, because it’s a bigger change, it usually generates stronger signals. A small change in a product will not generate too much signal, but if you create a whole new big thing that’s going to solve this problem for the customer, you’re going to generate some signal even if it fails. But if it doesn’t fail, which is the best case scenario, you create more value. So, there’s only upside in thinking in terms of bigger bets when you don’t have much data.

How do you keep your teams from falling into analysis paralysis when you don’t have data to make confident product decisions?

There are two important things. One is customer empathy — really thinking about the customer beyond you as a customer, but others as a customer. And also having some sort of diversity. You have your intuition because you’re leading the team, but you also need to bring different perspectives and make sure that we are collectively trying to understand the customer.

Diversity is very simple — people are different, and you need to bring the tension. Tension is good. You bring that to offset the risks of being too biased. But at the end of the day, don’t rely too much on that. You’re never going to reach a situation in the room with so many diverse people where everyone is like, “Yes, we all agree on the problem. This is it.” Never going to happen. Then you need to make the decision based on intuition.

And then, there is a secret sauce, which I’ve seen a lot of times in bigger and more bureaucratic organizations like banks: execution. Ideation and execution have a symbiotic relationship. If the person who is ideating doesn’t trust the execution, they will try to be as perfect as possible. But if you can execute fast, you’re going to be less attached to your idea because you can learn fast and then have another idea. A lot of times, you need to trust your intuition and make sure the execution is good. Otherwise, you’ll try to be perfect and afraid to start executing.

Have you seen diversity help the decision-making process — and a lack of diversity lead to bad outcomes?

It’s very common for startups. You usually have an owner, and the owner brings people they know. They all think they think differently, but they kind of had the same experiences.

I see a lot of departmental diversity at Lonely Planet because Lonely Planet, by design, is diverse. It has people from all over the world. It’s very cross-functional and multidisciplinary because we are a publishing business that is trying to digitize. There are a lot of conversations where people bring a way of thinking that’s completely different. Whereas in the past I’ve seen, “Hey, we think we are being devil’s advocate, but actually we’re just kind of tweaking each other’s ideas a little bit.”

But there are challenges both ways. When you have a very diverse group, it’s impossible to reach a decision through a unanimous decision. The goal isn’t consensus; it’s collaboration. Every perspective that challenges your assumptions, even one you ultimately reject, stress-tests the intuition you’re going to act on. You leave the room having pressure-tested your thinking against people who genuinely see the world differently. That makes the call you’re about to make alone a sharper one. So the leader still decides – but they decide better.

Knowing when to shift from intuition to data

How do you know when it’s time to shift from intuition-led bets to data-led iteration?

Between intuition-led early stages and optimization stage, there’s a big gap. The transition between those two stages is where you continue to make big bets. Over time, you rely less and less on intuition and more and more on data as it becomes available. Your data informs the next big bet, meaning that we are not going to just change the color of a button or something on the landing page. You’re going to be asking, “Okay, what are the big problems I can solve?”

When to start the optimization stage is actually not a very easy answer. There are a lot of people in the market trying to understand how you measure product market fit. There are surveys you can use. The P&L starts to talk with you a little bit. But once you found it, that’s when you can start to optimize and drive more incremental revenue optimization decisions, like funnel optimization, increasing variety or referrals inside your app. And, usually, that’s the moment where people start to scale paid media and paid investments, which makes more sense because you want to make the most out of the money you’re investing.

Can you share an example of a time you started with a big, intuition-led bet?

When I was leading one of Brazil’s largest credit card marketplaces, we saw that Brazilians were increasingly motivated by credit card reward points. This idea of points is very normal for Americans, for Brazilians, it was just starting about 10 years ago. The big insight was that utility bills, one of the largest recurring expenses, remained a blind spot in terms of credit card usage. We saw an opportunity to unlock that category for financial institutions and help customers get more points from things they didn’t think they could get points from.

So, the goal was to start narrow and focus. Rather than building the full platform, we focused on the core problem: we want Brazilians to pay a bill with a credit card, and we want something very secure, robust. We focused 100% on the wallet functionality. It was a very simple, bare-bone mobile app. You had a wallet, you added one credit card, and then, do people want to connect their bills? Once we confirmed demand — we even secured a partnership with Visa — that started to increase the volume in our app a lot, and we decided to focus on other bottlenecks.

As more volume started to come, now data is telling us that a lot of people are having problems signing up, or they can’t find the app to download, or there was a problem with operations. Our nonexistent support operations was a bottleneck, so we decided to build a support team. All of that started to become true because we validated the demand. And then it started to become more incremental features, until it became more of an optimization stage.

Why a bill management and payment tool in a credit card marketplace? At the end of the day, we were trying to collect behavior data for the users to offer better credit cards — helping customers understand what credit card they can be approved for, given their utilities, which is basically a very good proxy for, “What is our financial condition?”

Building the right team for 0→1

There’s a common instinct in larger organizations to staff up when launching something new. How do you structure a team in a 0→1 effort?

For me, it’s very simple: keep the team small, nimble, isolated, with clear autonomy. Big orgs often think that if you hire more people, it’s faster, but it adds a lot of problems — communication, overhead, scope creep. Adding more people can end up delaying launch. As we talked about, yes, you want to use your intuition, but your goal is really to get data, the volume. If you keep postponing launch, you’re never going to get insight on what actually worked and didn’t work.

And there’s another problem that happens over time — the more people there are, the more the scope shifts. You hire smart people who want to make smart decisions, and they’re not always going to agree with you. If you have a very clear view as a leader, sometimes you need people who can make that reality in a small team.

Are there specific qualities that make a PM better suited for 0→1 work? And are there warning signs that someone who excels in a scaled environment might struggle in an early-stage context?

In addition to intuition, which you develop over years of diverse experience, and which is usually what I look for in 0→1 PMs, it’s important to be very execution-driven. Not project management execution, but a little bit of technical intuition — speaking the same language of engineering, being able to collaborate. Because a good solution is not a product top-down solution that design and engineering executes. It is a solution where you come with a POV, and then with engineering, you develop a better solution that is simpler, faster, and reaches the same goal.

I usually find those skills better in PMs who have a little bit of experience in both worlds — who understand what it means to come from an engineering background. And you want someone who has a lot of startup experience, because in a small team, you need to collaborate very closely. In a lot of bigger corps, teams are more siloed and process-driven.

On the flip side, the warning sign is someone who has only big names in their resume. They’re used to a lot of process, a lot of formality, and a lot of data. Not always, but usually. If you worked at Google, you’re used to launching something and getting enough data in two days to make some decisions. By design, you’re also used to slower execution, because of very complex technology.

Protecting innovation inside large organizations

You’ve experienced 0→1 both inside large organizations and in new ventures from scratch. What surprised you most comparing the two?

At Red Ventures, I helped open the Brazil office. Our main business model is partnerships with big organizations, including the largest bank in Latin America, where we help them build technology to reach a specific business goal. Performance-driven, not output-driven. Red Ventures also had, in Brazil, a venture builder where we used the cash-cow money to reinvest into new digital products or digital brands from scratch.

The biggest surprise was realizing that what kills innovation and speed is the system, not the people. Some people think startups are successful because they have very passionate and committed people. The reality is that there are a lot of special and committed people in big organizations everywhere, but the system — processes, beliefs, culture — creates resistance that, over time, slows down and demotivates those agents of change. I partnered with a lot of big orgs. There were pretty good people there who were so happy to see us because we were helping them overcome a resistance of the system that they couldn’t by themselves.

When you’re doing 0→1 inside a large organization, there are a lot of forces working against you — competing priorities, risk aversion, stakeholders who want to see the product grow before it’s ready. How do you protect an early-stage product from getting derailed?

It’s really important to have a sponsor — a senior leader, or anyone who is very influential — who can protect the team. A 0→1 product has different success metrics, a different review cadence, and a different tolerance for failure. If there’s no leader who understands that, it’s hard to convince everyone that the team is being successful. There’s a lot of noise in the organization — the sales team wants to use that feature, the data team wants to change the platform. And everything feels urgent because the rest of the org is making money, whereas that team is not.

The sponsor helps shield those teams from the inevitable structural incentives of a big organization.

And there is one more thing: the definition of progress. In a big org, progress means money — P&L, revenue, or deliveries — we delivered this feature, this expansion internationally. But in 0→1, progress is not that. Progress is feeling confident that the direction you’re going is right, or, even better, feeling confident that the direction you’re going is not wrong, meaning you’re going to fail a lot. If you don’t have a leader who understands that, they’ll keep incentivizing the team to produce results as soon as possible.

The biggest mistakes and what to avoid

Looking back across all your 0→1 experiences, what’s the biggest mistake you’ve seen product teams make?

Adding complexity. I’ll frame complexity in a very broad term. Adding complexity can mean adding more features that are not necessary. Every new thing you develop is more complex to develop. And it adds data noise. The more things there are for the customer to interact with, the less customers interact with each thing, so it’s really hard to know what matters.

Adding complexity can be adding more people, more ideas, more communication overhead, more scope. And adding complexity also means adding more process. Too-rigid ways of thinking usually prevent adaptation. “Oh, we need to do the two-week sprint perfectly, no change of scope.” When you are very early, you need to have a little bit of room — maybe it’s a one-week sprint, and let’s change scope if we think it makes sense. The smaller you are, the less process you need. You want to focus 100% of your time on one big thing you’re trying to solve for the customer and understand if that’s the thing that really matters. And if it doesn’t matter, let’s go to the next thing.

For product leaders operating inside companies that want to build 0→1 capability, what structural or cultural conditions have to be in place before it can actually work?

It links back to the incentive structure. You need a leader who defines what success looks like and can separate the team from the organizational noise.

The other thing is real autonomy, which can come in different levels. I’m not saying, “Hey, this team can decide whatever they want about this product.” No. It’s the job of the leader, or sponsor, to really decide the level of autonomy. Maybe it’s, “The team needs to build this thing. How they’re going to build it, and what they’re going to do is their job to explore.” Or, “We already have a design well-defined — we just need to execute.”

But make it clearly defined and give autonomy in that space. Because a team that needs to get a sign-off on every small decision will have less and less confidence. And the less decision-making they can do on the spot, the slower you’re going to go.

What does LogRocket do?

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

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

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

In today’s episode, Julia shares:

• How a PRP (product request prioritization) system she designed herself in one weekend transformed Capacity’s CS feedback by replacing the chaotic “firehose” of requests with a ranked, data-backed list

• What running a human API layer taught her about prompt design, long before LLMs existed

• And the truth most teams skip — that AI agents are only as good as their instructions. AI doesn’t fix bad data; it amplifies it, and teams need to audit their data before writing a single prompt

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

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

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

The two culprits? Bad instructions and bad data.

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

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

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

Why?

Julia says:

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

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

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

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

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

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

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

The result?

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

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

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

Links

• Julia’s LinkedIn

• Capacity

Chapters

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

What does LogRocket do?

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

In our conversation, Minal talks about rethinking B2B UX for the Amazon-era buyer and how B2B buyers expect the same intuitive, seamless journeys they get as consumers. She explains where B2B and B2C should align — particularly in the core shopping flow — and where they should diverge. Minal also dives into the operational side of B2B commerce, sharing how AI-driven reordering, role-based guardrails, and the right performance metrics can ultimately drive long-term revenue growth.

The biggest misconceptions in B2B ecommerce

In your experience leading digital transformation for both B2B and B2C commerce, what is the biggest misconception in how product teams design the ecommerce user experience for business customers?

One of the biggest misconceptions I see, especially in B2B ecommerce, is the belief that the user experience doesn’t have to be as clean or easy to use as a B2C website. Until a couple of years ago, a lot of B2B websites were very manual. For example, you had to enter numbers instead of uploading sheets. The look and feel wasn’t very intuitive, and it didn’t allow you to move end-to-end through the discovery-to-purchase lifecycle smoothly. A huge factor behind that is that the B2B ecommerce industry had a late start compared to B2C.

But the people shopping on your B2B ecommerce site are also consumers in their day-to-day lives, and they still expect a clean experience. They still want a one-stop shop for all their needs. In fact, improving the experience in B2B can have an even bigger impact. A clean, intuitive UX reduces training time. It reduces the need to bounce between different websites to complete a purchase. And that convenience increases loyalty. So the misconception is assuming that business users will tolerate complexity just because it’s “for work.” They won’t — and they shouldn’t.

What beliefs about business buyers tend to drive digital teams toward that generic, complex spreadsheet-like experience?

I think a lot of it comes from legacy systems and legacy thinking. Most B2B organizations are still operating on older technology. They’re used to processes that are more manual than automated. Teams get accustomed to seeing things the same way all day, every day — and that familiarity turns into comfort. Over time, that comfort becomes the standard, even if the experience is clunky.

There’s also a strong belief that B2B shoppers don’t like change. That’s somewhat true because they’re doing the same tasks every day, often under time pressure, so if you change their workflow, they can get very antsy. Digital teams hesitate to modernize the experience, assuming complexity is safer than disruption. My argument, however, is that if you’re going to change it, make it easier. Don’t hide features that were visible on the page or add extra clicks. Instead, simplify it.

Another driver of that spreadsheet-like experience is not fully understanding how B2B users actually use the site. Some are power users who spend hours a day there. Others are quick in-and-out buyers — they know the exact part numbers, enter them, place the order, and leave. That spectrum matters. If you don’t research how long they’re on the site, what they’re doing, and how frequently they return, you end up defaulting to a generic, dense interface that tries to serve everyone but delights no one.

Where B2B and B2C should (and shouldn’t) align

Where should B2B and B2C experiences be nearly identical, and where should they really diverge?

I think the shopping journey itself — from discovering a product, reviewing product details, adding it to cart, checking out, and tracking when the order will arrive — can be the same, 100 percent. There really doesn’t need to be a lot of difference between B2B and B2C in that core flow.

Where they start to diverge is more on the marketing side. In B2B, you don’t necessarily need to market newer products the same way you would in B2C. Most B2B organizations operate under contract pricing for specific parts and products. Buyers often are only purchasing what’s been pre-approved. The decisions about introducing new products are typically made by the owner of the company or someone at a higher level, not by an individual buyer browsing the site. So while the end-to-end shopping experience can and should feel very similar, the marketing efforts are completely different.

What are the hidden friction points in B2B purchasing flows, and how do you mitigate them?

There are a few hidden friction points in B2B purchasing flows, and most of them come down to speed, repetition, and organizational complexity.

First, ordering itself can be unnecessarily slow. B2B buyers often know exactly what they need, such as part numbers, quantities, and SKUs. Features like quick order, where they can upload a spreadsheet instead of manually entering each item, remove a lot of friction. You can also build orders automatically using AI-driven or automated tools, or enable predictive order placements based on past behavior.

Inventory management is another big one. Predictive inventory checks can flag when a customer is running low or when a part is about to go out of stock. The system can prompt users to reorder with one click, and that kind of automation dramatically reduces effort.

Subscriptions are also powerful in B2B. In the consumer world, subscriptions mostly work for everyday essentials, such as pet supplies or water filters. In B2B, almost every product can be a subscription because purchases are repeated over and over again. Automatic replenishment can remove a lot of manual work.

Loyalty programs are another underused lever. Since B2B customers are making repeated purchases, offering loyalty points or rebates that they can earn back and apply toward future orders can strengthen retention and reduce switching.

Finally, one of the biggest friction points is role complexity. In B2B, you don’t have a single user who can buy anything. You have an approver, a quote creator, a purchaser, an owner, etc. Designing clear permissions and workflows so approvals don’t turn into bureaucracy is critical. In B2C, none of that exists — it’s one user, one cart, one checkout.

Encouraging repeat purchases in B2B ecommerce

If repeat purchasing is the backbone of B2B commerce, like you said, what are the most effective patterns for enabling that fast, low-friction reordering?

Definitely AI predictive ordering. That means creating AI bots that can go through your account, look at your ordering patterns, predict what you’re likely to need next, and suggest products so you’re not running out of stock. It helps ensure you’re ordering items at the right time instead of reacting after inventory is already low. Another big piece around reordering is warehouse inventory replenishment tied directly to the order flow. But that only works if you’re accurately tracking the exact inventory on the floor. If your inventory data isn’t right, the automation falls apart.

Business buying usually involves controls like permissions, budgets, and approvals. How do you design guardrails so they preserve governance without turning every order into bureaucracy?

It does require a bit of upfront effort from the owner of the company, but the key is building structured account management with clearly defined roles and permissions. Most mature B2B platforms, like the ones I’ve worked on at Sealed Air, HD Supply, and Lowe’s for Pros, all have account management built directly into the owner’s profile. The owner can create users and define what each person can and cannot do. Once that structure is in place, governance becomes embedded in the workflow.

A simple way to think about it is hierarchy. For example, at Interline Brands, we had just three roles: owner, who had full access to everything; quote approver, who could submit and approve quotes; and purchaser, who could add items to cart but not approve orders. If a purchaser submitted something, it automatically routed to the quote approver or owner. The permissions defined the workflow. You can imagine this at scale, like a large retailer with multiple franchise locations. Each location’s owner manages their own users and approvals within their structure. From their perspective, it’s simple: create a user, assign a role, and the system enforces the rules.

The important thing is that the guardrails are defined once and then largely “set and forget.” You want the system to handle it automatically based on predefined roles. When permissions and workflows are clearly structured upfront, you preserve governance without turning every order into a bottleneck.

Adapting to modern consumer expectations

Many organizations assume that B2B and B2C platforms must be fundamentally different products. In your experience, what actually changes when a company treats them as variations of the same core product or experience?

There are really two parts to this. Ten years ago, B2B and B2C were often treated as completely separate products. Today, more organizations are realizing that the purchase path is almost the same for both. The product catalog can live in the same PIM system. Product information can sit in the same CMS. A lot of the underlying systems can, and should, be shared.

Technically, what changes is that B2B has additional features layered on top. You might have different payment methods, contract pricing, approvals, or role-based permissions, but the core infrastructure of browse, search, product detail pages, cart, checkout, etc., doesn’t need to be reinvented. Instead of building two platforms that conflict with each other, companies are designing technology that overlaps and works in harmony.

You can see this with large retailers like Amazon, Lowe’s, and Home Depot, which serve both B2C and B2B customers. For example, Lowe’s for Pros may have a slightly different in-store experience for professional customers, but online, outside of approvals and permissions, the needs are very similar. Both a Pro customer and a consumer want to find the product quickly, buy it quickly, ensure it ships on time, and possibly arrange installation.

Culturally, the shift is even bigger. Organizations are moving from being hardcore manufacturing companies to digital companies. And in today’s landscape, it’s almost impossible to survive without investing in technology. With AI accelerating expectations, the pressure to modernize is even stronger. So when companies treat B2B and B2C as variations of the same core experience, they invest in shared platforms and customize where necessary. The core stays unified.

How much of that change has to do with how the business buyer persona has evolved now that every business buyer is also on Amazon?

For me, that’s what I call a myth buster — the idea that B2B and B2C users need to be treated completely separately. Not anymore. The same people shopping for their business are shopping for their home every day. They’re used to experiences like Amazon, which is incredibly easy to use. There’s no tutorial explaining how to navigate the site. The simplicity teaches you how to use it without formally teaching you.

Organizations that lead in digital experience have figured out how to make their platforms intuitive enough that customers don’t need instructions. They simplify the journey instead of layering on explanations. Because of that, the gap between what a B2B and B2C website needs is shrinking significantly. B2B customers now expect the same convenience.

Measuring ROI and driving digital transformation

Simplifying B2B UX can feel risky inside a legacy enterprise organization. What signals or metrics demonstrate that ease of use directly drives ROI and revenue growth?

Excellent question. The way you measure ROI from ease of use is actually very different for B2B and B2C. I’ll start with consumers because it helps frame the contrast. For consumers, lifetime value can vary widely. They’re not coming to your site with a purchase list. There’s discovery involved. You’re selling them. They’re comparing prices, warranties, and competitors. So for B2C, you often measure ROI through things like number of sessions, time spent browsing, and how effectively you convert that discovery into larger baskets. The longer they’re actively browsing and not sitting idle, the better. You’re coaching them from, “I need one item” to “I’ll buy 10.”

B2B is very different. A business user is often obligated to buy from you because of contract pricing, free shipping agreements, zone pricing, or guaranteed inventory. They typically come with a purchase ticket, so they know exactly what they need. So the ROI question becomes: how quickly can they get in, place the order, and get back to their job?

For B2B, shorter session time can actually be a positive signal. Faster ordering, high adoption of digital channels over offline customer service, and smooth reordering flows are strong indicators that UX improvements are working. Average cart size also differs, as B2B might average around seven items per order, whereas consumers may average closer to one or two. So the KPIs — session length, adoption, conversion — are interpreted very differently.

Another important distinction is acquisition cost. In B2C, you may spend significant marketing dollars to acquire and retain a customer. If their experience is poor, they leave, and that investment is gone. In B2B, customers are somewhat anchored by contracts, but that doesn’t mean UX doesn’t matter. It absolutely does — especially at renewal time. Switching vendors isn’t easy for a business, but when contracts come up for renewal, ease of doing business becomes a major factor.

So the signal that UX drives ROI in B2B isn’t, “Are they spending more time on the site?” It’s, “Are they ordering faster? Are they adopting digital instead of calling customer service? Are repeat purchases increasing? Is retention strong at renewal?” Ease of use in B2B translates into operational efficiency, loyalty, and long-term contract value — and those are very real revenue drivers.

Given that B2B represents a significantly larger share of overall commerce than B2C, why do you think so many manufacturers and legacy organizations are still slow to digitally transform their ecommerce experience?

One big reason is comfort with the status quo. Many manufacturers still believe their old Excel sheet–looking websites can continue to drive revenue because their customers are used to it. There’s a mindset of, “Why do we need a better-looking website? Why do we need to make it easier? Our customers love it.” That belief persists because B2B relationships are often contract-based, and revenue doesn’t immediately drop the way it might in B2C if the UX is poor.

But that thinking ignores what’s happening in the broader market. When competitors invest in digital transformation and create simpler, more intuitive experiences, customers start to notice. And while switching vendors isn’t easy in B2B, it absolutely happens, especially when contracts come up for renewal. That’s often when the bell rings.

Another factor is slow technology adoption. Many legacy organizations are still transitioning from manufacturing-first mindsets to digital-first mindsets. And in today’s landscape, that’s risky. It’s no longer optional to invest in technology — especially with AI accelerating expectations.

Mobile is another example. Five years ago, not having a mobile app might have been acceptable. Not anymore. Entire businesses run from phones and devices. In one consumer example, 60 percent of traffic came from mobile devices versus desktop. B2B mobile adoption may still lag in some industries, but that gap is shrinking.

Ultimately, the opportunity in B2B is enormous — but so is the risk of complacency. The organizations that move faster on digital transformation will capture loyalty and long-term growth. The ones that assume customers will tolerate outdated experiences simply because “that’s how it’s always been” may not realize the impact until it’s too late.

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, Gustavo talks about why creating value should be at the center of every product decision. He also shares how to evaluate initiatives, think in terms of compounding value, and lead effectively as AI changes the pace of product work.

Creating value as a product manager

You came up through the financial world and corporate development before moving into product leadership. How does that background inform the way that you think about creating value as a product manager?

Everyone in finance is always thinking about the concept of creating value. My philosophy is that creating value is the first thing that a PM should prioritize. Product people need to deeply understand how we create value, and that understanding starts with the financials.

At a basic level, a company creates value by selling products or services perceived as more valuable than the resources used to produce them. Part becomes profit, and part goes to the customer as surplus. The role of the PM is either to increase the total value the product is creating or the value that the company can extract from that value creation. If that’s the goal, the only way I can achieve it is if I understand my pricing, my costs, and how I get more customers to acquire more or retain more. You need to deeply understand each one, as well as the P&L.

A lot of PMs are excellent at craft — writing specs, running discovery, shipping features — but struggle to connect their work to how the business actually makes money. In your view, what separates a junior PM from a senior PM, and how much of that gap is about business acumen vs. product craft?

What I see a lot with junior PMs, especially the better ones, is the ability to take a specific initiative and understand all the nuances inside that feature, including the edge cases. Even junior PMs can do that well, and it’s what they focus on. Honestly, I did that when I was more junior. I remember my early days — it was Waterfall back then — creating specs with 200 pages and then blaming people for not reading them when things went wrong. The reality is that’s not helpful.

The difference with senior PMs comes from understanding value — how you trace a feature all the way from the user problem it solves to the business outcome that it drives. Then you connect the dots, which allows you to shape the scope a lot better — both the scope of what is implemented and the scope of what you communicate.

You can distill a feature to its essential scope and use that to prioritize what is really important: What’s going to create value here? What is the opportunity cost of not doing something else that could be creating a lot more value? As people get more senior in their roles, they understand that better. The good and bad news for junior PMs is that a lot of the work junior PMs used to do, agents can do. But on the other side, that frees them up to automate the boring work and speed up their career to become a senior PM as fast as possible.

How to evaluate product investments

What mental model do you use when you’re evaluating whether a new product initiative is worth pursuing?

If we had a crystal ball, the answer is net present value (NPV). What’s the value of the company, measured by discounted cash flow, if I do this initiative versus if I don’t? We don’t have a crystal ball, though, so we use proxies. To understand how much value something creates, we look at how many more users this could help us acquire, conversion lift, cost savings, or strategic positioning. Then, we connect those proxies to the company strategy and current priorities. That’s where you evaluate: is this a high-impact standalone thing, but outside of the strategy, or does it align?

At LawnStarter, we usually start any initiative with what we call an opportunity document. It’s a very simple document with two goals. One is simple math — what’s the best-case scenario for the impact this could drive? For example, someone says, “We should add a route optimization feature for our providers.” This is a common complaint from our providers in support tickets, and it could save them X hours per week, which gives us X percent more capacity and translates into Y more in revenue.

The second thing is to write down the hypotheses and the questions you need to answer to test them. For example, what is the cost of implementing a route optimization system? It’s very compute-intensive. What exactly would pros want? Do they want something automated or something with a lot of customization? How much do we need to build to give a good user experience?

And from the customer side, what happens if we start telling customers, “Instead of Tuesday, I’ll show up on Wednesday because it saves hours of driving?” Is that OK, or does it drive churn? This document might have 20 questions like that, answered by data, design, engineering, or the PM. It’s about defining the research needed before committing — asking questions, not giving answers. Then you write a very short go/no-go statement: what answers would lead us to pursue this versus not?

When you’re determining whether or not something will add value to the business, there’s a tension between evaluating initiatives in isolation vs. looking at them as a whole in the system. How do you hold both of these lenses at the same time?

First, you need to have a company strategy. Ideally, you know what the overall themes are that you’re investing in and how much you’re investing. Initiatives should fit within those, and you prioritize inside that framework. If something looks like a great opportunity but doesn’t fit, then you need to escalate and ask, “What do we need to drop if we really want to do this?”

The second part is more ambiguous. From a product leader standpoint, you need a clear vision for where the product is going. That includes understanding which areas of your product are not just one-shot away from creating value. It might take six iterations, but you understand that value compounds in those areas. There are other areas where you take one shot and create value right now.

Going back to NPV, it’s not just about what value something creates now — it’s the future value and the compounding that really matter. At LawnStarter, one area we’ve invested in over the years is how we match a customer to the ideal provider. That’s at the core of our marketplace. If we had said, “This improvement only gives us 0.1 percent,” we would never have built a great system.

Sometimes you evaluate an initiative as a standalone thing. Other times, part of the value is that it’s one step in a staircase of compound value. That’s where things get more ambiguous, and honestly, where I’ve been spending a lot of time recently, reshaping my mental model as velocity increases.

Leading with vision in an AI landscape

With AI fundamentally changing the velocity of product work, how do you prevent this idea of “We can do more” from becoming “We should do more?”

It’s funny because at the same time AI is changing everything about our jobs — my day-to-day is completely different from what it was three months ago — it’s not changing the core premises at all. It’s never been more important to have a clear, well-articulated vision that everyone on the team understands.

Before AI, you could enforce that vision by steering a team — “We’re doing this,” “Adjust this,” “This is a little off.” But now we can do so much more that if you try to operate that way, it becomes like herding cats. You won’t be able to do it. Now, the priority is, “Does everyone understand the vision?” That’s crucial because even when you’re not in the room, the direction is still clear and you don’t need to steer. It’s like internal company self-driving. You don’t need to be at the wheel, and it still goes in the right direction.

Of course, for the most critical things, I’ll still be there steering. But there are going to be many other things happening at the same time that I’m not even looking at until they’re in production. You have to trust that you’ve given enough direction. If you’re not setting a clear vision and not thinking critically about what you should do before you do it, it’s very easy for the product to become disjointed.

I’ve seen SaaS products where there are three different ways the product is trying to present some AI interface, and none of them actually solve the problem. That’s probably because it’s what PMs were able to prototype and push. That’s not a recipe for success. Things start conflicting with each other.

You mentioned that having a vision is more important than ever. Can you talk about what’s changed and what hasn’t in your role as a product leader in the last 3 months with AI?

Having the vision was always important, but a big part of what changes now is the way I’ve been talking to my team. In the near future, we’re going to get to the point that 80 percent of the tasks internally at our company are done by AI agents. It’s not enough for me to just have a vision — I need one that is actually codified so that both human PMs and AI agents understand it and act accordingly.

More recently, at LawnStarter, I rebuilt our internal knowledge system using Claude Code. We now have an entire markdown-based system in a GitHub repo that the entire company is using. I created the system so every PM could use Claude Code to create things like opportunity documents, for example. Then, when they’re doing that, the AI has links to our business context, vision, company goals, etc., so that everything can be tightened up together.

Essentially, AI gives us the first revision of, “Is this aligned?” Part of it is: can you create this alignment with code? That is very different from creating alignment by showing up in meetings and telling people, “This is not good enough. This is different from how we are treating this other situation here.” That also meant that in the last two or three months, I’ve shipped more code than in my previous 20 years. Now, we have a tool that the entire company uses, and all of its context is connected to AI agents. Yes, the job really changed, but it comes back to creating value and to our vision. It’s just with a different mechanism that is way more powerful.

Understanding value creation in the marketplace

LawnStarter is a two-sided marketplace, which means that value creation is more complex than a single-sided product, because you have to serve both the customer and the service provider simultaneously. Can you explain how this dynamic changes the way you think about what metrics actually matter?

LawnStarter is originally a marketplace where you can get someone to mow your lawn. It’s since evolved, and it’s different from traditional home services marketplaces in that we provide a lower-friction experience for the customer. You enter your address, get a price immediately, and if you accept it, we send a provider to do the job. It works like the Ubers of the world.

In terms of metrics, I once heard someone say that marketplaces are more like biology than physics, which is very true. It’s a complex system. If you compare it with a SaaS product or a DTC product, often you have one customer, which means one degree of uncertainty. You do something, and if that customer responds in a certain way, you’re doing better. If they don’t, you’re doing worse. When you have a two- or three-sided marketplace, there are all these components and interactions, so everything you do impacts many different systems and metrics at the same time.

When we’re thinking about metrics for initiatives, we need to think about what we’re trying to move, as well as what happens on the other side. For example, let’s say we’re going to make a change to our marketplace policies. We need to think about how that impacts how customers view our service, what percentage of jobs get picked up by the top pros, how that impacts retention on the customer side, and then how it impacts retention on the provider side, their routes, and profitability.

You need to go a few steps deeper in the marketplace and understand how the loop works on those metrics, and make sure you are not just thinking, “If I improve this conversion metric, everything’s going to go great.” Sometimes you improve conversion, but get worse results. In marketplaces, when you’re dealing with metrics, you need to think more about the secondary and tertiary effects on both sides.

For a PM reading this who wants to start thinking more like a business leader, not just a product practitioner, what’s the first thing they should do on Monday morning?

I think the first thing is to step back and ask yourself, “Do I fully understand how companies create value?” Especially if you don’t come from a business background, it’s worth spending time studying that. There are plenty of good books and articles, and you can honestly ask ChatGPT or Claude to explain them. Understanding the economics of how value is created, captured, and compounded is super key for a PM.

The second step is to get specific. Do you understand how your company creates value and the role of your product within that? Not just hypotheticals — do you know your average price? How does your company price services? What are the acquisition channels, how do they map to pricing, what different kinds of customers pay for things, and when they value them? And what are the costs associated with that?

It’s also important to understand the cost side of the P&L — what you spend money on that could be used as leverage or cut down. With that knowledge, ask, “Do you have a vision for where this product should be in three to five years to create dramatically more value than it does today?” Then, can you trace everything you’re doing back to that?

And finally, if your three- to five-year vision does not incorporate a world in which AI agents are everywhere, you should rethink it. They will be. It’s already starting to happen. That’s the reality we’re all in. It’s better to try to have fun with it and embrace it than fight it.

What does LogRocket do?

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

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

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

In this episode, we talk about:

• The decision-making behind why Framework scrapped their roadmap

• Why iteration, not technical proficiency, has been the most important skill to drive AI adoption in teams

• There’s actually a scientific reason why everyone’s so overwhelmed, and it’s called the “Zone of Absorption”

1. Why Framework scrapped its 2026 roadmap in February

Most product teams treat the annual roadmap as sacred.

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

The replacement wasn’t a new roadmap.

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

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

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

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

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

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

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

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

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

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

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

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

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

Jen’s answer is precise:

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

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

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

Links

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

• Framework: https://frame.work/

Resources

• ThredUp: https://www.thredup.com/

• Anthropic: https://www.anthropic.com/

• Leadership Without Easy Answers by Ronald A. Heifetz: https://www.hup.harvard.edu/books/9780674518582

• The engineer's ring: https://www.nspe.org/career-growth/pe-magazine/july-2009/called-order

Chapters

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

What does LogRocket do?

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

In our conversation, Khetiwe talks about her approach to thoughtfully introducing AI into complex marketplaces and the importance of building trust across stakeholders as part of that process. She shares how to avoid solving for the loudest voice and, in turn, how to anchor decisions in the right metrics. Khetiwe also discusses the evolving role of AI, including when to use it and how context and governance will shape its impact on decision-making.

Knowing which customer signals to solve

In B2B2C marketplaces, signals from clients, end users, and suppliers often conflict. How do you determine which problem is structurally important vs. just the loudest in the moment, and what signals do you trust most?

Often in B2B2C or marketplaces, the person or entity that’s paying, i.e., the client, is often the loudest. You’ll hear the client feedback, and that is really critical because your paying client is in control of the contract and derives revenue. But it’s important not to fall into the trap of treating every client request as a signal. You have to make sure you’re looking at whether the problem is solving for one side of the marketplace without degrading another side’s experience.

At Cartus, one of the flagship products was a self-service benefits selection tool. The transferee could select what benefits they were interested in, and one of our clients asked us to build in a quote functionality, which seemed simple and made sense on the surface. But as we thought more about it we realized that generating a quote before the person has decided what benefits they want is premature. The customer hasn’t entered the information necessary to generate a proper quote, and the supplier is looking for enough information to generate that quote.

If the user is in a self-service experience and hasn’t made the choice for that service yet, it’s too early to ask them for all of that information. So to balance that need we created an estimate tool, because that’s really what the client was looking for. They wanted the employee to be informed about the benefits they were choosing and how much that might cost.

That’s the balance — you hear the signal, but you don’t overrotate on doing exactly what the stakeholder is asking. You have to be thoughtful about how that impacts all stakeholders. The client didn’t at first love it because they were anchored on a more manual process, but after explaining the self-service nature, they understood.

Are there certain categories or instances where teams think they’re solving a user problem but are actually shifting friction to another party?

Absolutely. It’s important to understand who you’re solving for upfront. I’ve seen it a number of times where you think you’re solving the problem for the full stakeholder ecosystem, but you’re really only solving for one side.

For example, at Rent, the product was an advertising platform for people looking for apartments. Users go on the marketplace, look for an apartment, and submit a lead. If we’re only solving for our clients, the property management companies, then we’re solving for volume and quality of leads. They want all the information about when the user plans to move, what their family size is, if they have pets, etc.

But if we have all of those questions on the lead submission form, the renters won’t submit it, because it’s too much to fill out. So you really have to consider whether you’re solving for the core ecosystem or shifting friction from one group to another. If you strip down the questions, you’re shifting friction to the property, because now the property managers have to call the lead to get that information. On the opposite end, if you include everything, you’re shifting the friction to the renter, who has to fill out a long form just to learn more about the property.

There’s a real balance there. When you’re problem-solving, it’s not just about solving for one component — it’s about balancing friction and solving for the whole ecosystem.

Frameworks and signals across the full ecosystem

Have you developed any frameworks to predict when an optimization for one side will negatively impact another?

It’s funny — you can ask any of my team members, “What does Khet always say?” The number one thing they will tell you is, “What problem are you solving for?” That’s what I always ask my team. The two frameworks I use are simple: one, what problem are you solving for, and two, how are we changing the process as part of the solution? These aren’t formal frameworks, but they work because the problem needs to be holistic. You’re thinking about who the primary stakeholder is, but also how the problem impacts other stakeholders.

In answering how the process changes, you have to understand the current state, the future state, and the delta between them — what you’re actually changing and impacting. It’s straightforward, but that’s why I like it: what problem are we solving, and how is it going to change? If you think about more traditional frameworks, one is first principles — thinking about second-order effects when solving a first-order problem. What is the first-order thing, and what are the second-order effects it might have?

I come from a consulting background. Bain & Company has a hypothesis-first approach — before we build anything, what do we believe, and what assumptions have to be true to validate that? I use that mindset in product as well. What experience does the client need? What experience does the customer need? What experience do supplier partners need? That helps ensure the overall experience works.

What’s the primary metric you anchor on in a marketplace like this, and where have teams been misled by the wrong metrics?

This actually ties to the previous question about frameworks. One of the frameworks I love is the OKR framework, or objectives and key results. People say OKRs and sometimes don’t understand the spirit of it. For me, the essence is: what is the business objective we’re trying to solve for, and what are the key results that tell us we’re moving in the right direction?

There’s lifetime value and all kinds of key results a product person could use, but it’s important that a product team understands the mission and goals of the company. The team shouldn’t dream up objectives and key results that are separate from those of the organization — you need to focus on the core outcomes for the company.

For example, Cartus’ mission is to help people move with ease. If that’s the mission, then the primary goal should be: was it a successful relocation, and was the transferee happy? The client pays the bill, but if those two things are moving in the right direction, the client should be happy. Those are the core signals for whether we’re moving in the right direction, with other supporting metrics alongside them.

The same applies at Rent. The goal there is to help people find a home. If we’re spamming properties with hundreds of leads that consist of just a name and email, we’re not helping them close a lease. You could use the volume of leads as a metric, but that can lead you in the wrong direction. The client goal is to get leases. To do that, you have to be thoughtful about the balance of key health metrics — you need traffic and volume, but you also need quality. And you have to measure that quality to make sure it translates to what’s ultimately important, which is getting someone into a home.

Building trust when introducing AI

It’s impossible to have a product leader conversation today without talking about AI. In a domain like relocation, where decisions have significant financial and personal impact, how do you introduce AI into workflows where stakeholders need transparency and control?

It is a balancing act. In relocation, trust is really important; it is a benefit just like health, vision, or dental. You can’t get that wrong. If the company says you can move your family and your pets, but then we say “oh yes, we can move your horse” and that wasn’t in the policy, the transferee has already planned around that. Now you have a financial dispute, a broken promise, and a client whose employee is irate mid-move. Trust in the whole service breaks down fast.

So it’s important that you’re using AI in a safe and trusted way to maintain that trust. I think about it in two aspects. One is: can AI be trusted to reliably solve the problem we’re trying to solve? That’s for the product team to determine. The second is: is the client or stakeholder ready to trust that AI solution? There are two sides of the coin.

First, you can evaluate through a cost-benefit lens. Is this the right solution? Can we afford to invest in it? That’s traditional product thinking applied with an AI lens. But with AI, you also have to be thoughtful about whether your end user will trust it.

A funny example is one of our large clients, one you’d expect to be very AI-forward, told their account rep that they didn’t want us to use any AI and asked to stipulate that in our contracts. But when you peel that back, it’s not that they didn’t want AI — they just wanted to make sure Cartus was providing the service. So it’s important how you frame the use of AI.

Implementing AI does not automatically mean the removal of people. And if that is a major concern, as it is in relocation, then leading with “AI will answer transferee questions” lands very differently from “AI will allow us to meet your transferee’s unique needs whether answering a quick question or putting them directly in touch with their consultant”. Positioning matters as much as the technology.

Lastly, starting internally is often helpful. Automating known, repeatable processes is a good place to begin. We did that at Cartus through initiatives like reading invoices, auditing, and automating templated processes. By the time the client was ready, we were ready to move AI into external experiences.

Have you had any experiences where you’ve seen a team misapply AI or use it in a situation that’s not the right use for it?

One of my pet peeves is, “Let’s come up with an AI roadmap.” AI is a tool that can be used to solve problems, but it is not the roadmap on its own. You need to be thoughtful about what problems you’re trying to solve with AI. Everything you’ll hear from my team and me comes back to: what problem are we trying to solve?

I’ll give you an example where we applied AI, not necessarily in the wrong place, but maybe at the wrong time or without the right support. At Rent, we launched a natural language search bar on apartment.com. It was similar to how you can type into Amazon in plain English and get what you need. This was in the early 2020s, around COVID. Users weren’t adopting it, and we couldn’t figure out why. We thought it was a great experience.

As we discussed it, someone pointed out that the low adoption rate was probably about trust. If I’m shopping and I type, “I want fun pajamas for an eight-year-old boy,” I’m OK with getting results that are close. But if I’m looking for a home, I want it to be exactly what I’m asking for.

At the time, people weren’t experienced enough with AI and natural language to trust that if I typed “patio,” the system might interpret that as a balcony or an outdoor space. So there wasn’t enough trust. People preferred to use filters because then, they knew exactly what they were choosing. That’s an example where AI may not have been the right choice at that time. Or we could have blended approaches — using AI for the search, but traditional methods to show what was inferred, to give users more visibility and trust.

We eventually rolled it back, and the adoption data made that call clear. Users were telling us through their behavior that they trusted filters more than free-form search, and we listened. Many home search websites have natural language search now. The solution was right, the timing wasn’t..

AI tools are evolving and changing so quickly. As an executive, how do you decide how in-the-weeds you want to get with AI tools, and do you intentionally carve out time to upskill in that area?

As a leader, I need to understand the tools, the processes, and the work my team is doing so I can support them effectively. So yes, I carve out time to dive into the tools, try them out myself, and build things. Honestly, it’s quite fun. I have an undergrad degree in computer science, and AI has allowed me to tap back into that part of myself that was writing code and building things.

I think it’s important for a product leader to stay close to the technology, not just for that reason, but because AI is changing how we structure our teams. There are product managers who implement AI features, and there are also AI-native solutions that require AI PMs. That differentiation is new, but a lot of people are talking about it. Are you a PM working on AI features, or an AI PM building an AI-native solution? The problems they’re solving are slightly different, and the skill sets are nuanced. As a leader, it’s important to understand that difference, so you can build your teams appropriately, deploy them against the right problems, and be effective.

How AI is reshaping decision-making and ownership

How do you see AI changing how decisions get made across the multi-stakeholder marketplace?

I think we’re on a really interesting frontier. It’s less about the LLMs themselves and more about context engineering, which is where does the information live, and what information is guiding the AI?

What I find interesting is that if AI is making decisions, then the available information becomes the most important source of truth. That becomes your most important asset. Whoever controls that context controls the outcome. So how are you, as an organization, making sure that the context the AI is using is up to date, correct, and reflective of your principles, governance, guardrails, and policies? As more decisions are pushed to technology, that becomes really important.

Even if you maintain a human in the loop where the final decision is made by a person, AI still plays a major role in the fact-finding and information leading up to it. That underlying knowledge set becomes critical.

Even with a human in the loop, who owns the ‘context’ that AI relies on, and how do you feel that responsibility should be structured?

I don’t know that there’s a standard way to determine who owns the context now because it’s so new, especially at the enterprise level. I don’t think there’s an agreed-upon practice yet. It raises the question about whether there will be context engineering or a context owner role that coordinates across teams. Or will it sit with individual stakeholders, so marketing owns marketing context, for example? It could be pushed out to the core business. I think that’s going to be really important.

Even with a human in the loop, where someone is reviewing the output, people may agree with the result most of the time, thinking they made the decision. But a large percentage of the time, they may actually agree with the wrong answer because there’s a bias to assume it’s correct. So in this kind of world, context becomes even more critical. You have to make sure the inputs and guardrails are in place to prevent that type of risk.

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.

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.