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

The biggest misconceptions in B2B ecommerce

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Encouraging repeat purchases in B2B ecommerce

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

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

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

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

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

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

Adapting to modern consumer expectations

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

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

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

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

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

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

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

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

Measuring ROI and driving digital transformation

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

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

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

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

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

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

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

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

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

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

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

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

What does LogRocket do?

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

In our conversation, Gustavo talks about why creating value should be at the center of every product decision. He also shares how to evaluate initiatives, think in terms of compounding value, and lead effectively as AI changes the pace of product work.

Creating value as a product manager

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

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

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

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

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

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

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

How to evaluate product investments

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

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

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

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

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

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

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

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

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

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

Leading with vision in an AI landscape

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

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

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

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

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

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

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

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

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

Understanding value creation in the marketplace

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

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

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

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

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

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

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

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

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

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

What does LogRocket do?

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

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

Knowing which customer signals to solve

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

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

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

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

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

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

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

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

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

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

Frameworks and signals across the full ecosystem

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

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

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

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

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

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

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

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

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

Building trust when introducing AI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How AI is reshaping decision-making and ownership

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

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

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

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

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

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

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

What does LogRocket do?

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

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

The AI design perspective

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

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

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

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

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

How LLMs are reshaping digital experiences

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

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

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

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

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

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

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

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

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

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

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

Designing intentional AI experiences

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

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

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

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

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

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

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

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

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

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

Human judgement and managing expectations

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

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

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

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

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

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

Early career and leaning into excitement

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

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

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

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

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

What does LogRocket do?

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

In this conversation, Lucila discusses how cultural nuance shapes customer experience design, why discovery must start with frontline employees, and what it takes to scale a global CX team while maintaining shared values across regions.

Building hyper-localized CX in a global market

Could you start by describing your core customer base?

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

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

How do you adjust the CX journey across regions?

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

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

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

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

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

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

Designing for real users, not assumptions

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

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

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

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

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

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

We have two stages in our discovery process.

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

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

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

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

Have you learned anything surprising during discovery?

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

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

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

How do qualitative insights translate into concrete product decisions?

Qualitative discovery influences rollout decisions.

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

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

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

Scaling personalization without losing nuance

Are you seeing a global mobile-first movement?

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

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

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

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

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

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

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

Building a global CX organization

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

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

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

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

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

What communication practices support this alignment?

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

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

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

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

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

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

What lessons have you learned about building a global team?

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

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

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

What does LogRocket do?

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

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

Monetization for different user groups

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

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

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

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

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

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

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

Testing intelligently

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

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

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

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

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

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

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

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

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

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

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

The role of AI in accelerating PM work

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Empathy, data, and effectively coaching PMs

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

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

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

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

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

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

What does LogRocket do?

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

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

Converting potential into organizational impact

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

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

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

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

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

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

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

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

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

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

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

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

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

Creating scalability across an organization

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What it means to ‘lead by example’

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

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

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

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

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

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

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

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

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

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

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

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

What does LogRocket do?

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

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

Defining what’s worth testing

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Personalization and the user experience

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

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

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

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

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

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

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

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

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

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

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

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

Adapting to low-commitment behavior

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

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

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

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

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

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

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

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

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

AI is reshaping the search landscape

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

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

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

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

What does LogRocket do?

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

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

Creating value and identifying friction

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

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

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

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

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

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

Looking at the end-to-end experience

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

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

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

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

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

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

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

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

Translating signals into priorities

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

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

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

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

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

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

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

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

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

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

The importance of intentional framing

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

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

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

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

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

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

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

What does LogRocket do?

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

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

Starting with the problem, not the solution

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

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

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

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

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

Building a culture that allows you to pivot

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

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

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

Reframing digital from cost center to revenue enabler

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

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

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

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

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

Testing early to build credibility

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

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

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

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

Partnerships as accelerators

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

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

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

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

When a pilot is truly scalable

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

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

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

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

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

What challenges are often underestimated in early testing?

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

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

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

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

Knowing when not to build

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

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

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

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

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

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

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

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

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

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

• Desirability: Do customers actually want this?

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

• Viability: Can we make money from it?

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

How do you make stakeholder conversations more productive?

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

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

Bringing a business lens to product leadership

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

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

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

What does LogRocket do?

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

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

Regulation and designing within constraints

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

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

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

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

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

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

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

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

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

Readiness for digital transformation

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

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

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

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

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

When constraints improve the experience

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

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

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

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

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

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

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

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

The overlooked side of digital transformation

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

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

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

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

How are you seeing AI impact the digital experience space?

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

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

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

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

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

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

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

What does LogRocket do?

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

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

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

Defining engagement that actually drives the business

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

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

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

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

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

What’s your process for identifying that North Star?

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

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

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

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

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

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

When metrics lie: finding the real opportunity

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

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

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

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

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

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

How did you reframe that conversation with your team?

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

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

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

Winning back users at checkout with new functionality

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

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

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

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

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

How do BNPL and express pay shape user expectations?

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

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

Designing frictionless experiences in borrowed UI

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

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

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

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

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

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

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

Collapsing time to value with functionality

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

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

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

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

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

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

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

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

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

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

Operating under regulation without losing velocity

What have you learned about building products in regulated environments?

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

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

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

How do you position your product relative to infrastructure players?

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

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

What does LogRocket do?

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

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

Bringing a culture-first lens to transformation

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

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

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

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

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

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

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

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

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

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

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

Modernizing under real constraints

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

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

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

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

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

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

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

How many venues are there?

Forty-four.

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

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

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

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

Culture signals and psychological safety

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

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

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

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

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

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

Agile as a human system

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

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

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

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

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

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

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

Autonomy, morale, and a concrete example

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

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

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

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

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

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

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

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

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

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

Preserving what makes Alamo Alamo

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

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

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

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

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

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

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

Bottom-up culture and leadership influences

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

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

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

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

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

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

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

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

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

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

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

Knowing the system is working

How do you know when the system is working?

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

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

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

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

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

What does LogRocket do?

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

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

Evaluating AI opportunities through ROI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Letting data challenge assumptions

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

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

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

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

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

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

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

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

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

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

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

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

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

When AI stops being a differentiator

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

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

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

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

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

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

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

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

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

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

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

The core of an AI strategy

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

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

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

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

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

What does LogRocket do?

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

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

From agency work to corporate product strategy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Building 0-to-1 inside a large organization

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

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

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

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

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

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

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

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

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

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

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

‘Moving fast’ without breaking trust

Could you illustrate this with an example, like AndGo?

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

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

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

What did ‘venture governance’ look like in practice?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What AI-native builders change about product work

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

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

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

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

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

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

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

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

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

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

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

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

Leading AI adoption inside legacy companies

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

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

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

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

Where does AI competition show up first for incumbents?

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

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

Why is ‘comfort’ a liability in AI adoption?

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

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

