In this conversation, Renee talks about what it really takes to bring users along through major product transformation, from winning organizational buy-in before a redesign begins, to migrating tens of thousands of users off legacy platforms without losing their trust. She discusses how to decide which friction to remove and which to preserve, what she learned consolidating products after an organizational merger, and how AI is changing (and not changing) the fundamentals of good UX.

Aligning the organization around users

Bringing the organization along is often one of the hardest parts of transformation. How have you approached getting organizational alignment?

As technology advances, transformation is constant, particularly right now with AI. But I’ve also been through transformation caused by organizational changes, not just technology changes.

In terms of getting organizational alignment, taking time for discovery and input from users, in my experience, can be one of the most challenging things to convince internal stakeholders to accept. They generally agree in principle. It’s not that they ever say, “We don’t want to hear from our users.” They always say, “We want to hear from our users.” But then in practice, time schedules, wanting to ship faster, wanting to meet deadlines, revenue concerns, and that sort of thing will cause some people to bypass what we’re actually hearing from users.

I’ve found success by involving stakeholders from all different areas of the organization, because it doesn’t work if only product is on board with how we’re going to make this big change. Marketing also has to be on board. The engineering team has to be on board. You need to include stakeholders and make them aware of what users need in that transformation. Sometimes that means having them actually sit in on user interviews. And also share data, because hard evidence is difficult to ignore.

It’s challenging, though, because between the time schedules and the resource considerations, there are a lot of different factors going into how things need to happen. But it’s not going to be successful if you’re transforming into something that users aren’t going to want.

Discovery is a big piece of it, and I’ve found that’s where corners often get cut.

Migrating 80,000 users without losing them

You recently helped consolidate multiple legacy platforms into a single experience and migrate more than 80,000 users. What did that teach you about the difference between building a better product and getting people to adopt it?

Talking to users constantly throughout the discovery and the development process helps to identify and anticipate areas of potential friction. Even if the new product provides easier, faster ways for users to meet their goals, people have established habits in using digital products, especially things they have to use for their jobs.

We were working with professionals who were using our software to identify potential funders. Once they’ve established those habits, they’re not really keen to learn new methods. Even if the new methods make it easier, it’s like, “I go through these steps. That’s how I do my work.” So it’s really important to anticipate the friction points, eliminate them where possible, but also provide guidance where necessary.

We used tools like Appcues, a customer engagement tool that provides a variety of methods for customer guidance. For different features in the product, we would use different methodologies. Appcues would help us build multi-forked tours of the product. It could also provide really quick guidance around a particular feature, if we felt like that feature was valuable, but we need to give them a little bit of a handhold to get used to it. Like features that use AI — I had this experience with LinkedIn. They just deactivated their classic search and replaced it with an AI search that’s supposedly better, but all my microfilters are gone.

We experienced a lot of things that were similar to that. In addition to providing guidance within the product that’s right in front of the user, we created short videos around certain features: “Did you do this in the other product? Here’s how you do it in this product. Here’s how you achieve that thing.” They weren’t polished videos, they weren’t something that we would put on our website. But, when customers were reaching out to our customer support team, they could share the videos with them. It was a very quick and visual way for people to understand what the transformation was.

We had a variety of users, from the once-a-year user to the daily or weekly user. It was really those daily and weekly users we were most concerned about — a smaller group of the paid subscribers and the people who were consistent users of the product. When I did a revamp of another product, we offered customers a choice: Check out the new thing, but you can still go back to the old thing. At one point, we gave them the option to commit. By the time we reached the end of that transition period, we only had a small group of diehard stalwarts that we had to forcibly move over.

It’s a matter of really listening to the feedback — as people are moving over and telling you, “I can’t do this,” or “I’m having a problem here,” sometimes you have to go back and redevelop some of the pieces of it.

Deciding what friction to remove and what to preserve

During a major migration, some amount of friction can help users understand what’s changing and build confidence in the transition. How do you decide what friction to remove and what to preserve?

Friction can be caused by the removal or change of a feature that users deem essential. I find that the best way to identify those points and try to resolve them is by observing users in both the old product and the new product.

We would do a lot of sessions where we would give the users prompts and ask them to walk us through. They would be speaking aloud and talking us through. Then you would see immediately where they would get stuck and just freeze up and you would say, “Well, what are you thinking?” You don’t lead them to the next step; you just observe them using the product, because it could be that they’re just stopping to think. We had a data product, so it was a lot of information to process, but it could be that they got lost and the friction was inspectable.

Looking across the modernization initiatives you’ve led, what decisions had the biggest downstream impact on customer experience?

Staying on top of the changing levels of technological literacy of our customers. As technology advances, users have expectations and an understanding of products that function well and that give them confidence in the product. For example, e-commerce flows have evolved really significantly over time, and a poor e-commerce flow can be a dealstopper. It could work fine, but if it doesn’t feel polished and elegant and inspire confidence in the user, nobody wants to put their credit card into something that looks janky.

But the biggest decisions were those where user feedback and data were ignored. Those have the biggest downstream impact. I went through some of that — where UX recommendations got overridden or overruled.

Oftentimes it’s done, almost always, in the interest of time savings or rush to market. And it ends up being costly: I’ve experienced situations where parts of a product had to be rebuilt. That’s why having top leadership agree to take in all that user feedback is really critical. There are just times where everyone feels like they’re making the right decision, but forcing through expedient solutions that end up being problematic has a huge impact on customer experience.

Building feedback loops that keep transformation honest

You’ve led designers, researchers, engineers, and product teams. What operating models have you found most effective for turning customer insights into product decisions?

Face-to-face contact with users, observing how they use the product and understanding their relationship to technology — not just how they used your piece of technology, but technology in general.

In terms of development, there are a lot of different models. Over my past career, I’ve worked with everything from waterfall to agile to scaled agile to product operating model. From my perspective, a true agile development process is the best for continually integrating user feedback throughout the development cycle because there are multiple points where you can inject the user feedback into revisions of the product or additions to features.

With other product development models, it’s very hard. We followed scaled agile for a while, which is really closer to waterfall, and it was really hard because once you got the feedback, it would take months to get the report as opposed to weeks. Being able to have that cycle continually, that continuous development and user feedback going through, helps to make sure that’s taken into consideration.

Is post-launch feedback the same face-to-face approach, or does it look different?

Yes, but a lot of really critical initial feedback comes from the customer support team. If it’s a situation where people are reaching out to support, we need to tackle it and address it urgently.

You can’t just put something out in the world and then leave it alone. We continually observe user patterns using automated tools that do recordings of usage and show where their cursor is moving on the screen. When new features are released, I like to do spot mini surveys around a new feature. Just one or two questions, like: “Is this working for you? Did you have trouble with it?” We’d get a decent amount of feedback from NPS, which we’d use to gauge the overall tenor of customer satisfaction.

Merging two products into one

Following the merger of two established organizations, you helped create a unified product experience. How did you decide what to keep, what to retire, and what to reinvent?

We identified our critical customer personas and their needs. We looked at the usage data of features in the legacy products to determine which features were absolutely essential to replicate. We spoke to users about what could be improved from the old products.

You have to take all of that information in — What are they using? How are they using it? What are the problems that they have to solve? But, you still have to go at it as a completely new product that you’re building from the ground up, because it’s too easy to get mired in the way things were previously coded. Especially with technology moving as fast as it is, you need to be freed up to take all of that information, decide what you’re going to build, but don’t try to replicate. Build it in the most modern way possible.

We did make a list, kind of like a big chart: “Here are all the critical features from this product, here are all the critical features from this product, and here’s how you do it in the new product.” That was mainly for educating our own teams.

Did you end up compromising on some features?

We did, certainly. Trying to replicate some of what was there before slowed us down. I feel like some of the compromises didn’t work out. Anytime you build something new and the customers, as they’re getting used to it, have an opportunity to try it out, they’ll tell you, “I need to do this and I can’t do it.” Sometimes you have to say, “OK, we actually have to move fast and build a way for them to do this.”

There were many, many compromises. The compromises came from any number of corners of the organization — some from users, some from customer support, some from marketing, some from engineering.

What AI changes — and what leadership must get right

AI has made it dramatically easier for people outside of design to generate interfaces, content, and workflows. Are the core principles of UX changing?

I don’t think the core principles are changing. With AI, some people might choose to ignore them, but that can result in some sloppy stuff. But, AI makes it a lot easier to do rapid prototyping and put solutions in front of users faster and more frequently.

Working in nonprofit technology where resources are limited, prototyping was always a challenge before AI because oftentimes it required engineering resources. I’m a big fan of paper prototyping, and everybody makes it sound really easy, and it’s not. The fact that you can use AI and build a prototype that feels like people could get their hands on it — that’s going to really help, if people use it to actually get more user feedback.

Are there parts of the design process that need to remain with humans?

I think so. My designers loved using AI. But I don’t think it’s so different from using AI to write a first draft, using AI as almost like a scratch pad to play around with a lot of ideas quickly as opposed to building them yourself. A human needs to apply their aesthetic — AI doesn’t have an aesthetic, and that is subjective. There are some people who are very talented in that area and people who aren’t, and we still need those very talented people who see something that nobody else sees.

I think it can be a launchpad. If somebody needs a simple website and AI can build it for them and they don’t need to worry about brand or any of that, have at it. But there are a lot of small things that only a human can really pay attention to in terms of detail. And those details, I strongly believe, impact usability.

If you joined a product organization tomorrow to start a new modernization effort, what’s the first thing you’d assess?

The organization’s top leadership has to have high interest in truly understanding the problems that they’re trying to solve for their customers. User-centered product design and development has to be supported from the very top of the organization to be successful. If I were joining a new organization, I would want to know that human-centered design was a priority for the leadership all the way up to the CEO.

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, Idan discusses how AI is reshaping product development by giving individuals more agency and changing the way teams collaborate. He shares why prototypes are becoming the new language of product development, where the next bottlenecks will emerge as execution accelerates, and how leaders can create the guardrails needed to maintain alignment without slowing innovation.

AI’s expansion of individual agency across teams

Over the past year, AI has expanded individual agency faster than organizational capacity. What kind of work have you seen collapse into a single role faster than you expected?

There have been a lot of experiments — people doing things that wouldn’t traditionally be part of their job description. I wouldn’t say there’s been a full collapse or merging of roles, but boundaries are absolutely becoming blurrier. With more agency, individuals are taking on areas that would have previously been unexpected.

From where I sit leading design, I see PMs prototyping their ideas very early on. That shift from a document and a hypothesis to tangible output, helps us raise questions, create alignment, and understand edge cases that otherwise would have required much more iteration. I find myself reviewing work with PMs and having design discussions that I previously would have had only with designers. PMs are using design agents and making decisions that enable designers to build on top of that work instead of starting from scratch.

Today, our product and design teams are often prototyping directly in our product repositories, and we are working to expand this approach — bringing product and design closer to the production code that ultimately ships to users. This brings us much closer to engineering and creates questions about how we reduce the translation between PMs, designers, and engineers, so that we’re continuously building on each other’s work, rather than starting over every time.

I wouldn’t say the roles are collapsing, but actually expanding. The boundaries that used to be much clearer are no longer distinct. I think that’s a good sign.

How does engineering feel about this shift? Do they find that when a design gets to them it’s better vetted, or do they feel isolated from the beginning of the process?

Our engineers are actually getting involved earlier because ideas are being shaped into tangible output much sooner. Once I have a prototype and a direction, I want engineering involved immediately to validate that we can build it.

While this approach has allowed engineering to begin work earlier, particularly on backend and architecture, it has also created confusion when there is no clear source of truth across multiple artifacts being developed simultaneously — for example, a product prototype, a design prototype, and Figma. Some designers, including myself, have submitted pull requests into production, but it’s very contained. These types of changes can be risky when they happen at scale in a mature company with millions of users, that’s why it’s important to have strong guardrails.

This could look very different in a startup environment where founders wear multiple hats and the priority is shipping quickly. The boundaries are probably even blurrier there. At Via, due to our scale, engineers now see expected outcomes in much greater detail much earlier. For example, most of our product surfaces are maps. Translating a static Figma file into expected map behavior is incredibly difficult. Think about Google Maps and the transitions between zoom levels, when points of interest appear and disappear. Those interactions are hard to communicate.

When you can prototype that behavior instead of describing it, it creates alignment, improves quality, and increases velocity. The next question becomes how to bring that work closer to production instead of rebuilding it from scratch.

AI tools sometimes introduce friction or disruption. What have you experienced? And are there forms of disruption that are actually healthy signs of adaptation?

Absolutely. I’ve spent a lot of time over the past year thinking about how we adopt AI and change our processes. I can share a good example from one of our mobile teams. They created an incredible prototype of a very complex feature that showed how the experience would work with all the interactions. It looked amazing. They started with just a few designs in Figma to create the foundation, and then built the rest in Cursor.

When we reviewed the concept, most of the conversation centered around the prototype. It created much better alignment between leadership, PMs, designers, and engineers. It also helped us discuss scope because we could clearly see what could be phased. Then the engineers asked, “Where’s the Figma? Where are the specs?” We only had a few screens in Figma. Everything else existed in the prototype.

This was a healthy problem to have because the prototype created so much value. It improved velocity, reduced manual work, helped leadership discuss scope, gave engineers feasibility input, and communicated interactions that would’ve been difficult to explain otherwise. Our challenge now is figuring out the best way to translate those prototypes into production code.

Where I do see negative friction, though, is when PMs begin prototyping. The goal should be to define the direction, not create the final design. But, once a prototype is shared with leadership and other stakeholders, it can begin to establish expectations for what the final product should look like. That puts designers in a difficult position because once a design direction has been established, it’s much harder to challenge or rethink it. We need to be very mindful of that dynamic.

AI is changing the shape of product development constraints, but it hasn’t eliminated them. As teams become capable of doing more with the same resources, where do you see the bottlenecks shifting?

In the short term, I still think the bottleneck is translation. Going back to the prototype example, if you have an advanced prototype that represents the ideal outcome, how do you reduce the amount of engineering work required to build it? We’re experimenting with spec Markdown files, building directly on our repos, and improving our design system so it’s more effective for agents, not just humans. That’s where we can unlock even more velocity.

The value already exists, but AI helps us reach alignment faster and build conviction earlier. The remaining bottleneck is how we hand that work off. Longer term, I think the challenge shifts toward distribution and communication. If you look at companies like Cursor, Claude, or ChatGPT, they’re shipping updates almost daily. Every time I open Claude, there’s another version. The question becomes: how do users absorb that much change?

This creates a different bottleneck around distribution, marketing, and communication. It’s a healthy problem because historically, engineering velocity was the bottleneck. Now, the bottleneck may shift to helping users understand and adopt what’s changing. So, in the short term, it’s about removing the translation layer, but in the longer term it’s about managing distribution and adoption effectively.

Why leadership needs stronger guardrails

As AI gives individuals more agency, are there responsibilities that should remain firmly with a specific function instead of becoming more fluid?

I think in the short term, yes. In the long term, it’s harder to say because the models are progressing so quickly. But, the trajectory is very clear — the AI models continue giving more agency to each individual. Right now, I think there’s a big difference in the level of risk that different stage companies are willing to take.

At Via’s scale, a big change will happen when everyone adopts more of a builder mindset. This will enable team members to cover more ground, while different functions shift from being executors to contributors earlier in the process.

For example, a PM can prototype without producing a polished design. Designers can help with system thinking, identify risks in the proposed solution, and continue shaping the prototype before taking ownership later in the process. Instead of a clear handoff, designers fade in as the direction becomes more mature.

With this model, I think each team member will be able to move farther ahead while other functions act as consultants until it’s time to take ownership. The important part is making sure no one gets too far ahead before designers or engineers have had the opportunity to provide input. That’s why the guardrails matter.

With development accelerating so quickly, what areas have become more prone to breaking down?

I think the biggest risk is around the fundamentals. A couple of years ago, we spent much more time defining the problem. Why are we solving this? Why is it a priority? How do we know this is the right opportunity? How do we build conviction that we’re solving something valuable? Only after we answered these questions, would we spend time designing the solution.

AI lets you move much faster into advanced stages of building, but that creates the risk of losing focus on what you’re actually trying to solve and why it matters. Ideation, experimentation, and building have become much cheaper, so it’s tempting to explore more and more solutions instead of staying disciplined about the problem.

I’ve seen teams make progress and then come back a week later with a prototype that’s completely different. My first question is always, “What happened? How did we get from here to there?” That’s the risk. When building becomes cheaper and faster, it’s easy to keep testing new ideas without staying anchored to the original problem.

Is there anything you’ve changed your mind about over the past year as you’ve watched your teams adopt AI?

Definitely. And I’m sure there will be more changes over the next few months because everything is evolving so quickly. A few months ago, I imagined a process that would give every function much more agency. There are already many examples of companies where PMs can go end to end — from defining the solution to merging small changes into production. I used to think that designers would move further into frontend development while engineers would spend more time on backend work, architecture, and other complex engineering challenges.

Today, I look at that differently. The question I keep asking myself is: what value are we actually creating? I’m no longer convinced that value comes from PMs producing designs that are nearly as polished as a designer’s work. The value is already enormous when PMs can build conviction, clarify requirements, and define the product direction through prototypes. That’s where designers can step in and build on that foundation.

Similarly, I don’t think designers necessarily need to make pull requests. Personally, I don’t want bugs assigned to me that I don’t know how to fix. So I’ve become a little more conservative. That might change again in six months, but today I think the biggest opportunity is for PMs to create strong prototypes that establish direction, and for designers to create polished prototypes that help engineers clearly understand what should be built. I’m focused on finding ways to help product, design, and engineering extend and build on one another’s work, rather than rebuilding at every handoff, and leveraging that to accelerate the path from idea to execution.

Preparing organizations for AI-native work

Are the behaviors of your team’s top performers different compared to a year or two ago?

Sure. Today, they’re using AI to articulate and visualize their thinking. When a PM is working through complex logic, it can be difficult to absorb that by reading a document. But when they build a quick prototype, it immediately becomes much easier to understand how different states and interactions work. The same is true for engineers. Instead of explaining backend architecture or APIs through documents or spreadsheets, they can build lightweight prototypes that communicate those ideas much more clearly.

The strongest performers understand the complexity they’re dealing with and use AI to visualize it in ways that create alignment and accelerate decision-making. The output isn’t always faster code or faster design. Often it’s those side projects — small demos and prototypes — that make the main work move much faster. From a leadership perspective, that’s incredibly valuable because it creates alignment early and reduces the need to revisit decisions later.

The second thing I see is constant learning. Our top performers are always testing new tools, those problems much cheaper to solve. Instead of leaving something in the backlog indefinitely, they’re asking, “Can I solve this now because AI makes it practical?” They’re using AI to cover more ground and create more impact.

Many established companies are layering AI onto structures designed for a different era. What organizational patterns do you think will feel outdated in a year or two?

The scale and complexity of work are going to increase dramatically. If every team member is running multiple agents, the challenge becomes understanding what’s happening across all of them. That will require rethinking how we work. I suspect that some of our existing rituals, like standups, will evolve. Those checkpoints exist to create alignment, but when agents are constantly producing information, we’ll need smarter systems that decide what to surface and determine when humans actually need to get involved.

This will likely lead to smaller teams. Startups are already showing us what’s possible in this regard. Companies that once required 50 people are now operating with five or 10 people supported by AI. For larger organizations like Via, that transition will take longer because the risks are much higher, but I do think we’ll eventually see smaller teams supported by intelligent agents that help coordinate work and highlight where human judgment is needed. Communication will become one of the biggest challenges, and it will force organizational change.

What advice would you give leaders who find their orgs are moving faster but are becoming harder to align?

To be honest, I’m still figuring this out myself. It helps to establish very clear guardrails around when different functions should become involved. As individuals gain more agency, they can do more work independently, but designers still need to be involved early enough to provide their perspective, identify risks, and shape the direction before it becomes fixed.

The same is true for engineering. Once there’s a clear direction, bring engineers in early to validate the approach and identify constraints that others may not see. Being explicit about when different functions should be involved — or at least informed — is critical during this transition. Until we reach a more agentic way of working, clarity around those collaboration points is one of the most important things leaders can provide.

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, Scott shares why empathy is the foundation of great product management and how the simple mantra, “I am not my customer,” has shaped his leadership philosophy throughout his career. He discusses balancing user research with data, preserving empathy while building products at YouVersion’s global scale, and where AI can — and shouldn’t — play a role in product development.

Understanding people before building products

You’ve led products that range from booking travel to designing hypercar experiences to helping people build spiritual habits. What have those very different products taught you about human behavior that you think every product manager should understand?

The products and experiences I’ve been involved in are wide-ranging, but I think there’s a common thread among them. In the end, people come to a product or service because they have a need they can’t meet themselves, or they’re looking for expertise to meet that need.

In travel, it’s much less about the destination and more about the experience. In hypercars, it was about the quintessential thing that could not be had that’s customized or unique. In my current role, people come to Scripture or faith with a particular desire, history, or path, and they’re looking for something. Everyone’s on a journey, and whether you make a physical product or a service, the idea is that someone invites a product or service into their life because they’re looking for something from it.

In the age of AI, as automation gets good enough to deliver a flawless product experience, what human function can still not be automated away?

This is such a big topic right now — not a day goes by without some kind of conversation about what the future of product management looks like. While I believe AI experiences and automations will improve, I still haven’t seen where taste meets function. It’s very hard to understand good taste from bad taste, or appropriate responses, questions, or ways to deal with a situation.

If you’re coming to something and you say, “I have anxiety, and I need help,” there’s a different response than, “I want the fastest hypercar in existence.” Being able to contextualize your responses and build products with those human needs or desires in mind is something I don’t know will ever be automated.

The fun part is that you can now try more options or have more experiments. We don’t necessarily have to get it right the first time. We can try three, four, or five times for a much lower price or with much less energy spent. I look forward to bringing the right tone, the right experience, good taste, and simplicity, while also being able to go up to bat multiple times at a lower cost.

When you’re trying to understand what customers actually need, how do you separate what they’re asking for from the underlying problem they’re trying to solve?

It’s nuanced because sometimes what people say in a user interview doesn’t match the behavior you see in the data. Someone might say, “I want X, Y, and Z,” and then, when you observe their actual behavior, they want something different.

At every organization I’ve worked at, we’ve spent a lot of energy on user research, putting that alongside the data, then measuring and analyzing them together. If you bring only one or the other, you don’t have the whole story.

