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

How AI is reshaping the product lifecycle

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

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

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

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

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

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

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

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

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

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

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

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

From opinion-driven to AI-powered product development

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Evolving with the PM role

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

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

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

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

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

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

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

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

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

What does LogRocket do?

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

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

Product management in the media industry

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

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

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

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

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

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

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

Bridging product and editorial teams

How do you speak about the product?

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

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

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

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

Balancing different departments and media channels

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

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

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

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

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

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

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

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

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

Leading lean teams as a product executive

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

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

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

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

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

Ethical considerations in journalism

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

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

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

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

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

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

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

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

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

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

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

What does LogRocket do?

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

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

How AI is redefining product management

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

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

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

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

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

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

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

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

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

The new expectations for product managers

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

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

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

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

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

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

Leadership lessons from the US Navy

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

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

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

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

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

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

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

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

Staying relevant as technology changes

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

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

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

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

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

What does LogRocket do?

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

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

Balancing data with human judgement

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

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

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

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

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

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

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

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

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

Making decisions in cross-functional environments

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

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

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

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

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

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

Servant leadership in practice

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What does LogRocket do?

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

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

The unique power and complexities of marketplaces

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

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

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

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

Measuring durable network effects

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

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

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

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

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

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

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

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

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

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

Technicality and complexity in digital marketplaces

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

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

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

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

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

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

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

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

Where AI comes into the arts

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

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

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

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

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

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

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

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

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

What does LogRocket do?

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

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

Developing products across global and regional markets

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

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

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

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

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

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

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

From project management to product leadership

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

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

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

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

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

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

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

Effective change management and leadership

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

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

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

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

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

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

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

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

Designing for diverse users at scale

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

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

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

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

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

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

Driving a product mindset inside organizations

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

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

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

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

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

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

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

What does LogRocket do?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Knowing when to shift from intuition to data

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

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

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

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

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

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

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

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

Building the right team for 0→1

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

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

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

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

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

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

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

Protecting innovation inside large organizations

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

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

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

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

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

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

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

The biggest mistakes and what to avoid

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

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

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

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

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

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

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

What does LogRocket do?

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

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.