What does LogRocket do?

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

In our conversation, Jessica talks about her team’s efforts to create and refine products for Toast’s enterprise customers, while also creating value for the entire Toast customer base. She discusses the challenges of working on products for enterprises, such as complex integrations and other unique customer needs, as well as how they structure feedback loops across personas.

Building for enterprise customers

A lot of product leaders talk about their work as being a mini CEO. That model can be challenging if your team has different goals from adjacent teams. In that scenario, how do you work to align your team’s goals?

One thing that’s great about Toast is that we are all aligned on common core principles and priorities. This really helps when there are so many different product and R&D teams working in so many different areas of the product.

Toast’s core business is focused on small, dynamic customers and operators, but I look after the Toast Enterprise business — a customer sector that has unique needs. Enterprise customers have different expectations of how they interact with their technology partners. They frequently have more complicated tech stacks and have different implementation, rollout and ongoing account management needs.

When the Enterprise R&D teams think about our work we rely on and closely align with our company’s core principles. One of them is being “customer obsessed” — and for us that means making sure that the work that we’re prioritizing is well aligned with customer value. This is a type of core principle that translates across all our segments and serves us well when working with other product teams across Toast.

For example, we may need to invest in a feature or capability that is initiated for a larger, more enterprise level brand, but would still have a meaningful positive impact for a smaller operator who owns one or two restaurants. We’re always looking for opportunities to democratize our work and ensure we are delivering on the customer value of the platform as a whole. A good example of this is some of our recent investments in Toast’s Kitchen Display Screens. Enterprise R&D was able to work closely with our Kitchen Operations R&D team to deliver enhancements that make it easier and more efficient for customers to prepare orders in an “assembly line” fashion. This was a feature highly requested by enterprise customers, especially those in quick service environments, but it’s one that makes food prep more streamlined for customers of all sizes. If you have a make line set up like a factory line floor, this feature makes your life easier, no matter the size of your overall operation.

Toast R&D has a common mission to support restaurants, retailers, and hospitality operators. These different end users all share common problems, so my teams focus on that common denominator across the board and that unlocks a clear path for collaboration that all our partners in R&D (and other cross-functional stakeholders) can get behind.

Do you find you’re frequently competing for resources with teams that focus on SMBs rather than enterprise customers?

This is a reality in the product space as a whole — there’s always a limited amount of resources. We have to be fiscally responsible, efficient, and honest, this keeps your prioritization and creative approach muscles strong. So in some ways I appreciate this dynamic as a reality of managing an R&D team.

Enterprise does have dedicated teams, roadmaps and priorities however, and they don’t always perfectly align with other parts of the business. Something we’ve gotten very good at is working cross-functionally with partners in other parts of the organization to ensure we have the trust, clarity, and alignment on approach to ensure a great working relationship. We want to make sure that our colleagues feel comfortable letting us work in their spaces and feel heard every step of the way. To do this at scale we need a really solid development process, repeatable patterns, and a high bar for quality, communication, and engagement. Without this, we’d get bogged down by issues, overly burdensome oversight or other friction points that just slow down the timeline by which we can deliver value to our customers. The more we can hold ourselves accountable and our work to a high standard, the more trust we have in the organization, the faster we can go.

Even though the core problems faced by operators at the store level are the same across the board, we often need to level up the scalability of a solution for our segment. We have dedicated resourcing that we protect and shepherd to move those initiatives forward. In other places, however, we’ll partner and advocate within the organization. We’ll tell other teams, “Hey, we have this problem. Our customers are trying to achieve this goal. How does this map to what you’re trying to do in your roadmap?”

Often, we find a common thread between what an existing team is working on and what our team is pursuing for enterprise needs. In those cases, we’ll double down and ask, “How can we get there faster together?” This helps us solve a problem for both independent and enterprise operators just by having a conversation about use cases and approaches to make sure we cover all the bases.

Teams are sometimes surprised by the level of overlap that exists between customers of different sizes. Restaurant operators have a lot of the same core problems, enterprise is just magnified.

Feedback and navigating customers’ complex ecosystems

There are some unique challenges when your ICP is not just the enterprise customer, but a subset of that, such as the enterprise customer’s internal IT team. Could you say more about that?

Sure. One of the unique things about working with an enterprise customer base is the depth of their operations. An independent restaurant or retailer, they typically work from a small team — an owner/operator, maybe one or two additional employees who support them. They’re a one-stop shop where this small group manages their POS, inventory, procurement, payroll, and more. They also handle operations, including any integrations with key partners and third parties who provide services like ecommerce or delivery.

But enterprise customers will often have specialized functions. A marketing team, pricing team, analytics team, POS administration team and more. From a product development perspective, it’s been amazing to really get a sense of how they work, benefit from their specialized knowledge and translate that into seamless, delightful product solutions. There is a clear benefit in closely working with enterprise customers: engaging in the discovery process, taking them through wireframes/designs/prototypes, etc. Showcasing what Toast can do for them that’s different and better than their previous solutions is one of my favorite parts of this job.

What are some of the ways you work with these teams within your enterprise customers to influence the roadmap?

They’re great partners and collaborators. Toast has a very vocal, engaged and insightful Enterprise Customer Advisory Board that we work with regularly. We talk about feature ideas, market innovation, their strategic priorities, and the specifics of their teams using Toast day in and day out. I love that part of the job. They bring to the table a perspective on their own tech priorities outside of Toast, and that can be really insightful for us also.

They have high expectations, which we’re always striving to meet. They want flexibility, configuration support, and to tailor the solution to exactly what their teams need to be successful.

How do you structure feedback loops to ensure you’re addressing immediate customer needs while also anticipating future requirements?

We build strong feedback loops with the teams engaged in the work from the beginning. In addition to the Customer Advisory Board, we also work closely with our Customer Success, Care, Enterprise Solutions and Onboarding teams. They’re huge stakeholders for us. They are frontline colleagues who always offer a good pulse on how things are going.

We consider what our customers are looking for now and in the future. Where are they going strategically? What are they looking at for the next six months, one year, or five years? How do those needs align with Toast’s long-term strategy? How we are thinking about our investments and product bets? To truly understand and meet both current and future needs of our customers, our team really prioritizes a triad of inputs — internal stakeholder awareness, long-term strategic vision, and customer relationships and empathy. By triangulating across those, we aim to find the best path forward that offers the right balance of “just needs to work” and innovative solutions for the next generation of restaurant tech operators.

Lastly, we go onsite for real-time feedback. One of the important parts of working within an enterprise organization is that the POS is the hub that plays nicely with the rest of the tech stack. For example, we have a team working on a significant integration update, so we sent members of our product, design and engineering teams onsite to watch real-world operations, engage in full-day workshops with both the customer and their other vendors, so we could

develop a unified approach. We never want to develop in isolation — we think holistically about the problem end-to-end and in the enterprise space, this includes consideration of customers’ other vendors and partners and the real world tangible experience of the restaurant operation itself.