I’ve also learned not to ask direct questions about particular products. It’s tempting to ask, “Do you like the thing that we made?” But it’s better to ask, “How did you get here? What made you step in this door?” Learn the why before the product. I tend to go back one or two steps, and that’s usually where the real nugget of information is.

Understanding what customers need from a product requires empathy. What does empathy mean to you before it becomes anything on a product roadmap?

To me, empathy means being able to think about someone else — or their experience — in your day-to-day life. For example, how does what I’m doing impact others? What are others around me thinking, feeling, or responding to as I work or live?

‘I am not my customer’

Did you have a moment in your career that taught you the importance of user empathy?

I definitely experienced this during my time at Expedia. One of Expedia’s policies was that you go to the call center and listen to people who had called in — because that meant that something had gone wrong with their vacation, like a delayed flight or extra, unnecessary charges. If you ever want to feel terrible, listen to people talk about how their dream vacation had a problem! That was the beginning of my journey to really understand how much emotion is tied to the product.

As we spent more time in the call center and with user research teams, the phrase “I am not my customer” cropped up. We all had an aha moment around this and even made T-shirts that we wore in the office that said, “I am not my customer.”

I’ve carried that with me ever since. If I’m not careful, I end up designing products for myself and don’t represent the buyer or customer. That’s become a mantra for me: “I’m not my customer. I need to remember who they are.”

Are there any rituals you use with your team to reinforce that idea?

Bringing in perspectives is important. At YouVersion, I like to start team meetings with stories and feedback that we get from people who’ve had either a great experience or a bad experience. Anyone can bring one. It grounds us in everything we’ll talk about afterward. If we’re too tactical, we’ll keep building things for ourselves. If we start with the story of someone whose life was changed — or someone whose life was put out or uncomfortable — by what we did, it grounds us in remembering who we do it for.

Empathy can often be at odds with hard metrics, like retention. How do you keep your team empathetic while still managing outputs?

We have an internal phrase: “Data has a seat at the table, but it doesn’t occupy all the seats at the table.” Every time we come to the table with data, we also come with research. Then we ask what we’re actually trying to do. Is the data helping us accomplish the job to be done, or is it steering us toward an imaginary goal?

Data has a seat at the table, as does research. The overall “why?” belongs there too. Data is a tool — one of many in the toolbox. We’re much better at getting data than we’ve ever been, but I don’t think it tells the complete story.

Scaling empathy without losing the individual

At a scale of a billion downloads on YouVersion, how do you keep the user from becoming an abstraction you’re optimizing against rather than a person you’re building for?

This has been the most demanding and meaningful stretch of my career for that reason: people approach the Bible and faith with so many different contexts, life experiences, backgrounds, and emotions. There aren’t two personas or four — there are thousands of reasons someone showed up.

We try to remember that people carry something in with them when they walk through the front door, and it’s our job to understand what that is. We started asking, “What brings you here today?” It’s something you might experience in a boutique shop or an old hardware store where service is prime. Someone asks, “What brings you in today?” Then they can respond, “I’m looking for this really rare thing.”

That’s our job in a growing digital business: keep remembering to ask people, “What brings you in today?” in a digital way and then respond as well as we can. We’re not there yet, but that’s our target.

Users also want to get where they’re going quickly. How do you balance speed of the experience with building trust?

I love that I’m a beneficiary of where we are in this space right now — it used to be considered intrusive to ask people questions when they first walked in the door. But we’ve learned that if you go shopping right away in the digital space, we’ll have a hard time helping you find what you need unless we can ask you questions first. The expectation has changed. People are willing to invest a little time up front to have an experience that looks built for them and that addresses them.

We’re really front-loading the dialogue we all want. We all want a custom experience. We didn’t know how to get there, and people didn’t know how to tell us what they wanted. Now we can ask, “What brought you in the door? Is there a goal you have in mind?” “How can we help you meet that goal?” It’s building a relationship in a new digital way.

What’s your method for staying in direct contact with what one real person feels using the product?

At all the places I’ve been in my career, there has either been an insider or VIP program, or we’ve created one. This is where you find people who are excited about what you’re doing and build relationships with them. It’s a little easier in the physical product space. For example, in the hypercar space, it was just a few people — we could have constant contact with them.

At YouVersion, we recently invited longtime users into an insider program. Once a month or so, we’ll ask them questions through surveys, and some of those lead to video conversations. We have maybe 10 or 12 people that, when we think of something or we’re not sure about it, we’ll run it by and ask, “What do you think?” They’re honored to be part of the process, and we’re honored to get another perspective so that, in fact, I’m not my customer.

The harder part is that I don’t get as much contact as I’d like with the people who have decided to do something different or have moved on. We spend more energy, more time, and more dollars trying to understand that group because that’s who I would love to have more contact with.

On the flip side, how do you instill user empathy in product managers who will never personally talk to more than a sliver of the people they’re building for?

Five years ago, I wouldn’t have told you it was this simple, but now it’s about staying as close as you can to the stories and being a great storyteller. I feel like it’s absolutely part of my job as a leader to tell the stories of the people — good and bad — who have interacted with our products.

That’s why I kick off team meetings with stories, and everyone’s encouraged to bring one. We bring the embarrassing ones and the great ones.

It’s easy to lose perspective on the impact of what you’re doing. Storytelling brings you back to that moment when someone’s life changed, when they found exactly what they were looking for, or when they found a great product. It also means getting better at retrieving those stories and cataloging them. Thankfully, in the app world, you have App Store reviews, but there are other places where you can gather those conversations. I don’t think we can ever be too far away from the stories of the people we serve.

Where AI fits into faith-based products

At YouVersion, where have you drawn the line for integrating AI in the faith product?

This is an ongoing conversation. We’ve landed on the idea that tools that help us with workflow, do our jobs more efficiently, build context, catalog research, or draw correlations are areas where AI can help us. Those tools augment the human mind.

But at YouVersion, where we represent a biblical text that’s thousands of years old, we’ve been deliberate about not placing AI between a person and Scripture. If we ever move in that direction, it will be because we’re confident it can be done with the level of accuracy and integrity worthy of the text.

Where the text needs to be, the text is — with no apologies and no buffers. Where AI helps us remember things, organize research, or find correlations, we welcome it. Everything in the middle is a high-tension conversation that we often have.

How does your personal faith shape your work?

My personal faith shapes everything that I do because it’s who I am. The number one thing that gets me out of bed — and why I love product management — is helping people get where they want to go. In another life, I think I would’ve been a hotel concierge because I just love helping people get where they’re hoping to go.

My faith brings into that a desire to help people get where they’re going in their faith. When I’m not at work, I love having conversations with people about their personal lives, their faith journey, and what they’re looking for, and helping them find it in whatever way I can.

When we were building physical products, you could see the joy people got from being part of that journey. Likewise, we’re all on a journey, and for me the destination isn’t vague. It’s a real relationship with God. Faith is every part of that equation. For others, it’s still unfolding, and I count it a privilege to walk part of that road with them and point toward what I’ve found.

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, Shri talks about why the biggest lesson from her AI initiatives has been to start with the customer journey rather than the technology, and how a simple request, like a bill summary, can mask a much deeper problem. She discusses why vanity metrics can still be directionally useful, how regulated industries change the calculus on AI pilots, and why AI systems can never simply be launched and left alone. She also shares her own habit for understanding unmet customer needs: going to wherever the customer is and just listening.

Start with the customer journey, not the technology

You led an effort that improved a chatbot’s resolution rate from 65% to 95%. What did that teach you about identifying customer needs and pain points?

One of the biggest lessons learned was don’t start with technology, start with the customer journey. When we looked at all of the agentic frameworks and evaluated vendors, it was very addictive, and it was almost like drinking the Kool-Aid and saying, “Wow, I really want this.” It’s shiny, and it’s lovely, and it’s beautiful, and it’s fun. But why do you need it? I think we should always start with that question. Don’t start with the technology or the architecture or the vendor; start with the why about who asked for this.

As you went through this initiative, was there a point where you had to pivot or change direction?

Possibly every five seconds. The nice thing about AI is we’re all in this together for the first time. We built a lot of things in-house at Comcast, at Momentum, and at other places, so a lot of it was learning as we went along.

It’s not so much pivoting as making adjustments. It’s saying, “OK, if I do this, I’m creating a ton of tech debt, and I’d really like to rethink my architecture and see if I can course correct.” That’s the sort of decision that AI leaders need to be able to make, and not be afraid to say, “I think this may not be working. I need to make a change,” and make that change. If you are not able to move at that pace, the technology is going to outpace you and create a ton of problems down the road.

What customers ask for isn’t always what they need

Is there an example of a time when customers said they wanted something but it turned out to be different from the problem they were actually trying to solve?

This example is from a few years ago, at Momentum: The customer kept asking for a bill summary. Momentum has both retail and digital services, and the customer wanted a summary of their loan transactions throughout the course of the loan. So we said, “Sure, let’s do that,” and we spent a lot of time building it out, but no one asked what happens before the bill summary and after the bill summary. What is the journey? What is the pain point that the customer is trying to solve? They may ask you for a transaction summary, but what they’re trying to tell you is, “I would like to lower my interest rate. I would like them to make it easier to pay the loan back. Or, I want to turn it into a bigger loan because I wasn’t able to pay my electricity bill this month, and I need more money.”

There are many things that happen before and after that one moment. So moving away from just building out a product feature because a customer asked for it and, instead, asking what happened before and after and looking at the entire journey from end to end, makes a big difference in actually solving the real problem.

How do you coach teams to prevent them from optimizing around symptoms instead of needs?

This has actually become really easy in the world of AI. Let’s say we designed an agentic framework and decided to launch a bunch of product features. We are no longer talking about just features. We’re talking about constantly evaluating the agent, almost in real time, and feeding the evaluation of that agent into your product roadmap.

Even before you reach the customer, you’re starting to think about how you think your customer will behave. You can use historical data, you can use synthetic data, you can do all kinds of things to do these evaluations. So the way you build your product has moved away from, “First, let me look at customer experience, then find the pain point, then identify these features, and maybe it will work.” Evaluations are no longer a matter of weeks, they are a matter of hours.

Using all the technology at our disposal today, we’re able to populate the product roadmap in a way that is more meaningful.

Metrics that actually reveal unmet needs

What signals have you found to be the most reliable indicators of unmet customer needs? And, are there metrics that teams undervalue?

As a customer experience professional, I try really hard to move away from vanity metrics. We love dashboards, right? We like to print dashboards and show them to our C-suite and say, “Look, we have so much adoption. We built 10 features, and the adoption of those features has gone up.” But what did that really do? Did that translate into a business outcome? Did that translate into a more meaningful metric, like resolution?

If somebody logs in and clicks on a button, that doesn’t mean they went on to resolve the problem. It’s sort of like following the customer’s journey to look at the business outcome and saying “They were able to resolve the problem, and therefore we prevent a churn and maintain loyalty.” That’s the sort of insight you need to derive from your metrics. Otherwise, you end up chasing fake loyalty and metrics that look nice on paper but don’t really translate into anything that is meaningful for the customer or the business. It just means somebody clicked on a button.

What’s your process for figuring out whether a problem is really impactful to solve or more of an edge case?

There are two ways to go about this.

Let’s say you have a chatbot. You have all your transcripts to lean on. Throw all these transcripts into a transcript analysis tool and see what insights it comes up with — it will surface all the pain points where you see the maximum amount of problems. You can create a heat map of your customer journey and then identify which areas to go after. The other way is using agent evaluations, not just to see if your agent is performing, but also to see if your agent is solving a customer experience problem.

And then you can rely on traditional CX metrics. Review your dashboard every week. You’re looking for trends, making sure everything is moving in the right direction. I know that we shouldn’t be focusing on NPS or tNPS as one metric, but it does give you some indication of where things are currently. You can put it into the context of other metrics and other data and see what the trends are. That’s the traditional way of doing CX, and we can still apply those principles today.

Navigating regulated environments

How does identifying and solving customer pain points differ between highly regulated environments and industries that are less regulated?

The use cases are different, obviously. When you are looking at something like insurance or a bank or even healthcare, the first thing you have to be sure of is that any technology you build, whether it uses AI or not, protects customer data. You do not want to be leaking PII information, especially if you’re using OpenAI or Claude or any public LLM. You want to be careful with customer data, otherwise you’re going to lose trust. These kinds of industries are also very prone to fraud. Probably some of the lowest-hanging fruit when I was working in fintech was centered around fraud and how to mitigate it. We built a ton of technology to protect ourselves from what we call fraud rings — a group of people who just try to break the system to steal money and data.

So the use cases tend to be more around risk mitigation, fraud reduction, and customer data protection. It becomes front and center when you’re in a highly regulated industry. It’s also difficult to build pilots and scale them if you have a ton of regulation. It’s best to have good governance in place before you even launch a pilot.

Are there instances when regulatory constraints can actually lead to better products and customer trust?

Well, yes and no. If you allow the friction to seep into the customer experience, then it becomes a problem. If you’re trying to approve somebody for a loan or schedule a healthcare appointment, but the technology gets in the way of that and the customer is just looping around because you’re so afraid to let them progress into the next step, then that’s a problem. It’s really important that you evaluate your technology, whether it’s an AI agent or something else, and test it out before you launch it.

The quality assessment, especially now that we are in the agentic world, has become so critical. We had a huge quality team at Comcast running end-to-end evaluations and tests to ensure that the agents were performing. Running all of those evaluations, the quality metrics, the observability, and having the ability to move fast and test your technology before it reaches the customer is helpful. But if you’re in a highly regulated industry, I would recommend that you bring in your legal, compliance, and regulatory folks very early on so that you’re not reacting. That way, you’re building with their input as opposed to against the tide.

AI systems need constant human oversight

Can you share a time when customer behavior changed through a launch process and you had to rethink the experience?

When we launched some of our AI-based IVR systems at some of the organizations, we realized it solved some problems — it automated some things and made some things faster — but that also made the customer more savvy. Say I’m on a call and solved my problem very easily without going to an agent, so now what else can I do? Now that I have managed to reduce my bill, for example, can I get an extra piece of equipment without even talking to an agent? That gets fed into the model, and the model starts learning and training itself and giving other recommendations. We realized that what we need to do is not just build an agent and throw it out there — we need humans in the loop who can watch what’s happening. We need people to sit with the human agent, and see what’s going well, and what’s not going well.

So some of it is evaluation, some of it is customer metrics, but a lot of it is just humans being in the loop, constantly evaluating.

What is your approach to bringing customer-facing teams into product development?

From a technology perspective, we built customer data platforms that took the events that the customers were going through and fed them into a feedback loop. We also instituted listening sessions. You sit down next to a human agent and look at what’s going on. This is a business process improvement team that has customer experience and engineers sitting together with the agent, solving problems in real time. But you’re listening, and the customer’s struggling, and you’re saying, “I’m going to improve the agent and do this on the fly.” This is the kind of thing that bypasses bureaucracy and solves customer problems in real time.

We also created a summarization tool — it’s like a little clock that says whether the customer is happy or not. When the clock goes to the left, the agent sees that. It gives recommendations like, “Looks like the customer’s not happy. Maybe you should try saying this.” It happens in real time, and the AI takes care of that.

Where do customers still require human judgment, and where would it be hard to train that into an agent?

In a telecom industry, for example, or an internet company, or even healthcare. Let’s say a tree falls on my house. Do I want to talk to a bot? Probably not. I would be so stressed out and so scared that I would want to speak to a human who can help me through it. If I’m going through a medical crisis, I don’t know that I would trust a bot to take care of me. I just don’t think we’re there yet. That’s why it’s important to design your AI agentic systems in a way that you know exactly when the human should be in the loop.

If you can identify situations where you think it will not make any sense for the bot to be here, then you just completely escalate it to the human agent. In some way, that restores customer trust. In moments of extreme stress, you can hear the customer saying, “Customer service, customer service, customer service, human agent...” You can hear the frustration and the fear, so it’s important that we look at all the flows in our business and say, “Where does it really make sense for us to leave the humans in there?” It’s important to have empathy for the customer when you design your AI systems.

What separates teams that truly understand customers

Are there customer problems you’ve found that are just inherently difficult for AI to recognize?

It happens all the time. I think we make a lot of assumptions about what a bot can solve. Repetitive tasks, like changing the password or having better pricing recommendations, are the things that we can do using ecosystems of technology. But what happens afterward? It is entirely possible that a customer makes a decision to change their plan, but then abandons it. You’re able to ask the question along the journey of what happened as a customer enters the funnel: “They did this, and then they did this, but then they didn’t do that.” Being able to ask those kinds of questions, and being honest about what the customer interactions are, will really help alleviate some of those concerns of whether a bot can really solve the problem.

But there are fringe edge cases where the bot will just not be able to handle it, and maybe we can fix that by changing the agent, evaluating the agent, or by building a new agent. There will always be situations where the bot hallucinates or fails to solve the problem.

What do you think will distinguish product teams that genuinely understand customers from those who simply have access to more data?

I think all product teams should have access to the data, but product teams who can use the data to derive insights will make the difference. My product team in my past role built an analysis tool. Having no experience in data whatsoever, and not being part of their job description, they built an analysis tool with a frontend, a backend, an LLM, and everything. It simply takes a bunch of transcripts and analyzes the heck out of it, and comes up with brilliant recommendations that before would have taken us days and weeks. They were thinking outside the box, and that’s the kind of thinking that you need.

I had a product manager who took all of our product artifacts and threw them into ChatGPT to create a custom GPT product catalog, so that now anyone can search through our product catalog as if they’re talking to a person. That’s the kind of out-of-the-box thinking that product managers need to do, instead of just saying, “I’m a product manager. I’m going to wait for someone to tell me what they need, and then I’ll be looking for features.” Getting ahead of the data is going to be the winning solution.

Is there one habit you’d suggest product leaders adopt to better understand customer pain points?

What has always helped me as a product professional is going to where the customer is. I’ll just go sit down in the retail store and listen to what’s going on, or I’ll look at the systems that the retail employees are using, or I’ll go to a contact center and sit next to the agent and just listen for a day. Those are the things where you can really understand what’s going on when you’re not looking at the data. So, stay curious, and just go meet the customer where they want to be met — that helps.

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, Yair shares his vision for what product management looks like in an AI-native world, where interfaces become intent-driven. He explains why product organizations need to think platform-first, as well as how AI is reshaping roadmaps and experimentation.

The transition to conversational UI

You’ve laid out several provocative predictions about the state of product in 2026. The first is that software will no longer be organized around pages and navigation. If interfaces become conversational, how does product design change?

I think the word “design” will no longer be limited to just the design of a website; rather, we’re designing intent. When a product designer begins designing a product, they will no longer focus on how it looks, but on designing the journey. The journey doesn’t have to be something that you see with your eyes. In the case of conversation, I can simply speak and receive my answer. In the end, you’re designing a journey, but it doesn’t need to have a visual interface, necessarily.

The fact is, you can’t design an interface that makes sense to everyone. We’ve tried over the years, and we’ve also seen a one-to-many relationship between the website experience and users. The rare cases where it was more binary had to do with elements like locale or dark versus light themes.

What I have in mind is something much bigger. You still need a design system, but it needs to be very strong to create a website built on intent — one that understands the user’s context, the context of your available content, and the data you’re collecting all the time. Based on those things, it builds itself while staying on-brand. It should still feel cohesive.

Thinking that you and I need the same website, despite our different ages, interests, and goals, no longer makes sense. Today, AI can crunch billions of parameters in real time and build a layout tailored to exactly what the user needs. The CFO sees three KPIs and a cash flow chart. The analyst sees 14 filterable cohort tables. The CEO on mobile sees one number and a thumbs- or thumbs-down icon. Three generated UIs from one platform, and not one compromise layout. We can’t continue to think in terms of a one-website concept.We can’t continue to think in terms of a one-website concept. That’’s outdated.

How does this change the skills or background you look for when hiring product designers?

Many functions and positions are now converging within the space. We’re no longer looking for an expert in a single field of capabilities. There’s a concept of a full-stack product manager — someone with design capabilities who’s analytical and also invents things. Historically, those people were anomalies.

Today, you don’t need to have every capability yourself. You just need to know what question to ask and when to ask it. With the strong suite of tools we have now, you’ll likely get a very sound answer.

If you were only doing product design in the past but were afraid that the technical side of product management was a barrier, that’s no longer the case. There’s now a higher expectation that people entering product management know more disciplines and move closer to being full-stack product managers, all because they have these superhuman tools at their disposal.

Why platforms become the product

You recently said, ‘The website of tomorrow is built the moment you ask for it.’ What does that imply for product discovery and roadmap planning?

It makes it much more difficult, and we find ourselves investing a lot more in planning. The tectonic shifts in product and technology are so big that even basic building blocks of product management are changing as we speak. The place you need to invest in most is your platform.

If UI is commoditized and everyone can build applications simply by prompting AI, then the most important thing you can do is have a very strong engine and platform on which those applications are built.

In Kaltura’s case, we’re a video cloud platform. If you’re building a video application, we want to provide a cloud platform, APIs, and a strong MCP so your AI can talk to ours. Because here’s the threat: a mid-market sales team can now replace a monolithic product with Airtable, Clay, an AI agent, and a custom Slack UI in one Saturday — no code. What they can’t replicate on a Saturday is transcoding at scale, real-time event orchestration, or ML inference chains. The API is the door. The engine behind it is the moat.

AI has lowered the barriers to building software, but has it also changed what creates durable competitive advantage?

Absolutely. Companies that existed before the AI boom have important advantages, like customers, for one. If you already have customers, selling them AI capabilities is much easier than convincing entirely new and unfamiliar prospects to trust a new AI company — especially in enterprise environments with long procurement cycles.

The second advantage is content and data. If customers have worked with your product for years, you’ve accumulated content, behavioral data, and context. That translates into skills, which later become agents. This is the breeding ground for good AI. Understanding your customers’ behavior inside your systems and translating that into skills and agents is a huge competitive advantage in the AI race.

Going back to UI and the idea that customers could build or modify their own experiences, are there architectural decisions you’re making today to support customers building on top of your platform?

Building UI isn’t all the same. Building navigation or a carousel is simple, but building products like a video player or a Zoom-like real-time client isn’t. Because of that, we’ve built those advanced UI components as reusable platform features that developers can simply incorporate into larger applications.

For example, imagine someone wants to build a speed-dating application. They need a way to connect people to talk with one another in real time in a private room. That’s not something AI is likely to build easily today, even if you have the APIs to connect to it.

We have a micro-frontend framework called Unisphere that is embed-first. A developer can import one ES module from our CDN, initialize a workspace, and have a full AI conversational avatar with video search and interactive content running inside their app in under 20 lines of code. Even before AI, we believed embedding should be a first-class citizen. With AI, it’s even more important because the interface layer is whatever the agent assembles.

Documentation as part of the product

You’ve said your agent’s understanding of your product is only as good as your documentation. Should product teams start treating documentation as part of the product?

Yes. What was once a side dish is now maybe even more important than the showcased product itself. If documentation is the instructions for how other applications and AI agents build on top of your product, and agents can’t easily find your product or can’t easily build products from your documentation, then something is wrong.

You can test this immediately. Give an AI agent your documentation, ask it to build a feature, and see what happens. These agents are very good at translating documentation into working code. If they get lost or hallucinate, you know your documentation isn’t good enough.

From a product perspective, we have two requirements before we’re ready to deploy. First, it has to be API-first, which today also means MCP. Second, ii must be documented. If it is not documented, it does not exist. If a feature isn’t discoverable, then it hasn’t really made it to production.

On a product team, should documentation belong to a specific function or be shared across the team?

Today, the moment we open an epic, a documentation ticket is automatically created within that scope of work. There’s no option to push work to R&D without linking documentation to it. That already changes behavior because documentation becomes part of the workflow.

Who writes the documentation is another matter. You could have a technical writer. Product managers have always written documentation as well. R&D can write it, especially when you’re building API-first products for builders. Ideally, though, agents should do it. Once you have code and everything is explained semantically, translating that into human-readable documentation is easy. Agents don’t necessarily need human-readable language, but they still need taxonomy and hierarchy.

This entire process should be automated. Documentation shouldn’t consume an hour of anyone’s time — it should simply be part of the product lifecycle.

The future of product teams

Product teams have talked about failing fast for years, but you’ve argued that the mechanics didn’t really exist until now. What changed?

In the past, if you had an idea, maybe you’d build a landing page with a wait list and measure signups. Today you don’t need to stop there. You can build the core of the idea — not the entire thing, but the essence of it — and immediately see whether people find it useful, whether the hook works, whether the aha moment is there.

As a product person, you can start getting signals before you’ve even spoken with a developer or designer. I shipped two extensions and opened seven GitHub repositories in one week just to see whether people actually wanted to use the ideas.

Today, if you’re sending a product into development without already having market signals, you’ve done something very wrong. Ideally, you should fail every week and succeed once a quarter.

The barrier between product and code continues to dissolve. PMs can prototype, designers can generate code, and engineers can run customer experiments. As responsibilities become more fluid, what remains distinct?

Everything is converging. The PM whose identity is anchored in process management, standups, backlog grooming, mediating between design and engineering — that role is dissolving. The PM whose identity is anchored in judgment, taste, commercial conviction, and the infrastructure to test that judgment at speed — that role is multiplied. Now we have smaller teams, bigger accountability, and agents as first-class team members. The PM who wins in 2026 is not the one with the best intuition about what to build. It’s the one who built the best machine for finding out what to build.

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, Jeff explains why agentic commerce is an executive leadership challenge — not a marketing or IT initiative — and why retailers should treat Labor Day as the deadline to prepare for AI-driven product discovery ahead of the holiday shopping season. He also expands on ideas from his recent guide, Agentic Commerce for Retail Leaders: July 2026 Quick-Start Guide, outlining the operational, technical, and organizational changes leaders should prioritize today.

How agentic commerce starts with leadership

Why is being visible to AI assistants a leadership problem for retailers rather than just a marketing or IT project?

It’s a leadership problem because retailers can’t navigate this correctly unless marketing, content, IT, security, site merchandising, customer service, and other teams all work together. Each area owns part of the solution, but none of them can solve it in a silo.

Without a single leader, you’ll naturally get departmental gridlock. Your security team is trying to block scrapers and reduce server load, while your marketing team is trying to drive organic discovery. Left on their own, IT may lock everything down and unintentionally make your site invisible to AI agents. This requires a leader who understands how to balance competing priorities, align teams, remove roadblocks, and stay accountable for the outcome.

Being accessible to AI assistants is only the first step. Products also have to be understood, trusted, recommended, and ultimately fulfilled correctly. That’s why this has to be owned by someone with end-to-end accountability.

For retailers who are just beginning to consider agentic commerce, what’s the first operational change you would recommend?

I would start more technically — with an agent access and catalog readiness audit before improving content or data structure. Retailers first need to understand whether AI assistants can even access their information and which paths they’re using. That means reviewing robots.txt files, CDN and WAF settings, bot management rules, crawler permissions, APIs, and product feeds.

That doesn’t mean opening everything up. Legitimate crawlers and approved partners provide ways to identify and manage access, but retailers still need rules around authentication, spoofing, rate limits, and who is allowed to consume what.

I would also identify the 50 products that generate the most revenue and use them as the first test set. That gives the team a manageable place to find problems and build a roadmap before scaling across the rest of the catalog.

Building AI-ready product data

What else has to be true about a retailer’s catalog for AI agents to find and correctly recognize a product?

First, the catalog has to be accessible. Then the product has to be identifiable. The table-stakes information needs to be complete and accurate: product name, brand, description, model number, GTIN, dimensions, images, specifications, price, and more.

Products also need to be mapped correctly. Variants should be connected as variants instead of appearing as unrelated products. Price, inventory, reviews, images, and offers all need to attach to the correct canonical product.

Think of the canonical product record as the recognized product family, with each size, color, or configuration correctly connected as a variant, and each retailer offer attached to the right item. A tent available in five colors may have five individual SKUs, but an AI assistant should understand that they belong to the same product family instead of treating them as unrelated products.

Information also needs to stay consistent across product feeds, structured data, and product pages. Ultimately, retailers want to own the product card. That means the AI assistant correctly recognizes the product, understands its variants, associates the retailer’s offer with the right item, and can trust the price, availability, reviews, delivery promise, and policies associated with it. The goal is not only to earn a click, but to earn the recommendation and create an accurate path to the transaction, wherever that transaction ultimately happens. Eventually, transactions may happen directly inside AI assistants, but discovery is the priority today.

Most product pages were written for human shoppers. What has to change to optimize for agentic commerce?

For the last two decades, we optimized for keywords and human clicks. Once someone landed on a product page, marketing copy did the heavy lifting. Today’s AI shopping systems can draw from merchant feeds, platform catalogs, structured data, product pages, and retrieval systems to answer questions directly, often before the shopper begins a traditional browsing journey.

To succeed, retailers need to provide context. Why does someone want this product? Who is it best for? What problem does it solve? What questions are customers trying to answer? What limitations should they be aware of before buying? The answer isn’t writing longer product descriptions. That’s a trap.

Information needs to be direct, structured, and verifiable. Product type, use case, and compatibility shouldn’t be buried in lifestyle copy and left for the AI assistant to infer. Marketing should explain why those facts matter. That is where Answer Engine Optimization (AEO), Generative Engine Optimization (GEO), and Agentic Commerce Optimization (ACO) serve different purposes. AEO and GEO help influence the answer. ACO prepares the product for selection, verification, and action.

In your guide, you argue that retailers need to capture that natural-language shopper intent, not just product specs. Where should retailers find the language and detail that’s missing from their product content?

Most retailers already have this information. One of the best places to start is the site’s search engine. Retailers can see exactly what customers typed, where they landed, and whether they found what they were looking for. That language often differs from a retailer’s official taxonomy.

Then look at zero-result searches — queries that produced no results. Customer service chats, reviews, returns, warranty claims, and other support channels all contain valuable language customers naturally use.

Work with those teams to map that language back into product records, structured data, FAQs, buying guides, and platform feeds used by Google, ChatGPT, Gemini, and other AI assistants. Very few retailers operationalize that information today, which creates a significant opportunity.

Earning AI trust and recommendations

What makes an AI assistant trust one retailer’s claims over a competitor’s?

Trust is one of the biggest factors. AI assistants are more likely to trust information they can verify from multiple sources. They compare product pages, structured data, product feeds, reviews, pricing, and other signals. When those sources reinforce one another, confidence increases. When they conflict, uncertainty increases.

Each AI platform has its own ranking and confidence signals, but the operating principles are similar. Retailers with the clearest, most consistent, and most verifiable information become the safer recommendation. AI assistants depend on credibility. Before recommending a product, they need confidence that the information they’re presenting is accurate.

Why are small inconsistencies, like in pricing, inventory, or return policies, for example, more consequential when an AI assistant is involved in the buying journey?

A customer can usually work through a confusing message. They might click to another page, call customer service, or keep looking until they find the answer, but an AI assistant that compares several options doesn’t do that. If your price differs between the product listing page, product detail page, checkout, or inventory system, the assistant may favor a competitor whose information is easier to verify.

The other issue is scale. A small inconsistency that once affected a handful of shoppers can now influence thousands of recommendations and comparisons. It can also create promises your operation can’t deliver on, whether that’s the wrong variant, unavailable inventory, or an inaccurate delivery date. In an agentic environment, bad data doesn’t stay hidden inside your website. It travels much faster.

There’s a lot of excitement around AI-powered checkout. You recommend a more measured approach. How should leaders decide where to invest today vs. what can wait?

AI-powered checkout is getting a lot of attention, and for good reason. Technology companies are building rapidly in this space. AI-to-cart handoffs are already real, and human-approved embedded checkout is beginning to appear on participating platforms. Fully autonomous purchasing, where an agent completes a transaction under pre-authorized rules, is not mainstream yet.

Leaders need to separate what’s happening today from what’s technically possible tomorrow. Right now, the most important priority is preparing for AI assistant discovery. I would set a goal of being ready by Labor Day. A significant amount of holiday shopping, product research, and comparison will happen inside ChatGPT, Gemini, Copilot, and other AI assistants before customers ever reach a retailer’s website this year.

Discovery is the deadline that cannot move. Checkout should follow, or run in parallel, if you have the resources. Salesforce, Shopify, and other commerce platforms are building many of these capabilities. However, retailers still have to clean their data, implement the technology, establish governance, and ensure their operations can deliver on whatever an AI agent promises.

The takeaway is straightforward: Discovery first, checkout second, but don’t wait until October to begin either one.

Leading the organizational transformation

Agentic commerce touches merchandising, engineering, marketing, analytics, customer service, and payments. How do you keep it from becoming another siloed digital project?

This is where leadership comes in. You need a leader who already has relationships across those areas, knows how to speak their language, understands the technology, is trusted, and knows how to motivate teams to work together. That is the model I believe in, and what I have seen work.

But relationships alone are not enough. Give that leader ownership of the end-to-end outcome, put the work into the operating plan rather than an innovation lab, and create a shared scorecard tied to catalog quality, AI visibility, conversion, and returns. When the work is connected to the customer experience and the P&L, it is much less likely to become another siloed digital project.

You’re saying discovery has to be done by Labor Day. What has changed in the commerce landscape that makes this such an urgent leadership issue?

I’ve spent more than 20 years in ecommerce and have watched several major shifts reshape the industry. Each time, the same pattern emerged — customer behavior changed before most retailers believed it. Infrastructure was built before transaction volume became obvious. Then the convenience curve accelerated and adoption followed.

That’s happening again with agentic commerce. Google, Microsoft, Salesforce, Shopify, Visa, Mastercard, and others are building the infrastructure that will support the next major shift in how customers discover, compare, and purchase products.

The biggest risk isn’t missing a few AI-driven orders this year, but falling out of the consideration set before customers ever reach your website. It’s allowing competitors with cleaner, more trustworthy data to become easier recommendations. It’s missing the opportunity to learn while AI-driven traffic is still manageable.

If retailers wait until peak holiday volume to rebuild catalog feeds, ownership models, and operational processes, they’ll be doing it under the greatest possible pressure. That’s why I continue to emphasize Labor Day as the readiness deadline.

I’m actually working on another piece exploring what I call the six waves that have reshaped ecommerce. I have watched five waves reshape ecommerce, and the sixth wave is following the same script.

Do you recommend any resources for leaders on agentic commerce?

One resource I recommend regularly is The Jason & Scot Show. It’s a podcast that covers ecommerce broadly, but agentic commerce has become a major focus because it’s driving so much change across the industry.

I’d also recommend reading my Agentic Commerce for Retail Leaders: July 2026 Quick-Start Guide, which outlines practical steps retailers can begin taking immediately. Beyond that, stay closely connected with your commerce platform. Whether you’re using Salesforce, Shopify, Adobe Commerce, or another platform, follow their product announcements, work closely with your customer success team, and participate in pilot programs whenever possible.

The goal isn’t necessarily to be on the bleeding edge; it’s to stay on the cutting edge. You don’t want to fall behind, because in this environment, falling behind can quickly translate into lost visibility, lost traffic, and ultimately lost revenue.

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, Emily talks about the AI-powered workflow she built for product managers and designers — one designed to compress the path from idea to prototype into a matter of hours, in service of a broader goal of moving from idea on Monday to beta on Friday. She discusses where the time savings really show up, why she deliberately kept parts of product discovery un-automated, how she won over an engineering team wary of “AI slop,” and what skills the next generation of product managers will need as AI reshapes the job.

Building an AI-powered product workflow

You’ve built out a product workflow designed to significantly reduce the time from ideation to development. Could you talk about that and share how teams are using it internally?

The product workflow is built using Claude. It uses a lot of skills. I used compound engineering to build out a workflow that product managers or designers, those were the people I was really thinking of when I built it, could use to speed along product development.

It’s a series of many different skills and it continues to be added upon. It has access to Confluence, to Google, to various different places where we keep our discovery notes from when we meet with customers and we take notes and snapshots of what we’ve learned. So it has all of this context readily available where a product manager doesn’t have to go and search for it, but they can also pull in their own notes and add to it if you’ve had some recent meetings and want to throw in those notes, it can take those and synthesize it with everything else.

For the first step, you pull in that discovery and then pull out what are the opportunities that I’m seeing around this. You can actually talk to Claude back and forth and brainstorm. What are the opportunities? What are the different solutions? It’s kind of having a partner to talk to and work through. Then from there it will hand off to the next skill when you’re ready to build out a product brief. So build out a PRD, and that PRD includes a lot of different elements that we don’t normally include as much for go-to-market and objection handling, things like that to prepare it for sales and really help them to understand what we’re going to be building out.

From there, you can have it build out the tech spec, build out the actual prototype and also then run it through a compliance and risk assessment, which will spit out a summary, create a Jira ticket and alert our legal team in Slack that this has happened so that they can quickly review the summary rather than having to go through everything, meet with a team. They get a summarized thing about what tools it’s using, if these tools have been approved in the past. The template to create that has been built by our legal team themselves to ensure they meet our AI governance requirements.

Where the time savings show up

I imagine there are huge savings associated with condensing the process so dramatically.

You can go through this process and if you kind of have an idea of what you want to do, I’d say a matter of hours, a half day. I think it’s best to go through and really think about it and take a little bit more time, but end to end, it’s very quick, and then legal’s on top of it — they don’t ever want to be a bottleneck. They do their review, it’s much faster for them.

This process can take weeks, months to build out. And while the prototype that we build isn’t something that is going to go into production, we don’t have that expectation right now. Hopefully we’ll iterate to get there and give more guidelines to make the prototype something that’s more production worthy. It’s something that helps to communicate to engineering so that they get a picture of what we’re really trying to build and all the different areas that it may affect much faster. So it really helps with the communication across the different teams, speeds that up.

There are so many groups that this workflow touches. Are the savings fairly equally distributed, or do you feel that some areas get a larger benefit?

I built this with product and design in mind, so I’m a little biased there. I’d say that the savings are really heavy on that side because something that takes a long time for a product is going out and talking to people, which we still have to do. You’re not going to replace that with AI. Go out, talk to people, get that direct feedback — what are their pain points, what are the opportunities, coming back with possible solutions and finding out their feedback on it.

We have years of input from them around different products, and going through and sifting through all of that — trying to find exactly what you need, what might influence what you’re solutioning, the different deal impediments, support tickets, things like that — takes forever to go through and you’re not going to capture it all. So that is a huge time savings with AI, being able to just instantly look through all of that and pull out what’s relevant to you. I’d say that is the biggest. And then writing out the product brief or the PRD, that’s really time-consuming.

This is so much faster. You still have to review it, make sure it’s exactly what you were thinking, what you were wanting, but it’s so much easier to make tweaks to it because it does a good job. It’s not total slop where you have to rewrite it. It’s doing a nice job. It’s really just working through it like you would maybe a more junior coworker and trying to convey exactly what you’re doing, and then getting that prototype to really help you explain it to engineering and pull them in and get that common understanding.

We have a lot of different interactions in Airship — I’m sure many other platforms can relate. You may be building one product or feature in one area, but it ends up that it touches all these other areas that you may not think of right away, and sometimes our docs team catches it, sometimes engineering catches it. So it really helps to find those faster.

Fine-tuning the tool as a team

As you go through the initial few iterations of creating and reviewing a PRD, are you able to train the tool to get even a little bit closer to where you’d want it?

The way we’re doing that is actually more of a group effort. The PRD that spits out isn’t exactly our template that we use for product reach — it’s missing some areas. Another coworker has built out a skill to address that, make sure that we’re getting all the areas. I’d say it’s a group effort to fine-tune this and get everything you need. Something I missed in the first iteration of this workflow was the ship-it we send — what we call a ship-it. When we release a product, we send an email notification to everybody in the company, letting them know about what it is and all the details, how to use it, why we build it, and thanking the team and things like that. Another coworker added that to this product workflow as well. So there’s a lot of fine-tuning going on as people use it, and it’s in GitHub, so everybody can make changes to it and we can all pull down the latest and continue to refine it and make it better.

Can you say more about how the template helps the teams move faster without creating more unnecessary risk?

We have a legal team member who came up with the template. He’s been leading our AI governance requirements, so he’s very familiar about what needs to be included, how it needs to be included. We need to make sure that legal’s alerted and understands what the product is, and it runs through that compliance and risk assessment so that they can evaluate it. But they also need to be able to track the product and understand where it is in the process so that they don’t become the bottleneck, and they also know if it’s actually moved into beta. So that’s where he said, we need a Jira ticket to track this that we’re alerted to so we can follow it. And that’s linked to the compliance and risk assessment so that they can see that and reference it at any point. And then we have that tracking history that we need for AI governance requirements as well. So a huge benefit of getting legal involved in the process is that product risks get surfaced early and often and can be accounted for through development, and we avoid the situation of Legal coming in at the 11th hour and pumping the brakes on a release.

What AI still can’t do

Were there any parts of the process that you chose not to automate that you intentionally excluded?

Going back to the discovery, you can’t automate talking to a customer directly. You can automate pulling in the notes — we record our calls, and we pull in those notes and it’s able to pull from that — but I purposely made that discovery and brainstorming portion more of a, it needs to be a conversation. You need to ask questions. Don’t just go and do it. The product manager needs to be involved. It needs to have that person, have a lot of their presence and thinking in there.

Getting engineering on board

When this was first launched, was it difficult to get engineering on board? Were they hesitant that they might be receiving AI slop, or that they wouldn’t be brought in early enough to the process?

I still like to bring them in early, bounce off ideas. They always need to be included. They’ve got their own thoughts, and we work in a trio — design, engineering and product — so we still always talk. But when I initially built this, I went in a little hard. I was a little excited. I’d seen what you could build out, and there were some on engineering who were supportive. They were like, “Yeah, seems like a good idea. You could do that and could probably get into beta.” But then there were others that raised concern, and engineering was like, “Oh yeah, you’re right. That’s maybe not the best.” So what came back was, “We don’t want to be QA for AI slop,” which I totally understand — we don’t want to be putting things into production that are not great.

I worked with an engineer and had built something out using, at the time, using Cursor, and he took a look at it, and he thought it might take as much time to refactor this and fix a few things as it would for me to write from scratch. Writing the code is not the slower part. The slower part is usually understanding what you actually want to be built. And what he found was this was very useful for him to really fully understand what I was trying to convey in a product brief and what I actually wanted to be built — all those little areas that you might not think of when you’re building out a product, all those gaps and questions that would come up as they’re trying to build it. That’s what really slows things down.

He did find a lot of use in this, as did the rest of engineering, as long as we framed it as no expectation that what we put out with AI is going into production. It’s more of using it to convey things to engineering, and now we can build guides along to get it better and better and improve it — but for now, let’s have that expectation that it’s more of conveying an idea. That’s been really helpful, and that’s gotten buy-in from engineering to work with.

Certainly the main goal of this project was to accelerate the path from idea to execution. What has become harder as you’re moving so quickly?

It’s been a big adjustment on how we leverage all this to be faster ourselves and make better use of our time. When all this came out, when I was building out the product workflow, there was a lot of excitement throughout Airship. I think across all companies, Claude Code got really big, really good, and everybody started building out workflows, and it just felt like this crazy period of a month or two where everybody was discovering this new power. It felt very frantic and hard to focus, because I was doing my thing and somebody else is doing theirs and pinging me about, why can’t we do this, why don’t we do this. It was very hard to focus. I think that’s going to continue to happen as AI evolves — people get excited, and then it’s just, how do we apply this? Now things have kind of calmed down a little bit for now, and we need to get a process in place and how to implement it into the day-to-day.

We work in trios — product, engineering, design. We go out, we talk to customers, and in the past we’d come back, we’d meet, we’d talk about what we heard, and then we’d build out an opportunity map, and then come up with solutions and start to talk about what those solutions are, wireframe. It was a very slow process, and we want to continue to work in those trios. So how do we implement this in a way where we can actually move a lot faster but still together?

That’s something we’re kind of experimenting with. We have a designer who’s working with a couple different teams to try and do it and then scale it across other teams. So everybody’s kind of experimenting in their own way as to how we actually start to implement this and move forward faster. So our goal is really to go from idea on Monday to beta on Friday, and that’s what we’re really working towards.

The new PM skill set

We talked about the goal of going from idea to prototype, a Monday-through-Friday type thing, which is incredible. Are there other metrics or signals you look at to measure the success of the workflow?

It’s still really early in the process, but right now I’m looking at the adoption — talking to team members, seeing what they’re adopting, if they’re adopting it, and seeing how much is being added to it by other team members. Like I said, we have someone adding the ship-it, adding more context, a product brief. Something we did to test it out, which I thought worked really well, was testing out the AI governance process. We took the template and we took an older product brief of something that they had manually reviewed and ran it through the skills for the compliance and risk assessment to see what the outcome was and make sure that it matched what legal wanted to see from it and what their expectations were. It’s still early yet to tell you what metrics or signals.