Investing in work that impacts all customers

Traditionally, enterprise customers have more specific needs compared to SMB, but as you highlighted, you’re still inherently solving the same problem. Given those specific needs, though, do you create and roll out unique features for specific customers?

We can, but we find that everyone wins when we can invest in the platform to meet their needs more broadly. This sets us up to improve the product for all Toast customers and support other enterprise customers down the road. If a particular feature isn’t super applicable to the single-unit customer, but it is something we think a lot of our larger customers are going to benefit from, we invest accordingly.

You’ve talked a fair amount about your team from the standpoint of communication and alignment. When you’re hiring for your team, what specific qualities do you look for beyond education and professional experience?

When you work for enterprise customers, there is a certain level of process orientation that’s helpful. Communication skills are really important as well, especially when sharing a long-term vision. You have to bring people along the long-term journey while also supporting a near-term value proposition that creates excitement. I’m always looking for that in terms of how a candidate communicates their work.

To get a sense for this, I like to ask situational questions, like, “What is the hardest problem that you’ve had to solve?” “What types of problems do you like to solve? Tell me how you broke it down and what shipped first?” There’s a lot of platform investments required to build robust, strong enterprise products, make those investments, and tell that story about why it’s important is perhaps the most crucial aspect of the job.

I’ve also asked people when they’ve had to say no to someone. You have to be able to say no. That’s really hard, especially when you are so close to customers and have a lot of pressure within the organization. It’s a super important skill to not only be able to say no, but also bring people along with you and communicate effectively why you’re saying no. Sometimes the inverse way of asking about this is “Tell me how you explained why you couldn’t do something and what were the reasons and the trade-offs involved.”

In the enterprise product world, a lot of the problems that we are working on are complicated and full of dependencies. We have to make sure that we’re tackling and resolving dependencies quickly and upfront so the team isn’t blocked later on. I try to assess whether a candidate has the baseline program management skills to keep everyone on the rails and aligned.

Lastly, I always look for a sense of ownership — the ability to take responsibility for the final outcome of this work, break down these items, and tackle the many different functions required to get there. Having a strong sense of ownership, accountability, and incremental delivery are probably the most important aspects of the role.

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, Braeden talks about how his team blends machine telemetry with human context to guide decisions. He shares why he leans on a “map and compass” approach to combine data, empathy, and conviction, and how SmartRent is evolving from a point solution to a platform.

Understanding context and finding friction across personas

With billions of monthly IoT signals, as well as tens of thousands of boots-on-the-ground maintenance and property staff, how do you incorporate both machine telemetry and human insights to guide product strategy?

When we started with SmartRent, we had zero IoT signals — and now we have billions. There are some core ingredients to the recipe that have always been true. The specific tactics have changed given scale and variety, but key common elements are, first, a deep understanding of the people we’re solving problems for, as well as the B2B2C dynamic. We always need to know who our personas are and understand them as the humans they are. What is their incentive? How are they trying to advance in their career? What are their problems?

Then, we need to understand the consumer side. What is their incentive structure? How are they receiving this value prop? That context helps to build a compass. Internally, we talk about having a compass that starts with human understanding. We want the compass to include an articulation and understanding of what the data means — where it comes from and how it’s sourced.

The final part of the compass relies on conviction to move the problem forward. The issue with a ton of data is that when you lay it out on a map, you can get lost. Data alone doesn’t give you a decision. In a B2B2C dynamic, if you just adopt a data-driven philosophy, you can go too far and get lost in your map without a compass to help you navigate. And even if you’re getting the right amount of data, there’s still something else that can impact that data that the data itself is not representing.

A great example is a smart lock that’s installed on the front door of a building with physical damage. Your dataset may not indicate damage, but there’s human context driving it. Understanding all of that is how we navigate those challenges as a product team.

When you’re working with multiple personas across a product ecosystem, where do the biggest workflow friction points emerge?

The interesting thing about friction points in this type of product operating model is that they emerge when you look too much in a silo. In these models, there’s a virtuous lifecycle: the business is trying to deliver value prop to the end customer, and technology enables it. But when you dissect the workflow, if you only talk to one team — it might be marketing, leasing, or maintenance — you can get so deep into the value chain of their specific problem statements that you forget what the virtuous lifecycle is aiming for.

For example, one of the biggest friction points in apartment and multifamily leasing is maintenance. Around half of renewals — a resident’s decision to stay or move — comes down to their experience with on-site maintenance. You have to compel them to live there in the first place through marketing and leasing, and good tours. But once they’re there, it’s a different ballgame. If I have an issue as a resident, I’m measuring my experience on whether that issue is resolved quickly, with high quality, and with a good experience.

Maintenance teams also have a lot of turnover and retention issues. They’re inundated with so many things to do, like turns, cleaning, landscaping, and systems running well. So it comes down to where the time-suck is and how we can help them have better quality.

We do everything with the resident in mind. If we help maintenance in a resident-first way, it therefore helps both the team and the resident. And then maintenance is happier as a result because they get measured by that resident experience.

Your customer is not the resident. Your customer is the property owner. How do you ensure that a resident-first feature also moves the business outcome that your customer wants?

This is where product theory versus reality comes into contention. Of course, we may have things like a beautiful RICE framework to prioritize work, but in a B2B2C dynamic, we can get stuck on how to prioritize something that doesn’t have a direct ROI validation point.

In product, you’re trying to drive things that have ROI for your business and financial ROI to the end customer. For us, that ROI can show up as operational savings, asset protection, or charging for a tech amenity use case. But the ultimate ROI is whether we can help get higher lead-to-lease conversion. Can we help property owners attract more people to live on-site? And can we help that property owner renew them?

When we think about it that way, we can prioritize the end-resident experience features because we characterize them in a manner that impacts those outcomes. For example, when you’re coming home with your kids and you have groceries in your hands, it’s tough to dig out your keys and unlock the door. It’s a differentiator to use your phone or watch to get in. We would never charge a resident for that, but the property is thinking, “Well, I already have this tech. How do I differentiate that experience so someone renews with me?”

Incorporating intuition with prioritization

You mentioned RICE as a framework, but how it may lead you to prioritize the wrong thing. Is there a time when applying a product framework helps your team move faster — and when it slows things down?

My hot take is that if you start with wanting to apply a product framework, you’ve already started on the wrong footing. Frameworks aren’t bad — they’re tools. But you don’t pick up a drill or a wrench and go, “How do I use this and what should I use it on?” You start with the problem, and the context dictates the tool.

With RICE specifically, it can be useful, but it leaves out intuition. Say you score your items, and the highest one is 9.2. Is that the thing that’s actually going to move innovation up the hill to solve the real problem for the real human? Intuition comes down to conviction. You might actually want to go with a lower-scoring item because it enables a process change. That’s convicted product leadership — you create a world that’s not possible today by having intuition guide you through the map.

With prioritization, we start with context and the compass dynamic. Do we have a good sense of the specific humans? Internally, we make personas real people — actual people we have a relationship with. Then, we have the data part of the compass. From there, we have context and command on the problem statement. That leads us to the right framework.

In a B2B2C organization, how do you build a product lifecycle where the needs of all the personas — residents, onsite teams, commercial stakeholders, but also the enterprise — influence the roadmap? What’s your playbook for when those priorities don’t align?

We’re going through this right now. We’re in quarterly planning and solidifying our roadmap. Our first tenet is to always be ready to change. Our playbook needs to be responsive to enterprise needs, what’s happening in the marketplace, what’s happening with the businesses, and what’s happening with the consumer.

So, we established a product advisory council. Then we worked with client-facing teams and did in-person client visits to get nuance on each customer — because every customer is their own enterprise. They’re dealing with corporate strategy, organizational challenges, change management, and innovation. And for all product professionals, your customers are doing the same thing.

A big part of the playbook is: who do you want to become as your enterprise? Who does the B2B customer want to become? And where do residents want to go? Then we synthesize those inputs and make trade-offs based on the inflection point that creates the widest denominator of impact across the value chain. This is essentially a fancy way of saying, “What’s the 80/20 bet that gets your enterprise closer to who we want to be and helps the customer do the same?”

The final layer is embracing uncertainty. You have your map, you have your compass, you’ve plotted where you need to go — but start walking and make rapid iterations. At SmartRent, we timebox. We think about the minimum impactful product, or the biggest problem we can solve in a timebox-constrained scope. Then, we let the customer tell us whether we made progress.

Can you give us a real-world example of that?

We’re creating a platform experience that blends value-based features together. One example is bulk management, i.e., configuring features, settings, and preferences at scale. Customers own hundreds of properties, and we work with thousands of them. We have to solve things at the unit level, and then enable management across 100 properties, 100,000 units, etc.

Vacant energy management is one example. On a vacant unit, can you control the temperature so it’s comfortable for tours without running all the time and wasting money? We had to get that right at the unit level. Now we’re asking, “Can we allow a property manager to change that across 100 properties and 100,000 units?” If you can click a button once instead of 100 times, we reduce complexity. It saves time while meeting the need for a great end-customer experience.

Channeling the voice of the customer

You mentioned using a product advisory council to understand systemic pain points. What advice do you have for leaders looking to adopt a similar model?

First, it’s an opportunity to build trust with customers. There are lots of ways to do it, but what’s been successful for us is de-scoping unit-by-unit problem statements because we have other feedback channels. Start by assessing where your feedback channels are today, and what problem you’re trying to solve. For us, we wanted attention on where customers want their businesses to be in the future.

When you get customers in a room together, it’s different than a 1:1. People hear each other and realize they’re facing the same thing. Starting at that top layer gets you the right nuggets from the tactical layer, because then they’ll say, “The reason I can’t get to that big change is that I’m facing these tactical problems.” Now you can synthesize where momentum should go and get the demand signal for the roadmap.

We curated a cross-section: customers with different product usage, and different business models — own and manage, manage for owners, and owners with third-party management. Those differences create varying implications. The product advisory council gives you common themes and different tactical nuances.

Then we brought the raw feedback back to the whole technology team. Engineers, PMs, and designers know they’re trying to solve something for the property manager, but they don’t always know exactly what issues they need to solve. Raw voice of customer initiatives creates a lot of “aha” moments. Finally, we shared the feedback across our entire organization. The more everyone in our company understands the real-world realities our customers share, the more empathetic and forward-focused we are able to be across departments.

As you mature, you are moving from a smart device solution company to a platform company. What strategic shift has been most important in helping the market understand SmartRent as a platform?

I think that companies usually have one of two fates. You’re either a point solution that stays a point solution, or you’re a point solution that tries to become a platform yourself.

SmartRent is in that phase of going from platform story to operating and being, at scale, a platform where the story is well understood. The challenge is how to insert unique value into the end customer lifecycle. Tech gives you optionality. You can build something cool, but if you don’t scale it with the right sequence, you get lost, and the platform story doesn’t resonate.

From day one, we had a simple assertion: smart home technology isn’t purpose-built for multifamily. We started there, then we built access and asset protection. What’s the correlation? Operations of the asset — helping teams do the work faster with better quality for better resident experience. We talk about a physical AI layer. We can understand an HVAC unit problem in a vacant unit before it’s about to go down, create a work order, manage it, and provide access to complete it.

Getting lost in complexity and looking toward the future

Do you have any advice on how to take the complexity out of telling the story to the market?

It’s easy to get lost in complexity. For us, this is about smarter living and working. If we can be smarter, we can be 1 percent faster and 1 percent higher-quality every time we do something. At scale, that means better resident experience, faster leasing, and more renewals. For residents, it means value out of living in a community in a way you wouldn’t in another.

SmartRent sits with a unique value prop of being able to drive income, lower expenses, and make your home a home. And the platform play is always about empathy to the human. Who is the actual person? Can we help them realize how we’re solving a problem for them? Everything else is delivery.

What will the role of product technology look like in multifamily real estate over the next five years?

It’s a huge opportunity. To address the next five, it’s good to think about where we come from.

Multifamily has been brass keys — very offline and with disjointed technology. Adoption accelerated with the COVID pandemic. Leasing offices literally stopped, so if you had to give up brass keys as a resident, what were you going to do?

Over the next five years, I anticipate that the next disruption factor will be AI. Software is going to become commoditized and easier to build. For big real estate companies, creating software becomes more approachable. Then, you have to look at what you have and ask, “How do things flow together, add business value, and help data and experience transform the business?”

The opportunity is in the foundational truth of human problems that you haven’t been able to solve — and now you can — but in a way where things integrate. Experiences become easier and more approachable, and you use AI strategically.

What does LogRocket do?

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

In our conversation, Kim reframes “networking” as social connection, then gets practical about building and maintaining relationships as a busy product leader. She shares how small, consistent interactions compound over time, how to right-size your effort based on your goals, and how to build an authentic presence without diluting your message.

Networking doesn’t have to be cringe

Networking can be intimidating for a lot of folks, including product leaders. Where do you think that negative connotation comes from? And do you find that response to be similar across industries?

Yes, I do think it is a cringe-worthy word, and I do think it is a cross-industry response that’s not specific to product leaders. The way I like to think about it is that networking is really socialization. If you think about it like a social event or a social opportunity, that’s really what it is, it just happens to typically be for a professional reason. If you replace the cringe-worthy word “networking” with “social,” it makes it a bit more appetizing.

The main thing to keep in mind is that you’re getting to know people, you’re putting yourself out there, and it’s really all about making connections that may benefit you or others now or in the future. I think the negative connotation comes from how we’re raised, especially in the US. We’re driven by this idea of self-made success. We hear, push through the challenging times and make your own way in the world.