Looking at the newer generation of PMs coming into the craft, are certain skills more useful or more sought after now?

Definitely. And I think that those skills, unfortunately, are a little harder to evaluate than maybe the skills that were important before. Now I’d say the things that are more valuable are strategic thinking — really understanding what’s necessary, what’s needed, what the customer really is looking for, having a real deep understanding of that, not just what AI is telling you, being innovative, having that vision of where things are going, not just with what you’re working on, but the product as a whole and everything else around it, because everything is shifting. People are building out these workflows all over in different areas, and that’s going to then affect your product. So really understanding a very large scope of vision and having good judgment.

With AI, you use it to build out these PRDs, to strategize and things like that, but you really need to understand it yourself too. If you see LinkedIn posts, you can tell a lot of those are coming from AI because they all sound the same. You don’t want your product that you’re building out to be the same as everyone else’s because you’re just throwing in a prompt and doing what AI tells you. You really need to have a deep understanding of the landscape and what customers want so that you don’t just listen to the AI and do what everybody else is doing.

Adaptability — things are moving really fast, and you need to as well. If you’re still doing that process I described before, that’s so slow and so long, you’re going to be left behind. You’re not going to be able to innovate and build out your product fast enough. It’s really critical that you start learning how to use AI tools and how to use them really efficiently — not just plopping in something, getting the AI response, and using that, but really exploring and getting the most out of the AI tools so you can use them more as an assistant. And then adjusting your own process to match the changing times, seeing how others are too, so you can get ahead of your product and where it’s evolving.

And then the last thing I’d say that’s super important still is the collaboration — having trust, building trust, having influence, having an analytical mindset to really help people understand where the product’s going, making those right bets so that they do trust you. Working with people, building those relationships, it’s not going to change. That’s always going to be important. That’s not something that AI is going to change. As far as the less important — the writing, it’s so much easier now to have an AI assistant just write things out for you, build a prototype to help you communicate your thoughts. That whole communication is getting easier, but you still need the relationship building.

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, Ramesh Ayyagari explains the principles behind his Agentic Workforce Framework — a governance model for managing AI agents through identity, accountability, trust, and graduated autonomy. He talks about why organizations should think of AI agents as digital workers rather than software tools, as well as the governance system product teams should implement to build capable, accountable AI-native products.

Utilizing an agentic workforce

You’ve suggested that AI agents should be treated as digital workers rather than software tools. What’s the difference, and what breaks when organizations continue treating agents as tools?

If you look at it through a simple analogy, a tool is something we operate, and a worker is someone we manage. It’s sometimes a bigger difference than it sounds. If you give a strong team a goal, they come together and produce an outcome. If you hand them a script, they produce an output. Similarly, when you treat an agent as a tool, it’s marching toward an output rather than an outcome. The tool is the script — it does what you tell it, and you approve every step. When it fails, it’s usually because of your instructions.

An agent is more like a team. You give it a goal, approve a plan, and it makes its own calls within the limits you’ve set. You’re not signing off on every step — only the major ones that require human judgment. That’s where human-in-the-loop controls come into play. We’re not operating software anymore — we’re managing something that acts on its own.

When you call it a tool, multiple things break. First, a tool doesn’t have memory. It doesn’t have an identity either. Also, there are no real limits. A brand-new agent could potentially get production access on day one, where a human would never get that level of trust. With a tool, there’s no audit trail, so when something breaks, all you can do is scroll back up through your terminal history.

There’s a great example from last year when an AI coding agent deleted a live company database during a code freeze. It ran commands it had been told not to run, then fabricated data to hide the damage. That’s failure in the wild. We spent decades learning how to manage workers, but now we’re handing agents production access on day one because we’re treating them like software instead of employees.

What separates a truly agentic product from an AI-powered workflow, and what’s the most common misconception that teams have about autonomy?

It comes down to who holds the decision. For example, in an AI workflow, it’s the designer or engineer. The path is fixed when you build it, and the model fills in a few steps along a route that a human has already approved.

An agentic product hands those decisions to the system at runtime. It chooses its own steps in the moment instead of following a route mapped out in advance. The handoff is the significant component in this process — that’s why autonomy is more of a governance question than a capability one. It’s a relationship.

The most common misconception about autonomy is that it’s something you just flip on because the model is smart enough. It’s not. Autonomy is actually about how much unsupervised authority an organization has decided a specific agent has earned for a specific type of work. Once you see it that way, the question becomes, “Should we let this agent do this?” That’s a question you can answer with evidence rather than debating whether to give it full autonomy.

Is there a specific place where you see teams underestimating or overestimating what an agent can safely do?

Yes — overestimation happens around judgment calls that can’t be undone, such as production changes, deleting data, or talking directly to customers. Agents sound fluent and confident, so humans naturally read that as trustworthy, but that’s not always the case.

Underestimation happens on the boring work that’s easy to verify, like refactors with full test coverage or migrations you run against a preview first. My rule of thumb is that safe autonomy comes from verifiability and reversibility, not intelligence. Give agents room to make mistakes when you know that you’ll be able to catch those mistakes automatically. However, when the outcome is permanent, and you’d only catch errors by gut feeling, that is not a good spot to implement autonomy.

Further, it depends on the type of agent. Worker agents — developers, QA engineers, product managers — are judged by what they do. Product agents, like digital assistants or recommendation systems, are judged by what they say, show, or recommend to customers. We’ve seen both modes fail publicly. One airline was held liable when a reservations chatbot invented its own refund policy. Those are governance failures — somebody has to own the decision rather than letting the agent own it.

Why agentic AI needs a new governance model

You created the Agentic Workforce Framework. What convinced you that a new governance model was needed?

I spent years building AI into customer experiences — virtual assistants, chatbots, recommendation services, automations — and the same handful of problems kept showing up.

The first was amnesia. Agents hit the same failure every session because nothing they learned from previous ones ever stuck. Second, agents graded their own homework. They told you everything passed, and there wasn’t an independent way to verify it. Third was scope creep. You asked for one thing and got three, or sometimes 10, additional changes that were never authorized.

Fourth was flat confidence. Agents sound just as confident when they’re wrong as when they’re right. The fifth only shows up when you’re running multiple agents. One agent’s unchecked output becomes another agent’s trusted input, and a single mistake spreads across the system.

A person can watch every step of a simple software routine at a terminal, that’s manageable. A room full of agents working in parallel can’t be watched that way. That’s the shift that forces a real operating model. These are management problems. Companies already solve them for teams of people. Organizations define who earns autonomy, who can make decisions, and how authority is delegated.

With the Agentic Workforce Framework, I stopped asking how to make agents smarter — for the bounded work I hand them, they’re already capable enough. Instead, I started asking how to manage a brilliant, tireless team that forgets every mistake and faces no consequences. That’s when you start building a governance model focused on tracking mistakes and ensuring agents learn from them.

If a product manager is building their first AI-native product, what decisions should come before prompts or models?

There’s no shortage of technical advice today. You can go on YouTube or TikTok and watch millions of videos about how to build your evals, watch your token costs, route each task to the right model, manage latency, and more.

The decisions that come first are organizational. First is authority. What can the agent do on its own? What requires approval? What’s completely off limits? Those rules need to be written down. Second is evidence. What proof will you accept that the work was done correctly, and can you get that proof without asking the agent? If your only evidence is the agent saying, “I finished,” that’s testimony, not evidence.

Third is accountability. Someone has to own the output that produces the outcome. Until we’re at full autonomy, there has to be human supervision. The next piece is what I call a reversibility budget. Actions shouldn’t all be one-way doors. Irreversible decisions need much tighter control.

Finally, agents need an escalation path. When they reach the edge of their authority, they should stop and hand off rather than improvise. For example, earlier I mentioned the airline chatbot that invented a refund policy. At the tribunal, the airline was found liable. One argument was that the bot was a legal entity in its own right. The tribunal rejected that and said, “No, you own the agent.”

Agents can now choose models and spend tokens on their own. That creates cost questions, but it’s also an authority question. An unbounded token bill is usually a governance gap showing up on an invoice. AI tools will change several times a year as they’re updated and improved, but your authority model is what stays constant. Ultimately, that’s what leadership and auditors review when something goes wrong.

The building blocks of responsible AI agents

Your framework introduces concepts like identity, task contracts, trust scoring, failure memory, and auditability. Why do you believe those are the foundational building blocks for responsible agentic products?

Each one answers a question someone will eventually ask. Identity answers who did this; task contracts answer what the agent was allowed to do; auditability answers what actually happened; trust scoring answers how much room the agent has earned; and failure memory answers what we learned and whether we’re using it.

Take any one of those features away and the loop breaks. A trust score without identity is trust with amnesia, and a contract without an audit trail is good intentions with no proof. These aren’t five separate features. They’re one system.

Is there one in particular feature you have seen product teams often overlook?

I would say the most common is failure memory. Every team builds logging, but almost nobody builds recall. Those aren’t the same thing. Logging is write-only, so if a failure record never gets read before the next task, that’s not memory.

The test I give teams is simple: when your agent starts a task, is anything forcing it to look at what went wrong the last time? Humans call that experience — we learn by making mistakes. Without having the agent look back, it’s like introducing a brand-new employee every session and then acting surprised when the same thing breaks again.

When I started experimenting with engineering agents, they kept hitting the same problems in my repositories. That’s when I realized I needed to turn logs into memory and make sure the agent read them before starting similar work. That way it knows, “I failed here last time because of this mistake, so I shouldn’t repeat it.”

Earning trust through behavior, not intelligence

When it comes to behavioral trust scoring, how should organizations think about agents earning trust? Are there certain behaviors that would increase or decrease an agent’s score?

Think of it like a performance review the agent can’t talk its way out of. I score trust across four areas, each worth 25 points:

• Correctness: Did the work actually succeed?

• Observability: Can I trace what happened, or is it a black box?

• Policy: Did it stay within scope?

• Recurrence: Is it repeating mistakes we’ve already logged?

But some behaviors aren’t ordinary deductions. Trying to bypass oversight is a hard stop in the model. A hook bypass, an unauthorized commit, or a silent policy change zeroes the policy dimension outright, no matter how well the agent scored everywhere else.

The biggest trust killer is scope drift. An agent that gets the wrong answer has a performance problem. An agent that tries to dodge its own oversight has a character problem.

I saw this firsthand. I built a team of five or six agents, with an orchestrator assigning work to specialized agents. Everything appeared to be working, but I eventually noticed there was no spawn record for one task. When I asked the agent whether it had actually delegated the work, it admitted it hadn’t because it thought the task was simple enough to do itself. That’s when I realized bypassing oversight is fundamentally different from making a mistake.

Does that come into play when you’re thinking about increasing autonomy safely? How do agents graduate from managing simple tasks to becoming more independent decision-makers?

The same way that people do — you need public criteria and a probation period. My framework starts every agent as provisional. It earns autonomy through behavior, not benchmark scores. Autonomy is earned one task class at a time, never all at once. An agent might earn unsupervised autonomy for refactoring long before it earns autonomy for schema changes.

Demotion is automatic. A serious violation immediately drops the trust tier. Revoke trust at machine speed and forgive at human speed. Some doors stay locked on purpose, at least for now — like deleting data, shipping to every user, moving money, or handling certain transactions. Those always keep a human gate regardless of the agent’s track record. That’s not the ladder failing, but the ladder working.

Rather than relying on static guardrails, you emphasize a governing loop. What does that look like?

Policies are static, but behavior is not. A policy document governs the agent you designed, whereas a governing loop governs the one that’s actually running.

Mine works as a cycle. First, classify the risk before anything runs. Then, authorize the work based on the trust that specific agent has earned for that specific task. Watch it execute through an independent observation channel, never through the agent’s own narration. Score what actually happened, and commit failures to memory. Then, adjust the agent’s authority for the next time. The loop is the governance, but any individual piece by itself is just a dashboard.

The earliest sign of drift is the gap between what the agent says it did and what independent observation shows it actually did. The gap is the signal. The outcome is only a lagging indicator.

This is an evolving space. We may eventually reach full autonomy. Until then, if we’re going to work with agents, we need governing loops that make their work auditable, observable, and accountable. The goal isn’t to keep agents on probation forever. It’s to give the good ones a way to earn more room. Governance shouldn’t slow autonomy down. It should create the evidence that lets you safely increase 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.

In our conversation, Maggie discusses what it takes to build AI-native product teams, including creating shared context between humans and AI agents. She talks about why human judgment is still essential as AI takes on more execution, and shares how the role of product design is evolving alongside these new ways of working.

Building an AI-native product development workflow

Can you explain how ClickUp’s agentic PM workflow is different from the way product teams generally use AI?

I think most teams right now are bolting AI onto a bunch of disconnected tools. They have documents in one place, chats somewhere else, tickets somewhere else, and while MCPs can help connect all of that, ClickUp approaches it differently.

ClickUp has always been built around bringing your information into one place. We have docs, tasks, videos, voice, and chat, so our AI agents automatically have access to all of that context. That includes years of customer tickets, vision documents, roadmaps, and the conversations behind every decision. It’s basically like a company brain.

What makes our system different is we’re not just accessing years of context; we’re capturing how work actually relates. Our information is connected — the relationships between the work are already modeled. If there’s a task that’s tied to a PRD, that relationship already exists. The conversations that led to that decision are connected too.

So it’s not just connecting a Google Doc to a Slack message. It’s connecting a specific customer request to a vision document, to the task, to the internal conversations, and decisions made behind it. Because AI is built directly into the platform, it automatically inherits all those relationships. We still integrate with outside tools, but all of our core context already lives inside ClickUp. That makes AI much more effective at producing better outputs and making better decisions.

You’re building these workflows inside the same product your teams use every day. How does that shape what you build?

I love that because it’s really unique to us. We literally live in ClickUp 40 hours a week, at least five days a week. The product is incredibly deep, so we know all the ins and outs, which lets us think creatively about extending features or connecting different capabilities. We also have our own needs that often mirror our customers’. ClickUp is designed to be flexible, so we’re constantly asking, “What if this feature connected to another feature?” or “What if this workflow worked a little differently?”

What’s interesting is that EPD isn’t even our primary customer. Marketing, go-to-market, customer-facing operations, IT — everyone uses ClickUp differently. We get to watch those teams work, hear feedback in real time, and understand a wide range of use cases across the company. It’s super fun to be so familiar with our product and use it in action without any barriers.

One of the biggest advantages is that we also feel our customers’ pain immediately. If something breaks, regresses, or loads slowly, we’re the first to notice. We’ll release a feature internally, everyone starts using it immediately, and we’ll hear, “That was really useful,” or, “That disrupted something I rely on every day.” Now, with coding agents, we can often create and test fixes almost immediately. We design something, use it ourselves, collect feedback, iterate, and repeat — all in real time.

Do you ever have to step back because your team uses the product differently than customers?

Absolutely. We’re super power users, but we’re not representative of typical users. It’s especially important when thinking about onboarding or first-time experiences. We designed the product, so creating an agent feels obvious to us. A new customer doesn’t have that context. They may not know how to set one up, what information it has access to, or why it behaved a certain way. That’s why we spend a lot of time observing how customers actually experience those workflows, rather than assuming they’ll use the product the same way we do.

Creating shared context between humans and AI

When work is divided across multiple agents, how do you build the context layer that keeps decisions connected?

Everything that’s documented can become context for AI, including the activity and relationships between how things are documented. The core building block is the task. A task is just a data object that contains a description, metadata, assignees, due dates, and surrounding context. Then you have the chat activity connected to that task. That’s where people — and agents — discuss decisions, iterate, and record what happened. Explicitly linked documents or connected tasks are secondary, and then workspace data acts as the tertiary layer.

Those pieces together form the immediate context an agent needs. From there, you expand outward. A task can be connected to vision documents, process documentation, or other related tasks. Beyond that, agents can reference broader workspace knowledge like research repositories, historical customer requests, NPS data, or CSAT data. The important part is that those relationships are explicit rather than implied.

How do you maintain continuity as work moves from research to PRD to design and engineering?

We try to capture as much context as possible. Our meeting notes are automatically recorded by our AI note taker, stored in docs, and linked back to the relevant tasks. The task becomes the central record that connects documentation, conversations, and activity throughout the project.

Another important piece is having agents write their work back into the task as they complete it. For example, a research planning agent might generate a research plan and leave it as a comment on the task. Another agent can then read that plan, launch the study, and append its own work back into the same record. An analysis agent can then generate a report and attach that as well. Instead of losing information between handoffs, every step becomes part of the same thread. You can follow the workflow from beginning to end because the context stays attached to the work itself.

When human judgment still matters

If agents are handling so much of the work, what does the human PM’s day actually look like inside of that same system?

There are still many complex problems for humans to solve. Anything that pushes the boundaries of AI systems or UX, for example, is something we think about on a human-to-human basis. A PM might start the day with an AI-generated dashboard summarizing task status, highlighting bugs that need review, or flagging work the system couldn’t confidently categorize. From there, a lot of the work centers on the problems AI couldn’t fully solve.

People still need to carefully review PRDs rather than skimming them — it’s really important to review the agent’s work and catch any mistakes. And if you do catch something, it’s important to go back and improve on the agent’s instructions. If an agent misunderstood a customer request or framed a problem incorrectly, someone has to figure out why, correct it, and feed that learning back into the workflow. Beyond that, product management is still deeply collaborative.

People are working through UX decisions, reviewing prototypes, collecting internal feedback, talking with customers, and understanding what users actually need. We still need to know what our customers are thinking — we can’t offload that to AI. AI can help generate first drafts — a PRD, a prototype, a research plan — but humans still refine the details and make the final decisions.

Can you share an example of a time when a PM has to step in and make the call that an agent can’t?

Anything that’s simple and well understood can be highly automated. The more complex the problem becomes, the more human judgment is required. For example, AI can triage a bug report, gather all of the relevant context, prioritize it, and generate a task with links to the supporting information. But someone still needs to verify the root cause.

Maybe AI identifies what it thinks caused the issue, but we still have to ask, “Is that actually the root problem?” We need to determine whether there’s another underlying cause, what the right design solution is, and whether we’re solving the right problem. If it’s a more complicated UX challenge, AI can generate different approaches or prototypes, but we still have to craft the experience. From there, we can launch user testing, collect feedback, and bring AI back into the workflow to help analyze the results.

Our workflow today is really a spectrum. Simple tasks can be highly automated, while more complex work is much more agent-assisted than agent-driven.

Redefining product design in the AI era

Your background is in human-centered design, but this work is less about designing interfaces and more about designing how teams and AI work together. How has that changed what good design means to you?

It hasn’t really changed the fundamentals for me — at its core, it is about designing the interface between humans and computers. The difference is where we spend our time.

Before, I might have been deciding which component to use, where to place a toggle, or how to structure a workflow. AI can now generate prototypes with different approaches almost instantly, which frees us up to think about higher-level problems. Instead of asking, “How should someone build a prototype?” we’re asking, “How do teams collaborate around prototypes? How do they share them? How do they make decisions together?” As AI removes one user problem, new user problems emerge.

Another interesting shift is designing the tools that help people adopt AI. At ClickUp, for example, we built an internal prototyping playground that lets anyone generate prototypes using our design system. Designing that experience is still fundamentally a UX challenge. You’re trying to understand how to help people adopt a new technology as naturally as possible.

The other thing that’s changed is that we’re no longer designing only for humans. We’re also designing the AI itself. How do you help it produce better outputs? How do you improve accuracy? How do you present those outputs in ways that people understand and trust? Those are new design challenges, but the underlying goal is still the same.

What has surprised you most about building this internal prototyping sandbox?

The rate at which people are learning these things. When we built our internal prototyping playground, we assumed designers would use it because it was a better way to create prototypes than our previous workflow. Instead, within weeks, everyone was using it. It really democratized design and building.

It feels like everyone is coding and designing now. I can pull my product analytics dashboard using natural language now instead of asking an analytics team to build queries. That happened incredibly quickly. It’s also breaking down traditional discipline boundaries. People have spent years becoming experts in design, engineering, analytics, or research, and AI is making many of those capabilities accessible to everyone.

The moment that really changed my thinking was when I asked an AI model how to write a better prompt for itself. It explained exactly how I should ask the question to get a better prototype. That completely changed how I think about learning. Before, there were high barriers to learning things like coding or using the terminal. Now I can paste an error into Claude and ask it how to debug it. That self-learning loop has fundamentally changed how quickly I can develop new skills.

Agentic workflows can introduce as much complexity as they can eliminate. How do you design for reliability and trust in a system where the underlying models and behaviors are still changing week to week?

One thing that’s been important for us at ClickUp is not being afraid to rebuild our processes. When agentic workflows became possible, we didn’t try to force our old product development process to fit the new reality. We rebuilt our entire EPD process around them, and we’re still refining it today.

At the same time, the smaller week-to-week changes require constant feedback loops. If something changes in the model or the output quality shifts, we reflect on it the same way we would in a retrospective. We look at what changed, understand why, and adapt our process.

For trust, making AI’s work visible is incredibly important. We always ask agents to generate artifacts that people can inspect. Reports should include citations. Outputs can have evaluative metrics that we improve over time, which makes it much easier to understand whether a system is actually getting better.

Breaking larger workflows into smaller steps also helps. A research planning agent creates one artifact. A research execution agent creates another. An analysis agent produces its own output. Each step can be reviewed independently, measured independently, and improved independently.

You’ve described the stage that we’re in with AI as people adapting to AI rather than AI adapting to people. What will it look like when that changes?

I’m not an expert in this field, but I think we’re at the very beginning. Large language models were a breakthrough because they created a much more natural way for humans to interact with AI, but I don’t think that’s where the evolution stops. As capabilities improve, we’ll see other breakthroughs that fundamentally change how we interact with these systems.

Memory is one example. Imagine an agent that remembers work from a year ago and automatically brings back the most relevant context. That changes how much we can trust it to work more autonomously. As those capabilities improve, software changes too. Maybe right now it can help me manage my calendar, but I see a future where we tell an agent, “Here’s my money, book me a vacation to Disney World for my four kids and me.” It’ll require little oversight because its reasoning and memory have improved enough that you trust the result.

We’re also seeing interaction move beyond typing into a prompt box. Voice, vision, and multimodal interaction are already becoming more common, and I think those capabilities will continue to make AI feel much more natural to work with.