We’ve got all these rags to riches stories — Oprah Winfrey, Coco Chanel, Ralph Lauren, college dropouts who started startups in their garages and then became billionaires in tech. Being self-made somehow feels more respectable than being spoonfed opportunities. It can also feel strange to put yourself in a vulnerable position or ask for support when maybe you’re looking for a job.

But instead, think about it as: I’m going to meet some new people and give them an opportunity to meet me, and we’re going to look for common ground. We’re going to experience some new things together and keep our options open.

How has your own definition of networking evolved or changed throughout your career?

I recently wrote this article called “I Thought Networking Was Sleazy and I Was Wrong.” I’ve been working remotely now for five and a half years since the pandemic, and I realized how much I enjoy getting out and networking. I attended two networking events within about two weeks of each other, and I felt really electrified. I got out, I met new people, I was in different kinds of environments, and I talked to people with a product background and also people from my university who have all kinds of different professional backgrounds.

It made me think about college. I remember being offered a job by an alumni I was connected with through a club. I thought it was like a free handout. I was completely averse to it. I said, no way, I’m not even going to send my resume. I wanted to prove I could make it in the world.

Over time, I realized that was really silly — to think someone would offer an opportunity because they wanted something in return, or that it made me less of a person to accept support from someone. Now that I’m older and I’m actually in a similar position, I’m on my college board and I can support students coming out of college and looking for opportunities. I realized that people just want to help each other.

This is what networking is about: supporting one another and seeing others succeed. And I jump at the chance now to attend networking events, whereas in the past I would’ve said it feels too fabricated or manufactured. It’s completely opposite now.

Maintaining relationships while still meeting new people

As a CPO, I’m sure you’re very busy. When you think about allocating your time for networking, do you intentionally divide it into time for maintaining existing relationships and time for finding ways to meet new people, or does it just happen organically?

Historically for me, it’s been a bit more organic, but I do take time to connect with people regularly. I still have one-on-ones monthly with old colleagues and we stay connected. I also went out to brunch with colleagues I hadn’t seen in over eight years, which was delightful.

What I would like to do in the future is put more intention around it — maybe quarterly, make sure I get out there and go to events. And you don’t have to always think of networking as a business-focused exercise. I can think of networking as expanding friendships, like through my kids’ sports. All of that is still networking. You don’t know where relationships will lead, and you may end up forging a path together in ways you don’t anticipate.

Networking efficiently when you’re overloaded

Product execs are overloaded. They’re busy in all aspects of their life. What does efficient and meaningful engagement look like in the face of that?

It comes back to finding ways to just be social in general. It can be anywhere, anytime, with anyone. I struggle with perfectionism and I tend to overthink things, so my advice is: don’t overthink it.

If you want to reach out to someone — say hi, catch up, connect someone to an opportunity, follow up on something you saw — it doesn’t have to be long and drawn out. It can be a two or three sentence LinkedIn message: “Hey, it’s been a while. It’d be great to catch up. I saw this post and thought of you. I’ve got somebody who might be a great fit.” It doesn’t have to be perfect and it doesn’t have to be time consuming.

The trick is to keep it going regularly. It becomes part of your regimen — weekly or monthly — just constant connection. I was doing a Peloton workout and the instructor said something that stuck with me: “Fall in love with the process.” The outcomes aren’t always the end goal. You have to apply discipline to consistently go after what you’re trying to achieve. That’s the same with networking and building your connections.

One example: I was on vacation in Bar Harbor near Acadia, walking down the street, and I smelled this amazing scent. We were behind two ladies, so I said it must be one of their perfumes. I asked my family if I should ask her what it was, and my daughter said, “No, that’s so embarrassing.”

But I did it anyway. I ran up and said, “Excuse me, your perfume smells amazing. I’d love to know what it is.” She told me, and I found it when I got home. The point is: don’t be afraid to approach people. It can be something small like that, or you’re at a conference and someone spoke on stage and you want to talk to them more. You can strike up a conversation about almost anything, make those connections, and you never know where they’ll lead.

How to start and match your effort to your goals

How do you get started? Do you recommend blocking time on your calendar for it?

Yes, if that makes sense for them. The first step is to understand what your current goals are — and your goals will change, so your strategies should change along with that. If your goals are to stay put, remain satisfied, or help others connect, the way you engage might be different than if you’re actively looking for a job.

If you’re actively looking, you probably do want to sit down a couple hours a week, look for opportunities, network, find events, and engage in digital forums. Understand your personal goals and what you’re trying to get out of it. Then you can decide how much time to put toward it: is it maintenance mode or active growth mode?

Do you have an example where networking quietly compounded over time and only later revealed its full career impact?

Yes. The majority of my career changes — individual job changes and company changes, including industry changes — have been through networking. Only my first and second jobs were through traditional recruiting, because I was fresh out of school and determined to make my own way.

The first seven years of my career I was in government consulting. Around seven years in, I wanted something different. I had a neighbor across the street working for a company and they needed a digital marketing manager. I said, “I don’t know anything about that. They’re never going to hire me. I don’t do marketing.”

But government consulting — strategic communications and change management — had transferable skills. I was nudged along by my partner: “Give it a try. Go talk to people. Worst case, it doesn’t work out, but at least you’ve had the discussion.” I did, and I landed the job.

A year and a half later, my boss left and my colleague said, “You should apply for the digital product manager role.” I said no way. She was talking about APIs and I didn’t know what an API was. I felt too junior and embarrassed. They said, “Don’t worry. You have the skills you need. We’re going to teach you.” That kicked off my decade in digital product management.

That’s how it compounds. I then got multiple opportunities — recruited into roles or pursued opportunities I saw through my network. I probably wouldn’t have had those opportunities if I hadn’t leveraged it.

How do you evaluate whether a professional interaction is worth continuing or if it’s something you should let fade away?

I think you know with intuition. You follow your gut. I was talking to someone who said she uses a rule of thumb: if I try to engage someone three times and it doesn’t come together, or the chemistry isn’t there, then I let it go.

In a professional setting, you might connect on LinkedIn, exchange cards, message a bit, and it doesn’t pan out — that’s okay. Not everything is meant to work out. Things may not be right now, but they might be a year or two from now. Keep your network alive and you never know where things will pan out.

Building a presence online without diluting your message

There are so many channels people can use to showcase their work and enhance their professional profile. What factors should product leaders consider when making that choice?

It goes back to: set your goal. If your goal is to establish yourself as a thought leader, you should produce your own content or re-share others’ content with your thoughts added. It can be writing, video, podcasts, being a guest on a podcast, or a personal website.

You also have to consider what you can actually share. I don’t showcase much company work because it’s under NDA. But if something is public — a product, a marketing page — you can highlight it and write about the experience of building it or what the team achieved together.