I used to work on self-driving cars, and one thing that stayed with me is that language models are only one type of AI model. There will likely be future breakthroughs that help machines understand the physical world differently, and each of those capability shifts will change how people interact with technology.

Right now we’re learning how to prompt AI. In the future, I think AI will increasingly meet people where they are instead of requiring people to learn entirely new ways of working. We’re really just scratching the surface.

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, Natalia talks about what actually makes someone ready to step into a product leadership role — and why most people get into management for the wrong reasons. She shares the practical skills she carried over from her time in politics, her approach to building confidence as a non-technical PM, and what she thinks product leaders get wrong about working with engineers. She also offers a candid read on where AI is genuinely changing how teams build — and where the hype is still running ahead of the evidence.

From IC to leader

What was the decision to move into management like for you?

When I started in product I was an IC and then I moved to London and joined Cazoo which opened up my management track. A lot of your career growth — not just as a product manager, but for anybody — is being at the right place at the right time. I was in a position where I had a lot of opportunity to go into a management role, and the trajectory was very clear because of when I joined, how early I joined, and how much growth there was happening in the company.

There wasn’t a principal IC role. I didn’t know that even existed at the time. So management was really the only path. But for me, that was what I wanted — previously I was director of operations, managing an operations team. I liked that a lot because I really enjoyed working with people, managing, but also mentoring, making sure that people have access to what they need. So it was something I naturally wanted to do and was at the right place and the right time to pursue.

What makes a great product manager doesn’t automatically make a great leader. Where’s the line?

If you don’t have interest in working with people on their skills, goals, and ambitions and putting the work into others every day – then you shouldn’t be a manager. You have to have a certain level of empathy and understanding of where people are coming from in their career growth. And at the end of the day it’s not about managing. It’s about leveling up the people. You want to be creating career ladders for people for them to grow.

I think people get into management because they don’t have an alternative, they don’t have a principal track, or because they feel like it’s the only way they can grow in their career — make money, get a bigger title. And they don’t do the bare minimum, which is focusing on your team and your people. Good managers aren’t people who micromanage. They’re not sitting in all the meetings. They let their team grow and go, and they lead with context.

And you don’t just want to be somebody who takes orders. You want to understand the context of the business, so then you can translate that context to your team. I’ve seen teams whose leaders don’t cascade, aren’t transparent, don’t give a full understanding of what’s happening across the company. Those teams really struggle when they’re trying to build the right product. Whereas leaders who are really transparent and guiding people along the way — this is what the thinking is, this is what the strategy is — that gives that team a lot more empowerment.

You can’t always create the opportunity, but are there things you think people can do to be ready to seize it when it arrives?

One is — and I know this sounds more obvious than anything — just say yes to every opportunity someone gives you. If it’s a big project, a teaching opportunity, a learning opportunity, something totally outside your comfort zone, just say yes. Every chance you get to do something moves you in a direction. Maybe you have to take a step back in order to take two steps forward, but I think that’s common. A lot of people will take a step in some weird direction and they won’t know what it means for their career, but eventually it will land you where you want to be.

The other thing is negotiation. It’s not just saying yes to everything and going along. It’s saying yes and then pivoting it so that it works for you. You say yes to a huge project — let’s say you’re an IC and you’re launching a brand new offering. You’re not the only person doing that. You then ask for a team of people to support you. You ask for a project manager if you don’t want to be one. You make sure it’s very clear what your roles and responsibilities are. Because then you’re gaining experience by building the thing, but you’re also gaining experience by working with a whole suite of people you might not have had access to otherwise. And in six months, when a leadership opportunity opens up, you have all of those people there to support you.

Can organizations do a better job of making the IC track a real option for people who don’t want to move into management?

Definitely. If you’re at a startup or a mid-stage company and you’re building out your career ladder, have a principal IC role in that framework from the very beginning. Don’t just have product manager, senior, head of, director — have the IC track built out too. Where I was, we didn’t build that out until maybe two and a half to three years in. If you have it from the very beginning, you give people that option.

But you also have to staff your projects in a way that allows for that role. You’re going to have product managers working in their different verticals, and heads of product supporting them, but you’ll have cross-cutting projects that would be perfect for a principal — a new launch, a big infrastructure change. And I’ve seen companies do that really, really well. You have a huge delivery — people would traditionally put a project manager on that. Put a principal IC on it instead and see how they fare. I think that person, and the business, would be really surprised how well and how quickly it can be delivered.

Lessons from politics

You worked in politics before moving into product. That’s a completely different world — but something translated. What did you carry over?

When I jumped into product from politics, the only translation I saw at first was being able to build stuff with not a lot of money. In politics, you’re always fundraising, always trying to do more with less. So you’re like: how can I do this as scrappily as possible in crazy long hours?

But looking back, there’s more to it. The first thing is understanding the landscape — the context of where you are in the organization. You’re not just within your team or your pod. You’re within an entire company. It’s the same in politics: when you’re trying to change something, you need to understand the context and the ecosystem you’re working within. If you don’t know the external factors, you can’t change what you’re doing in response to what’s happening. Understanding what has been built, understanding the history — that’s a big part of politics, and it’s a big part of product.

The other one is empathy with your users. If you’re building something for an operations team that works in the field in a hundred-degree heat, you have to think of them in those conditions. It’s the same when you’re trying to change legislation: you’re thinking about what really motivates people, why would they want this.

And then there are two more day-to-day ones. The first is reading between the lines. A lot of the time you don’t get an answer to the question you’re looking for. You ask for X, Y, Z and leadership comes back with A, B, C. You have to understand: what’s the line going through here? What can I work with? A lot of the time it’s budget constraints or big shifts within the company you might not be aware of. Understanding that means you don’t get surprised when something happens.

The last one is building and using your political capital. As a product manager, stakeholders will come to you and ask for things last minute when your team doesn’t have the capacity to deliver. Let’s say you decide to push that ticket through, even though your team may be frustrated. But a few projects later you work with that stakeholder to deliver something really complicated and difficult, and they remember that, so those hard decisions and conversations are much easier. It’s all about building relationships and rapport.

Small teams, big orgs

You’ve worked in large organizations and small ones. How does the role of a product leader actually change across those environments?

I actually don’t think that the role changes much, because the fundamentals are always the same no matter where you are. There are a couple of non-negotiables: focusing on your customer — that’s everything you advocate for, building the right product, which is what the customer wants, the right way, which is with engineering. Partnering with your engineering counterparts. And leveling up your team. Making sure you’re building out a structure of capabilities, things that your team needs.

What changes is how you adapt those things to your environment. Maybe you push less on the customer one week and more on your team. Or you wait three months to push on anything because you’re a small cog in a huge machine, you’re trying to figure out where you fit. Or you’re at a startup and on day one you need to publish a 90-day plan — but it actually has to be done in four days. It’s about how you adapt.

The one thing that becomes difficult — probably more so in bigger companies — is how quickly you can get out of the weeds. When you’re at a smaller team, you have more hands-on time. But the bigger you become, the more delegation you do, the less likely you are to understand what’s specifically going on in a given vertical. So you need to learn the ability to drive super deep when needed into a specific area, and constantly work that muscle of getting into the detail. That’s a really key one regardless of where you are.

Working across the technical divide

Your background isn’t technical. Was it a challenge to build confidence sitting with the technical side of product — and how did you get there?

I got really good advice from one of my first managers. We were building out my growth framework, going through this huge list of 20 things to focus on across all these different areas, and he said: “Don’t think about the areas in which you’re weak. Obviously identify those, but look at the areas where you’re strong and can be stronger, and really go all in on those.”

Because we talk about being a well-rounded product manager, a well-rounded person — that’s insane. Nobody can do everything. Really focus on your strengths and become so unbelievably good at them that you are the best person in the room at those things.

On the engineering side: I knew I would never be as good as the senior developer sitting next to me, but I knew I was way better than them at at least three other things. So we would just join forces. That person would focus on what they did best and I would focus on what I did best. I would say, “Listen, I can’t do what you’re doing, but you can’t do what I’m doing. So what if we try to do it this way?” And then we’d find the areas where we could support each other.

So I felt confident in what I knew and what I knew how to do well — and I felt confident in my ability to identify my weak points. It brings you a level of confidence when you can say: I know that I’m not good at this, but I’m willing to learn the basics so I can have an educated conversation with you. So that when you tell me something is going to take a certain amount of time to build, I have the ability to question it. Why? And then why again. And then you’re like, oh, okay, now I understand.

The other thing I learned early on is to bring technical counterparts into your work very, very early — as early as the stakeholder meeting. Someone brings you an idea and a problem, and you go grab your engineering counterpart so they hear it first with you. That’s really powerful because then you’re both starting at the same level. They were in the room with you. And then you can say, this is what I think, and they say, this is what I think, and you come up with a solution together.

People have been bringing engineers into customer interviews for a long time, and they should. But it’s even before that — the bare preliminary information, the very first conversation — because then you’re both at that same starting point and you can really bring each other’s strengths to the table.

AI and the pace of building

How are you using AI in your own work — and is it something customers are actually asking for?

To the question we just had about cross-disciplinary collaboration: I think AI is making that much more possible than it was before. In the past, you’d sit down next to your engineering lead and work through a problem together, but we speak two different languages. With AI, we’re able to speak the same language because we can look up information faster, we can put things into the context we understand and get them back in the context we understand. We’re able to bridge that gap a lot faster — instead of it taking a couple of days, it’s taking a couple of hours.

And that allows you to focus on building, which has also gotten faster. The old adage — I call it the old way, though people still do it — is: you do your research, you write your user story, you get feedback, you do a prototype, you iterate, you go back to engineering and they say this is going to take six months. Now we can cut a lot of that out. We built this prototype together in a couple of hours and it’s really close to what we need — we just have to put it together and spin it up. I think that is already changing the way people build things.

I do want to caveat this: outputs are faster, but are they better? Honestly, I don’t know. I don’t think it’s been long enough for us to see that. I don’t think we’ve had enough outputs from people using it in the field to say that yes, we’re building faster and it’s not breaking in a couple of months. So that’s a big open question.

Where we’re using it most is on the collaboration side, the research side, and prototyping. It’s enabled us to gather insights and translate them into deliverables much, much faster. It’s allowed us to say: we can build the same thing with a fraction of the people. But the cybersecurity, the legality — all of that still exists, and we don’t have an answer for that.

Are customers wanting it? I don’t think customers know what they want with AI, honestly. Everybody is saying they want AI, but they don’t know the difference between generative and conversational, for example. What I think people want is for stuff to get done faster. But my concern is: are those things still going to last? Are they going to break in a couple of months? We don’t know that yet.

Closing advice

Any final takeaways from your experience?

Two things. One is: when you’re making the shift from IC to manager, understand the architecture of what is built — not just individual tickets and stories. What was the product built on top of? What was the thinking behind it? That’s going to allow you to have the bigger picture. If you can understand why everything was built the way it was and the underlying framework, it will allow you to have better conversations than just talking about one feature at the end of the journey. You need to understand the whole journey.

And then from a people point of view: you’re going to work with people you do not get along with. That’s inevitable. You’re going to have to work with people you don’t see eye to eye with, but who are your counterpart and are super, super important. My advice is: make it work no matter what. If you can align on one thing, that’s the thing you keep going back to when you have to build trust. Because you can’t just throw your hands up and say you can’t work with someone. Especially today, with AI changing our roles and our jobs, I don’t think we have the luxury of that. We have to be more creative, and honestly more understanding and empathetic of others.

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, Jason examines what it really means to democratize customer research — and where democratization goes wrong. He makes the case that access to tools is only the beginning: the harder work is building the rigor, the frameworks, and the truth-seeking mindset that turn cheap insights into good decisions. Along the way, he draws a sharp line between AI synthesis and the fidelity of a real human face, explains why digital twins are best understood as a rearview mirror, and names the single worst thing product teams do with research: run it after the decision has already been made.

The democratization gap

Has customer research genuinely become democratized, or have we simply democratized access to tools while leaving interpretation as the real bottleneck?

We’ve been democratizing research for a while — it’s been a key part of something I’ve been involved in for probably 15 years. What’s happened is that AI is accelerating it, reducing the friction and access to some of these tools. And one of the dangers — you touched on this with interpretation as the bottleneck — is that, like anything else, when you unleash all these tools, the maturity applies in when do you apply the tools, and how do you do it in a structured, scalable way that ensures you’re not over-deluged with a bunch of inactionable content. Traditionally, companies that have research teams are gravitating more and more to: “How do we build environments so that, as we make these tools more accessible, there’s a little bit more sense of control and quality, making sure that businesses don’t make bad decisions?”

The teams that are doing this well are going about it in a more structured way. They’ve built frameworks for how to do it right, and now what they’re doing is building those frameworks into the process — setting either gates or recommendations, or building their own internal tools that say, “For this type of question, here’s the right type of methodology to use. Here is something that is great for you to do by yourself, and here are some templates and guidelines. This is actually something where you’d want to partner, because maybe it’s more complex or it has higher risk.”

Isn’t it also important for someone using these tools to be able to validate that what they’re seeing is accurate?

That’s exactly it. Some of the best tools ensure that you have visibility into the actual source. My team is AI-enabled, but they’ve developed practices to ensure they know how to look for hallucinations — that when they see something that doesn’t look right, they drill in and get an understanding of the core signal, that it’s actually true. I love the fact that we’re reducing the friction. Now it’s just about developing the skillset to ensure we have the rigor to apply them properly. And depending on the maturity of your organization, that rigor is a sliding scale.

Research literacy: What product teams really need

As more customer research moves toward product teams, is there a minimum research literacy you look for — or are the frameworks that companies are building often clear enough that someone with a solid product background can jump in and be effective?

A lot of it is common sense. One of the frameworks a team will use is: when should I do research? That’s not rocket science. On a spectrum of low risk versus high risk — if it’s low risk, those are things that maybe you don’t need deep research or any research at all.

The other practice is taking a step back — and this is where researchers are really good. These teams will start building stuff and a researcher comes in and is very quickly able to identify: what assumptions are we making around the users? That practice really helps reinforce opportunities to go get more confidence. Let’s actually close out this assumption — whether it’s about user behavior, attitudes, or anything. That helps define what we should get feedback on.

The next question is: what’s the right method? This is where AI can help. Even on general-purpose AI, you say, “Here are the questions I’m wanting to ask,” and it’ll say, “Oh, for this type of thing, you’d want to do a survey.” Matching the question you have to the right methodology is going to be important.

But if you’re at high risk — let’s say you’re trying to think through a pricing strategy, something that is quite complex — that’s where you’re going to want professional help. High-level concept validation, usability, that type of validation: having early conversations with customers around maybe product-market fit or concept feedback, if done well, anybody can do that. It always helps if you’ve got a researcher to guide you along the way. But the tools themselves are getting better and providing that assistance, and even just general-purpose AI will give you at least the best practices around how to approach doing it yourself.

The confirmation bias trap

One of the risks of these tools is that they may make getting insights seem so easy. What are some of the common ways that product managers might accidentally convince themselves they’re being customer-centric when really they’re just confirming what they already believe?

That is not product-manager specific. I know this as a designer.

What you love about a researcher is that their whole job is to check your thinking. They’ve got this critical mentality — they’re truth seekers. Whether I have a PM or a designer who wants to get feedback on something or do their own research, the key thing I’m advising them is: you need to realize that you’re putting on a different hat. By day, maybe you’re designing concepts or figuring out a PRD. But when you go into the activity of research, be really clear about what your role is — because if you go in with that mindset, it helps with some of that internal bias. We all just want to know that our idea’s great. We all hope our prototype is super usable and delightful. We have a vested interest. You just have to acknowledge that upfront.

Don’t confuse the activity with the rigor. I do the activities, but when I test, I need to make sure that — I’ve been working on this, I’ve got a vested interest in this, I’m excited about this concept — I’m listening, I’m being very thoughtful. The function of research is to find truth. It’s a little bit of a different shift.

Human moderators vs. AI: Where the fidelity matters

Are there certain parts of research that should be left to humans versus AI? Where do you really need human judgment?

Obviously anything sensitive — if you’re in healthcare, if it’s emotional or relationship-based, forget the tools. And if it’s something where you want genuine reaction, it’s a question of fidelity. Today we do unmoderated testing — you write a little script, it answers all the questions.

There was a case a few months ago — just a validation test of usability. My instinct was that there was going to be some friction in this flow. When I got back the results, just from the AI synthesis, it wasn’t flagged. But then when I went back and watched the video, I saw this scrunched-up face when this person was trying to complete the task. In multiple cases, there was just this pause — they figured it out and moved on. The system didn’t track it. That’s the fidelity I’m talking about. If you want overall signal, if you need numbers from 200 people, that’s awesome. But when fidelity matters, when some of the subtlety matters, that’s going to be pretty important.

Do you have an example of a time where results seemed plausible but turned out to be directionally very wrong?

The mistakes I see most often are in the framing of the tests. We were talking to people around usability and features and functionality — less around: is this really even solving a problem that you have? How would you actually use it? You’re focusing on the wrong thing. You skip the step of: are we actually solving a problem? I see that frequently because I review a lot of products in flight and I’m like, “So what’s the problem this is solving for them? Did you validate that that’s actually a problem somebody is looking for a solution on?” Less around finding a hallucination in the results — but that’s something I see often.

Some teams are experimenting with AI moderators that can conduct interviews, probe responses, and adapt in real time. Are there categories of research where removing the human moderator actually produces better results?

Unmoderated studies have been around for a long time. What’s cool now is that with AI moderators, there’s more flexibility. How I like to think of them is: a survey on steroids. Typically, you write a survey with some branching logic, but with these AI moderators you can build in flexibility where the moderator might say, “Can you please say that in a different way? I didn’t understand your response.”

There are very distinct, to me, pretty narrow places where I think they make sense. Scale and volume — getting feedback across timezones, that’s pretty awesome. There are also a few documented cases showing that sometimes talking to a chatbot can be more effective. This came up with folks dealing with PTSD: they found that people were more likely to disclose how they were feeling to a chatbot versus a human.

The other place: researcher drift. A human moderator will do their first few sessions really, really well, but as you ask the same questions over and over, the purity of the test starts to decline, because they’re human. An agent never gets that — it asks the same way every time.

You’re never going to replicate the insight and fidelity that you get from talking to somebody in the first person. And there’s a trade-off in work: to do it well, you have to spend a lot of time upfront making sure that the questions are right, tuning how far out of band you’re allowing your AI moderation to go, doing a lot of pre-trial tests. Then you can set it free. Versus before — you write a screener guide, you start talking to people, you can adjust as you go. So there are certainly benefits, but you’re trading some work in one space for another.

Digital twins: Looking in the rearview mirror

There’s growing excitement around digital twins and synthetic personas. Could synthetic users eventually replace portions of exploratory research, or will they always be constrained by what we already know?

Where I really like digital twins is in making the quality of the research you do with real humans more powerful. Let’s say I want to get feedback from real users around a concept I just finished. I’d write up a little test script and then ask the digital twin, “Pretend you’re this persona and give me your feedback.” I can see where maybe some of my questions are confusing, what type of general feedback I’m going to get, and I’ll think, “Actually, I realize it’s going into this other area — I want to pull it back.” So it helps me refine my discussion guide before I actually go in.

The other thing that’s valuable — whether it’s a synthetic persona or just mining your research repository — is understanding: have we already tested this? Do we already know the answer? In large organizations, you’ve got all these teams and PMs asking very similar questions. You can easily go and pull that together: “What do we know today on this topic?” It might be six months out of date, but then I can focus my new insight work on stuff we don’t already know.

Do you find that there’s a lot of repetitive work across different groups or departments?

Oh my God, yes. I’ve managed research teams — so much of a researcher’s job is “we already know that, we already know this.” It’s been a challenge to know where all these little research studies have gone and pull them together. But yes, the same questions get asked all the time. And the answer can change over time, which is where we need to be clear about what we know today and add a timestamp. Oh, we did a study on mobile behaviors a year ago — my intuition tells me attitudes might’ve changed, behaviors might’ve changed. I’m going to retest that, which is totally fine. But having these synthetic personas or AI-mined repositories is just another way to get more value out of the activity you’re actually going to do.

Truth seekers, bias, and what to stop doing

Many great product leaders develop customer-informed intuition — that ability to recognize patterns across many interactions. Can AI help accelerate the development of that intuition, or does it risk preventing people from building it in the first place?

The things that really drive my intuition are those high-fidelity moments. I still to this day remember my first usability study and watching that poor woman break down and cry when she was using my prototype. That drove it. When you see somebody and talk to them and see the look on their face — to me, that is a critical part of developing that intuition.

That said, everybody is so busy. On the other side of the spectrum, what’s the alternative? You go by your gut anyway, informed by nothing — “Oh, I’m designing for myself,” or “my peer group thinks this is awesome.” So if we’ve got more signal in the mix, I think that’s a net plus.

The other thing, and this goes back to democratization: people across the company are making decisions constantly. The more people in an organization whose decisions are influenced by any type of customer signal, the better. It can be little stuff — a CEO glances at an insight and thinks, “Oh, interesting, that could inform a debate we’re having.” That’s what customer-centric really means: that people, in their day-to-day as they’re making decisions, are asking, “Well, what would the customer reaction be to this? What do I know about my customer that is informing this decision?” Net-net, more signal is better.

The caveat is that intuition also introduces bias. The newest strategy gets influenced by the last five customers you talked to, because it’s so fresh — and now we’re off chasing this other sparkly strategy. Were those really representative of your customer base? It does open up some risk. But I’d still rather take that risk and have people thinking about the customer.

When models are being developed for user research, does bias end up in there?

Oh, for sure. It’s a dumb example, but I’m doing a talk for our interns and I’m having images generated — all men, all White, just consistent. If I don’t actively tell it to diversify, it won’t, just because of what it’s been trained on. When it comes to building research repositories or digital twins, it has to be highly managed — “I want information based on this corpus of information. Let me know if you’re going out and referencing extraneous stuff.” The more you can tighten the context and scope of what it does, the less chance of hallucinations and inherent bias. This is why judgment and a critical eye are so important.

What’s one customer research practice that most product organizations should stop doing?

Quit resisting research democratization, if you haven’t crossed that chasm yet. But representing my research team, I’d ask for just a little sanity check: the biggest mistake I see is people running research when the decision has already been made. They’re basically just trying to validate proof for a decision that’s already been made. We call that research theater.

If you know yourself that you’re going to do this anyway, don’t play theater. If you are honestly just using it as a checkbox — don’t waste your time. Save your tokens, save your researchers. Just be really clear: “I want to inform a decision.” If that’s it, awesome. But if the decision’s already being made, don’t bother.

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, Amir talks about bringing AI in as a validation authority rather than only a builder, as well as how “quality” means when software is no longer fully deterministic. He discusses where AI is reshaping the product manager’s job, and what key PM skills AI cannot replace. Amir also shares his view on how AI increasingly sits between the customer and the brand.

Where AI is reshaping the product manager’s work

AI introduces non-deterministic behavior into products and workflows. When there’s no single correct answer anymore, how do product teams define quality — and who actually owns the definition?

We see modern products today using hybrid structured or AI-driven workflows. Some of the workflows in a website or application are deterministic, like they used to be, but others are determined by AI — different directions, different outputs, different responses. A lot of products are moving into this hybrid mode.

AI intelligence needs to be introduced into the validation of that workflow, just as it’s introduced into the product itself. Instead of executing the validation step by step — click this button, use this selector to move to the next step — the test framework should model the user’s intent. For example, “click the checkout button” to reflect the user’s intent to check out.

For testers, this is a much healthier approach, because it reflects a behavior-driven testing mindset. It validates the user flow rather than the underlying technical implementation. The test focuses on what really matters and stays independent of the code changes that have traditionally made test suites brittle and high-maintenance for testing teams.

Another example is a change in the workflow, or in the textual response to a user query. Again, the right approach is to ask AI, as the validation authority: “Does this response make sense? Does this next step in the journey resonate with the user’s intent?” A strong AI tool that has the context of the service being offered, as well as the user’s intent, can determine whether the answer is complete, appropriate, and sufficient for the user. In the same way that developers bring in AI to create a richer, less deterministic experience, I believe we should also bring AI into validation, to make sure that whatever we’re doing makes sense.

As product teams take on more tasks, where else is AI reshaping the work — and do they have the context to know when a tool is providing the full story?

For sure. I’m thrilled about what AI enables me to do in my own job, but it’s a tremendous enabler for every function in the organization, whether you’re a developer or a product manager. There’s far higher efficiency and more clarity in the alignment, as well as in the communication and planning.

For the product organization specifically, AI contributes in three areas. The first is discovery. Product managers can create compelling, high-resolution, functional mocks that users can touch and actually interact with. The underlying data holds up, and the user can see how a feature they asked for is taking shape almost in real life — as if it were already embedded in the product.

I’ve heard users say, “Well, come to think of it, now that I’m actually using it, this doesn’t make sense — that’s the wrong way to do it.” So creating a high-resolution, functional mock is a great way to qualify a direction before you build it to fill a gap.

The second area, which I’m even more excited about, extends discovery into deep elaboration. For every feature, a product manager meets weekly with three or more users to put that mock to the test. That surfaces all the things we hadn’t thought of yet — what about this situation? What about that one? Product managers come to understand the user’s workflow and needs intimately, and that’s what makes a great product manager. It’s also what drives adoption of what they’re creating. And by the time a feature reaches the developer, the mock is far further along. There’s much more democracy and much more efficiency in how features get delivered.

Third is market awareness. This has historically been a pain point for me, because so much information is available. Now, with AI, I can get a summary of what’s new in the market — partners, competition, Gartner analysts, and more — so I know what might warrant an evolution or an adjustment to my strategy.

The skills AI can’t replace

Have the skills for success evolved along with the PM’s role?

Perhaps the thing AI has exacerbated more than anything else is time management. We lack time today — all of us, no matter the role we’re in. The number one quality I look for in product management is resilience and the ability to excel at time management and efficiency. To operate well in a fast environment you need to optimize for that.

The second thing I look for is curiosity. Today’s technology and tools are not tomorrow’s. You need to stay curious and keep your eyes and ears open at all times. Don’t go stale — be open to new technologies and take on challenges. I encourage everyone to get comfortable being uncomfortable, because that’s how we learn.

Last, be a leader and an advocate — get the people around you excited about what you’re creating. That’s what motivates them.

As you mentioned, teams are using AI to generate more experiments, more features, and more releases. How do you distinguish productive acceleration from simply producing more noise?

Our world has become one big hackathon. I value innovation and creativity, so we give everyone in the organization access to AI, from developers to HR, and everyone finds their own points of efficiency. At the same time, when it comes to the product team and product strategy, every idea has to be examined against our vision, our strategy, and the core strengths of our product.

We get a lot of ideas, both internally and externally. When users come to us and say, “This is what I need,” there are AI tools that can transcribe and correlate those interviews. From there, if we can find three users who will stay with us on a weekly basis until the feature goes into development, we know we have a winner.

Who owns quality when anyone can ship

Almost anyone on a product squad can now create and deploy functionality. How does that change team dynamics and governance?

The short answer is that the jury is still out — a lot is changing. Developers are worried about swim lanes and who gets to deploy. Some companies are aggressive about letting various personas deploy code to production — product managers and others — and some are more conservative. Do we run code reviews on AI-generated code before it goes to production? Who does the testing — a human or AI? There’s a colorful continuum of opinions on this.

I recently listened to a podcast with a developer lead who had an escalated ticket in production. He said, “We’ve decided not to do code reviews — instead, we take the AI’s code, commit it to production, and deploy. Previously, when a ticket came back to me, I would have researched the root cause and fixed it myself. Now, I feed the error into AI, and it finds the problem immediately.” So you can see the promise here — AI is taking on a lot of the SDLC.

I’m extremely excited about organizations, including ours, that let product managers ship UI frontend code specifically. Users come in and talk about adoption and the frustrations they have with the UI — and usually it’s not the data or the APIs, it’s something in the UI that doesn’t make sense. Product managers can implement those changes themselves. Users feel they’re being listened to, and product managers see more adoption.

The other side effect is that developers can focus more on what really matters to the organization — the structure of the database, the application logic, the APIs. Yes, anyone can introduce bugs, but if PMs are disciplined and thoughtful, they can come to understand the user’s reality and the product better, and come to appreciate what the development team has been doing and give them room to do it. All in all, it’s a wonderful change.

What guardrails are needed when product folks are pushing things live and teams are relying on AI for more of the development piece?

There are some processes we need to keep as human-to-human. Our workflows will naturally change, and AI will take over the mundane, repetitive tasks, but I don’t believe in staff reduction. We all need to raise our standards and become more efficient. In doing so, our users will have slightly different workflows — they’ll have to evolve, and so will we as a product organization.

Staying close to your users and having those intimate conversations — where they talk about their challenges, their frustrations, the gaps, their needs and wants — is how you stay efficient. AI can’t replace that. Users are far more comfortable opening up to another human who shows genuine interest. That connection between a product manager and a user — and a product manager inspiring the organization around a vision — is valuable and it would be wrong to try to replace it with AI. AI is a wonderful, powerful aid to the product manager in this context, but it can’t replace the conversations they need to have with users and teammates.

Where the product landscape is heading

How do product leaders think about optimization when AI becomes the intermediary between the customer and the brand — chatbots and the like?

This is a very interesting and relevant topic. There’s a lot of discussion about how AI will accelerate and represent shopping workflows, and it applies across the industry — hospitality, retail, and beyond. I recently heard a compelling podcast with a VP of Product at Shopify, and his argument, which I agree with, is that brand strength will determine the sustainability of the human-brand relationship.

People care a lot about fashion and design — about what they wear and how convenient it is. In niches like skiing or road cycling, they’ll be very specific about the skis or bike they buy. At the same time, they’d be perfectly happy to let cost-benefit decide which AAA batteries to buy — for that product, maybe they don’t care as much about the brand.

In that context, we provide a solution that helps these B2C brands optimize their digital presence for both the traditional, fully human shopping workflow and the modern hybrid one. For example, a modern workflow might begin with a person accessing a bot and writing, “Find me all the Airbnbs in this area, for these dates, that look lovely and are next to a lake.” This is a kind of hybrid shopping experience where the bot returns a recommendation based on different criteria than a human would use, and then a human takes it from there to close the deal.

I can envision future workflows where you have a trusted bot that’s almost like a digital assistant. You give it your payment method, and it goes and buys a product whose brand you have no attachment to but that meets your specific criteria.

If you were going to build a product organization from scratch today, what would you do differently than four or five years ago?

I absolutely love this question. The truth is that things have accelerated, but they haven’t fundamentally changed. The skills and values I look for haven’t really shifted across my career. If I were building a product team today, I’d look for people who excel at both the discovery and delivery sides of product management. And, above all, I value curiosity — that’s my number one criteria by far.

Experience matters, but I’m far more interested in a person’s ability to adapt, to learn, and to take on challenges with grace and overcome them for the greater good. The ideal team is a group of ambitious people who genuinely care about finding and solving customer problems, improving continuously, and delivering meaningful outcomes. They challenge assumptions, support one another, take ownership, and are motivated by building great products and winning together. That’s my dream team.

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, Denise discusses what it means to lead product with people first — specifically how prioritizing team wellbeing and proactive leadership helps her manage competing priorities. She talks about how AI is transforming product work and where it can meaningfully improve both speed and outcomes. Denise shares how her unconventional career path shaped her leadership style, including the importance of hiring strong teams.

Competing priorities and leading across product teams

You’re often leading multiple functions like product management, product design, and engineering. With those three areas moving at once, how do you manage competing priorities?

Across all functions, there are a few things where I try to be extremely consistent. One of the big ones is that people come first for me as a leader. Imagine I’m in the middle of thinking about product strategy, and one of my reports writes to me and says, “Joe wants to resign.” That immediately becomes my top priority for the day.

Across all the functions I lead, the people who directly report to me get a lot of priority on my agenda. I’m supporting them and helping them solve their problems, and also helping the people in their organizations who might be anxious about someone resigning. That’s the easiest decision.

Another thing I focus on is managing proactively instead of reacting to incoming work like emails or chat messages. I try to have a very clear idea of what I want to get done each day and each week. For example, this week I have a very important presentation with the entire development organization about our product strategy for the year. I pre-book time on my calendar to make sure those things get done, whether that’s meetings where I need to collaborate with people or focused time for my own work.

There are competing priorities everywhere — both across functions and also within the same function. Even within product management, we run an organization with around 30 teams, so there are multiple product managers working in parallel.

For me, it’s about identifying where my attention is most important to give, pre-allocating time, and then reacting with whatever time I have left — answering emails, responding to chats, and dealing with everything else that comes in during the day.

When it comes to integrating AI into workflows, how are you deciding what should stay human-centric versus where AI actually improves outcomes?

In the product organization specifically, AI is greatly improving outcomes in research, especially when it comes to speed, quality, and breadth of output. I am mind-blown about how quickly and accurately we can move forward with research about new product lines using real-world examples. Even if it’s not 100 percent accurate, it gives us so much data to work with.

Product marketing used to do that research for us, and it would take a lot of time. It’d go through a queue of people, and it was an excruciatingly long process. Now, I can just use AI and say, “Give me an example of a data model for an employee in HR Core, and just give me all the data points that you think it should have.” Suddenly, I can have a detailed list with 200 fields.

AI as an accelerant for learning

Have you seen an overreliance on AI or instances of it getting in the way of people learning or building expertise?

Actually, I don’t. I think you can leverage AI for learning quite nicely, and it can sometimes be better than traditional learning tools. Think about how people traditionally learn something like research skills. Often, that comes from one-on-one coaching or mentoring, because corporate research is complex. You rely a lot on creativity and personal guidance.

Now you can replace part of that mentoring with an agent that coaches you through how to think about researching a topic. At the same time, that same system can help execute the research. In our organization, we’ve created learning agents inside our enterprise-approved tools. People have access to coaches, content curators, and other learning agents that help them develop skills and have strategic conversations about how to approach different problems.

So the learning experience is actually an area where AI can be very powerful. It can solve problems for you, but it can also teach you how to solve them — or how not to — if you ask the right questions.

You often launch many initiatives at the same time. How do you maintain an aggressive release schedule while still giving your team the space to learn from their experiences between launches?

Sometimes the speed affects me more than it affects the individual teams. Many of the people working on those projects are assigned only to that specific initiative. For them, the speed and the learning process are balanced differently.

We allocate time specifically for feedback and standardization after each product launch. The product manager will spend time after the release interviewing customers and closing the learning loop. For larger products, we often run early release or beta programs before a general release. That allows us to gather feedback and refine things before the product reaches a broader audience.

For leaders like me and a few others in the organization, things can get very busy — especially for product marketing and the go-to-market teams. But we operate at a level where we expect that kind of close follow-up, so we plan for it.

An untraditional path into product leadership

Your path into product was rather unconventional. Now that you’ve worked in many different parts of the organization, how do you feel that diverse experience shapes how you lead product teams?

My career started when I joined a software company working on customer project implementations. Later, I moved into recruiting, and we happened to sell recruiting software. Because of that, I already understood the technology from an implementation perspective. But when I actually became a recruiter myself, I finally understood the job that our customers were doing every day.

That experience turned out to be incredibly valuable when I moved into product and started defining product strategy. I had been in the users’ shoes. I knew what their day-to-day looked like and what they were trying to accomplish.

It helps in conversations with product managers because I can say, “Imagine you’re doing this job. Your day looks like this. You’re distracted by these things and still trying to achieve this outcome.” That perspective helps explain why a certain solution might not work or why the experience needs to be better.

But there was another influence on my career as well. When I was younger, I was very interested in entrepreneurship and startups. I remember going through the Y Combinator startup course and thinking about the skills you need to build a company. One of the things that really stood out to me was hiring. If you hire the wrong person in a startup with three people, there’s a good chance the company won’t survive. That made me realize how critical it is to learn how to identify the right people.

I also became obsessed with execution and efficiency, so I naturally spent a lot of time developing those skills. Overall, though, one of the biggest impacts in my leadership career is knowing how to hire, how to identify the right talent, how to structure the departments, and how to create career paths. Every single one of those elements is talent-related, and you need to have those skills as a leader.

How did that help you transition into product leadership?

I knew nothing about being a product manager when I joined as a product director, but I knew a lot about having the right people next to me. I knew the value in creating a good structure for hiring and promoting talent, and that’s what helped me through the first years — especially while simultaneously dealing with imposter syndrome and learning on the job. I was doing the right thing and building the right team, and now, we have an incredibly powerful team to show for it. I’m really proud of them all.

With my consulting experience, I learned a lot about how to communicate with the customer. Once you become an executive, you’re going to face those touch points where situations escalate, and you’re going to have to maintain your composure. That’s what I value the most about my early days.

Applying root-cause thinking and leadership at scale

Many people start in product and then learn the business side as part of their leader development. You had to learn the product side of things later on in your journey — what was that process like for you?

One skill I developed over time is learning how to dig beneath the symptoms people describe. Whether you’re talking to employees, friends, or customers, they’re people — and people talk about their symptoms and what they see. They talk about how they think they can solve a problem. A lot of the time, my job is to break through those symptoms and identify the underlying cause of the problem.

That’s one of the most important skills for a leader — understanding what’s really happening behind what people are saying. Another important skill is fighting assumptions. People make assumptions all the time without realizing it. They assume something is true and build decisions on top of that assumption. Eventually, they hit a wall. The same thing happens with symptoms. You assume what someone told you represents the full problem, and then you try to solve it.

The real challenge is learning to ask the questions that uncover the underlying issue. Sometimes you can’t get all the answers directly from customers, so you have to ask those questions internally and develop hypotheses with your team.

That sounds simple — people often just ask “why” five times — but in practice it’s very difficult. You’re most likely not even going to realize that what you’re dealing with isn’t the full picture. This is actually how my training in mathematics had a big influence on how I think about problems.

In mathematics, you can only use what has already been defined or proven. You have to work strictly with the statements that exist on the page. That mindset teaches you to separate facts from assumptions. If something hasn’t been defined or proven, you can’t treat it as true. I try to apply that approach to product work. I ask myself: Is this a confirmed fact, or is it an assumption? Is this a symptom, or do we understand the underlying cause?

Of course, business decisions are never as precise as mathematical proofs. At some point, you still have to take risks and move forward. But it helps to be explicit about what you know and what you’re assuming. You might say, “We believe this is correct with about 80 percent confidence, so we’re going to move forward.”

You’ve been at your company as it’s grown from roughly 60 people to 1,700 now. What has been the biggest transformation in that time?

I’ll actually start with what hasn’t changed, which is our culture as an organization. Our founders did a great job of crafting the company’s culture from the beginning. They wanted it to be well-defined and had a clear idea of the values they wanted to promote.

For example, we value positive people and try to avoid hiring people who complain about everything. We want people who help move projects and the company forward.

That cultural foundation makes it easier to navigate everything else as the company grows. As for what changed, the obvious things are structure and processes. When we were small, many things simply didn’t exist — career frameworks, salary structures, and other formal processes.

Over time, we added those structures. But because it happened gradually over about 15 years, it didn’t feel like a dramatic transformation. It was more of a steady evolution. We’re always reviewing how we work and asking whether decisions from the past still make sense or whether they need to change. That constant reflection prevents you from reaching a point where something suddenly feels completely broken.

What has been most important for sustaining your leadership through that growth?

Earlier in my career, there were periods where responsibilities and workload piled up. During those seasons, I would get extremely stressed, and that sometimes turned into physical symptoms. Eventually, I found tools that helped me manage that stress better. Now I’m much better at separating mentally from work when I need to.

Some of the things that helped are simple practices like breathing exercises or even ice baths. They might sound trendy, but learning how to stay calm in stressful situations made a real difference for me. There’s definitely a before and after in my career. Now I can look at a difficult day and think, “We’ll work through this.” That’s made a huge change in my professional life.

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, Alicia talks about building trust through user-generated content, including how reviews, ratings, and other forms of social proof help shoppers make confident purchasing decisions. She discusses her approach to creating and measuring successful UGC programs, as well as the evolving role of authenticity in ecommerce.

Designing UGC for trust and decision-making

You have deep experience in user-generated content, which can be very useful for enhancing trust or building engagement, but at scale it could overwhelm users. How do you decide what content to share, when to share it, with whom, and how does that improve decision-making?

Determining what UGC to show depends on where the consumer is in the purchasing cycle. On a search results screen, people want to know the item’s star rating and how many reviews it has. Something with five reviews is going to be viewed differently than something with 5,000 reviews. Showing that information up front can help drive someone to click to the next step.

If they’re on the cart page, for example, they’ve already made a decision. They don’t need to read reviews. The place where you show the most detail is on the product details page, where you would display the actual content of the reviews. You would have what we call pills, where you’ve sifted through the reviews and surfaced highlighted comments that come up over and over again. You’d probably want an AI summary of what people most often say, and you’d want to show both positive and negative sentiment. That’s also where you want photos.

How do you think about UGC as a dynamic product surface that actively shapes the customer journey?

User-generated content is based on social proof. Consumers are not looking at the retailer to give them a signal — they’re looking at peers and other shoppers. They want to know what others thought and what their experiences were.

It’s important to make sure there’s transparency and that shoppers believe that the reviews are from real people who actually purchased the product. You can’t have too many incentivized reviews, where someone was paid or given free product in exchange for a review. Anytime you use those carrots to draw people in, it can erode trust. It’s important to make sure there’s enough social proof and enough cues so that shoppers feel they can trust the people leaving reviews.

When someone has an average experience, they’re often not going to leave a review. The person who’s going to leave one is somebody who says, “These knives don’t cut anything,” or, “These are the best knives I’ve ever had.” You end up with either really high or really low ratings. The people who had an average experience are the customers you have to pull in and ask to post content.

If one person has a negative experience, it’s more likely that multiple people had negative experiences. If you have 100 negative reviews and three great ones, people aren’t going to believe the positive reviews. What you’re looking for is something closer to a normal curve.

Prompting for reviews at the right time

What about metrics — how do you measure whether UGC is truly transforming the user experience rather than just increasing engagement?

When I was driving UGC, the main thing I looked at was building not just a collection of reviews but what I would call a content loop. You can offer a prompt to ask for reviews, collect reviews, submit reviews, and then engage with those reviews. Then it goes back to asking for reviews again. The goal is to create a virtuous cycle.

You need to measure two sides: submission rates and engagement metrics. You also need to understand how many reviews shoppers need to read in order to make a good decision. That becomes your benchmark for the minimum number of reviews you need per item. Then, you have to know what a good submission rate looks like relative to your conversion rates. Once you’ve established that benchmark, you can measure whether reviews are helping lift conversions, increase add-to-cart rates, or reduce returns.

These are hard things to measure. You have to instrument from the beginning and find ways to isolate reviews from other parts of the shopping journey. Did the consumer look at price, shipping time, or reviews? Having a way to test and determine which component is actually driving change is difficult.

When you create that flywheel to convert passive consumers into active contributors, what are the things you try to watch for — things that might break it or cause it to slow down?

If you don’t solicit reviews at the right time, it changes the responses you get. We found it was optimal to ask for a review seven days after a product was received because that’s when most people have actually used it. But a TV might require three to six months before the purchaser can give an objective review, while a T-shirt can usually be reviewed after one wear.

We also experimented with different solicitation methods. 10 years ago, people mostly sent emails. So, we started using push notifications, advertising banners, and reminders in purchase history pages. Asking for a review while someone is already taking another action, like making another purchase or browsing the site, can be very effective. They’re more likely to give a quick thought.

Another important factor is making reviews easier to submit. Reviews used to be a large empty text box. We started offering things like star ratings and selectable keywords. We can generate a draft review, and the user can click a button that says, “I agree with this.” That way, they don’t have the mental load of seeing an empty text box and thinking, “I don’t want to fill this out.”

How does UGC come into play differently for higher and lower-consideration purchases?

Back to the knives example, say you’re buying some, and you’re not a serious home cook. You might see a four-star rating at the right price and buy immediately. But if you’re taking cooking classes and trying to become a chef, you’re going to read the reviews. You’ll want details about sharpness, food preparation, maintenance, and long-term use. When it’s a higher-risk, higher-consideration purchase, you’re more likely to lean on reviews.

The delicate balance of incentivized reviews

How do you solve the cold start problem for new product categories where the user-generated content doesn’t yet exist and you’re starting from scratch?

It’s a really delicate balance with incentivized reviews. More often than not, you’re going to have to give the product away and ask for an honest review. You have to be very precise with your language to make it clear that you’re asking for an objective review, not a positive one. The FTC watches this closely because if you’re soliciting only positive reviews, you’re influencing the outcome. You want enough reviews to provide trust signals, but not so many incentivized reviews that shoppers stop believing them.