The main thing is knowing your audience, what you’re trying to do, finding the right channel, and building a consistent rhythm.

What common mistake do you see product leaders make when trying to build an online presence?

AI slop is definitely a dilution. If you’re going to produce content, make sure it’s authentic. I believe in quality over quantity. I would rather post less often and have it be high quality, especially weaving in storytelling.

With all the AI-created content out there, storytelling sets you apart. It shows you’re human, you have experiences, you’re processing them, and you’re turning them into something useful. And you still have to know who your audience is, because you’re asking for something in exchange — their time.

Teaching networking in a remote world

How should product leaders mentor the next generation in a world of remote work and AI-mediated communication?

Encourage people to get out there. A lot of people are working remotely and they’re isolated. Even for me, going to events made me realize I needed to get out more. People at those events were saying the same thing — even if they go in, it’s only once or twice a week.

We need to embrace what’s natural to us as humans: social connection and human dynamics. And even if you’re an introvert, pay attention to how you feel after interactions. Are you charged up or drained? If you’re drained, maybe you overextended or did too much talking.

One of the keys to networking is having balanced conversations — spend as much time asking questions and getting to know other people as much as you do talking about yourself.

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, Neeraj discusses the PM’s role in keeping teams motivated as the tech landscape becomes more crowded and ideas are harder to make feel “new.” He shares how his developer background shapes the way he collaborates with engineers, why teams lose energy when goals shift or progress stalls, and how to reignite an original spark of excitement when projects get derailed. Neeraj also explains how he evaluates candidates for their ability to inspire others and the small shift in his own leadership style that had an outsized impact on team motivation.

The power of purpose in product leadership

When did it click for you that inspiring and motivating teams was critical to being an effective product leader?

For me to give something my all, there needs to be a rationale. There needs to be a reason for why I’m doing it. That either comes in the form of me knowing what the goal is and that this is a step toward realizing that goal, or it’s something that’ll give me a lot of benefits. I have to be interested in what I’m doing to give it my all. That’s just the type of person I am.

When I started my career, there were a lot of things I had to do just to do them. I noticed that if someone told me the reason why I’m doing it and how it fit into the bigger picture, it gave me more motivation and inspiration to give it my all and do more. It fostered this productive environment for me so I could excel. That’s when I realized how important it is to give people that same bigger picture if you want them to be fully motivated.

How has that perspective evolved as the tech landscape has become more crowded?

I started my career in 2015. In the tech world, every time you were doing something back then, it felt new. There wasn’t that much competition. Think about YouTube and all these other great products out there — they were the first of their kind.

Nowadays, it’s more important to stay motivated because it’s hard to think of doing something completely original. Instead, you’re doing a variation of something that already exists. A lot of people get discouraged or feel defeated because some other big tech company is already doing it. You have to give your team a reason to keep doing what they’re doing.

The way I see it, it’s actually easier to motivate people now. In the past, you could just say it’s something new and you don’t know if it’s going to work out. Now you can say, “Although we’re not doing something new, we’re doing something that’s better or faster, or that will benefit our audience a lot more.”

Motivating developers with engagement, not direction

Having worked as both a backend developer and a PM, what have you learned about what truly motivates developers versus what PMs often assume motivates them?

The root motivation is the same for both parties. It’s identifying the problem, understanding the problem, and knowing how to solve it. But the key thing with what I call the “technical audience” — anyone in R&D, development, QA, release engineering — is keeping them engaged.

People tell me that, given my background as a developer, I have a key advantage because I can speak developer language. I would say that’s an advantage, but in a different form. The key thing is still keeping them engaged.

There’s a difference between a PM telling everyone what the problem is, tying it to the big picture, and then giving the solution, versus actually engaging the audience. In that first scenario, they’re just hearing it. They’re not being engaged. They might just forget it the next day.

How does your developer background shape the way you work with engineers?

What I like to do is present the problem, but let them dissect the problem and give me their explanation on how they would go about solving it. This is where my technical background is a key advantage because I understand what they’re saying and I can ask the right questions to further dissect the problem. I’m just presenting the problem. I have an idea of how it can be solved, given my technical experience. But I let them explore the problem with me and give me their perspective on how they would go about solving it.

This can lead to other discussions like architecting an appropriate solution, how to further innovate, and so on. Then I can tie it back to the original problem we’re trying to solve. Again, it’s about keeping the audience engaged — where the audience, in this case, is the team that’s working on the problem.

What drains early excitement — and how to rebuild it

Building something new usually starts off with an initial spark of excitement. In your experience, what’s the most common thing that drains that early energy?

What usually kills that initial excitement are two things: any drastic changes to the goal that we’re working toward, or if we’re not making any progress.

For drastic changes, those things are out of our control. Sometimes they just happen. But to keep everyone on track, keep the momentum going, and keep everyone energized, it’s about sticking to our roots — explaining the big problem and why we have to make changes. You have to practice effective communication. Then the team can judge for themselves whether these changes are out of their control or something that needs to be done for financial reasons or other purposes.

A real-life example was back before COVID, when I was working at a biotech firm. We built a database management solution for big clinical companies. Everyone was excited. But we built an on-prem solution. Then COVID hit and there was a dramatic shift in the market where everyone was demanding cloud solutions.

Many features we created from scratch that depended on an on-prem infrastructure became obsolete. We did all this work and everyone was happy, the hard work paid off, but in the end we couldn’t do anything with it. That was a case where external forces out of our control derailed the project.

What do you do when months of work suddenly feel wasted?

I always paint the big picture. At the end of the day, we are employees at a company and we want to do what’s best for the business. In that case, I framed it as, “This is where the money’s at, so we, as a company, have to chase the money. We can be the first to build this.” We kind of had a moat — we were like early Salesforce for clinical data management solutions, where we were the only ones doing it. So I inspired and motivated my team by saying, “No one else is doing it, we can be the first ones, and we can capture a wider market.”

Keeping this momentum train going by telling them what the goal is, and why we’re working toward that goal is, in my experience, the best way to keep people going. If they know their work is part of a bigger goal, they work happier and harder.

Navigating disagreement and building shared investment

Sometimes a team member doesn’t like an idea but still needs to work on it. How do you get someone who disagrees with a direction to still feel invested in building the best version of it?

There are three types of problems. For this, I’m going to ignore the first type: human conflict. Someone not getting along with others is something else.

The other two types are more straightforward. The first is when someone doesn’t want to do something in the way it was planned. There’s a problem, we have a solution, and they’re working on a certain aspect of that problem, but maybe one developer wants to implement it one way and another developer wants to implement it another way. This is very common. What I usually do is hear both parties out. It’s not a matter of choosing the best one; it’s choosing the one that’s the easiest to achieve.

Another thing I do is always deliver solutions in phases. Maybe developer A wants to do it one way and developer B wants something a little different, but it’s more involved. I say something along the lines of, “We’re trying to deliver this by the end of the year, but we’re not stopping after that. We’re going to continually improve it.” Phase one is the MVP we deliver this year. Phase two is a more polished and improved product.