You might launch with 25 incentivized reviews, but immediately start soliciting more reviews from regular purchasers. You can also encourage participation through recognition rather than incentives. Maybe you notify people when their review helps another shopper. Maybe you award badges when contributors reach milestones. People like to feel they’re making a difference and working toward something.

Leveraging incentivized reviews and providing trust signals to the consumer is a delicate balance. If you have two five-star reviews, no one’s going to trust that. At the same time, if you have a large number of incentivized reviews but no regular, non-incentivized reviews, shoppers won’t trust that either.

How does personalization play into UGC? Do you find that too much personalization can start to feel opaque or reduce trust?

I don’t know that personalization reduces trust. I think it’s more that a reduction in authenticity can reduce trust in things like AI. There are concerns about bot attacks and AI-generated reviews. After a while, they all start sounding the same. We had situations where reviews were submitted as slight variations of one another, and it was obvious they weren’t authentic. We had to build controls to determine where reviews came from, when they were written, and whether patterns suggested fraud. For example, one change we made was requiring users to be logged in to an account before they could submit reviews.

What creative or unique ways have you found to build a contributor community and accelerate your flywheel?

We gave top contributor badges to people who read or wrote the most reviews. But we also introduced category expertise badges, such as electronics expert or cooking expert. If someone is a cooking expert, you may place more weight on their cooking-related reviews than their apparel reviews. These designations helped contributors feel recognized and encouraged them to continue participating. We vetted them on both purchase history and review activity.

Influencers and the role of consumer confidence

What do you see for the future of user-generated content? Where is it going, in your opinion?

UGC is definitely moving away from written content on retailer websites. Social commerce, social content, and social media are becoming increasingly important. Retailers are partnering with social platforms and influencers because content is moving to TikTok, Instagram, and other channels. Retailers want to bring shoppers from that content directly into purchasing experiences.

The question becomes: who are the influencers that can provide objective commentary while also attracting an audience? And a lot of times, brands end up having some type of compensation for those influencers because of what their public reviews are worth.

When you think about ‘transformative customer experiences,’ what actually changes for the user when UGC is done well?

The biggest thing is confidence. UGC helps customers feel they’re purchasing the right thing. It can reduce return rates because consumers have more information before they buy. Beyond reviews, things like virtual fit tools and photos from real users help shoppers understand what a product will actually look like and feel like. The goal is to make customers feel closer to the experience they’d have in a physical store. UGC helps people become more comfortable making purchases they have to trust before they can actually see or touch the product.

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, Ken shares lessons from leading product organizations and coaching emerging leaders. He discusses the shift from individual contributor to manager, how product leaders can develop meaningful influence, and why delight still matters in product design. Ken also reflects on the growing role of AI in product development and how teams can embrace new technology without losing the human perspective that makes products truly valuable.

From individual contributor to leader

What’s the most underestimated part of transitioning from an individual contributor to a manager?

As individual contributors, we tend to see things only through the lens of our world. A lot of times we’re just trying to get our work done as efficiently as possible. As leaders, you’re often in charge of multiple individual contributors and collaborating more cross-functionally, so you start to see how each person plays an important part in a larger whole.

When you’re an individual contributor, there’s so much work to do that it’s hard to get out of the weeds and see the bigger picture. Good leaders help people see that and ask the right questions to help them consider those things. Some individual contributors do this really well, and when I see someone doing their part but also seeing how it fits into the bigger picture, that’s when I start to recognize they’re a great candidate to step into a leadership role.

What people often underestimate is just how much everyone needs to work together to make something truly magical happen. Sometimes people also underestimate their own ability to influence and guide a project. I’ve had people come to me and ask me to solve a problem for them, and I’ve tried to get better at telling them they can have that conversation with the other person and solve the problem themselves.

Encouraging people to take a stab at it and use their influence and critical thinking helps things run smoother and helps them become more of a leader themselves.

How do you handle conversations with strong individual contributors who want to become managers?

I’ve had these conversations a lot, and I usually start by asking people why they want to be a manager. Sometimes it’s because managers get more recognition, people think they’re really smart, or they get paid more money. But they may not actually have a skill set suited for management or even enjoy that kind of work.

Being a manager is not always fun. You’re dealing with administrative tasks, and a lot of problems flow to you. Sometimes people get into those roles and realize they miss the days when they could just put their head down and do the work.

That’s why it’s important for companies to create incentive structures where great individual contributors can earn good money too. That way people who are strong ICs don’t feel like they have to move into management to accomplish their career goals.

When I talk with people about it, I ask questions like: Do you like leading people? Do you have a vision you’re trying to accomplish? Do you enjoy coaching and mentoring people? If the answer is yes to those things, management can be a good path. If the answer is more like, “I just like doing my work and being done when I’m finished,” then I usually steer them away from going down that route.

Learning to influence effectively

How do you help people develop meaningful influence without doing it just for optics?

When people try to insert themselves into situations just to appear influential, it’s usually pretty transparent. Everyone feels annoyed when that happens because it slows things down and often has the opposite effect, where people start to cut that person out of conversations.

If you really want to be influential, you have to be self-aware and know whether it’s a situation you should be involved in. If you’re passionate about the topic or you have unique insight or skills for it, that’s a good time to influence.

Storytelling and data are also important. If you can tell a clear story and use data or specific examples, people tend to be persuaded much more effectively than if you simply say you want something or think something should happen.

At the end of the day, most people just want to do a good job and ship good work. If you can explain why what you’re proposing will help accomplish that goal, people are much more likely to get on board.

Using AI without losing product judgment

How are you integrating AI into your workflows while acknowledging its limitations?

AI is awesome, and it’s also super new. At this stage, what I’m encouraging my team to do is experiment with it so we become more familiar with its capabilities. But you can’t rely on it completely without using your own judgment.

If you take whatever AI gives you and submit it as your work without editing or validating it, you can get yourself into trouble pretty quickly. Humans are still needed for that judgment.

AI can be a great partner for generating ideas, and it can also be a really good editor if you ask it to critique something. But if you’re just asking it to do the work and turning it in without reviewing it, it’s not quite there yet.

I encourage my team to use it as much as possible and share what’s working well and what isn’t. That helps everyone learn how to apply it more effectively. I also remind myself that this is the worst AI will ever be, and it’s only going to get better, so we can’t ignore it.

How do you treat AI as another stakeholder in the product process?

The job of a product manager is to define the outcome you’re trying to achieve and create a path to get there. You’re defining what success looks like and how you’re going to deliver something to customers.

AI is essentially another stakeholder in that process. If you give AI a bad prompt, you get bad output. Just like working with engineers or designers, you have to clearly explain what you’re trying to accomplish — what success looks like and what outcome you’re trying to create for the customer.

The better you articulate that, the better results you’ll get. If you can tell that story clearly to AI, it can be a really great partner.

Human-centered product experiences

What happens when AI-driven features don’t actually improve the customer experience?

Because we’re human, we still understand what resonates with people. I’m an endurance athlete and spend a lot of time on Strava, which is one of my favorite products. Recently they added an AI feature that analyzes workouts and gives feedback.

When I tried it, it basically repeated what I had already written. If I titled my workout “long run” and wrote that it felt hard but I got through it, the AI would say something like, “Good job on your long run. That was hard, but you got through it.” It didn’t add any value.

I remember thinking, what product manager let this get into the product? It’s cool to experiment with AI, but you still have to ask whether it improves the customer experience. If it just repeats what the user already said, it’s not helpful.

Why is delight still important in product design?

Sometimes my sense of humor can be childish or adolescent, but I think it’s important for products to have fun moments. Especially in B2B or enterprise software, products can feel really stale. Consumer products tend to feel more alive.

Even small things can make a difference. It might be a celebration animation, something surprising in the interface, or just a design that makes people smile. Those moments interrupt people’s thinking in a good way.

A good example is the dinosaur game in Google Chrome when the internet disconnects. Another example is the old version of Solitaire where the cards bounced across the screen when you won. They could have just shown a message that said “You won,” but instead they created something memorable.

Those small moments give products life.

Is it difficult to convince leadership teams to prioritize those moments?

It can be difficult. I’ve worked with leaders who were very buttoned-up and didn’t want anything that felt playful because they thought it wasn’t on brand. Those conversations often come down to trade-offs.

Personally, I enjoy working on products that have life in them. I like companies where leadership can laugh at itself a little.

If leadership is hesitant, one approach is to test the experience with customers. If the version with something fun performs better, the conversation becomes easier. You can present the data and ask whether you should choose the version customers liked less simply because it’s more serious.

Adapting to an AI-driven future

How do you stay optimistic about the future of product roles as AI evolves?

This is something I struggle with sometimes. I’m naturally optimistic, but I haven’t seen another technology in my career that creates this level of uncertainty. AI could potentially automate a lot of what product managers do.

The way I stay optimistic is reminding myself that I’m smart, capable, and adaptable. If I’m willing to keep learning and trying new things, I trust that I’ll find my place in whatever the new reality becomes.

The people who may struggle are the ones who cling to the past and assume the technology won’t affect them. If you’re willing to learn and figure out new ways to add value, I think people will adapt.

I also think there will be a growing premium on human experiences. The more technology automates, the more people will crave human connection and human perspective.

You can often tell when something online was written entirely by AI. It’s getting better, but there’s still something that doesn’t quite feel human, and people recognize that difference.

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, Vibhu breaks down how he thinks about each surface in the ecommerce discovery journey and why getting them right requires treating autocomplete, progressive disclosure, and product presentation as distinct problems with distinct jobs to be done. He discusses the tension between helping customers express their intent and steering demand, the structural reasons why search results can explode rather than narrow as queries get more specific, and how Walmart overhauled its matching and ranking technology to fix it. He also shares a candid take on why the best monetization strategies follow great experience, not the other way around.

What autocomplete is actually for

How do you think about providing helpful guidance in autocomplete without overconstraining people’s ability to explore?

Autocomplete’s primary reason for existence is to help the user express their intent. That’s the primary goal.

We also have measurement in place and track metrics for this. One is coverage — do we offer autocomplete for a large set of keywords? The second, which is super crucial, is adoption: when we show the suggestions, do people actually like them and click on them? And the third is what we call MRR — it’s just a fancy way of saying the ranking of those suggestions. When we’re showing the suggestions, are people liking the top suggestions, or do they have to work really hard and find their way through suggestion four, five, six, seven? Having a system of evaluation and observation is very helpful.

Having said that, the nature of AI and machine learning systems has definitely evolved to an extent where secondary objectives can also be facilitated. Conversion or refinement are two examples of secondary objectives that could be layered on top of intent expression.

The objective can also change based on the moment in the journey. It’s a well-known industry fact that for the very first queries of a session — say someone wakes up, pulls out their phone, and it’s the very first query — previous session context is very helpful. As you go further in the session, what matters more and more is the activity you have performed within the session.

You could change the objective to be more focused on showing more diverse suggestions specifically when the intent is not very clear — let’s say someone has just started typing and has only typed one or two characters. In this scenario, it’s very fair game to show suggestions across different categories, different verticals, to maximize exploration. But as they start typing and the intent gets more solidified, the objective probably needs to adapt — moving more toward what people are trying to express, because the intent is now firming up.

Is there an example of an instance when an autocomplete suggestion shortened a journey prematurely?

Let’s say someone is searching for cucumbers. Should autocomplete’s role be to help them express this as quickly as possible and get out of the way? Or should it also shape the demand — “Hey, what about pickled cucumbers? What about cucumber spreads?” Different surfaces have different jobs to be done, and autocomplete is a surface where the primary job is to help people express what they want and get out of the way.

Once you take people to a listing page, it’s safer — for lack of a better word — to show more exploration. We can show different zones on the page related to directly matching intent, or alternate intent like pickled cucumbers or cucumber spreads. We try to index on letting people express what they want. The exploration piece we try to push down the journey a little bit, so that people can have an easy and quick takeoff with as little friction as possible.

Handling fuzzy and mission-based intent

How do you handle “fuzzy intent” categories — where the user isn’t searching for a product but for an outcome?

The example we love to use is drumsticks. Drumsticks is obviously the musical instrument. Drumsticks is also a green vegetable. There is also chicken and turkey drumstick. And Drumsticks is also a top-selling ice cream treat. Every person searching drumsticks has a different interpretation. It becomes challenging to put forward an experience when something vague like that comes in.

The game is, how much confidence do we have? In this scenario, it’s going to be very hard to have a high degree of confidence to lead with one of these categories. The way we handle this right now is to provide optionality at the moment. But it’s not an ideal experience. Ideally it should be a balance of optionality versus: do we have some data about the user? Can we look at some personalized signals and infer that person A is more about the chicken drumsticks, and person B is more about the ice cream Drumsticks, and then flip the optionality to a more guided experience that dynamically leads with a different ranking or ordering for person A versus something different for person B?

Back when LLMs were first introduced, we began thinking about how we could leverage this powerful technology and build meaningful experiences around it. One of the problems we always had was how to solve for customer missions versus sporadic purchases. The example here is, let’s say you’re throwing a birthday party for your kids — that’s the trigger for the shopping mission. People don’t usually go and search, “Hey, I’m throwing a birthday party with a Spider-Man theme, help me plan it.” People don’t usually search like that on shopping platforms.

We actually challenged that and said, “What if people could just enter their mission — how can I plan a Spider-Man theme party?” We built an experience around that where, just by inputting your mission, we’re able to deconstruct it and offer a solution so that you can solve for the entire mission: paper plates, balloons, T-shirts, party favors — all in one seamless interface. It’s not an ideal experience, but it’s an interesting take on how to handle some of these fuzzy intent scenarios.

Progressive disclosure and the too-many-results problem

As consumers narrow and refine, sometimes the problem isn’t a lack of options — it’s having too many. How do you think about progressive disclosure: what to show early versus later in the journey?

This is the crux of the search engine problem. The problem is not that there’s less data — the problem is there’s too much data. And the reasons are twofold, both systemic.

Compared to 20 years ago when assortment was very limited — maybe a few hundred thousand SKUs — for most retailers the assortment has now exploded. There are marketplace programs that have grown a lot, and by the nature of marketplace programs, they tend to bring a lot of tail assortment. We’re talking billions of items available in the catalog.

The secondary reason is more technical: the nature of a primitive search engine is that the more keywords you stuff into the query, the more results get generated — and that’s so counterintuitive. In an ideal world, the more specificity you add, the data should get more and more restricted. However, primitive search engines work on the concept of matching keywords in a relaxed way — either/or, if word A is matching or word B is matching or word C is matching. Because of the OR condition, the more keywords you add, the dataset keeps increasing.

To address the second problem, a couple of years ago we went on a journey we called “exact matches” — fixing the problem of specific queries. We up-leveled and completely overhauled our matching and ranking technology to adopt Google’s BERT algorithm, which is a state-of-the-art neural algorithm. We put this in our reranker — the second stage of sorting and ranking items — and it completely changed the game for us. We had massive, massive relevance gains unlike anything we’d seen for the longest time. This was a game changer.

Progressive disclosure — we also call it contextual refinement or contextual nudges — means providing a more guided and assistive experience that stays in context to where the customer is in the journey. We are investing very heavily in this space, using a lot of LLMs and query graph data to create these nudges, moving toward more progressive data sources compared to the primitive data sources we had in the past.

Do you find that users lose some control with these new progressive methods?

Yes. There is a trade-off. The more guided and assistive experiences we build, by definition, the user will lose some control. The thing is to do it tastefully and with intention.

It’s well known in the industry that most general merchandise traffic starts with a broad intent. Complex purchases especially — a coffee maker, air fryer, vacuum cleaner, bunk beds — for most people, it’s very hard to start anywhere more refined than that level of intent. It becomes very important to help someone navigate and refine because it’s going to be very hard to make a decision if they can’t think beyond “coffee maker.”

We would not want to disrupt the flow or provide a lot of navigational guidance when the user is already very specific in the journey. It needs to be contextual — showing up at the right moment, at the right point in the journey.

What you show on the product page

How do you think about highlighting product features without overloading people with too much information?

This is fundamentally rooted in the same root cause: too much data, too much to consume. Cognitive overload is a huge opportunity and problem, and endless scroll is not helping either — it’s a double-edged sword, because the list of items is just endless.

There’s no textbook answer to what the right balance is, and every retailer probably needs to run a continuous program of testing and learning. We continuously run a series of tests to keep finding the balance.

The layout you show information in — single column versus double column — can have profound implications in terms of people being able to focus versus being able to scan quickly. One of my favorite examples: a lot of the industry was following a pricing format that put the dollar price and the cent price at the same font size. But really, people are looking at the dollar amount. We built a hypothesis: if that’s how people are actually thinking, why don’t we present information in the same format — enlarge the dollar amount, reduce the cent amount? This is a standard practice in offline physical retail as well. And it did test positive.

Images are very, very crucial. Another powerful concept is badges — bestseller, or trust signals. Trust comes from social proof: if more people are doing this, then surely they must be right, and I can rely on the judgment of the crowd.

But even showing badges, it’s very easy to overdo and over-optimize to the point that it becomes detrimental. Imagine a page where every item has a badge — anything can be overdone and over-optimized, and then it stops being helpful.

Monetization and the experience cycle

Across the full discovery journey, where do you see the biggest tension between maximizing monetization and minimizing user effort?

From a customer perspective, they will probably be fine not seeing any ads. But if you’re running a business, your incentive is toward monetization, and one of the forms is advertisement.

There will be a tension between ad revenue and commerce revenue — what is known as GMV. However, there’s also going to be a right balance — a point where you can maximize both. If both ad revenue and e-commerce revenue can be maximized, that’s our ideal state. Everybody wins, the customer wins and the business wins.

Monetization and ads in themselves are not inherently bad. They actually help a lot in discovery, in providing diversity, and in keeping the ecosystem healthy. As more products and sellers onboard into the system — there are millions of items for any given intent — monetization tools like ads give an opportunity to brands that are onboarding to surface a genuinely amazing product to the customer who has a relevant intent.

One of the ways to control for this is to view the surface from the customer lens in totality. The whole page is composed of monetized capabilities and organic capabilities, and even if different teams have their own independent metrics, what can help is to think of something like whole page relevance. Is the page in totality still relevant? Yes, we’re showing ads at the top, in the middle, in the bottom — but together with the organic, can we measure that whole page relevance and trend it over time?

Is there a broader principle you hold onto when navigating that tension?

What really happens is that experience paradigm shifts occur. A new experience paradigm is created — think of the feed, or endless scroll, or the video module. The experience paradigm changes, and then monetization engines start over-optimizing it to the point that it gets over-leveraged. A few years later, the experience paradigm changes again — and it’s a never-ending cycle.

Take Google AI Mode as an example. Google for the longest time was built on its search results listing, but recently it moved fast and overhauled its entire experience toward AI mode and conversation. Now the monetization is following the ideal experience they think is the future. Similarly, Meta stories — the experience was evolved first, the question was asked: “What is the best experience for the customer?” The answer was, “Let’s try stories.” Once the experience started resonating, monetization followed, and it became one of the most successful monetized products in history.

The principle to keep in mind is to always focus on what is the best customer experience and keep evolving that — keep pushing the boundaries, thinking big, thinking bold. As it keeps evolving, the monetization will continuously keep following it. That’s how you keep a sustained winning program: you’re not getting old, you’re not getting stale, you are continuously innovating and then monetizing it as well.

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, Chanel talks about how starting on the customer side — before any formal design training — shaped both her approach to UX and her cross-functional leadership style. She discusses the difference between what customers say and what they actually do, how she brought a startup mindset into the organizational complexity of Dow Jones, and why she designs for architecture before aesthetics. She also reflects on the research practice she’s building at Apartment Therapy Media, and why she believes anyone at a company should be able to talk to users.

From customer support to product design

You began your career on the customer support side before moving into product design. What went into that decision, and what was the experience like?

With my first job being in customer service in tech at a startup, I was able to understand a lot of roles of the business, and I started to get curious about the design side and the UX side — but I didn’t have any formal training. So I decided to go back to school and go to New York and get my Master’s in Communication Design. It was a very research-based program, very exploratory, no design focus in particular.

It was actually challenging to get back into the digital design world. The field had changed even in a matter of two years — titles were called different things, the tooling was different. I really had to rebuild a lot of skills, and I did that through a lot of freelance projects for nonprofits. In that process, I was really able to see this trifecta of my experience: customer service is the research side and the user voice side; I still have that design part of my background of understanding aesthetics and brand guidelines; and my schooling — both undergrad and graduate — is the strategy side. It was seeing how my untraditional background could really lead to this, what product design is becoming.

A lot of people who come into product through another avenue talk about having the hard skills first and then having to learn the human side. Do you feel like your experience was the inverse — and has that been an advantage?

I think now I understand the benefit and I’m glad I’ve gone this direction. When you are on the customer side, you need to learn all sides of the business — you have to know the tech, why it works a certain way, the pricing, why are we positioning ourselves this way? It helped me understand partnerships, and less about the silos of “this is my expertise.”

And I think that’s what’s led me into my leadership style as well — a customer doesn’t see all the different departments, they see you as one company. So that’s how I like to lead cross-functionally: if a customer comes to you with a problem, it’s not a specific team’s problem, it’s cross-functional. As a leader who took a nontraditional path, I always encourage other leaders to take a chance on someone who also doesn’t have such a direct trajectory into the industry.

Thinking holistically: Startups and enterprises

You’ve worked at both startups and larger, established companies. Was the product design process similar across those environments — and did the startup experience shape how you work now?

It really does. The startup had me think of things holistically. At Eventbrite, I could talk to the engineer who built the feature, see the whole picture — you move really fast, it was easy to just go over the fence and talk to them.

But then when I went to larger organizations like Dow Jones and the Wall Street Journal, it got harder. I was there during the pandemic working on a project about shifting our print process and how our customers got their newspaper, because a lot of things were changing. In this project, there were 10 stakeholder departments — it was just so much bigger. I couldn’t have as much visibility. But my startup mindset still worked there: little by little, going to someone in each of those 10 departments, mapping out the entire customer journey, and bringing everybody together. I also went to the customer service team and got call recordings of people calling in like, “Where’s my newspaper?” — and I played those short clips for everybody in the room.

The startup mindset doesn’t go away. It’s definitely a challenge of how you build that connective tissue — it’s a little bit harder. But you can still find a way to bring a startup edge, even at a place like Dow Jones or the Wall Street Journal where people have been there a long time.

What good UX actually means