The third type of problem is when we have a goal, but a developer wants to do something that’s an extreme variation of the goal. Unless there’s really good justification, most of those get shut down because they drastically change the end result, and then we have to go talk with stakeholders and get more information. In those cases, I have to further dissect the problem and understand why they want to do it that way.

Do you have any exercises or rituals that help teams identify opportunities to improve existing products?

Prior to starting a project where we’re creating a platform, not just one feature, I create a report where I identify how others are doing it and tie it to the problems associated with it. There’s also a phase where I’m working with customers who are using legacy products or features to understand their pain points. I create a report on the pros and cons of the existing legacy product or features.

From there, I have a discussion with the team to get insight on their end. For example, when talking about legacy features, we identify the pain points and discuss how we can resolve them or make them better. And we go from there.

Hiring for the ability to inspire others

When you are hiring PMs or developers, are there any specific signals you look for that tell you somebody has the ability to inspire and engage others?

Every time I’m interviewing another PM, I look at the way they’re communicating. I want someone who gives me the big picture — the context, what the problem is, how they approached it, and what the end results were.

So when I’m interviewing PMs, I look for that. Not a yes-or-no answer, but someone who gives me enough context and keeps me engaged. They’re telling me a story about the question I’m asking. That’s what we want, because when a PM is presenting a problem on the job, they have to be thorough and give the full picture.

A small change with a big impact on motivation

What is one small behavior change you’ve made as a leader that has had an outsized impact on your team’s motivation?

Before, I was very direct — this is the problem. The slight change I made was always giving the “why.”

Back when I was a developer, I had a lot of managers. They were all good managers, but there was one particular manager who always gave me the big picture. They would always answer the why. Why am I doing this? This is the project, this is the rationale.

So that’s the small change I made. Every time I’m talking about a new project or problem, I always give the why: why this needs to be done. Just knowing the why motivates people. They feel like they’re doing something that has an impact.

Do you see that ‘why’ as giving people a deeper sense of purpose?

Exactly. Going back to my personality, I need to know why I’m doing something to give it my all. I feel like that’s universal. As long as people have a reason for why they’re doing something, they’re working toward something. Unless you’re lazy, you make sure it gets done, and it’s hard to be lazy when you have a career because you’re getting paid to do it. Having the rationale of why you’re doing something and the impact it has on a wider audience makes it more authentic.

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, Chad explains how Simon is reshaping omnichannel shopping in malls through a unified physical-digital ecosystem, highlighted by the new Simon+ loyalty program. He describes how his breadth of experience from his generalist career path spanning development, UX, marketing, and product helps him manage scope, spot risks early, and build real cross-functional buy-in. Chad also shares how Simon validates consumer experiences across various properties and shopper types, tailoring testing and personalization by channel and center-level personas.

Working in digital convergence

Throughout your career journey, you’ve worn several hats, working in frontend development, UI/UX, and, now, product. How has that broader background been helpful in your current role?

The concept of digital convergence is big for me. We all use websites and apps daily and get to see what works and what doesn’t in blended physical-digital experiences. As product leaders, our goal is to deliver something seamless with the right feature set. Success comes from the ability to design a product that meets unique user, or in our case, shopper and tenant, needs across all channels. Having a diverse career journey has helped me pull the right experiences forward for use today. Having worked in frontend development, I can “talk the talk” when it comes to establishing tech requirements through a product lens. I can put myself in other people’s shoes, and that’s been super helpful.

As someone with a “jack of all trades” career path, you learn to effectively manage scope and win buy-in across wide stakeholder groups since you’ve been part of so many of them. This doesn’t always come easy in complex organizations where there are deeply rooted business rules and context, but over time, I’ve learned to offer a grounded perspective that factors in the many needs of a product. Each functional marketing area is going to need support in a different way. The ultimate stakeholder for our products is the end user, but it’s just as important to keep comms wide open across the entire business or else our growth tactics will ultimately fail.

That prior experience helps me catch things early on that others might miss. This could be technical challenges that need legal vetting or identifying media impact before rolling an anticipated UI/UX change. I’d encourage entry-level product people to raise their hand on as many peripheral tasks to their work as they can to gain this type of experience. Even better when the tasks are outside of their area of expertise.

Do you find that the best product leaders come from a generalist background?

Not necessarily, but I think it might help. I think this is highly dependent on the org structure and products the PM is working on. Having an eagerness to learn and get exposure to different areas of the business will create better product leaders. Coming onto a team in a junior product role, one might think there are rigid frameworks to follow, but after almost 15 years in the digital space, I can confidently say that most of it is fluid. It is easier to navigate complex problems when you have a diverse digital background.

We also collectively benefit from product people who deeply focus on one area and that really comes down to the product org and how niche a product is. I would imagine some fintech and other highly regulated gov spaces benefit from prioritizing niche expertise. My own personality and style of work lend much better to the idea that I can go learn something, add it to my arsenal, and then move to another critical area where I’m needed.

Thinking like a generalist

How does your ability to put yourself in other’s shoes benefit end users?

It bleeds into the product in a good way and really benefits all marketing channels. When we look at mobile apps, websites, or physical space solutions, it’s critical to be on the front lines receiving both customer and internal feedback, grounding decisions in data. I think having experience in multiple functional areas serves well when working at the rapid pace of today’s digital expansion. It also acts as a good hedge against any myopic or group think patterns. Go get the buy-in across all business areas, leverage peer expertise, and translate that to the ultimate customer experience. If you come straight in without doing the groundwork to understand other’s needs, you won’t have a well-informed perspective.

Is there an example you could share of a time where you were able to identify a blind spot or a risk that someone with a narrower background might have missed?

I’ve been involved in some major re-platforming decisions that had heavy agency involvement. Agency recommendations are valuable but it’s critical to test out alternative viewpoints that are grounded in perspective from those inheriting long term maintenance of a platform. I try to read the tea leaves and identify biases for a particular recommendation. I think this approach goes without saying, but it’s honestly surprising how often I’ve seen recommendations go unchallenged without proper due diligence.

Rather than get too caught up in the product or tech decision at hand, I try to take a step back and collect feedback from peers. When it comes to re-platforming decisions specifically, as a good leader in that space, you want to get the answers from all functional areas that are using a platform and build strong, formulated opinions.

In a previous role, I challenged a major multimillion-dollar decision to shift to a new agency-recommended DXP/CMS. The initial decision was driven by a desire to consolidate all tech under a top SaaS provider, but we hadn’t fully teased out the pros and cons. I did research in each functional area and had strong conviction to offer up a dissenting POV. The new CMS would have provided great platform consolidation and helped with advancing headless content architecture, but we were not at the stage to deploy that content across our existing marketing channels anytime soon. We would have been left with a hefty price tag for something we’d only begin to realize gains on in 1-2 years. This meant taking a step back and staging our SaaS expansion in crawl/walk/run phases. We would still move in that direction but scale appropriately with a proper roadmap.