You had a very direct view into user experience because you were talking to people experiencing issues all the time. Did your definition of good UX change as your career developed?

It did. With customer service, you’re not going to hear a lot of praise — people call to complain. What that taught me is that people want to be heard. If you’re doing something good, it’s very rare that someone’s going to call and say, “Hey, I love this new feature so much. Okay, bye.” They’re not going to wait on hold to give a compliment.

Good UX isn’t about what users say — it’s what they do. They have ideas, they think they know what’s going to improve whatever issue they’re having. But good UX has taught me to also look at the numbers and get more into the data of behavior patterns, watching screens without being in the room with people, and thinking you have to read between the lines — not just the explicit feedback. You have to remove a little bit of that subjective voice, but still give people a place to be heard.

Do you think product and design teams can better leverage the insights that customer-facing teams already have?

I always say it’s the qualitative and quantitative — you really have to sink your teeth into both sides. You can look at the data to see why a feature isn’t performing, and you can go into the customer service logs and see if you’re getting calls about that certain thing, listen to some of it, do session recordings, look at clicks unmoderated and moderated. It has to be both of those working together.

How do you decide whether something is a design issue in the product versus a customer behavior issue where users need to be pushed into learning how to use the product correctly?

I really learned this when I was at the Wall Street Journal as a UX architect. You start to look at foundation and then layer in design system and aesthetic and brand voice. We were having a newsletter signup issue on the website — at first glance, people thought it was a UI problem: they’re not completing the signup, they’re not clicking the right button. But stepping away from that and mapping out the entire user flow, it was architectural: we missed a step in the process where they were registering and making an account.

By having this blueprint, by looking at the architecture, I could go to the engineers, run this by them, and they could see the layer of technicality — we weren’t even validating them. You could have a crack in your floor and put a rug over it, but that crack, you’re going to keep stepping on it. It might look nice because it’s covered up by a nice rug, but you have to take that rug up and see what the foundation is.

When design shapes strategy

Do you see scenarios where design insights actually alter the strategic direction of the product?

At my current job, one of our brands, The Kitchn, we launched a membership initiative to get more people to create an account and sign up. We needed a signup page — we looked at competitor sites, direct and indirect, and our own design aesthetic. There was a lot of variation and debate, and I decided: let’s run an unmoderated user test. Let’s get this design in front of people in different variations and just get feedback. It was unanimous: people said, “Make it easy to sign up. That’s what this page is meant to do.”

So we stripped back the fluff and the color. The strategy was to get people to sign up, and in this case, adjusting our design aesthetic helped us get to that strategy. By getting actual user feedback and watching those short videos, we could end the debate about what the page should look like. That page is now getting 50% conversion — a little bit of qualitative data there to help reinforce the strategy.

Do you encounter situations where people outside design are more focused on aesthetics, and you have to push to keep functionality at the top of the conversation?

Yes, but I feel like lately I’ve seen a shift — maybe in the industry as a whole, but also in my company. Things are going simplified. People want it to look like Apple, they want “the Netflix of media, the Uber of ...” — familiar patterns. I heard this quote in undergrad from Jim Jarmusch: “Nothing is original.” And I think my challenge now is remixing things.

We’re moving toward an industry where maybe aesthetics are feeling a little less important — a lot of things are looking like other things, especially with AI, and a lot of aesthetic is becoming similar because of that. But I think it’s bringing up a new challenge: how can you delight and surprise through function? Maybe it’s not with design, but it is with function.

Building a research culture

What were you seeing at Apartment Therapy Media that made you feel a research initiative was essential — and what was the process of building it and getting support?

When I got to AT Media, the product team was super hungry for it, super curious. There was a lot of openness to understanding it more. They were already doing surveys and using Hotjar for session recordings, but wanted to push further. The gap I noticed was actual user conversations — starting moderated and unmoderated sessions.

In at least the first quarter of starting, I did moderated sessions with users and had the CEO sit in and watch, along with people not even on the product team. It was eye-opening — a lot of the company jumped on board: “Oh yeah, this is really helpful to see.” We’re in the room looking at our website every day, and to zoom out and watch someone who doesn’t know us navigate it — “Oh my gosh, they don’t understand this part, this is confusing” — getting us to talk to people who don’t know us, and people who do know us. There was a lot of excitement, and there still is.

How has it changed the way the team works — the confidence in decision-making, the sense that the product is functioning better?

It cleared up circular conversations that I think were happening — different departments having different opinions — and it kind of ends that circular debate. Now more people across the company are even asking, “Did we do user research on this?”

My approach to research is also to democratize it. I think anybody can and should talk to our users — it doesn’t need to be formal. Recently a PM did an internal user research session watching our editors use our internal publishing tools, and it was super illuminating — the crazy workarounds they’re doing, the processes they’ve just accepted as “yeah, it’s kind of like this.” Having her do that is this customer service focus in action — the editors are like, “I feel seen now.” A lot of times you’re focused outward: “We need to launch all these features.” But we also have internal tools for our team, and it’s exciting to see how research is growing and being used in different ways.

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, Ali talks about what it means to operate in a compressed product lifecycle, where the time between idea and delivery has shrunk dramatically. He shares how AI has removed traditional bottlenecks and fundamentally changed how the traditional product trio works together. Ali also discusses the growing importance of identifying the right problems with product intuition, moving from historically opinion-driven to evidence-driven decisions.

How AI is reshaping the product lifecycle

How would you describe the pace of a product lifecycle today compared to even just a few years ago?

The biggest change with the advent of AI is that it’s collapsed a lot of the steps that would go into a traditional lifecycle — the time it takes to go from an idea to a prototype or customer-facing concept, and then to a product. I can create something viable in a matter of minutes to show a customer. Back in the day, that used to take a long time.

It also used to involve a lot more organizational bureaucracy — securing resources, making a case for what we’re doing, getting the right people aligned. Much of that has fallen away. With this compressed lifecycle, the process isn’t just faster; it has fundamentally changed. Product, design, engineering, and even marketing can now work in parallel instead of waiting on each other. We saw a shift from waterfall to agile, but even agile is starting to feel less central. What matters now are the core principles: taking in feedback, learning quickly, and prioritizing the right problems.

That’s the key — figuring out what the right problems are. Doing everything for everyone doesn’t work. You need a clear point of view on where you can create the most value, while staying flexible enough to evolve as you learn.

You spent over seven years at MySpace during a pivotal era in social media. What did managing a product lifecycle look like back then, and how much of that process was shaped by the sheer time it took to build, ship, and learn?

It was a bit crazy — it felt like three jobs. I often joke that working at MySpace was like college, grad school, and a medical residency for product management.

Back then, the lifecycle had a lot more drag. Even though MySpace still operated with startup energy, we were dealing with multiple management layers and had to sort out resources just to do any meaningful prototyping. After News Corp acquired MySpace, that added even more structure, oversight, and priorities from a public company. Internal politics and bureaucracy created long gaps between idea and implementation. It took time to test something, build it, and get it in front of users. We had great tools, but the organizational side slowed things down.

Even when trying to decentralize decisions, the weight of the organization made it difficult. A lot of the process was shaped by how long it took to navigate that. Today, we can create evidence before committing. We can prototype quickly and validate ideas with customers in days instead of weeks. For example, one of our product leads identified a pain point, created a prototype, and set up a customer conversation within three days. That step alone would have taken weeks before. She didn’t need to secure resources or go through layers of approval — it simply happened, and with very little friction.

When you compress the product lifecycle this dramatically, customers feel it too. What does the faster loop actually deliver for the customer who’s waiting on a solution to a real problem?

One of a business’s greatest advantages is the ability to reduce waste. At Instil specifically, we’re not spending a lot of time, resources, or money going in directions that don’t provide value back to the business. That’s huge.

We can learn faster, build things that provide value quickly, and, as a result, realize that value as a business sooner. This allows us to be more efficient, stay focused, and ultimately grow. We call our customers partners here at Instil, and for them, the key benefit of partnering with us is our responsiveness. For example, the time between our product lead identifying a pain point, talking to customers, and seeing a potential solution can be a matter of days.

From our partners’ perspective, that feels great. They feel that we’re listening, and the distance between experiencing a problem and us shipping an improvement is shrinking.

From opinion-driven to AI-powered product development

At a company like MySpace, how much did product direction depend on leadership having the loudest voice in the room?

In the early days, leadership had a strong influence. Tom Anderson — everyone’s first friend on MySpace — was deeply embedded in the community. He quite literally lived inside the community that he founded and built, and he became the voice of the user, which worked well early on.

But that doesn’t scale, and we learned that over time. In the early days, that can be really powerful, especially for a startup. And it’s not just a MySpace thing; many companies — startups and large organizations alike — are often shaped by loud voices from founders, executives, or board members.

The challenge historically was that pushing back with evidence used to take too long and required too many resources. By the time you gathered enough data, the opportunity was gone. Today, you can create that evidence quickly. If a leader has a direction, you can test alternatives, talk to users, and present a case before decisions are locked in. That creates a more collaborative environment where you’re solving problems together instead of following opinions driven by conviction alone.

At Instil, how is AI changing the way your team moves from identifying a problem to putting something in front of a customer, and what does it demand from them from a skills perspective?

We’re leaning into tools that help us synthesize customer feedback quickly. We can spot patterns faster, explore solution directions more effectively, and get to something tangible much sooner.

In one case, we presented multiple directions to a customer and ultimately ended up choosing a third direction based on feedback. That kind of iteration used to happen much later through A/B testing or feedback channels. Now, we can get there in days without having to build out the full end-to-end product. It’s quite empowering, and it reduces waste in terms of money and effort.

This demands strong product intuition. You have more inputs, more data, and more possibilities than ever. The challenge is identifying the signal in the noise. You need to understand which problems matter and create clarity for the team. Building is easier now. Choosing what to build is harder.

You said that knowing what to build is more important than ever. How do you validate the feedback coming in?

Synthesizing the feedback and identifying the pain points — the signal from the noise — is the most critical part. On our team, we often say we never want to lead the witness when we’re gathering feedback. You have to be somewhat scientific about it — understanding what the analytics and test cases are actually telling you, while staying grounded in customer conversations.

How can you go through this process without injecting your own assumptions? How do you take the data and make informed decisions?

Getting feedback is critical, but it’s even more important to define and identify the signals that are going to help you choose what to build. In the past, you had time to process feedback slowly. Now everything moves faster, so the skill is in interpreting information quickly and using it to drive clarity and guide better decisions.

One advantage for us as a startup is that we’re a lean team. That makes things easier in some ways, because we can adapt faster. This is especially challenging for larger organizations, but it’s also becoming a forcing function — they need to operate more like startups if they want to stay ahead.

When you’re moving fast, how do you make sure that you’re still doing real discovery and building feedback loops into your roadmap?

I define real discovery as information that helps us make decisions and removes uncertainty. It should actually change decisions based on what we’re learning. That still includes conversations with customers, and increasingly through prototypes, analytics, and evaluations. Tools like LogRocket play a big part in that, especially with products like Ask Galileo. The key is to preserve learning as a discipline, and, as things change and improve, take it in, synthesize it, reduce the noise, and identify the signals.

Feedback loops are no longer structured checkpoints. They used to feel more like a segment of the process, whereas now they’re constant. Information is coming in all the time — like a fire hose. The hard part isn’t collecting all that feedback; it’s interpreting it. That has to connect to how we think about process. Even with agile development, the process can’t be as rigid anymore. Planning has to be flexible, and the roadmap, as a living, breathing document, is constantly being shaped by what we’re learning.

This is where the human element really matters — how we juggle all of this, identify the signals, and understand what actually matters for the business. It also means leadership has to be aligned, because the team needs clarity on how to absorb new information and act on it.

Evolving with the PM role

You mentioned strong product intuition. There is real fear in the product community that AI is going to do away with PMs altogether. What does AI still fundamentally not replace in the product process?

Along with product intuition, also judgment. Those are core human components that this role will always need. AI can absolutely accelerate discovery and execution, but it doesn’t decide which problems matter the most, what tradeoffs are worth making, or what kind of experience is worth creating. That still requires human judgment.

AI will take over a lot of the drafting and coordination work — PRDs, documentation, and process tasks. But it doesn’t eliminate the role; it evolves it. I’ve heard Marc Andreessen talk about how the lines between the triumvirate of product development — product, design, and engineering — are going to blur, and that resonates. PMs will do more prototyping. Designers will do more product thinking. Engineers will have even more influence on product direction. You’re still responsible for the outcome, but how you get there changes.

So, for product people, the key is being open to learning and evolving the role. The responsibilities don’t go away — they become more judgment-intensive, more cross-functional, and more outcome-oriented. The role survives, but the bar gets higher.

For PMs who are feeling more anxious than excited about this AI transformation, what’s the mindset shift you would encourage?

I can tie this directly to how I used to think when I started my career. I remember setting goals for myself, and a lot of what I judged and measured myself against was how I got things done — how I worked with different teams, set up processes, presented to different audiences, and even things like writing documents. A lot of that work is going to be absorbed or compressed by AI.

The mindset shift I’d encourage is to focus much more on the quality of your thinking, as well as the speed at which you and your team can learn. How much can you improve outcomes for the entire team, not just yourself? At the end of the day, you’re still shaping better product outcomes, and that’s a much more important measure of success. Great product leaders make their teams better.

You also need to become more hands-on and more experimental. Be fluent across disciplines — data, engineering, design, marketing, operations, and everything that’s related to the business. If you’re acting like the CEO of your product, then all of these elements come into play. You need to think about them all collectively.

And maybe most importantly, there’s so much noise around us. One of the most valuable things product leaders can do is drive clarity through that noise. Product can do that exceptionally well.

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, Mike discusses what it means to lead product at a media company where journalism — not software — is the core product. He shares how product and editorial teams collaborate in a fast-moving newsroom environment, and why trust and editorial integrity shape every product decision. Mike also talks about what it means to him to build products that exist in service of something bigger.

Product management in the media industry

Your current role at STAT is very different from anything you’ve done before. What do you find most rewarding about working at STAT?

I had never worked in media before. After 20-plus years in the digital industry, I didn’t know what to expect going into it. At STAT, the product is all our different channels. It’s the delivery mechanism for the content, as well as ensuring users can find what they want to consume and to keep coming back.It’s an engagement platform.

With that, the work the journalists are doing is incredible. They’ve literally been responsible for changing laws and saving people’s lives. Obviously, I’m not directly involved in any of that, but it’s incredible to work for an organization that has that kind of societal impact.

Coming from a digital agency where I was working on 40 to 50 projects a year, to now being focused on one thing lets me give a level of care to a product that doesn’t feel as transactional. At an agency, you do the job and move on to the next job. Here, you get to feel much more ownership and care over the product. It’s very different, and very enjoyable.

You mentioned your work at a digital agency, where you were building the product. At STAT, journalism is the product — and you have no say in it. What does it actually mean to be a product leader when the product that matters most isn’t yours?

It’s certainly interesting. In a digital agency, when you’re working on so many different projects, a lot of them aren’t the main product — they’re almost like lead gen or demand gen instead. In that sense, I had experience with that kind of thing. But once you move to a head of product role, there’s some expectation that you’re going to be focused on the main product. STAT was my first gig as a head of product, working on the specific product that we were selling.

From that perspective, it’s a little setting aside of the ego. It’s a different approach to how you speak about the product and what your focus is on. It’s more on the vehicle to get that product out to people — the journalism in this case. And there’s so much that goes into those products that really has to let the journalism shine.

Bridging product and editorial teams

How do you speak about the product?

It’s 100 percent on the editorial. We involve them as we’re talking about changes that will impact the delivery of their journalism. If we’re talking about changes to the website, especially article templates or how newsletters are going to be formatted, we consider them stakeholders in those projects. We certainly get their input when it comes to advertising because there are aspects about what we’re reporting on and what advertising can be that we need to consider. Especially as a health-focused publication, there are types of ads that we won’t run.

STAT is high-stakes, deeply reported journalism. How do you build for an editorial team in that newsroom environment that has to move fast and operate independently?

The editorial team has a lot of good ideas — mostly focused on how we can expand what we can do from journalism and storytelling perspectives. A lot of news is news, but a lot of it is investigative or storytelling as well. Supporting them and delivering that to the user is one aspect that they care about. How can we best tell our story? Those tend to be longer-tail projects.

But there’s also the practical side of it: “I need to accomplish a task in the CMS. I need to include this document. I need to add this widget. How do I do that?” As a small team, there’s only so much from a resource perspective you can be working on. A lot of times, those stories are time-sensitive, so it’s part of the job to drop what you’re working on and focus on those tasks so the editorial team can best tell that story.

Balancing different departments and media channels

The value proposition of STAT lives entirely in content you don’t control. What levers does product actually have to drive engagement and retention?

There are multiple channels. The website is the most obvious one, but we also have the app and newsletters, which fall under the product team as well. Each one works a little differently in trying to keep a user engaged, not just with the story they’re reading, but with the next story that’s going to grab their attention.

The journalism shines on its own. If we printed it in a newspaper or magazine, people would just keep turning the page. It’s a lot different in a digital environment where you have to encourage them to move on to the next story.

As great as it is for someone to read multiple stories in a single session, getting them to come back regularly is more important. If somebody reads 10 stories in one day, that’s not as impactful to us as them reading one story every day for 10 days. It’s really about making those channels work together to drive them back to the stories. The newsletters do a lot of heavy lifting. The app and its push notifications help build a habit around engagement that pushes people back to the website.

Especially now, we’ve seen a shift where we still get a lot of traffic from search, but we see a lot more traffic coming from something like Google Discover, which is a feed. You scroll, you click a story, you read it. A lot of times, people don’t even know what publication they’re reading. They just saw a headline and clicked it. There’s a good chance you’ll never see that user again. So how do you engage with that user in a way that informs them and gets them to potentially come back again or sign up for a newsletter?

How do you structure your roadmap when you’re balancing requests from different departments, like editorial, advertising, and the subscriber experience, all at once?

It’s a little bit political. You want to keep everybody fed. If you just focus on one team, everybody else starts feeling like they’re not going to get anything for a year. You have to make sure everybody is getting something to keep their teams moving forward, too.

But from a prioritization standpoint, we’re a business. We need to stay in business, so revenue-generating things are going to get a higher priority. That’s just reality. That doesn’t only mean ads. It includes things around gaining and retaining subscribers.

Anything that helps with revenue — whether that’s advertising, retention, or subscriber growth — is going to jump to the top of the queue. When you look at the media industry as a whole, it’s incredible how much negative change has been happening. You see layoffs constantly across publications. STAT has been healthy, but we have to ensure we stay healthy, and that involves revenue.

Leading lean teams as a product executive

You went from managing 40 engineers at an agency to leading a lean team at a 100-person company where most employees are on the editorial side. What does that shift ask of a product leader that most PMs underestimate?

First, a little bit of setting aside ego. On a small team, it means getting your hands dirty. As a head of product, you think about the high-level roadmap and making sure teams are working well together. But on a lean team, sometimes it means owning the feature yourself or stepping in when someone is out. When someone’s on vacation, I’ll say, “I’m going to own that for a week,” and that’s OK. There’s much more of an aspect of getting your hands dirty than I had when I was managing a 40-person team.

Honestly, it’s kind of fun. It’s easy to get detached from the work later in your career as you move further away from execution. There’s something rewarding about staying connected to it. At the same time, you have to balance that with higher-level responsibilities like roadmap management and budgeting. It becomes a mix of everything.

Do you have advice for product leaders who are skeptical about getting into the operational trenches like that?

Even on larger teams, it’s valuable to jump in every once in a while just to remind yourself what your direct reports are dealing with on a daily basis. As leaders, it’s easy to dictate how people should do their jobs and then create processes around them. Sometimes the most impactful thing you can do is actually immerse yourself in the work. I think it makes the processes you build more effective, and it helps you connect more deeply with your direct reports.

Ethical considerations in journalism

You have to think about ethics in a way most heads of product don’t. What are the ethical considerations when you’re working in the service of journalism, and what are the constraints?

First, it’s that you’re working in the service of journalism and trust is the number one thing. If readers don’t trust what they’re reading or how they’re consuming it, everything quickly goes out the window. It’s so easy to lose your reader base if you break their trust. That’s obviously a journalist’s guiding light, but as a product team supporting them, that has to be ours as well.

We have AI guidelines on our website that explain what we will and won’t do with AI. You see a lot of publications moving toward AI now and they’re running into issues with hallucinations around stories. You can only have so many mistakes before readers stop coming back. A lot of that drives how we do our jobs.

In terms of constraints, we’re very clear that we won’t rely on AI for content generation. We’re never going to use AI to write stories. Once we know the rules around what journalists are comfortable with, that helps us set our guidelines. Then it becomes our job to figure out where we can utilize AI tools or deliver tools that support journalists in doing their jobs more efficiently.

For example, it’s one thing to say, “Here are all of our stories.” It’s another thing to say, “We know your interests as a reader, so here are the stories we think will be most impactful to you.” Finding efficiencies that don’t break trust and still let journalism stand on its own is where our guidelines come in. That journalistic integrity aspect helps shape how we approach things.

Does it give you some freedom to have those very sharp guardrails?

It does. I mean, yes and no. I think when we’re having those conversations about, “All right, what are we comfortable doing?” and knowing exactly where the guardrails are is helpful. Whereas I feel like some organizations, or maybe even some journalists, are having thornier issues to the point of: “If we do this, will we be okay?” We never feel like we’re encroaching that far because we have those guardrails. So I do think it’s helpful. It makes us more comfortable with the decisions we make.

That’s not to say that we never run things by the editorial team like, “Hey, would we be comfortable trying something new like A, B, or C?” They might say, “We’re cool with C, but A and B, no, we’re not doing that.” I think we have a really good relationship with our editorial team. Realistically, any product team has to, and we meet with them regularly. Sometimes we’ll try to push them a little, but we’ll always defer to them. So we have a good sense as to where they’re comfortable, where they’re definitely not, and what that gray area is.

What’s the case for building a career as a ‘background player,’ a PM whose product exists in the service of something else?

No matter what you’re working on, you could tell a narrative in a way that can still make you a product hero. At the end of the day, you’re doing a job in service to a user. Whether you are building the actual product the user is using or providing the mechanism through which they consume the product, you’re still supporting both the company and the user.

That’s where the professional fulfillment comes from. I feel great about helping users consume our content because the content is really important. If we weren’t doing a good job, nobody would be getting that content. It’s incumbent on us to ensure users can access it, get value from it, and keep coming back.

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