Since this was in a martech-heavy role, I might have defaulted focus on the technical stack, and most certainly would have come up with a better architecture, but we wouldn’t have been ready to use it in any meaningful way. My previous experience as a homegrown CMS business user and UX designer, meant I had built templates and taxonomy in the past and had a unique perspective that ultimately drove a better product decision. I can contribute most of that knowledge to past experiences wearing many hats.

After you communicated your concerns and advocated for considering other options, what was the course of action?

In a way, it opened an internal think tank. We pulled together a working group of individuals who hadn’t been heard. We went below the executive level steering committees and collected feedback from the lower/middle rungs of critical functional areas. Once I got the necessary feedback supporting an alternative viewpoint, I packaged it up for leadership. The working group helped us gain a better understanding of what was involved for the hands-on knowledge workers doing the work and helped us realize that we needed stronger representation across the board.

Testing across different customer segments

Product, like many functions, has certainly been affected by AI. What advice would you give to folks who are at an earlier stage in their careers and may be concerned that their expertise won’t be valued?

We’re in a very delicate time. I augment my work with AI tools, but still have daily questions about what is good AI practice for today vs. a few years down the road.

I’ve seen many alarmist narratives about AGI taking tech and product roles, but what I’ve seen myself and through feedback from other tech peers, is that AI tools are not ready to do the critical thinking. Our obligation is to experiment with and augment our work with these new technologies where it fits well. A good approach is to ask, “How can I cut 10 or 20 percent of my time that’s currently being spent on admin tasks and get time back to create value in our product?”

That seems to be the lowest-hanging fruit. The advent of agent building, SaaS admin agents, and the wealth of knowledge one can gain through copilots is exciting. I think agent orchestration is the next big thing in the product space but needs a little more time to mature. There’s been a rush by big tech to deliver the tools, but I still see lots of limitations in my own AI workflows. That being said, amazing connector products are being rolled out every day, and I do think this means we can spend more time creating and ideating vs. just managing a book of ever-expanding SaaS platforms.

My advice to a junior product manager would be to raise your hand, experiment, and be thoughtful about communicating to leadership about where AI is helping and where it is not. There is a lot of pressure to use GenAI or risk getting left behind but not all use cases are production-ready and that is perfectly fine. The key, I think, is to find spots where AI tools do good work, like prototyping UI before it gets to development or helping with requirement gathering. I would 100 percent recommend using those tools today. Figma and Notion’s AI products have been a huge help in this space.

Simon has been a mall operator for over 65 years. At a high level, how do you think about providing a consistent experience across the whole digital footprint, from websites, apps, or mall kiosks, and also meet the unique needs of each use case?

I think all digital teams face challenges when delivering across so many marketing channels. We all saw companies struggle to adapt when forced into the digital space during COVID, but that’s never been the case for Simon.

Simon has put the shopper first, both in physical and digital space well before the biggest loyalty and digital-first pushes have happened. There is relentless focus at Simon to meet the shopper where they are and offer the best incentives, whether in-person at one of our centers or through our web and app experiences. The concept of digital convergence and omnichannel excellence is at the core of all our decisions.

We have always driven strong in-store shopping and brand awareness through our data-enriched websites, app, and digital directories, as well as through Simon Search, which lets shoppers browse products online or through onsite directories, to quickly and easily find what they’re looking for, both in-store and online. This robust channel development helps us cater to every shopper persona.

This year we also launched Simon+, a first-of-its-kind loyalty program delivering rewards wherever they shop with cash back, points and perks for shopping at Simon centers or online at ShopSimon.com. The program has a simple, always-on platform where members can access exclusive offers, receive cash back and points for qualifying in-store and online purchases, and unlock curated rewards. This new program is designed for today’s modern shopper.

To deliver a unified message to shoppers across online and in-store shopping experiences, we focus on our user feedback loops and leverage best-of-breed session recording and analytic tools. We have a good pulse on the Simon shopper, but keeping an active check on a user’s digital vs in-store affinities is critical. It’s sort of a push-pull. What works on one channel doesn’t work everywhere, so we are very thoughtful and intentional about our approach. For example, we recently underwent a redesign to simplify the UI and UX on our digital directories at each center.

The user journey on the touch-screen directories in centers now prioritizes quick search and browse actions with minimal touch or typing required. The UI/UX decisions came from in-person testing and frequent iteration based on our event-driven analytics layer. The filtering needs and use of critical UI real estate will never be the same compared to our web/app experiences. We took our strong underlying center and store taxonomy and reduced the features and content accordingly without sacrificing relevancy.

I would imagine that the shopper personas for individual stores within a Simon property can be quite different. How do you approach testing those different customer segments?

We can derive good insights from a given shopper segment and link it back to a shopping story rooted in the specific center they’re visiting. Simon properties range from regional malls to luxury shopping destinations, so it’s not one size fits all. That means our product strategy must be highly adaptable.

There’s a wide range of shopper personas, and we try to meet each one where they are through personalized offers and content. With a deep analytics layer using an event-driven architecture and a healthy amount of business rules, we deploy template-specific changes depending on the center and store to account for shopper preferences and demographics. We still need to be thoughtful on the strategy side, but deep segmentation capabilities are now available and in use in an automated fashion within our SaaS platforms.

Analytics doesn’t always provide the complete picture, though, so leaning into qualitative feedback and user testing is key here, especially in a scenario such as anonymized users interacting with our digital directories.

Redefining omnichannel and loyalty programs

Simon recently introduced the Simon+ loyalty program. Could you describe this omnichannel loyalty program and explain why it was developed?

Yes, of course! Simon+ is unique because it offers our new loyalty program that brings cash back, points, perks and exclusive offers both in-center and online at ShopSimon.com. We pull it all together into a frictionless experience and have such diverse rewards, which means every shopper has something to love. Who else offers points, not just for retail purchases, but also for food court visits?

With Simon+, you can earn cash back, points redeemable for rewards, as well as exclusive offers from 500+ of your favorite brands. To me, this is what omnichannel success looks like. There’s no fragmentation or need to use multiple different apps to feel like you’re getting the best deal. If you were already planning a trip to one of our premier shopping destinations, why not save money in the process?

As use of the Simon+ program scales up, our engagement data, and peripheral Shop.Simon.com marketplace and Simon Search aggregate data all feed into better recommendations for our shoppers. We’re going from scheduled to real-time activation.

As you think about the next phase of digital growth for Simon, are there any particular technologies or integrations that you view as critical for scaling and growing even further?

We are focused on platform-driven personalization since there are endless possibilities there. The foundational work we’ve done allows us to serve dynamic customer journeys based on user preferences and actions.

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.