AI has made building faster and cheaper than ever. That leaves product leaders with an uncomfortable question: if engineering isn’t the bottleneck anymore, what is? And do we still need product managers?

Today’s guest has a clear answer. Naomi Lariviere is Chief Product Officer at ADP, where she oversees a roughly $4 billion mid-market portfolio for a company that pays one in six Americans. Her career path is unusual for a CPO: she started as a business systems analyst in financial services, then stepped away from product to run an IT PMO, professional services, and even pricing and sales ops before coming back.

Her take: much of the PM job over the past decade drifted toward tickets and standups instead of customers and markets. AI is finally a chance to hand that work off and get back to the real job.

In this episode, Naomi shares:

• What happened when ADP’s dev team tried to deliver without a product team, and why they came back

• How ADP studied what its PMs actually do all day to find the busywork AI can take off their plates

• Why she’s skeptical of the push to turn every PM into a product builder who ships code

• How ADP keeps innovating when a single mistake could mean thousands of people don’t get paid

  ---

1. The experiment: Shipping without product

At ADP, the question of whether product was still necessary didn’t stay theoretical. When the idea came up that product could be eliminated, Naomi handed the dev team the challenge and told them to figure out how to deliver something on their own.

It didn’t take long for the gaps to show.

“Ultimately we ended up, ‘Oh, wait. We need the product person to tell us, like, well, what are the rules? What is the compliance regulation?’”

Naomi’s explains why this happened:

“AI makes building cheaper, but it doesn’t make choosing things any easier.”

Product takeaway: Speed without direction isn’t progress. As AI compresses build time, the scarce resource becomes knowing which problem to solve, under which constraints, for which customer. If your org is debating whether product is still needed, the fastest way to answer is to look at what breaks when nobody owns the rules, the regulations, and the “why.”

2. How PMs got “Scrumful, not Agile”

Early in her career, Naomi spent her time with clients and prospects, doing market research and studying the competitive landscape. Then Agile arrived, and the expectations quietly shifted. PMs were now expected to write every requirement, run the backlog, and direct each sprint.

The cost of that shift was everything PMs stopped doing:

• Talking to clients

• Understanding the market

• Reading the macroeconomic picture

And that’s exactly why AI looks like a threat to some. If the job is writing PRDs and user stories, AI can do it.

But that was never the actual job:

“What product actually is doing is synthesizing multiple inputs and then going, ‘Here’s the best opportunities that we have to solve a problem, and here’s the ones that are gonna make you money.’”

Product takeaway: If your team’s value is measured by how well it runs ceremonies, it’s vulnerable. Look honestly at where your PMs’ hours go. Process should exist to drive decisions, and every recurring meeting should earn its place by unlocking one. Three standups across three teams is busywork, not product management.

3. Innovating when a mistake means someone doesn’t get paid

Startups can push code multiple times a day. ADP, with over 1.1 million clients, operates with much higher risk. They pay 1 in 6 Americans, and as Naomi says:

“When you think about somebody’s pay, they could be counting on that check to make their rent or, you know, pay for a vacation, or they’re getting married and they need to put a deposit on an event space. You know, if we do something that means they miss that, that is, that’s not okay.”

That doesn’t mean ADP doesn’t move. It means it moves deliberately:

“We innovate actually all the time, but we do it very thoughtfully and in a very controlled fashion.”

Product takeaway: “Move fast” isn’t a universal virtue. The right release cadence depends on the cost of being wrong for your users. In high-stakes domains like payroll, finance, and healthcare, the product team’s job includes keeping the user’s real-world consequences at the center of every innovation decision, and building the controls that let you ship confidently.

4. Product managers, not product builders

There’s a growing push to turn every PM into a builder who ships code with AI. Naomi thinks that misreads what the role is for.

“Yes, I do know how to code, but do you trust me at launching feature and functionality into a platform like one of ADP’s? Probably you shouldn’t do that.”

The skills that actually make a PM effective are the ones that coding doesn’t touch. Interviewing a client without introducing your own bias. Understanding what pushes someone to buy. And above all, telling the story:

“When someone asks me what would be the one surprising thing about my job that most people don’t understand, it’s the storytelling, it’s the influencing that we do. And, you know, coding doesn’t help me do that.”

Naomi does expect roles to become more fluid, but she wants developers doing what they’re great at and product people doing what they’re great at.

Product takeaway: Before requiring that every PM become a builder, ask what you’d lose. The PMs everyone in an org seeks out, from sales to engineering to execs, are rarely the best coders. They’re the ones who read the room, carry empathy for the user, and articulate why something matters. Protect and invest in those skills; they’re becoming the core of the job.

Chapters

00:00 Introduction
02:24 Naomi's path from business analyst to ADP product leader
04:19 Is AI the end of product management?
06:12 AI makes building cheaper, not choosing easier
08:22 How product teams became "Scrumful, not Agile"
12:58 Why ADP has to innovate carefully at its scale
15:32 Process with a purpose vs. process for its own sake
17:30 Should product managers become product builders?
20:22 ADP's jobs-to-be-done study of the PM role
22:13 Fluid roles and why less technical PMs can deliver more
25:43 Storytelling, empathy, and the human skills AI can't replace
28:23 Conclusion

Links

• Naomi’s LinkedIn

• ADP

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.

Every product team is shipping AI. But for many companies, very few users are adopting it. The people who try the feature love it, and adoption stalls anyway.

Charanya Kannan thinks that’s because teams obsess over building AI and barely think about adoption. As VP and GM of Navan Anywhere, she puts Navan’s AI travel and expense tools inside Slack, Teams, and Gemini, where people already work, instead of asking them to open yet another app. She joined Navan when it was still called TripActions and doing under $50M in revenue. Now it’s well on its way to $1B!

Her core belief: if customers have to work harder to use your AI, it isn’t actually better.

In this episode, Charanya shares:

• How Navan Anywhere was built distribution-first, bringing booking and expenses into the tools people already use every day

• Why Navan’s margins went up in the AI era, while the rest of SaaS braces for compression

• And why she believes PMs who mostly manage process and Jira tickets will fade away, while those who can actually drive user benefit and business outcomes will matter more than ever

1. Building is easy. Getting users to adopt is the real problem.

These days, you can create an AI prototype in about a weekend. But getting anyone to actually use it? That’s where most teams get stuck.

Charanya’s fix is to skip the “please come try our shiny new thing” step entirely. Navan Anywhere lives inside Slack, Teams, and Gemini, where people already spend their day. They don’t have to download a new app or form a new habit because, as she says:

“If they have to put in extra effort to do something because AI is superior, then AI is not really superior.”

Product takeaway: Plan for adoption as you plan the feature. The easiest product to adopt is the one that shows up where your users already are.

2. Not everything needs to be a chatbot

Six months ago, Charanya told her designers to start brushing up on evals, because chat was going to eat everything. Then users actually tried picking a hotel from five paragraphs of text. It turned out that people booking hotels wanted to see photos of the hotel.

So, Navan mixes and matches. Chat handles the “here’s what I want” part and the UI handles the “let’s compare” part, while payments stay firmly on the reliable deterministic rails.

“The real judgment or discernment is: Where do you bring in AI? Where does it make sense to bring in your agentic systems versus where do you fall back to your deterministic systems?”

Product takeaway: “AI everywhere” isn’t a strategy. Use AI where it removes friction, use UI where people need to see things, and be skeptical about AI related to anything that moves money.

3. The two kinds of PMs & why nobody’s irreplaceable because they write great Jira tickets

Charanya has mentored dozens of PMs, and she sees two types: Those who spend their days running standups and shuttling messages between sales and engineering, and those who ask why the team is building something at all, and whether it’ll still matter in five years.

Only one of those jobs survives the AI era.

Navan runs a travel business doing over $3B in bookings with fewer than five PMs, and engineers write a lot of their own tickets.

“Everybody knows there’s a problem, but how do you frame that problem? Give the problem eyes and ears and a figure that people can go after and solve it… If you’re just thinking about processes 80% of your time, that’s not what we want.”

Product takeaway: Process should be about 20% of the job. If it’s 80%, AI is coming for that part first.

4. How Navan’s margins went up in the AI era

While most of SaaS is sweating over inference bills, Navan’s margins are growing. The trick is letting AI do what it’s good at: it now resolves about half of support conversations, up from a third back in the pre-LLM days.

The truly messy stuff still goes to human travel counselors.

“When you’re stuck in a plane for five hours on the tarmac… no AI can come and solve the problem for you.”

Product takeaway: Let AI handle the repetitive stuff, save your humans for the hard stuff, and treat your model choices like the budget decisions they are.

Chapters

00:00 Introduction
04:17 Why AI features don't always get adopted
06:30 Building Navan Anywhere distribution-first
10:13 When to use AI vs. deterministic systems
12:01 Conversational cognitive load and why good UI still matters
15:57 Evals, distilled models, and the AI reliability pyramid
20:14 Product owners vs. product managers in the AI era
26:10 How Navan is growing margins while SaaS faces AI compression
31:40 Conclusion

Links

• Charanya’s LinkedIn

• Navan

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, Angélique shares the three principles she returns to when designing for the underserved and never-before-served: education, simplicity, and support. She talks through the assumptions that trip up well-intentioned product teams, the community events that replaced traditional user research, and a security feature that tanked adoption the moment her team stopped thinking from the user’s point of view. She also dives into what it’s like building EliseAI’s first B2C product inside a B2B company and where AI belongs in a support experience built for people with the least room for error.

Building for the underserved

Who are the end users you’ve built for at Nubank, Comun, and now EliseAI?

In the first part of my tech career, at Nubank and Comun, I was building for end users who were new to financial services and digital financial services. These were people who were getting a credit card or a bank account for the first time, or sending a remittance to a different country for the first time, or who were unfamiliar with using apps for banking needs. At Elise, I look after the experience of those going through the experience of finding a home, which is, I’d say, equally critical as financial services.

Here, it’s making this experience intuitive for the full spectrum of end users. This could be affordable housing applicants who are going through the Elise flow for the first time trying to apply for a home, or who have never used technology for any of their housing needs. Their needs are similar — both are going through a highly stressful moment in their life where they’re sending money to someone, getting a loan, applying for an apartment. It’s been a nice thread in my career, building for that subset.

Comun was specifically focused on undocumented immigrants. It was a digital bank for undocumented immigrants. It served everyone, really, but because the product enables people to get a bank account without a Social Security Number, it particularly catered to undocumented immigrants. The app was also fully in English and Spanish, so it catered even more to Latino undocumented immigrants. At Nubank, back in Mexico City, they were predominantly people from Mexico but who had never had a bank account before and previously were maybe saving under their mattress, and for the first time wanted to use more formal financial services.

Three guiding principles: Education, simplicity, and support

What principles matter most when you’re designing for users with limited experience or comfort with technology?

Typically, I always keep three principles in mind when I build for this type of end user.

The first one is education. I don’t assume any prior knowledge of the product. This could be explaining how interest rates work on a credit card, which you and I would know, but that’s not at all intuitive to someone who’s never owned a credit card before. Or being transparent about how income requirements work in housing, like someone submitting their income and not understanding why they’re below certain thresholds. Things like linking FAQs, educational videos, a UI wording that is educative is very, very important.

The second one is simplicity. Less is more. The UI needs to be really simple, straight to the point. I always try to make sure we minimize the amount of screens to complete a flow, that the browsing is simple, that every step is over-explained in simple terms — again, not assuming that this person has ever gone through a flow like this before.

The third one, which I think is really important and often overlooked, is support. I’ve done a lot of support work also in my career, so it’s very important to always give them a way to reach out for help. The first layer of support is increasingly AI, obviously, but they should never be stuck in the loop of either the technology not being able to help them, or not knowing where to look for help. This is very important, that there is an option for support, AI or human.

Where product teams go wrong

What do product teams tend to get wrong when they design for users whose financial circumstances, language skills, or digital literacy differ from their own?

This is one of the most surprising aspects of building for low-income or low-tech-sophistication users. Across teams that I’ve led and worked with, I always see two assumptions that people repeatedly make. The first: we tend to assume a lot of previous knowledge about a product or process, and someone who’s never used technology before, or is new to a system, a country or a process, may not necessarily know. One example is when applying for an apartment, what is a guarantor? When I moved to the U.S., I wasn’t familiar with what that meant, why I needed it, what they needed to show — whereas that’s a very intuitive concept for anyone who’s applied for an apartment previously. Never assume previous knowledge.

The second: teams assume a level of trust in technology that isn’t actually adapted to the realities of the end user. There’s a political scientist I really like called Francis Fukuyama, and he writes about low-trust and high-trust economies — how certain countries or communities operate in a fundamentally low-trust environment. Their trust circle is smaller; they tend to distrust larger organizations, institutions, new technologies. But people working in tech inherently trust tech. They don’t necessarily think that if you’re asking someone to input their bank information on a mobile, this person is going to think they’re being scammed, because that’s not going to be their first intuition. But that is the first intuition of a lot of people living in lower-trust communities, in which they often get scammed, for instance. The credit card is an obvious one — there’s a lot of social proof that we need to build to increase product adoption. In FinTech there’s a lot of things we can do. I think in housing as well, there’s a lot of things we can do to build trust, but that’s very often overlooked.

Can you walk us through a product decision that changed once your team better understood how the user was actually navigating their experience?

One example from one of my previous jobs is that we wanted to make the bank account connection more secure. We wanted to enable people to connect their primary bank account so that they could pull the money from the other bank account and then make payments. One way of doing that, which is quite common in the U.S. banking sector, is what we call micro verification. It says, “Hey, I sent you two cents on your primary bank account.” Now you go to the primary bank account, you see the two cents, and then you have to enter the amount. Most people working in tech probably have gone through that experience before, using digital banking services. We implemented that, and our product adoption completely dropped. People were very confused. They didn’t know how to use it.

They distrusted the fact that they had to enter their other bank account information. They weren’t sure how to go back and forth from one app to the other. So we had to quickly find another solution: building a very sophisticated risk score, so we’d only add this friction for very high-risk users who may be fraudulent, and find other ways to do verification for everyone else. Most of the undocumented immigrants we were working with — this was their first time using a digital service, and now we were asking them to open three apps at once and do something called micro verification. It just wasn’t viable. For the ones who did have to continue with that process, we also built educational videos — step-by-step, why it’s important, and how long it will take.

Getting inside the user’s world

Is there anything you do in particular to help your teams get in the mindset of the user?

I think user research is really important. There is traditional user research, but there is also non-traditional user research — going to the places where the target user lives and works or applies for an apartment, talking to them, seeing them using apps and technology, understanding what they’re afraid of. It also, frankly, requires a level of empathy that is really important. When building teams that build for the end user, it requires a different and, I think, higher level of empathy to be able to put yourself in someone else’s shoes, in a life that you have never lived and probably will never live.

What have you done to get meaningful feedback when traditional user research doesn’t work?

This is interesting because when I started at Comun, which is the digital bank that builds for undocumented immigrants, I tried conducting regular user research calls. I would reach out to our users and try to schedule a call with them. Friday, 2:00 PM — they would say, “That’s great.” I would send a calendar invite, and then I would connect at Friday, 2:00 PM, and no one would connect. This would happen repeatedly. At first, I didn’t understand why. So then what I tried to do is just call their number, a few different times throughout the day — obviously, only when I had their approval to reach out to them.

I realized that they ended up picking up at different times of the day, and were very happy to talk to me, but they just happened to be in their car commuting, or they’d just gotten home. A lot of them don’t have traditional working hours — different shifts, night shifts, construction sites, cleaning services — and they don’t know where they’re going to work the next day, or what time. So even though they wanted to help and wanted to talk to us, we couldn’t stick to a very specific schedule. What I realized is that what we really had to do is go and meet them where they are, in the spaces where they live, work, or hang out.

At Comun, because a lot of our users were from the Latino population, we would go to local community events and have stands, and talk to people there — “Hey, have you heard of Comun? Tell us more about how you send money back to Colombia. Tell us more, what bank do you use? Do you have a bank, or do you use your husband’s bank?” Because a lot of the time we also realized they share the accounts, for instance. How do they get paid? Those informal conversations, in person and at community events, ended up being the most relevant for knowing what to build and what the pain points were — a lot more than phone conversations, which were very difficult to get.

Designing for high-stakes decisions: Money and housing

EliseAI is a B2B platform for property management companies and you’ve been brought in to build the B2C end user experience for the renter. How do you balance the needs of both, especially when they have different priorities?

This is a very interesting question because there are very, very tough trade-offs between prioritizing B2C and B2B — something I’ve experienced for the first time joining Elise, because it’s the first time I’m joining a company that’s B2B. When working at a company that’s purely B2C, the end user is the client; the revenue of the company depends on whether the end user likes the product or not. That’s very different from B2B, in which we’re selling to businesses, and the client is not the end user. Elise’s platform is built for B2B, so they remain the main client. So when there are very urgent B2C issues, this is always prioritized, because in a way it can also impact our client. If someone misses out on a unit — Elise works with some of the largest property managers in the country, some with buildings in very remote areas — that unit can be vacant for a couple of months. In that way, their issues overlap.

But a lot of the property managers also have feature requests that have no impact whatsoever on the end user. That’s when it sometimes conflicts: should we improve the end user-facing platform, making the flow more educational or simple, or improve a feature within the B2B-facing app so property managers can more easily understand what’s pending on their side? That’s difficult, because the property managers are the clients — that weighs heavily in the prioritization.

AI, education, and trust

When users need to understand things like credit scores, income requirements, or why an application was denied, where should education live within the product experience? And how does AI adoption differ across your end users?

This has changed quite a bit with AI and is still changing. Previous to AI, when I was at Nubank, there was a typical help section, which would have the FAQs, educational videos, and we would use LLMs to maybe customize what FAQ would show up first. We would also link FAQs and videos throughout the UI, which is still something that I try to push teams to do now as well.

But now with AI, the new and better way to do it, in my opinion, is to have an embedded AI assistant that is constantly visible throughout, desktop or mobile. Instead of going to search the help section and having to press a back button and then coming back to the step where they’re struggling, there’s always an AI bubble that’s there, like, “Hey, I’m not sure what that step is, or what ID can I upload? or why is this failing?” And so they have a personal assistant that’s helping them throughout the process. Another interesting thing to explore too is other channels outside of the product — WhatsApp works very well for some communities. If they submit a support ticket in the app, or they’re talking to the AI and they exit the app, they just won’t go back to it. On WhatsApp, they actually respond immediately.

It’s a mix. The trust issue is definitely there, but what’s interesting is that even when we have humans responding, we are now being asked if it’s AI — the humans also have a certain tone of voice. It’s hard now to differentiate when it’s a human or when it’s AI. I would say for lower income populations, or even immigrants who don’t necessarily speak English well, long texts don’t work at all. So it’s either a short text, or some of them want to call. What I’ve done in the past is making sure we send videos — a series of how-to videos on YouTube — so when someone’s like, “I still don’t understand, that’s too long,” we just send a link, and then they get it that way.

My philosophy when it comes to support is that they should never be stuck in a loop of no help. So we have a support team — now at Elise it’s 7:00 AM to midnight — where if the first layer of AI is not able to help solve the issue, it escalates to a team that is trained to respond to those questions.

How do you apply your guiding principles—education, simplicity, and support—when deciding between using an AI assistant versus keeping a human in the loop?

Education is educating the AI to use an educational tone. I actually feed the AI a tone of voice, which is the same one that I use to train the support team: empathetic, straight to the point, avoiding extra words so that the text is not too long. I literally have dos and don’ts, such as do not say, “Hi, thank you so much for contacting us.” No, it’s, “Hi, I saw that this is your issue. This is how we’re going to solve it. This is what you can do next,” in a very empathetic tone, but we don’t want three paragraphs. So it’s training the AI to be educational, and even the prompt assumes no prior knowledge, and explains in a simple, straight-to-the-point way. That also works for simplicity and support. The AI needs to be escalating when it doesn’t understand or it’s not able to help the user, instead of hallucinating or giving answers that aren’t there.

Even though it’s the same underlying technology, the prompts we use for AI responses to B2C users are completely different from the prompts we use for our B2B customers or our internal tech team. The knowledge is different, the guidance is different, the prompts are different.

As AI moves into essential services, how do you make sure it removes barriers rather than creating new ones?

I think the knowledge feeding the AI is really crucial to make sure AI is an enabler rather than a barrier. This technology is very, very powerful and we can model it however we’d like. The type of knowledge that educates the user is truly important, so that it becomes an educational tool, rather than something that’s confusing or making it even more complex for them to understand.

I also think about enabling AI to decision, as opposed to just a chatbot. AI can make faster decisions. So once it takes action, it contributes to removing barriers, which are actually often human bottlenecks — like decisioning on an application or on a credit card, or making personal information changes to a bank account that a bank clerk would otherwise make, or a few hours waiting at a bank branch. The speed of AI itself can remove barriers rather than creating new ones. And, obviously, we need guardrails in place. Having a very strong product QA in place is really important — I always have a team doing product QA and human QA. And we always have a way for the end user to escalate any issues, so that if the AI isn’t being an enabler and rather is being a barrier, we can catch that and iterate on 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.

Most of the AI products getting hype right now are built for people like us: the tech industry. But your customers don’t care how the AI works — they just want their problem solved in a way that’s easy for them.

Brian McMullin, SVP and Head of Product at Network Solutions, has spent 15 years building for small businesses at companies including HubSpot, ezCater, Wayfair, and SamCart. In that time, he’s yet to meet a business owner who wakes up thinking, “I can’t wait to use AI today.” For many of them, a prompt box might as well be a terminal window.

So his team doesn’t ship the box. They ship the finished work artifact, and all the user has to do is claim it.

In this episode, Brian shares:

• Why doing the work for small businesses first, instead of handing them an empty prompt box, is what gets them to try AI

• His warning about baking inference into the core of your product before token pricing settles — and the two models he’s testing to find out what small businesses will actually tolerate

• And what SamCart taught him about churn: customers left because basic things were broken, not because features were missing

1. Nobody wakes up wanting to use AI

Brian’s customers get maybe a couple of hours a week for anything that isn’t serving their own customers (marketing, website updates, invoicing, etc.). Nobody in that position is going to spend it learning what a good prompt looks like. So his team skips the box, and even the menu of agents to pick from:

“Rather than showing them the prompt box, or even, ‘Hey, we have these agents, come use a marketing agent’ — we need to take one or two steps further and say, ‘We’ve used this agent to map out your next two weeks of social media posts. Go schedule them, and if you want us to keep doing this every two weeks, turn it on right here.’ Come and claim it.”

The customer’s only job is to approve something that already exists.

Product takeaway: Make the action you want to be the easiest one available. For non-technical users, that means doing the work speculatively and asking for confirmation, not instruction.

2. Proactive AI only works if it’s specific to that customer’s business

There’s an obvious failure mode here, and Brian names it first: if you do the work for someone and make it generic, then you’ve just built a spam machine.

“It can fall flat if it doesn’t feel personal… The tricky part there is what you need to drive that level of personalization is ultimately context.”

His argument is that this is where established software companies have a real edge. Everyone has the same models, but not everyone has years of history about how a particular business actually operates.

Product takeaway: Take inventory of what you already know about each customer that a competitor would have to learn from scratch.

3. Be careful about building inference into the parts of your product people already pay for

Serving one more customer used to cost almost nothing. Inference broke that — and telling a small business that the same outcome now costs more is a hard message no matter how you frame it. This leads to a caution you don’t often hear from someone shipping AI features:

“It’s actually almost a little bit of a warning of how deeply to embed AI into your core product and value proposition. Until we get to more stability in token pricing, the more you bake it into the core of what you do, the more you’re going to have to figure out how to have a predictable cost structure for your customers.”

Domain registration works fine without AI, so Network Solutions has some insulation. Products where AI sits inside the workflow people already bought have none.

Product takeaway: “AI-native” is a positioning decision with a variable cost attached. Work out which parts of your product would still be worth the subscription with the inference switched off.

4. Nobody has landed on the right way to charge for AI yet

Brian’s team surveyed customers on pricing and found no consensus at all, so they’re running both common models: tiered usage, which risks the problem of paying for credits you don’t use, and a flat monthly price per agent, which puts a paywall in front of something customers haven’t tried yet. Worth listening to his breakdown of the tradeoffs on each. But the sequencing argument underneath matters more than the choice:

“The biggest risk you have is that nobody actually uses the product in the first place. There is a temptation to build complex monetization models and put in tons of limits and over-engineer that aspect before you’ve truly found product-market fit.”

Product takeaway: Strict limits imposed early mostly buy you a smaller sample of the usage data you need to price correctly. Let people use it, then decide what to charge.

5. What SamCart taught Brian about churn

At SamCart, Brian’s team was building good monetization tools for creators, and marketing was excellent at selling them. Then they read the churn reasons:

“None of it was about these new features not driving them revenue. It was about, ‘I can’t get this basic thing to work. I need to add my team and I can’t do that. I can’t connect my payment processor in the way that I want to, and I’m not able to take payments.’”

He also found that customers often buy for optionality and never touch the feature they bought for, which makes the core experience, not the headline feature, the thing that keeps them.

Product takeaway: Retention is a lagging indicator, so argue for core experience work on frequency and breadth of usage instead. In the episode, Brian walks through how he makes that case to a CFO asking for ROI on a login page.

Chapters

00:00 Introduction
02:11 Brian's product journey from developer to SMB product leader
04:05 How small businesses went from distrusting AI to have AI FOMO
07:33 SMBs don't wake up excited to use AI, they want to close the deal
10:05 Stop showing the agent, ship the finished work
13:11 Inference costs break the old SaaS margin math
16:23 Testing free credits and tiered usage with small businesses
18:10 What usage-based pricing does to ARR and predictability
23:51 Churn is a pile of micro-annoyances, not one event
26:29 What SamCart's churn data revealed about broken basics
30:18 Conclusion

Links

• Brian’s LinkedIn

• Network Solutions

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, Abhi talks about what it takes to build instant payments into the core of a customer experience - from identifying the specific moments when speed actually matters to a customer, to keeping the underlying complexity of real-time money movement invisible to the people who depend on it. He shares how Routable rethought its product experience around trigger moments and conversion, the metrics that became essential once decisions had to be made in near real time, and why trust, rather than speed alone, is what keeps a payments product credible.

Rethinking the experience for instant payments

Instant payments aren’t simply a faster version of traditional payments — they change the economics of a marketplace. What do product teams need to rethink once payment becomes part of the customer experience rather than just the first step in a workflow?

Customer empathy is a foundational pillar for our product team, and it’s one of our company’s values. For us, it was: How do we engage with empathy with our customers? We are a two-sided platform in many ways: the businesses sending money and the payees receiving it. What we uncovered was that they want to shorten the loop of earning and getting paid and the instant rails are increasingly in demand to accomplish that quickly.

When we talked to our customers, we found that they were very interested as well, because for them it was a retention lever. It was like, “Hey, my payees and stakeholders need it, and it will help us make them more satisfied and help them close that gap between earning and paying.” We needed to rethink our experience because it was not built for real time payments, and we had to find where the trigger moments were.

There are a lot of payees who are like, “Give me the money, I am fine whenever it comes.” but there are others who are really interested in instant payments. We wanted to capture the group that was super interested and had high intent. The other interesting insight was that there was a segment that was very interested in instant payments on the weekends — maybe they needed the money for a trip and couldn’t wait for Monday. So we realized that there was a group that always wanted instant and others that wanted it situationally at the right moment, but how do we find those moments and trigger the experience at that moment?

We had to think about the customer journey and figure out how to insert the experience, and what kind of experience could help make that choice. It’s almost like a checkout conversion. Once we have that buyer intent, how do we convert that intent into action as fast as possible and close that gap? Those were the two big aspects of rethinking the experience for instant payments.

There has been a shift in the market, too. There was a time when instant payments didn’t have much adoption, there wasn’t as much customer propensity to take it on. But with the new rails coming in — RTP and FedNow, and even stablecoins, we’ve seen a shift in the market in the last 12 to 18 months where instant has become the primary choice for all parties. In the past, the recipient always wanted their funds fast, and that makes sense. But now every party sees the benefit of having instant visibility into transactions. Instant has become a core pillar of our product strategy. We pride ourselves on paying anyone anywhere, including global markets, so having instant payment available not only in the U.S. but in international markets is the core strategy for our business.

What customers actually wanted

Besides the segment that wanted payments faster on weekends, were there other customer needs you uncovered?

From a payee standpoint, those were the two critical insights: There are some groups that say, “I always want it fast,” and the other group was a bit more situational.

One of the things we learned from the businesses was that, for them, instant was both a retention lever and a satisfaction lever. We also saw that instant could be a monetization lever, giving businesses an opportunity to turn payments into a profit center rather than simply a cost of doing business. This is what we are championing with our clients: If you can enable instant and close the gap between earn and pay, then you can drive satisfaction and retention for your payees and also create value for the business.

Balancing speed and trust

FinTech products require balancing speed, risk, and trust. Have there been situations where making a product faster would undermine customer trust, or the other way around?

Trust is our real product. In payments, the businesses we serve value that they can trust us to send the money to the counterparty. The receiving parties trust that we will deliver the money to them. We always strive not to undermine this trust at any point, and we also have to ensure there is no operational complexity.

One of the things we’ve enabled well is what I call a product operations function, which is to look at the product and the needs of the clients post-launch of the product in the market. Many product teams are focused on building the product and launching. But I think the hard work comes after the launch, because that’s when you have to fine-tune the product and make sure it’s operationally viable. We talk about value and viability, and that is what PMs own. Most of the time viability is business viability, and that happens upfront. But if the operational viability for the product is lacking after the launch, it will be very hard to keep the product maintained in the market, no matter how valuable the product is. So we reversed it, and took a pre-mortem approach: What will go wrong, and what do we need to have upfront to make it operationally viable?

We spent a reasonably good amount of time on beta and pilot before going to GA. That wasn’t because we weren’t feature complete, we were feature complete in a traditional sense, but we wanted to build hardened requirements for supportability and operations. So even if one transaction doesn’t get to the intended party, or it’s late or delayed, we can have a remediation with the right tools. It’s all about visibility, having the observability, and then having a remediation action. I have a product operations lead on my team who was super focused on building those requirements upfront in the product build cycle, rather than after the fact.

Leading the cross-functional build

Building products like instant payments requires close alignment across product, engineering, banking partners, fraud, operations, and customer support. What leadership practices become most important for that kind of cross-functional alignment?

One of our key values is “Collaborate to win.” I strongly believe that successful teams have a clear north star metric that everyone is aligned to. It’s about shared outcomes and shared context. It’s easy to say this, but it’s hard to practice. Getting buy-in and alignment is where the real hard work is — communicating it out and getting the buy-in. Once you establish and get that buy-in, execution is smooth.

It takes a lot of upfront hard work to get that shared outcome and shared context. But, the hardest part was getting that alignment, not just with internal parties but with some of the external partners too. Once we got external partners to buy into the north star and gained that alignment, the rest of execution was much smoother.

That must be difficult, too, since regulatory and compliance factors change over time.

Compliance and risk are big for us, so we had those functions participating right from the outset. In fintech, regulatory compliance is part and parcel of the product design. The bigger issue to tackle was focus and prioritization. We took a few cycles to build it, considering the complexity of the product buildout. The real question was how do we keep teams focused and filter out all the noise? This is where a lot of the product leadership role comes in: Make sure your teams are focused, do continuous and rigorous prioritization, and make choices of what not to do, especially saying no to a lot of non-critical product requests, so the team can remain focused on what they need to deliver.

Several of your products, including this one, required building entirely new capabilities rather than extending something that already existed. When you’re creating a new team around a technically complex problem like that, what do you focus on first?

I’m a big fan of product vision north star, aligning the shared outcome and then sharing the context across all teams. That’s a crucial step, especially for a large cross-functional team. The first step is team formation, staffing the right people, this product required a village to build. But the other important part I want to call out is the right process to complement the team — we use this execution framework called Shape Up. It operates on a six-week cycle, and every six weeks you build something that is either demoable or releasable. It’s very different from agile methodology — it’s based on agile principles, but it takes it to the next level.

I want to tie this back to the product operating model: How do you create a truly empowered team? We’ve been working for a while on this concept of empowered teams of engineering, product, and design, that can take a problem, own it, work through the Shape Up methodology to break it down into six-week cycles with clear goals, and then execute on that. Creating the shared context and shared outcomes and getting that alignment upfront, plus the model of empowered teams using the Shape Up framework, has helped us move with high velocity toward the desired outcome.

Data at the speed of instant

Instant payments don’t just speed up access to money — they also accelerate learning about customer behavior, like the insight about weekend timing. How did having those near real-time signals change the way you make product decisions?

With instant payments, you have real-time data. Data-driven is one of the key principles we had, but instant took it to the next level. In a more traditional sense, you could probably get away with looking at data weekly, but in an instant scenario, we had to build metrics and dashboards so that almost at a daily level we are looking at the data and how things are performing. For example, not everyone is eligible for these instant offers, so we want to make sure that we continuously monitor the eligibility and how the funnel is converting.

We get real-time data and make decisions based on it. Our operating model changed to a consumer-centric mode where the data and decisions are real-time. Instant changes that paradigm for B2B. Now you’re in a consumer-centered model where you’re reviewing data in real time, looking at product behaviors and user behaviors, and adjusting levers in real time. Using those levers so we can adjust them in real-time to hit our outcome metrics was a substantial change for us.

You’re analyzing data more frequently. Are there certain metrics that have become more valuable given the shorter payment cycle?

At an overall level, the north star metrics didn’t change. But at a more granular level, we had to enable new metrics. One of which is the eligibility percentage: How do we maximize the percentage of transactions that qualify for instant?

This goes back to the tradeoffs we discussed on risk and compliance complexity, which are being managed through the eligibility criteria. We had to balance maximizing reach while minimizing compliance risk and fraud risk. We had to figure out how to balance them to have high eligibility and low risk.

The second lever was conversion. You may have a high intent, but the intent may not translate into completed action. So how do you close that gap between intent and action? We built an end-to-end metrics funnel, from notification email sent, to email opened, to button clicked, and then to accepting the instant offer. Enabling that funnel conversion metric was a big part of what we accomplished, and we’ve built a culture to make decisions based on this metric.

Owning the complexity

Reducing the time between work and payment is clearly a benefit, but it adds complexity on the technical and operational side. How do you decide what parts of that complexity customers should experience, and which should remain invisible?

One of our core product tenets is to own the complexity, it’s also Routable’s brand promise. We own the complexity so that there is no operational chaos on the customer side. We need to tackle regulatory complexity, fraud management complexity, and experience complexity. So, how do we make all of this simple and almost invisible to both parties, especially to the clients who are sending money? That was the key for us: building an experience that does not require much incremental effort for either party.

We inserted a trigger moment in the payment notification. If you’re already getting these notifications, that’s the right moment to make a choice about changing the payment speed. We had to figure out how to insert an experience that is seamlessly integrated into that notification trigger and doesn’t come across as a marketing offer. That was a core tenet for the experience design.

There was another level of complexity — technical architecture complexity. It’s not just about the payment; with the rails and the experience being instant, and all these real-time signals, the platform had to evolve to support instant money movement. Money movement is now happening in seconds versus minutes, so we decided to build a new platform to support the needs of the experience. That was another complexity we had to abstract away from both parties, we rolled it underneath the experience so it’s invisible to the customers.

You ask about tradeoffs. For Routable, it’s not a tradeoff of convenience and complexity. It’s really about trust - that’s our product. Our clients trust us to pay what is due, and our payees trust us that they’ll get what they are owed. That was something we didn’t compromise on. We won’t make tradeoffs on trust or on compliance and risk, but we will make tradeoffs on our timeline to get us to our goals.

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, Suneth talks about the three-year effort to transform HP’s enterprise platforms from maintenance-mode technology assets into true products — treating internal business units as customers, building a product management practice from scratch, and even reframing compliance itself as a product with its own roadmap. He also shares how that shift helped HP advance its compliance strengths, and how his team decides where AI capabilities should live as build-versus-buy questions get harder to answer.

From technology asset to product

What changed at HP that made the traditional approach to managing enterprise platforms no longer sufficient? What’s the reasoning behind the move to platform-as-product?

Before taking on this role, I had spent much of my career in product development and bespoke software delivery, so I already approached technology through a product lens. When our platform organization came together about two years ago, it quickly became apparent that we were largely managing our platforms as technology assets rather than strategic products.

The conversations were typically centered on operational metrics: uptime, cost to operate, incidents, and service stability. Those are important measures, but they don’t tell you whether a platform is creating business value, enabling growth, or helping the company move faster. In many ways, it was a model I’d seen in other organizations as well.

At the same time, the pace of innovation across the industry was accelerating. Whether it was AI, automation, analytics, or new platform capabilities, vendors were delivering meaningful advancements at a rapid rate. Yet we often found ourselves unable to take advantage of them because of technical debt, heavy customization, or being multiple releases behind. Our business partners would increasingly ask, “If the platform can do this, why can’t we?” That question became an important catalyst for change.

We also recognized that our investment approach was too focused on maintenance and sustainment. What was missing was a strategic roadmap for how these platforms should evolve over time. Reusability, adoption, modernization, and innovation were not being managed as intentional outcomes. As a result, teams frequently had to build capabilities from scratch, increasing both cost and time to value. The move to platform-as-product addressed those challenges. It shifted the conversation from maintaining technology to continuously evolving capabilities that serve the business. Each platform now has a clear strategy, a roadmap, defined outcomes, and measurable value drivers, just as any product would.

When we looked at all of those factors together, it became clear that a different operating model was required. Treating platforms as products gave us a framework to modernize more effectively, accelerate adoption of new capabilities, improve reuse, and align platform investments more directly with business outcomes. That’s ultimately why we came together as a team and why the platform-as-product model became such a central part of our strategy.

Building the product management practice

Can you briefly explain who your customers are on these platforms?

We’re fundamentally an IT-for-IT organization. Our primary customers are our peers across the CIO organization, particularly the value-aligned teams responsible for delivering business outcomes. These teams work closely with functions such as sales, supply chain and finance, translating business objectives into technology-enabled capabilities.

Our role is to provide the platform foundation that allows those teams to move quickly and effectively. We focus on ensuring the right capabilities, services, and products are available so they can build and deliver solutions that drive the outcomes their business partners are seeking.

In that sense, our direct customers are the value-aligned teams themselves. By enabling them with scalable, reliable, and continuously evolving platform capabilities, we help accelerate delivery and reduce the complexity of building solutions from scratch.

Beyond that, there is a natural ripple effect. The value-aligned teams serve the business, and the business serves HP’s customers. So while our day-to-day engagement is primarily with our peers inside the CIO organization, the capabilities we deliver ultimately contribute to business performance and, in some cases, directly influence the experience of HP’s end customers.

That’s why we think of our platforms not simply as technology assets, but as business enablers. Our success is measured by how effectively we help our internal customers achieve their outcomes, which in turn supports broader business and customer success.

So how did you start building the product management practice?

When we brought the organization together, one thing was clear: we needed to evolve how we operated. We had incredibly strong platform talent and deep domain expertise, but product management required a different set of capabilities. The challenge wasn’t the quality of the people; it was creating the structure, skills, and mindset needed to operate as a product organization.

We focused on two priorities. First, we brought in the right leaders to establish and scale a modern product management practice. Second, we built an operating model to support it. That operating model became the foundation for how we worked, how we developed talent, and how we drove consistency across the organization.

A critical part of the journey was investing in the people already here. We wanted to build capabilities from within, not simply hire them from outside. Relying exclusively on external talent creates unnecessary friction and misses the opportunity to leverage the deep institutional knowledge that already exists. As a result, training, coaching, and upskilling became core elements of the transformation.

That investment continues today. We have ongoing learning programs for product managers, engineers, and platform teams, and we work closely with strategic partners to stay current on emerging practices and technologies. More recently, that focus has expanded to include AI-native product management and how AI can enhance product strategy, delivery, and customer engagement.

Ultimately, our approach has remained consistent: bring in new talent and perspectives where needed, while continuously developing the people already in the organization. The operating model ties those two elements together and helps create a sustainable product management community that continues to grow, adapt, and mature over time.

What do you look for now when you’re hiring product managers, in terms of AI skills?

This has evolved significantly over the last 18 months. The foundational capabilities of product management are still essential. We look for people who have successfully managed products, developed strategy, worked closely with customers, navigated complex stakeholder environments, and consistently delivered business value. Those fundamentals haven’t changed.

What has changed is the expectation around AI. We now look for product managers who understand how to leverage AI-enabled tools to amplify their effectiveness. It’s not just about working faster; it’s about making better decisions, conducting deeper research, uncovering insights more quickly, and improving the overall quality of outcomes. Product managers today have access to capabilities that simply didn’t exist a few years ago, and we’re looking for people who know how to incorporate those tools into their day-to-day work.

The second area we’re increasingly focused on is what we call the full-stack builder. This is an evolution of the traditional product manager role. In addition to owning product strategy, customer engagement, and roadmap execution, these individuals have a strong understanding of engineering practices, the software development lifecycle, and agentic AI systems. They know how to orchestrate work across people, platforms, and AI agents to accelerate delivery and innovation.

We’re actively bringing this capability into the organization today. While traditional product management skills remain critical, we believe AI-native product managers and full-stack builders will become two of the most important roles over the next 18 to 24 months as we continue to transform.

Learning to listen to internal customers

When the customers for your products are your internal business teams, how do you understand what they need and translate that into a product roadmap?

Serving internal customers is different because a lack of feedback isn’t necessarily a positive signal. If internal teams aren’t engaging with your platform, they’ll often find alternative ways to solve the problem. In many cases, silence is actually a sign that you’re not creating enough value.

Early on, we recognized that adoption couldn’t be a pull model. It had to start as a push. Our responsibility was to proactively engage with customers, understand their challenges, and demonstrate how the platform could help them achieve their goals. As the platform matured and delivered value, that dynamic gradually shifted from push to pull.

We borrowed a concept from leading product organizations: Customer Success Management. We asked our product managers to act as customer success leaders, not just product managers. A key part of their role was building relationships with internal customers, providing white-glove support, and helping teams realize value from the platform. We held workshops, monthly ideation sessions, and regular business engagements focused on understanding objectives, exploring use cases, and identifying opportunities for rapid delivery.

One of the most important mindset shifts was moving away from a requirements-first approach. Instead of starting with everything a customer wanted, we started with what the platform could deliver today to help them achieve business outcomes faster. From there, we could iterate and expand capabilities over time. That approach significantly accelerated time to value.

We were also applying what is now commonly referred to as forward-deployed engineering long before the term became popular. We would rapidly build a proof of concept, validate the use case, and demonstrate the outcome. That hands-on engagement created momentum, accelerated adoption, and strengthened the partnership between our platform teams and the value aligned teams.

Ultimately, the transition from push to pull came from one principle: ensuring our customers were successful. When customers experience value quickly, adoption follows naturally, and the relationship evolves.

One strategy, five platforms

How do you create a consistent product strategy across platforms as different as SAP, ServiceNow, payments, commerce, and integration?

The goal isn’t to make every platform do the same thing. These platforms serve very different purposes. Adobe Commerce is customer-facing, SAP is deeply domain-specific, and MuleSoft is an integration platform that enables connectivity across the enterprise. A one-size-fits-all strategy simply doesn’t work.

What you can do is create a common strategic framework that applies across all platforms while allowing for platform-specific execution. We developed a strategy built around five pillars: simplification, adoption and maturity, innovation ignition, operational excellence, and compliance and security. Those pillars are intentionally platform-agnostic. They provide a consistent way to think about progress and investment without prescribing the same outcomes everywhere.

For example, simplification means something very different on SAP than it does on MuleSoft. In SAP, it’s about reducing customization and moving toward a clean core so upgrades can happen faster and with less effort. In MuleSoft, simplification is about increasing reuse and standardization so teams can leverage existing APIs and integrations instead of continually building new ones. The outcomes are different, but both support the same strategic objective.

Our platform product managers helped shape the framework from the beginning. We came together to define the overarching strategy and then built FY26 roadmaps aligned to each of the five pillars. The initiatives within those roadmaps vary by platform, but they all connect back to the same strategic themes. That’s how we standardize. It gives you the framework to talk about in a consistent way and the flexibility to be specific where it matters.

With competing demands across so many platforms, what gets prioritized?

Once we established the framework, we assessed every platform against a maturity model across each strategic pillar. The model included roughly fifteen subcategories and measured capabilities on a spectrum from reactive to leading. That assessment gave us an objective view of where we stood and created a heat map that clearly highlighted areas of strength and areas requiring attention.

From there, prioritization became much more straightforward. We always have a finite investment envelope, so we direct funding toward the highest-value opportunities where maturity is lowest. The goal is to elevate those critical capabilities while sustaining the areas that are already performing well.

When we built our FY26 roadmap, we used a simple two-dimensional lens: business value and maturity. We focused our investments on the capabilities that would deliver the greatest impact while moving the most significant gaps forward. In practical terms, that meant turning the red areas into yellow, while ensuring the green areas remained strong. It’s deliberately simple, and it’s the approach that’s held up for us.

Treating compliance as a product

How do you build compliance into a platform in a way that lets teams move faster rather than slowing them down?

Traditionally, compliance happens at the end of the process. Teams build and deliver, and then they encounter a series of control gates that require rework, delays, and additional effort. We wanted to change that dynamic.

Compliance was one of the five pillars of our strategy because we had clear visibility into where the gaps and friction points existed across our platforms. Rather than treating compliance as a set of checkpoints, we treated it as a product.

When people hear “product,” they often think of software, but in this case it’s a service-oriented product. Take a common ITGC requirement like timely incident management. The product isn’t just a control. It’s the end-to-end capability: the process definition, stakeholder responsibilities, workflows, reporting, and services that enable customers to meet their compliance obligations with minimal effort.

The key shift was moving the focus from what we needed to do internally to what our customers needed to be successful. We built a service layer around compliance requirements and packaged those capabilities into reusable products that teams could consume consistently.

We’ve also matured those products over time. In the early stages, many of these services were highly manual. We then introduced automation and standardized reporting, creating semi-automated capabilities. Today, some of those same products have evolved into AIOps-based services supported by autonomous agents. The underlying objective hasn’t changed, but the delivery model has become increasingly self-service, intelligent, and scalable.

That’s how compliance becomes an accelerator rather than a constraint. When you build it into the platform as a product, teams no longer encounter compliance at the end of the journey. They consume it throughout the process as a built-in capability, allowing them to move faster while strengthening governance and control.

You strengthened the organization’s compliance posture. What organizationally and technically contributed to that result?

What made the difference was treating compliance as a product rather than a project. Too often, organizations overly focus on meeting only the immediate needs. We took a different path and approached compliance as a transformation. That meant redefining processes, establishing clear service ownership, improving repeatable compliance products and controls, and helping teams build on their understanding that compliance is a core business capability. The goal was to more deeply embed compliance into the way we operate.

It wasn’t a single technical change or organizational initiative. It required aligning people, processes, and technology around a common operating model and strengthening a structure that scales consistently across the organization. This demands tremendous commitment from the team. But that investment leads to a stronger foundation. Today, we have further developed processes, reusable compliance products, and greater clarity around expectations and accountability. As a result, we’re able to move faster, scale more effectively, and continuously strengthen our compliance posture.

The key to this mindset is recognizing that this is never about solving isolated compliance requirements. It is about continuing to strengthen a capability that improves how the organization operates year after year.

What comes next: Signals, and the AI build-versus-buy question

What signals tell you that a platform is becoming a successful product rather than simply a well-run technology?

The strongest signal is when customers start coming to you asking how they can build on the platform, what capabilities already exist, and what they can reuse. That’s the point where the conversation shifts from operating technology to consuming a product. Instead of us driving adoption, customers are actively seeking ways to leverage the platform to achieve their outcomes.

We also track a set of metrics to understand whether we’re moving in the right direction. Platform Net Promoter Score (NPS) gives us insight into customer sentiment, while measures such as reusability, maturity, and cost per transaction help us evaluate how effectively the platform is delivering value. As we execute against our roadmaps, we expect those maturity scores to increase over time, providing a quantitative view of progress.

For me, though, the most meaningful indicator is the transition from push to pull. In the early stages, we had to invest heavily in customer engagement, advocacy, and adoption. We were constantly demonstrating value and encouraging teams to take advantage of platform capabilities. Today, on some of our platforms, conversations have fundamentally changed. Customers are approaching us with questions such as, “Can I use this capability?” or “When will this feature be available?” Many of those discussions are centered on AI and automation, where demand is often outpacing our ability to onboard teams responsibly.

We’re not at that point across every platform yet, and there’s still work to do. But where we are seeing strong customer pull, increasing reuse, improving maturity metrics, and growing demand for new capabilities, those are clear signs that the platform is evolving into a product rather than simply being managed as a piece of technology.

With AI capabilities coming from enterprise platforms, external vendors, and your own teams, how do you decide what to build, what to buy, and where each capability should live?

We start with our broader enterprise AI strategy, which is led by our Applied AI team. We complement that with a platform-native AI strategy supported by a set of guiding principles that help us make decisions in a rapidly changing landscape.One of the most important principles is augmentation versus differentiation. We ask a simple question: is this capability creating meaningful competitive differentiation, or is it augmenting an existing process? If it’s primarily augmentation, our default position is to leverage native platform capabilities. It’s typically easier to implement, easier to maintain, and allows us to benefit from ongoing innovation within the platform ecosystem.

We also evaluate total cost of ownership. We’ve already made significant investments in our core platforms and licensing. Wherever possible, we want to maximize the value of those investments before introducing additional technologies that increase complexity and support costs.

Another key consideration is technology sprawl. As AI lowers the barriers to building and acquiring solutions, organizations risk creating fragmented technology landscapes. Like many large enterprises, we’re actively working to simplify and consolidate. We want innovation, but we want it in a way that’s intentional and sustainable.

That said, if a capability is truly differentiating and can accelerate business outcomes, we’re willing to bring in external solutions or build capabilities ourselves. The important thing is making that decision deliberately. What may be differentiating today can become a standard platform capability tomorrow. That’s why strong partnerships with platform vendors are so important. We invest heavily in those relationships to gain early visibility into their roadmaps, participate in preview programs, and influence future capabilities. In some cases, we may choose a third-party solution knowing that a comparable native capability is likely to become available in the near future. When that happens, we can transition to the platform-based solution through a planned and intentional lifecycle.

We’ve deliberately avoided creating a rigid decision matrix because the market is evolving too quickly for static rules to remain effective. Instead, we apply a consistent set of principles around differentiation, augmentation, total cost of ownership, platform leverage, and technology sprawl. Those principles don’t guarantee every decision will be perfect, but they ensure each decision is thoughtful, transparent, and aligned with our long-term platform strategy.

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.

Every day, more of your traffic isn’t human. AI agents show up, grab what they need, and leave — and you pay to serve every visitor, whether they see your brand or not.

Today’s guest has seen this from both sides. Brandon Harris is VP of Product at Pantheon, the WebOps platform behind a huge slice of the WordPress and Drupal world. But before that, he was sending the bots — at Wiser, where his team scraped millions of pages a day to power retail pricing intelligence.

His take: agents aren’t killing the web. They’re just the new way information is traveling. And the companies that adapt are about to pull way ahead of the ones that don’t.

In this episode, Brandon shares:

• How AI is turning the whole web into one giant CMS and quietly rewriting the job of anyone who publishes content

• Why site visits are the new impressions, and what happens to hosting economics when the meter can’t differentiate a customer from an agent

• Why trying to keep agents out is the modern-day version of blocking Google from indexing your site, and what to do instead

1. Agents aren't killing the web. They're just the next mode of transportation.

The “dead internet” theory assumes that this new wave of internet traffic is essentially eating itself; AI made to consume AI and AI made to be consumed by AI. Brandon has a different opinion, and he relates it to the history of transportation:

“We were walking, and then we found wheels, and carts, and animals, and then bicycles. We could do some self-powered things, and then trains, then cars. But each time that happens, there’s this sense that the new technology for transportation is gonna overtake all of the previous technology, and we’ll never use it. But the reality is, I still have to teach my kids how to ride a bike.”

If you replace the thing being transported from people to information, then agents are a genuinely new transportation method. As a result, browsing traffic is changing. But it’s not being eliminated.

“We’re gonna see a compression in the volume of human traffic, and we’re gonna see a compression in the volume of traffic that is intended just for browsing, but it’s never gonna go away. And in some ways, it makes it more valuable.”

Product takeaway: Falling human traffic isn’t an automatic sign of failure. The mix is changing underneath the number. As a result, you should segment your analytics by traffic type before you react to the topline. Because the humans who still show up are arriving with more intent than they used to, and that should change what you build for them.

2. Why site visits are the new impressions

Here’s the uncomfortable math: a bot and a buyer cost your CDN, host, and CMS the same amount to serve.

Brandon, who spent a stint as interim CMO at a previous company, sees the same correction coming that advertising already went through: going from counting eyeballs to paying for action.

"The visit will become kind of like impressions. They're valuable, but not the same value as a conversion. And we'll start to get better at tracking both."

The interesting part is that this isn’t a case for locking the gates, so to speak. Brandon’s point is that the industry posture is shifting from keep everything out to something more selective — closer to traffic grading, where a site decides what a given interaction is actually worth and both sides negotiate from there. Some large publishers are already building toward charging for access.

He relates it to sites in the past blocking Google from indexing them:

“Five years ago, everything was: how do we block bots, how do we stop them from coming? And it’ll shift to, well, we want some, but not all [agents].”

Product takeaway: If your economics are priced per visit but your value is created per conversion, you have a modeling problem that’s going to get worse every quarter. Start instrumenting traffic by value now — which agents drive real conversions and which are pure cost — so that when better grading and pricing tools arrive (Brandon guesses roughly a year, and probably from startups rather than infrastructure incumbents), you already know what you’d pay for.

3. Is the whole web becoming one giant CMS?

Traditionally, a CMS holds structured information and assembles it into a page on request. Now, that’s a pretty fair description of what an agent does to the entire internet.

Brandon watched an early version of this at Gannett fifteen years ago, where a project assembled news sites on demand from whatever content was available across hundreds of properties. The difference now is that the source pool is everyone’s site, not just yours:

“If the web is the CMS, if all this data is available very quickly in real time, I can assemble it into whatever I need it to be to either build a new product or a new page on demand.”

He’s clear that this produces slop, too, not just value — the same split we get across all platforms. Which is why the job of publishing content changes. It’s no longer enough to just have accurate information sitting on your domain. Your content now has to survive extraction and still be recognized as yours.

“How do you provide brand placement within the content that you create, so that when it is pulled, it is still representative of your brand or harkens back to your brand?”

Brandon frames this as inserting your brand’s “fingerprints” into your content the way broadcast used product placement. The industry’s done this before: Google forced an entire generation of teams to learn how to structure content for a crawler. This is the same thing, just maybe one level up in complexity.

Product takeaway: Audit your content for what survives being pulled out of context. Does a paragraph lifted into an answer still carry your point of view, data, name, etc.?

4. Look for the drift before it wrecks the tool

Unhappy users rarely file a ticket saying they’ve lost confidence in you or your product suite. They just start to drift, slowly, in a way that never shows up as an event.

Brandon’s framing for what to do about it comes in two parts:

First, know what you’re protecting:

“Understand your superpower and your kryptonite. Your superpower, amplify it — get your super suit, get the utility belt. For your kryptonite, protect against it, because it’s not just things that you’re weak at, it could be things that drain you and drain your value.”

Second, go hunting for change on purpose, because it won’t announce itself. He borrows the term from machining:

“If you’re not looking for the drift, you won’t see it until it’s messed up your tool.”

This means watching real user sessions, tracing where people fall out of the funnel and why, and treating behavioral shifts as information rather than noise. This loops straight back to agents: the mix of searchers and browsers on your site is changing right now. If AI handles the initial lookup, then maybe your search bar matters less, and your browsing experience matters more. You won’t know unless you go and check.

Chapters

00:00 Introduction
02:24 Brandon's product journey: From film school to Wiser and Pantheon
03:46 The dead web debate: Agents are just the next mode of transport
07:13 Why traffic-based pricing can break when the majority of your visitors are agents
09:37 Site visits are becoming the new impressions
12:08 Grading traffic and the identity arms race it will start
15:33 When the whole web becomes your CMS
18:02 Putting your brand's fingerprints in content that AI will pull without accessing your site
22:45 How people decide to trust a site
27:39 Watching sessions to catch user drift before customers quietly leave
32:31 Conclusion

Links

• Brandon’s LinkedIn

• Pantheon

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, Schwartz talks about what inclusivity actually means for a product team — not a single interface that tries to serve everyone the same way, but a product that lets a first-time player and a 25-year veteran each find their own moment of joy. She discusses building teams that include both the expert and the beginner in the room, translating jargon like reverb and distortion into something a new player can feel rather than just read, and why she pitches inclusivity to leadership not as a values statement, but as a growth number.

Redefining who counts as a musician

Who has the musical instrument industry traditionally been designed and built for?

It depends. Inclusivity can relate to any category. Even though I happen to be in the music industry, it comes down to who is your audience, who is the audience you want to grow into, and how can you include them? It can be anything or anyone.

There are some companies who target a user in a particular part of their journey. I’m going to use some of the more school-focused, education-based products that are targeting that younger demographic, newer to their journey. They’re specifically targeting that person, but they can grow as that person learns. They can continue to grow with that company.

But what I’m talking about in my experience is more the popular music, the recording-based music, or fretted instruments, as they say. Who is that customer? Who do they design for? I think largely it becomes and has become the player. They want to talk to, speak to, and engage with those who use their products. Usually, once you start playing — let’s use guitar for example — you start understanding those things within a year or so, and as you grow in your journey, you can continue that for a lifetime. You are a player, so therefore you fit into their category.

Who’s making music now that wouldn’t have called themselves a musician 10 years ago, and how does that redefine the audience?

You nailed it. That’s exactly why this becomes an interesting conversation now. Over the course of 10 years, we could boil it to five years, even two years, and the definition of who is a musician, who can create music, has dramatically changed. Going back to pre-AI, pre- a lot of the technology that has grown to support new players, that target audience for MI companies 10 years ago would have had to invest a good amount of time and money to be comfortable enough to be one of their engaged users.

But that changed—needle scratch—to a point where you no longer need years of formal musical training to begin creating music. All you need is to be able to access your keyboard and an app, and you are making music to a degree that you can be composing orchestras. You could be making beats, designing and writing rock bands, without ever having to know one note or be able to sing one note. That’s how it changed so dramatically and why it’s so interesting.

Designing across the beginner-to-pro spectrum

How do you build a single product experience for someone playing their first chord and someone who’s been playing for 25 years?

That’s where it gets a little complicated because, from my perspective, trying to make sure we are inclusive to all doesn’t mean you have to have a one-size-fits-all solution — one onboarding journey, one UI that has to satisfy somebody who just picked up an instrument for the first time versus someone who’s been playing for 25 years. It doesn’t have to be the same. You just need to make sure that each of those categories, in their extreme, can do what they want to do, can engage with the product, can find that moment of joy as easily as the other one. That’s all you have to do.

I’ve seen established music companies say, “We don’t want to look stupid, or talking down or condescending to a player who knows exactly what they’re doing. We don’t want to ask, ‘do you know how to play a chord?’” Of course you don’t, but two things: First, you need to support that user at every step of the journey. And you would be surprised how open more established players are to making sure other people can learn — they’re not going to turn their nose at why you’re offering this kind of information. And, quite frankly, we have sophisticated MarTech tools right now to make sure you don’t even have to see that information if it doesn’t pertain to you.

If you don’t want to insult that power user, where’s the line between making something effortless and making the skill behind it feel unnecessary?

That’s exactly the fine line that one has to traverse: to make sure you don’t condescend to a pro user, but that you’re also inclusive. That’s sort of where the experience starts, and it’s where, from a product perspective, I get really interested: How do you do that? What language do you use? What does it look like, and what does it feel like? We need to maintain the brand integrity — we don’t want to look like we’re pandering or going beyond who we are as a product. That’s the real fine line, but it’s really important.

Building inclusive teams to build inclusive products

Are there any techniques or frameworks you use — questions you constantly ask, or mantras you have?

I do it rather intentionally, and how I do it is by creating the team itself to develop a feature. Say we’re going to develop a feature, an onboarding, or roll out a new product. I like everything to be collaborative, so it’s not just one vision or one focus. It’s been crucial to me to build my teams to make sure we have somebody to represent each side inherently. We have a player who really does know, speaks the language, and knows what they want and don’t want. Conversely, we need the person who is just beginning their journey. That’s the most important thing, having the two together. As we’re ideating, as we’re doing wireframes and user flows, both sides of that user are in mind, always, in the room at every step of the journey.

You’re designing something, and someone will use a word or a phrase that a beginner wouldn’t understand, and the beginner says, “Wait, what is that?” “Oh, yeah, you don’t know that yet” — so how do we support you at that moment? That’s how it’s building that team. It’s not even just about product people — it’s about your content providers, your designers, your UI, UX. Everything should in some way have that breadth and depth of experience in the room for collaboration.

How does who’s actually in the room designing a product change what the product ends up saying to the people using it?

Just data. We start with our existing data — what do we know about this person or this audience from a data perspective, and how can we apply that as sort of a shot in the dark, an assumption theory? Then we plot that out as quickly as possible, get to some MVP, or minimum viable product, and get that out there, and start testing and iterating: Were we right? Are we wrong? Should we adjust? Should we pull back? It really just starts with that best guess.

Speaking to different fluency levels

When a technical term means everything to a veteran and nothing to a beginner, how do you decide whether to teach the word or design around it?

That’s something I’m still experimenting with. That question is so relevant when you’re talking about music — how do you describe sound? How do you explain distortion or delay or reverb to somebody who has no idea? They’re words, and you could read the words, but until you actually hear it, you go, “Oh, that.” That’s a big challenge. But as we move toward these more experiential moments, where you’re able to, say, hear what reverb sounds like, I’ve been able to design experiences where you can show it dry, meaning without that particular effect. Let the user hear it for themselves, let them understand it. And, ideally, let them play around with it, take a knob or a dial to pour more in or take more off, to really start to feel it.

That’s just one example of how jargon will impact your experience, because you want to get a sound — you know the sound, you’ve heard it, you know an artist who plays in that style or sings in that particular way. How do you get there with words? It’s impossible.

How do you know whether a design choice is working?

As easy as a heat map, or using triggered events. When they came to this part of their journey — “Do you know what reverb sounds like? Here, press this” — how many people pressed that? That’ll tell you right there. And then, following that down, what are the other KPIs you have for that feature? Whether it’s converting, buying something, or taking on a subscription, you start to see that if you get people to understand and feel and really get what they’re doing, your KPIs will increase across the board. If they know what they’re doing, they’re going to enjoy it and do more of it.

Making the case: Inclusivity is growth

When inclusivity doesn’t show up as a metric the way conversion or retention numbers do, how do you justify keeping it on the roadmap?

I justify it by not having it on the roadmap — by not saying, this is going to be an exclusive experience, because that doesn’t really resonate in a boardroom. I don’t mean it literally, but when resources are limited and you’re trying to hit numbers, that’s something that’s not really valued.

So what is inclusivity? If you take a step back, it’s really about growth. That’s it. If I can say, I will increase our user base by X percent, they’re like, great, go do that. That’s inclusivity in practice — reaching people who may not have previously felt these products were for them and helping them achieve what they came here to do. It’s making sure we’re speaking their language and applying learning techniques in a way that’s meaningful to them. Growth follows when you create that value.

At several companies I’ve worked with, that is a metric we track. We call it the moment of joy, that aha moment. Anyone who’s trying to make music can hear it. They did it, they get that feeling of joy, and you can really capture that and go, ding, that moment. From a product perspective, we want to get you there. We back into the moment you first enter our experience to that moment of joy: How do we get you there, how long will it take, and what are those inflection points we can look at from a data perspective that say, if we follow these steps, then you’re 7X more likely to have that moment. And we’ve got you for life. We’ll be that specific and meticulous about every hour in that journey to get you to that moment.

How do we know that? Anyone who’s a player who’s been playing for 25 years, we’ve asked this one question: What was the first song you learned to play? They all know it. They all talk about how they learned it. They all talk about that moment when I figured out that last chord that George was playing — “Aha, that was it, I was in.” Or that moment I sang and heard my voice sound like so. Every musician has that moment, so how can we help you get there quickly?

Leading inclusively, from culture to the next generation of creators

As a leader, what are your golden rules for building a culture of inclusivity?

Being absolutely inclusive. How can I expect product leaders or designers to be inclusive in all their work if I’m not inclusive with a team? How can I build a team that has a variety of voices, opinions, backgrounds, and facts?

Diversity isn’t just gender-based or background-based — it’s also about what kind of people they are. Are they super type-A, the type who always achieves their goals and likes to make a checklist? If I’m designing a learning product and I’ve got all those types of people, it’s kind of easy. I also need to hear the voice of the person who really wants to do it, but they’re too busy — how can I support them?

What about someone on my team who’s a busy parent with kids to work around, but who really wants to satisfy their dream of being able to play an instrument? I want to hear from them too. How do you find time? How can you get 20 minutes out of your day? It’s about bringing people with different backgrounds, perspectives, experiences, and ways of approaching the world — and creating space for those perspectives to shape the work.

As the definition of a musician keeps stretching, what’s the next kind of creator most companies in this space haven’t noticed yet?

I don’t know about “haven’t noticed.” There’s a tremendous amount of attention right now on people who may not identify as traditional musicians but are creating music. If you’d asked me that question a year ago, I would’ve answered the same way. But as of now, the spotlight is on that cohort, on those potential users, with such a flurry of excitement. And I love it — I’ve always believed everybody should be able to make music, even though a lot of people in the industry are resistant to that. This very underserved, huge user base is now getting the love and attention it deserves.

What was your aha moment when you fell in love with music?

I get the chills even thinking about it. I am what I like to call a perpetual beginner — I’ve never really learned how to play, but I do remember being a teenager and wanting to be in a band because I loved music so much. My aha moment was that time when I was in a garage with my friends and I became the lead singer because I didn’t have any instruments, and it was easy. I could do it. But having that moment where you’re singing and the drummer’s playing the drum part and the bass is playing, the guitar is going, and suddenly — we’re a band! It was so exciting. There’s nothing like that feeling of playing together and making a noise that sounds at least somewhat similar to the sound you’re trying to make. It’s amazing.

It’s so much fun. It’s frustrating and hard, but that’s why I feel like I’m in a good place to support that user — I’ve made a career and a life of music without really being able to play. So you can do it. Anybody could do it. It’s true, especially now.

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, Swapna talks about designing AI around the work employees are already doing rather than asking them to adopt new habits. She discusses building trust in nondeterministic systems, the new evaluation practices AI products require, and why the future of enterprise AI lies in agents that can carry work across systems.

Making enterprise software disappear

You’ve built products across payroll, HR, recruiting, and workforce technology. What’s the biggest lesson you’ve learned about what employees actually need from the software that they use every day?

Employees just want to get the job done. They need the software itself to disappear. Nobody wakes up wanting to use an HR system — they just want to get paid correctly, get answers to questions they might have about policies, get a laptop replaced, that type of thing. Their problems have essentially remained the same despite changes in technology, and I’ve been through those technology transformations. People want to use the software to do what they need to do and then be on their way.

With Kore.ai’s AI for Work platform, what problem were you trying to solve beyond simply adding another AI assistant to the workplace?

This is true for any enterprise: the biggest problem employees have is needing to use 10 different systems to get their jobs done. Ideally, they should be able to go to one place to ask their questions and get the help they need.

The first question is, “Where do I need to go to do that stuff?” As everybody starts to add AI, the problem compounds. Even if I need to go to HR, do I need to go to a specific HR system for policy questions? And another for benefits? As an employee, that’s not a good process.

The problem that I was trying to solve is how to make employees’ lives easier using AI. We need to make it simple for people to do their work without having to go to 10 different systems. This starts with meeting them where they already work. That could be in Teams or Slack, or a web UI. We don’t need to make people develop a new habit.

Building trust into enterprise AI

Enterprise AI operates in regulatory environments where mistakes can have real business consequences. How does that change how you approach the product design, testing, and rollout?

Even in enterprise software, compliance has to come first. I’ve built those products from the ground up. Mistakes in payroll, compliance, and HR have huge consequences. It’s the same in AI, and that risk compounds even further.

You need to make sure answers are thorough and that humans are in the loop in sensitive areas. You need to be very careful about preventing hallucinations, providing accurate answers, escalating to humans when needed, and accounting for compliance-level rules. The overall compliance landscape should be thought through before you ever push something live. Building specific guardrails — like masking sensitive data, for example — is not an afterthought. It needs to be included in the design itself.

When you’re doing regression testing, you should have golden datasets and rules that you’ve already thought through. What types of policies and procedures will inevitably come up? These are called evals in AI. When you’re rolling the product out, you have to start with context grounded in the organization’s data so that the agent doesn’t hallucinate. If it can’t answer, there need to be correct fallbacks so that it doesn’t make things up. It should either escalate to a human or say, “I don’t know the answer to this question, but here’s a document for you to review or here’s someone you can ask.”

How do you mitigate the hallucination risk of LLMs and get the end user to trust an AI agent with sensitive data?

You have to build trust from the moment a product is rolled out. As a user, the first time I interact with a system, I expect it to do the job I want it to do — almost as well as a human does. If it doesn’t know the answer, it should send me to a human rather than make one up.

A company’s policy document repository is very important here. For example, I’ve worked with customers who have laid out “moments that matter.” In an HR scenario like a bereavement leave case, LLMs are very good at handling that type of sensitive information. But as soon as the situation involves sensitive data or something like an employment violation, those are the “moments that matter.” Once an AI detects that type of intent, it should give a very empathetic answer and pass the situation along to a human because mistakes in those contexts are very costly.

When you’re designing AI workflows, you need to understand those workflows end-to-end: what are the connection points between different systems and different users, and how do I now redesign and rethink this entire workflow while keeping humans in the loop at specific moments?

What new practices have become essential for evaluating an AI product before it ships?

One of the biggest things is evaluations — making sure the product is working correctly. There are two types: one happens during the build itself, and the other happens during internal rollouts or pilots. During the build, you anticipate what people might ask, but when you actually roll the product out and people start asking questions, you may realize that you haven’t thought of every scenario.

What’s different here is that you’re not evaluating a UI; you’re evaluating conversations. There’s no UI to speak of, so the design practices become different. Are you empathetic? It’s a whole new way of thinking. There also isn’t the single point of failure that you used to have in traditional software development. It’s generative so that the answer can be different every time. Pinpointing where something is going wrong requires investigating a whole range of possibilities: “Is it in retrieval? Where did it actually go wrong? How do I even fix this?” There’s not a straight answer.

It’s very different from traditional UI development because now you are dealing with conversations or voice. Traditional development practices are completely thrown out of the loop. Still, spec-driven and test-driven development concepts, which have existed in the software world, are now reflected in practices like evals and spec-driven development. They’re new practices that you need to adopt.

Rethinking product development for agents

Having worked in both traditional software and this non-deterministic new world, do you have a preference?

Currently, I do not know how I would go back to the old way. Now, I’m thinking in terms of agents and how to develop them. When I’m given a problem, I try to map the workflow, and my mind immediately goes to, “What agent would solve this workflow? What systems are involved?” My thinking has changed dramatically. I’m also thinking in terms of conversations. To paraphrase Satya Nadella’s term, AI has become the new UI. I find it difficult to go back to traditional software development at all.

Your team rolled out the platform internally first. What did that reveal that you couldn’t have learned through customer interviews or usability testing alone?

Initially, I was rolling it out to different users. We spoke to different user groups, really trying to chart out their days: “What’s your day-in-the-life like?” These are UX research practices that have existed for a long time in software development. Those practices are still important. Nothing substitutes for good UX and UX design, though the traditional terms have changed a bit. Talking to users, talking to customers, and finding the right problem to solve have not changed at all.

I spoke to our HR, IT, and sales departments to learn what their jobs-to-be-done are. Once we had a good set of interviews and a grasp of our internal systems and workflows, we evaluated whether the use cases we built were still applicable. What tweaks would we actually need to adopt it within the enterprise? We had the golden datasets, and we’d thought through the test sets, but when it came to rolling it out for real, there were surprises. People use every system differently, so we didn’t anticipate certain questions.

Like any software rollout, we learned as we went, adapted, and evaluated. It’s true for every single enterprise: Who are the users? What problems are they trying to solve? What systems are they touching? What workflows are they using? Then, after rollout, does it work? Have people actually adopted it? Are they coming back? Is it successful?

Can you share an example of something that surprised you in the rollout?

Initially, when we were working with policy documents, we had to configure the system so that the right countries’ policies were displayed to the right people. We only realized that during testing. It all came down to how you organize your documents and make sure answers come from the right documents in the right format.

Designing for adoption, not disruption

AI is changing how people work almost in real time. How do you design a platform that can evolve just as quickly without forcing employees to reinvent their workflows constantly?

You need to meet employees where they work — whether that’s in a chat or a web UI, you shouldn’t change that. The user’s habit actually lives in those systems. In most cases, it is in Slack or Teams, and anytime you make changes, the experience should survive every model upgrade, every capability change, and every new architecture change behind it.

That’s why the platform-first approach works. Models can be swapped, but you need to be able to do new regression testing. The workflows that people have already gotten used to should not break.

When you’re building an employee-experience platform, what signals tell you that the product is actually improving how people work?

This has always stayed the same in enterprise software — it’s about retention more than adoption. The first metric is whether or not people have taken to it. Then, the real test is whether they are coming back to use it.

For example, with HR software, you are often required to use it — there’s no other way for you to submit a time-off request. But if it is optional, and now you can submit a time-off request using AI, are people actually using it? Have they come back because they liked it and it made their work simpler? Further, are they now starting to use it for complex tasks? As we move to agentic AI tasks, a good example is a user telling the AI, “Plan my leave. Check my vacation, look at my policies, and tell me the best leave that I can take that optimizes my time off with my vacation days.” That’s a complex-level task that an agent can actually do.

In IT, for example, the AI can go in, check when your laptop lease is going to expire, and automatically send emails to an administrator that the laptop needs replacing. That’s a level of autonomy, but of course, I always stress having a human in the loop.

When people use it as their first stop because it’s that useful, that’s when you know it is successful. There are some easy metrics to track, such as lower ticket volume, because you can conclude that people are getting their questions answered by the AI. HR can then do higher-level tasks and focus on strategy rather than answering questions.

From conversations to end-to-end work

Looking ahead, what do you think the best enterprise AI platforms will do three years from now that today’s products aren’t yet capable of delivering?

They’ll be able to carry work across systems instead of just answering questions. You’ll hear about orchestration in the AI world — a typical enterprise will have 50-plus systems. There’s an end-to-end workflow that can execute across those systems rather than relying on these single points of contact with AI tools.

Further, today’s products are mostly conversational. They’ll summarize documents and answer questions, but the opportunity is to cut across workflows. For example, “I can manage your end-to-end day from morning to evening. In the morning when you come in, I can tell you what meetings you have. Here’s your dossier for them.” Work should be a lot simpler, and it still isn’t. These systems need to be proactive, anticipating what you need and taking that busy work away. This will make work more enjoyable because AI systems can do a lot of the grunt work.

As expectations for output accelerate alongside AI, how can AI help employees keep up?

It’s the cause of these increased expectations, but it can also help you. Nowadays, there’s no other way — to do your best work, people are being asked to do more work with less. It’s not stopping. So AI is an essential component.

We all talk about using humans in combination with AI. I truly believe in that and think AI should be seen as an asset rather than a replacement. If you view it this way, it can augment people to the point of driving higher satisfaction. That’s a win-win for both the organization and the employees who work there.

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.

Her perspective is grounded in a central conviction: as AI lowers the cost of building software, features alone will become increasingly difficult to defend, and durable differentiation will come from the context, semantic infrastructure, workflow intelligence, and trust systems that let products understand a business and evolve with it. In this conversation, Soni discusses what it means to make an enterprise legible to AI, why products must earn the right to become invisible, how personalization can remain transparent and controllable, and why the products that endure will be the ones that continuously increase their value to customers.

Beyond features: The new durable moat

With tools like Claude Code dramatically lowering the cost of implementation, many products are starting to look remarkably similar. What still creates durable differentiation?

Durable differentiation is moving away from the feature itself toward more infrastructure, context, and the semantic layer that sits underneath it. Features are already copyable. I like to think of them more like menu cards. One vendor introduces a feature capability, the other can copy it fairly quickly, and it’s another version of it that is sitting with a different prompt, different model, maybe slightly different implementation approach. Now, as the cost of building falls, the shelf life of the standalone product differentiation is reducing significantly.

What’s becoming really hard to replicate is the system that enables the AI to understand the business environment, like the relationships between the data, the meaning of the workflow, the users’ context, what decisions are being made. What are the decisions that the customer cares about? What are the outcomes that they’re driving for? The semantic and the contextual layer is what makes the entire enterprise legible to the AI.

Once you have that, you can enable the model to make smarter decisions, orchestrate across workflows, and deliver an experience that is relevant to the end user, rather than simply generating a generic response to them or building a generic feature. And the second part of the differentiation is the infrastructure itself. The ability to connect systems, the right systems, preserve the context over a multithreaded set of information, govern the actions, and create the feedback loops, so the product can learn from the usage and the outcomes itself.

So I believe that the products that will win will be self-evolving systems, honestly. They will not simply ship a fixed set of features. They will continuously become more intelligent and valuable as they understand the customer’s environment better. Otherwise, we’ll be just building point solutions with increasingly similar capability, and that’s really not differentiation. So as the features start to become a commodity, the advantage is the context graph, the orchestration and the infrastructure underneath, and a self-healing, self-evolving system for the product to evolve with the customer’s needs.

If feature parity is becoming inevitable, where should teams invest to create experiences that are difficult for competitors to replicate?

Teams should invest in understanding the customer’s environment deeply enough that the product becomes connective tissue within it. That starts with listening carefully to the customer — not just to the feature being requested, but to the outcome they’re trying to achieve, the systems they already use, the workflows they depend on, and the friction preventing them from realizing value.

From there, the opportunity is to build the semantic layer and contextual intelligence that let the product fit naturally into that environment, rather than sitting beside the customer’s infrastructure as another isolated tool. Teams also need to invest in curation and adoption: providing a capability isn’t enough. You have to configure it for the customer’s context, help embed it into the way they work, and make sure they’re realizing the intended outcome.

A competitor may be able to replicate the visible feature. It’s much harder to replicate the accumulated understanding of the customer’s environment, the integrations, the adoption model, and the trust that develops over time. That’s when a product becomes more than software — it becomes part of the customer’s operating infrastructure, and therefore much harder to replace.

The paradox of invisible design

Sometimes the best products are those that become “invisible.” What does invisibility actually mean from a product design perspective?

I think it’s such a powerful moment when a user lets you put your product that is almost invisible to them on their mobile phone. A product earns that right to become invisible when the user trusts it deeply enough to depend on it without having to constantly manage it. My perspective is drawn from my earlier work in security. The best security systems are often the ones that recede to the background, that do the work for you but you don’t need to worry about them, because they only surface when there’s a threat or an anomaly or an insight that really requires attention.

I think the same principle applies more broadly today beyond the security industry. A product becomes invisible when the interface is no longer the center of the experience, but the solution is, the outcome is. The user continues to receive the outcome that they care about, while the system blends naturally into their workflow or the work routine.

The customer should be able to define the problem, or you sit down and understand the outcome clearly that the customer’s driving for. The product should almost become so frictionless, the way we deliver it, that it becomes a part of the routine, whether they need an interface, or they need a recommendation, or they need an automated action or no visible interaction at all. What do they care about, and how can we deliver that in a very orchestrated manner, in a more trustworthy manner? That’s where a product can really be invisible, but I do not mean invisible to mean opaque. The user must still understand what the system is doing, retain control over the important and consequential decisions, trust the product, and understand the business context in which it is operating.

Ultimately, invisibility is really not the absence of the product, but it’s an evolution of the experience that you bring to the user and the presence of value, without the burden of operating the product or the product requiring the user’s constant attention. In short, a product becomes invisible when trust is high, friction is low, and the outcome stays visible even when the interface doesn’t.

Personalization without complexity

As products become more personalized to each user’s context, how do you keep that from becoming overly complicated or error-prone?

Personalization, again, has to start with a deep understanding of the problem the user is trying to solve. Personalization should not require users to reorganize their work around the product. The product should adapt to their context and working model. This was valuable in the pre-AI era as well.

The first principle for a product to get personalized or to be adopted in a personalized manner is to show the work, especially early in the relationship. The AI should make reasoning, assumptions and proposed actions, visible enough such that the user can understand how it reached the conclusion. Over time, as the system improves itself, the user may choose to delegate more authority, but that trust at the beginning has to be earned. That’s where human-in-the-loop comes in.

The second principle in personalization is more about inspectability. Let’s say the product goes more invisible, but the user should always be able to go back, query what happened, why a certain decision was taken, and understand if or why the AI may have taken a wrong turn. It should be reversible, because that’s what is sometimes needed. That makes the system more stable, because when it’s imperfect, it’s not inscrutable.

The third principle is flexibility, like how I was talking about being able to revert back, but it’s the flexibility in how the outcome is delivered. Personalization should not be limited to the way that the interface has to change. Different users may need the same outcome, same capability, but delivered to different experiences. It could be a mobile experience, it could be a web interface, it could be an automated workflow, it could be an MCP-enabled interaction. It could be as simple as, “Pull it into a Google Sheet for me.” That’s the flexibility of personalization. That model hasn’t changed. So it’s not about personalizing the interface, it’s about personalizing the experience by leveraging the workflow that works for a user’s mental model, and it’s deeply rooted in the user’s problem. Again, transparent enough to be able to earn the trust, flexible enough to fit the workflow, and controllable enough that the user never feels that they are not in control or the product is unstable. Ultimately, the AI has to earn the right to make decisions on the user’s behalf.

Products people don’t want to leave

Switching costs are often framed around data lock-in or integrations, but there are also emotional and behavioral switching costs. How do you design products a user doesn’t want to leave?

This is actually my favorite question, because the premise hasn’t changed between pre-AI and post-AI. That has always been the core challenge: how do you build something that people just love to stay in, day in and day out? I think, again, it goes back to understanding their mental model, how they work, how they make decisions, what they trust, and where friction appears for them. The product has to fit naturally in their mental model, rather than asking them to get out of it and continuously adapt again and again to the product that you have built for them, and that’s challenging. That’s complete friction right there.

The second part is trust. Customers stay when the product is reliable, it’s understandable, and it’s consistently helping them achieve the outcomes that they care about. Then the third, which is increasingly important — this is the part that gets me really excited now that it’s possible — is evolution. The context today is already evolving. The data is always fresh. It’s real-time. The priorities are always getting updated. Workflows are getting really flexible and real-time adaptable as well. The insights available to them are getting generated. It’s learning and it’s feeding you information. What if the product evolved with the context? The product should not remain static.

I think the strongest products now will need to become increasingly self-healing and self-evolving. So they will detect where something has changed, adapt the experience or the workflow, automate what can be automated, request permission when appropriate, continuously improve, without requiring the user to go elsewhere to fill minor feature gaps. Because you’ve got the right context which is constantly updating. You’ve built it over time. You’ve built a connective tissue where it works with your infrastructure. All you need is the product to evolve, and you’ve already set the experience in the way that you want to deliver it. That creates a much stronger form of retention for the customer and customers want to stay. This way the product understands their environment, reduces their effort, and becomes more valuable over time.

I think the goal is not to create a dependency through lock-in. The goal is to create confidence that it’s continuously relevant and it’s working for you, not the other way around.

Enterprise UX in an AI-native world

With AI, has the definition of “consumer-grade experience for enterprise” changed?

I think if you root the definition of a good enterprise experience in deeply understanding the problem, then you’re fine either way, with AI and pre-AI. What has really changed is the evolution of what experience means. Good enterprise UX was once largely defined by making complex software easier to use: clearer navigation, more coherent information architecture, fewer steps, and less training. Those qualities still matter, but they are now table stakes.

What has changed is the unit of experience. Enterprise UX is no longer confined to a screen or device. It now spans workflows, roles, data, integrations, automated decisions, and interactions across multiple systems.

A beautifully designed interface inside a fragmented workflow is not a good experience. If users must reconstruct context, repeat information, move between disconnected systems, or manually coordinate decisions, the underlying problem remains unresolved.

AI expands the remit of design further. We are now designing how systems interpret intent, communicate uncertainty, request approval, take action, and learn from outcomes.

Good enterprise UX is therefore no longer simply about making complex software usable. It is about designing coherent, intelligent, and trustworthy business systems. Screens still matter, but they’re no longer the primary measure of the experience.

If voice and natural language become the primary frontend interface, how does that change the role of product design?

The experience and the way you deliver it is definitely changing. Previously, you had to go gather the intel. You would go to solutions engineers, you’d go to customers, you’d set up labs, you’d look at competitors’ information, you’d look at documentation. You were gathering context. Now that context is automated for you, so how do you automate the ingestion of context? I like to call it the ExperienceOS. So you’re now building an ExperienceOS first, the ingestion of that customer feedback, the competitive intel, how products are being used, and behavioral data together, creating an AI-ready to read an automated .md file with full context of the product experience.

Once you have that, leverage a design system that is AI-ready that can read natural language and an .md file for AI-dev creation, and now you’ve got end-to-end. You’ve got context, a prompt, and you’ve got your natural language input that pulls it all together. Your design is now fed by voice, natural language, and with the context inputs. Again, the work needs to be done on the context layer, semantic layer, pulling information from so many different sources and making sure there is no hallucination. That’s one place where you put a human in the loop or a learning system there.

The second is if it’s spitting out automated experience, whether it’s screens, whether it’s MCP, whatever that might be, how is that being checked? There needs to be a person who’s reviewing that, or an agent that has learned what it needs to deliver. So I think that’s how product design is evolving, from the overall ingestion of an evolving contextual layer of multiple sources, rooting it into the business outcome, rooting it into the experience that you want to deliver holistically as a company, as a vendor, and then using natural language prompts. A lot of work needs to go on the prompting itself. You do that work, and then it leads to a much more streamlined model of delivering product experience.

This can make it feel a little like design is not important, but I think a lot of work now goes on building the right systems design, building the right libraries, rooting it into the right decisions such that a single command, even from a designer, can fix the system completely. So a lot of focus goes on the platform layer, context layer, and it’s not about tweaking one screen at a time. It’s tweaking the system, making it more intelligent at the same time. The visible frontend may increasingly become language, but the real design material is the behavior of the system.

What survives the commodity trap

If every company can generate code, ship features quickly, and access increasingly similar AI capabilities, what will separate the products that endure from the ones that become commodities?

I think products that will endure are those that are rooted in business outcomes — products that customers can trust, that they can almost have a relationship with. That’s because the product is compounding in value for them; self-healing is one example of that. Then why would I buy from you versus somebody else? Because you have an infrastructure that it’s rooted in, that you understand my business, and that together both of them become a connective tissue. I think that’s the one that endures.

Products that become commodities will just provide feature-level capabilities, point solutions. Enduring products will help lead organizations through their own transformations — continuously providing that transformation to customers is what endures. Commodity products provide capability; enduring products continually expand what the customer is capable of achieving.

Many valuable product metrics today weren’t measurable just a few years ago. How is AI changing what product leaders should be measuring?

AI is changing product measurement in two ways. First, it allows us to measure signals that previously existed only in unstructured conversations. Second, it allows us to connect those signals to product behavior and business outcomes. Product leaders no longer have to rely exclusively on surveys, interviews, support tickets, and manually synthesized field feedback. AI can analyze customer conversations, implementation notes, sales commitments, product usage, support interactions, and behavioral data together. That creates entirely new measures. We can identify which promises were made during the sales cycle, whether the product delivered on them, where adoption stalled, which customer problems are becoming systemic, and what interventions are most likely to improve the outcome.

These capabilities also make measurement more dynamic. Once an organization identifies and resolves one source of friction, the next constraint emerges. The KPI itself may evolve as the business becomes capable of seeing and solving new problems. That is particularly important for CIOs and transformation leaders. Many know they need to lead change but are looking for partners who can help determine what to measure, interpret what the signals mean, and identify the next action.

The most valuable product organizations will not simply report what happened. They will continuously identify what is changing, explain why it matters, and recommend what the business should do next.

As AI becomes more embedded in how products work, how do you see the role of product and design leadership evolving?

The role of product and design leadership is expanding. For years, we largely designed software that waited for users to operate it. We are now designing systems that interpret, recommend, act, learn, and increasingly participate in the work itself.

That requires a broader form of leadership. Product strategy, design, AI, customer experience, go-to-market execution, infrastructure, and organizational transformation can no longer be treated as separate disciplines.

The opportunity is not simply to ship more capability. It is to design the complete system through which a business becomes more intelligent, more adaptive, and more capable. The leaders who shape the next generation of products will be those who can make complexity coherent, make intelligence trustworthy, and make transformation adoptable.

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.

Everyone says good PMs have product sense, but how many people can truly define what good product sense is?

In this episode, we’re joined by Kevin Sung, VP of Product at Life360, where he runs ecosystem strategy, the foundational infra and developer experience group, and works alongside the AI platforms team. Before Life360, Kevin spent several years at Dropbox, leading the Usability team that owned performance, reliability, and CX.

Kevin’s worked in both the goal-seeking world and the customer-obsessed one, and he’s clear about which one AI is about to make obsolete.

In this episode, Kevin shares:

• Why product sense is customer centricity

• The difference between lazy product management and rigorous product craft (hint: it’s how strong your opinion is before you start)

• How his team at Dropbox found $24M in ARR hiding in a cohort nobody was looking at

• And how to get leadership to fund the unglamorous quality work that never wins a roadmap fight

1. If your job is running every permutation, AI already does it better

Kevin isn’t in the doomer camp on AI and PM roles. But his reasoning for why the job survives is sharper than the usual reassurance.

AI removed engineering headcount as the bottleneck on learning — you can prototype and validate in days instead of quarters. That doesn’t reduce the need for judgment.

“In a world where you can now ship lots and lots of ideas quickly, it becomes even more important now to have really strong product sense and customer centricity in order to decide that you are shipping the right things.”

He’s skeptical of the 10x-your-experiments crowd for a specific reason: someone is on the other end of all those experiments, and a product that changes on you every day makes them a test case. Then comes the line that should make a few PMs uncomfortable:

“If all you’re doing is facilitating maximalist tests, an AI will always outperform you, because they will be able to come up with every permutation and actually ship it. So then you are actually obsoleting your own job.”

Product takeaway: Audit what part of your team’s week goes to generating and coordinating options versus deciding between them. The first half is getting automated. If your PMs can’t articulate a customer-grounded hypothesis before an experiment runs, you don’t have a product function — you have a permutation engine.

2. Lazy product management vs. Product craft

Kevin has a refreshingly straightforward definition of product sense:

“What is product sense? It is customer centricity. It is understanding a customer’s painful needs and being able to translate that into business value [...] One of the big differences between the two is the strength of your opinion, and that opinion is based on your understanding of what a customer’s needs are.”

The rigorous version sounds like this: based on what I understand about this customer’s life, here is a painful problem, here is my hypothesis for solving it, here’s how their behavior should change, here’s the business impact. Then you find out whether you were right — and either way you get smarter.

The lazy version outsources all of that to volume. Kevin points out this predates AI entirely; it’s the same instinct that had teams running a hundred A/B tests a day and Google testing shades of blue. AI just made it cheaper.

There’s a second-order risk too. If everyone lets the same handful of models generate their ideas, everyone’s product converges.

Product takeaway: Make the hypothesis a required artifact, not an optional one. Before anything ships, someone should have written down what they believe about the customer and what behavior change would prove them right. That document is the difference between learning something and generating noise — and it’s the part a model can’t write for you.

3. Don’t let data quietly become a spreadsheet maximization game

At Smule, Kevin led growth in an environment he describes candidly as goal-driven: here’s a number, find twenty ways to move it. When a key metric dropped, they’d spin up a tiger team and build a list of hypotheses.

And then:

“Seven times out of 10 the culprit would be found by ultimately one of us running through the app itself, going through a flow, and being like, ‘Oh, this is clearly the thing that was broken.’”

His conclusion isn’t anti-data. It’s about what happens when data is the only input.

“If all you do is look at data and you use data to then double-check other data and form hypotheses on that, and you’re not talking to the customer, you’re not experiencing the product yourself, you can very easily just turn this into a spreadsheet maximization game.”

Dropbox showed him the other model — real-world Wednesdays, a large user research team, an expectation that you talked to two to six customers a week. He also makes a sharp distinction about growth work itself: growth is gasoline on a fire. If the product genuinely solves a painful problem, growth accelerates it. If it doesn’t, you get a pop and a drop.

Product takeaway: Put a standing constraint on your team that every metric investigation includes someone actually using the product through the affected flow. It’s the cheapest debugging step available, and it’s the one most often skipped — and if your instrumentation can’t tell you where users are struggling without a manual walkthrough, that’s the real finding.

4. Resentment compounds over time

At Dropbox, Kevin led a group called Usability, spanning key user journeys, service performance and reliability, and the entire out-of-product experience — because your relationship with a product includes every moment you’re outside of it trying to get help. The team spent a year making lots of small things better and produced roughly $24 million in ARR from churn reduction alone.

The hypothesis they pitched it on was wrong.

They’d argued that first impressions matter most, so the gains would show up in month-one and month-two retention. Those numbers didn’t move at all. What moved was month 13+ — fifteen years of accumulated customers, improving by roughly half a percentage point. At that population size, half a point was eight figures.

Kevin’s explanation for why is the part worth stealing. Their time-to-visual-complete metric averaged around 15 seconds globally, and every one of those slow loads was a small deposit:

“These things create moments of what I call moments of resentment. Like, man, all my files are stuck in here. I can’t remove them, but I’m frustrated, but I can’t leave you. And then it just builds up and builds up and builds up.”

Frustrated-but-locked-in users don’t churn on the day they get frustrated. They churn on the inciting incident — an outage, a trust-breaking event, a price increase. The price increase doesn’t cause the churn. It collects on years of resentment.

Product takeaway: Your loyal users absorb the most accumulated friction, and their churn stays invisible until something triggers it all at once. Before your next price change or migration, ask what the resentment balance looks like on your longest-tenured cohorts — a small lift on a very large denominator usually beats a large lift on a small one.

Chapters

00:00 Introduction
04:06 Defining "product sense"
07:45 How the PM role is evolving
10:20 Kevin's growth lessons from Smule
14:22 The $24M retention bet
18:29 Resentment builds until users snap
22:38 Selling a bet you can't model
24:36 Enshittification and paper cuts
27:51 Life360, where trust is the product
32:23 Conclusion

Links

• Kevin’s LinkedIn

• Life360

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.

Today, Anthony is responsible for advancing Equitable Advisors’ vision for a modern, integrated digital ecosystem that brings together advisor enablement, client experience, wealth management strategy, and product innovation to help advisors deepen relationships, operate more efficiently, and deliver greater value to clients.

In our conversation, Anthony discusses how AI is changing expectations around speed without changing the fundamental role of financial advisors. He talks about why product teams should focus on solving real workflow problems before introducing new technology and why measuring business outcomes matters more than measuring adoption. Anthony also shares why trust remains the foundation for the adoption of advisory technology.

Designing for outcomes, not AI

You’ve led digital product strategy across several of the largest wealth management organizations. What expectations do advisors have today that simply didn’t exist before AI became mainstream?

Both the clients’ and advisors’ expectations have changed, but not so much in terms of the output, final product, or engagement mechanism. That hasn’t changed in many years, but how we do it surely has. How quickly things evolve has changed significantly as well.

As we’re still in the early innings of what AI really means and what it will become, expectations from advisors and clients are primarily about speed. It’s the ultimate output and how you get to it, how it can be delivered from a service offering or relationship management perspective. What could have been developed or produced previously in two weeks can now sometimes take two hours.

A lot of firms and teams want all of the latest and greatest, and they want it yesterday. That mindset hasn’t changed, but the expectations for what it would take for large enterprises to provide this level of support have changed.

It’s up to us to stay grounded on the “why.” Why are we doing something? Why are we enabling something faster today than yesterday? That allows advisors to understand it’s not just “do it because.” It’s because of what it enables — a new feature, a new part of an advisor’s practice that they couldn’t provide to clients before. Ultimately, the speed at which it has happened is the big difference.

Many organizations are adding AI features everywhere. Why do you advocate rethinking workflows first?

I feel very strongly about this. Again, the important question is, what’s the why? It’s not technology for technology’s sake or AI because everybody else is doing it. It truly is about determining which processes are fragmented today or don’t exist. Maybe you want to scale your practice from supporting 150 clients to 300, and you think creating a new workflow or adding automation using AI will make the difference.

It’s about identifying what your problems and opportunities are, and how you can solve them. Often, it can be solved by AI or other technologies. Other times, however, it’s not technology at all. We all know the fastest way from point A to point B is a straight line, but oftentimes finding point B is the most difficult part.

Is what keeps product leaders up at night different today than it was a few years ago?

I think the problem is the same, but how it gets solved has changed. From a product leadership standpoint, that’s the dynamic culture we live by. We understand each day what changes, what moves, what’s different, and what’s similar. That’s the beauty of the world we’re in — it’s never the same workday.

Where we provide value is evaluating the landscape, seeing how something works in our space, and continuing to evolve. Before, we could have been in the evaluation stage for a year or 18 months. Now, the company we’re evaluating might not have even existed 18 months ago

Even the number of technology options has grown exponentially. Every day new companies emerge because it’s much more efficient and faster to build a platform and provide an offering. The differentiator becomes: How do you scale it? How do you future-proof it? It might be the right solution today, but how do you ensure you’re still here tomorrow? That’s something everyone should be thinking about continuously.

Building an adoptable advisory platform

Advisors have different business models, client bases, and levels of maturity. How do you design a platform that feels standardized enough to scale but adaptable enough to serve very different ways of working?

Advisors have always been unique and intricate. They’re ultimately business owners running their own companies. For firms and teams like mine, we are the advisor’s business partner — we support them in their independence. Even if we look across 10 different advisor practices, each one could have five advisors. Very quickly, a multitude of variations emerge.

There are certain ways of doing business where we say, “We support you. We provide different tools at your disposal,” whether that be people, process, or technology. We cover the core elements around security, governance, controls, and compliance to ensure that their practice continues to thrive.

From there, we allow optionality depending on where the practice is today. It could be growing, part of a succession plan, or changing its client base. From a platform standpoint, you need core elements that define the standard. Then on top of that, advisors can select from a menu of capabilities that plug and play to meet their needs — that’s the key.

It’s what we call a Goldilocks mentality — your best tools and best processes should be at the forefront and continuously evolving, while allowing practices to build the toolkit that’s right for them.

Product teams often focus on measuring adoption. But I would think in your case, advisor success is what really matters. How do you determine whether a new capability is helping to drive those stronger business outcomes?

I’m passionate about this. We work in a world where just because someone uses our product doesn’t mean that it’s a success. In our business, if one person is using our platform for 14 hours a day but their business is suffering, that’s a failure on our part. Maybe their usage numbers are through the roof, but they’ve lost 20 percent of their clients or can’t attract prospective clients — if that’s true, then we’ve missed the mark.

It comes back to what problem are you trying to solve? Are you trying to help advisors reach more clients in less time? If so, that’s your metric. Or, are you trying to scale knowledge more quickly or provide additional certifications? In that case, that’s your measure of success. It’s not, “Build software, people use it, and we all go home and high five.” We enable advisors to drive their businesses through the functions we create.

The other element is qualitative versus quantitative measurement. Sometimes you can’t measure success purely through facts — you also have to understand client sentiment. How are people receiving these capabilities? Often, your goal is simply for someone to feel better when they interact with your product. It’s not always about usage, and it’s also not just a numbers game.

We’re a goals-based business. If we’re not supporting clients in reaching financial success and happiness through their advisors, then ultimately we’re not succeeding.

How technology should enable people

You mentioned quantitative vs. qualitative data. When you think about what AI should automate, are there parts of the business that you very strongly feel should remain with humans?

Yes, I do, and I think this is a healthy conversation to have. We often use the terms AI and automation interchangeably, but automation has existed forever and will always continue to exist. AI, however, has become much more mainstream over the last three to five years.

It boils down to who is in the middle of that? Who is that client? Who is that advisor? Which parts become table stakes, and which parts do we actually want a professional advisor — a human being — to provide guidance, judgment, and perspective?

There are elements that AI, automation, and technology are phenomenal at, but in our world in particular, we spend a lot of time preparing for the unknown. A lot of clients will say, “Why do I want to engage with an advisor? Well, because I want to make more money.” But I think this needs to be reframed. People engage with advisors because they want to set themselves, their families, and their loved ones up for the future in the most productive, successful way possible. One day, we won’t be here anymore, and sometimes, bad or unexpected circumstances happen. People use advisors to plan for those things so that if they occur, the people they love aren’t severely impacted.

AI, technology, and tools can make all of those processes more seamless and efficient, but the human element of having a conversation will always exist. Customers and advisors truly want the balance between EQ and IQ. For example, there are many things that customers didn’t have access to before but can now access instantly through technology. The differentiator is how to put tax strategy, estate planning, and everything else into their personalized life.

We’re always going to have clients who trust AI tools, but ultimately want someone to sit with them when they go through a difficult life change or plan for the future. That’s why I believe high-EQ advising will continue to matter.

You place a strong emphasis on advisor enablement — not just on shipping technology, but on surrounding it with onboarding specialists, workflow experts, and marketing support. Where have you found product teams often overestimate what software alone can accomplish?

It’s not about who has the fastest, best, or most up-to-date technology. Of course, that’s a big part of success and our company’s accomplishments, but it’s a balance. A lot of firms actually have the opposite problem — they have the latest and greatest technology, but they’re experiencing a training problem. They can’t get enough people to understand how to utilize the product, implement it, or integrate it into their business. That technology then sits on the sideline.

That’s where having a dedicated enablement team makes all the difference. It allows advisors to say, “Here’s the problem that I’m having today,” and then determine which tools or processes to integrate into their business, whether that’s marketing support, advisory services, consulting, or digital enablement. That’s where you find the sweet spot and how you ultimately win.

It’s also no longer good enough to have one win. You have to stack wins day over day and week over week. Everything has a role to play, whether it’s the markets, geopolitical events, or broader industry changes. I’m a big believer in the team concept. The strongest advisor doesn’t need to be an absolute expert in every area — instead, they need to know how to most effectively leverage the resources around them to build the business, grow the practice, or protect it.

How do you think about trust as AI becomes part of advisor and client experiences?

We’re a relationship-based business — that’s the industry we’re in. Every firm has access to slightly different tools, products, and services, but distinctions between them are fairly small. The biggest difference-maker is the people who support you day to day, week to week, or month to month.

Trust is paramount to everything we do. We spend a lot of time building trust, and if it’s lost, it’s very hard to gain back. Neither clients nor advisors want to experience loss of trust. That’s why at Equitable Advisors we feel very strongly about continuously leading with insight and guiding with empathy.

Yes, conversations can be about the numbers, the model portfolios, and the investment selections — all of which are important. But it’s also about how the interaction made the client feel. How do we ensure the human connection remains the most important part of what we’re doing?

I often think about a story I heard where someone described their week by identifying the good, the bad, and the interesting. If all three created meaningful conversations, they felt it was a successful week. I think the same way about the advisor relationship. If something good, bad, or interesting happens, and my advisor is the first person I want to call for guidance — as well as to ensure my goals are still on track and my family is protected — that’s success. That’s where trust becomes the most important part of the relationship.

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.

“Advisor” generally describes insurance/annuity, investment sales, and advisory professionals who may hold licensing as insurance agents, registrations with broker-dealers, and registrations as investment advisory representatives of registered investment advisors, respectively. Equitable Advisors, LLC (NY, NY), member FINRA, SIPC (Equitable Financial Advisors in MI & TN), a broker-dealer // Equitable Advisors, LLC, an SEC-registered investment advisor // Equitable Network, LLC (Equitable Network Insurance Agency of California, LLC; Equitable Network Insurance Agency of Utah, LLC; Equitable Network of Puerto Rico, Inc.). Equal Opportunity Employer – M/F?D/V.

Equitable is the brand name of the retirement and protection subsidiaries of Equitable Holdings, Inc., including Equitable Financial Life Insurance Company (NY, NY) and Equitable Financial Life Insurance Company of America, an AZ stock company with an administrative office located in Charlotte, NC and Equitable Distributors, LLC. GE-9107224.1(09/26)(exp.09/30)

In this episode, we’re joined by Kunal Thadani, a product leader at Houzz, where he’s working on one of the harder consumer problems out there: helping people who have no idea where to start make high-stakes, expensive decisions about their homes.

Before Houzz, Kunal was Head of Product at The League, the dating app acquired by Match Group. He also writes Insider Growth, a newsletter that explores growth case studies from companies like OpenAI, Asana, and Uber.

In this episode, Kunal shares:

• Why “remove every step of friction’ is a rule that only works for low-stakes, stateless products — and the three-bucket framework he uses to decide where friction actually belongs

• The two ways friction goes wrong, including the one almost every company is guilty of and doesn’t notice

• Why the personal AI setups product leaders keep posting about are fragile, inconsistent, and non-transferable — and what his team built instead

• How a shared context layer in a single repo turns “five to 10 user interviews” into research at a scale PMs have never had access to before

1. Not all friction is bad: Why "remove every step" only works for low-stakes products

Product-led growth often says to strip out every step between the user and their “aha!” moment. Kunal’s experience working on fintech products taught him that this advice assumes a kind of product most teams aren’t actually building:

“What fintech has really taught us is all friction is not bad. Classic product and PLG thinking says, ‘Hey, remove every step.’ And that works well when the product is very low stakes and it’s stateless.”

Home decisions, loan applications, identity, money movement, fraud, underwriting — none of these are stateless. They have consequences in the real world, and often the user has to wait on something happening outside your product entirely.

His framework has three buckets:

1. Required steps can act as trust signals.

2. Delays can be turned into progress arcs.

3. Constraints can be commitment moments.

Product takeaway: Before you delete a step, ask what job that step is doing. Friction that signals trust, fills a wait, or marks a commitment is doing work that a smoother flow won’t do for free. The question isn’t “how few steps can this be?” — it’s “which steps earn their place?”

2. How splitting one ask into two decisions 10x'd our conversion rate

We told Kunal about how LaunchPod itself got validated. We put a modal on the LogRocket blog asking if people wanted a podcast and requesting an email. Conversion was atrocious.

We nearly killed the idea. Then someone suggested splitting it: ask for a yes/no first, then ask the yes’s for an email. Email conversion went up more than 10x — by adding a step.

Kunal’s read on why:

“What changed wasn’t the UI. It was more about the psychology. When you asked for the email up front, the user had to make two decisions at once: Do I even want this? And do I want to hand over my contact information to this company?”

Separating the two removed the cognitive load from the first decision — and once someone has said yes out loud, the ask lands differently.

But he was careful to bound the lesson. At The League, the team ran a live speed dating product where interest was easy to collect and attendance was not.

“If it’s a feature where you’re actually getting people to pay, I’m pretty bullish on: you still separate the decisions out, but how do you collect some sort of down payment?”

Their fix was a $4–5 ticket to join the waitlist. Low enough not to gate anyone out, but high enough that people actually showed up.

Product takeaway: Splitting a big ask into a small one and a bigger one reliably lifts top-of-funnel numbers. Just don’t confuse the lift with real demand. If the downstream behavior you care about is showing up or paying, put a small, real cost in the flow — otherwise you’re optimizing a metric that stops predicting anything.

3. The two failure modes: Friction that serves you, and friction that doesn’t

Kunal isn’t arguing that friction is always underrated. He has a sharp view of where it goes wrong, and it’s two specific failure modes:

The first is friction that’s dressed up as care but exists to serve the company. Cancellation flows are a popular case: hit cancel, get an offer, decline, get a discount, decline, get a downgrade option.

“It’s being framed as more like just making sure — versus, hey, helping you understand what you’re actually giving up.”

His version of an honest cancellation flow is one that tells you exactly which features, workflows, and automations stop working, and on what date. Same number of screens. Completely different intent.

The second mode is subtler, and almost everyone is guilty of it: friction that was legitimate once and never got dialed back after trust was earned.

“If I’m already a loyal verified user and you keep making me reprove myself, re-verify, re-KYC every time, it ends up being less protective and starts to feel more like, ‘Hey, you don’t trust me.’”

Product takeaway: Audit your friction on two axes: who does it serve, and is it still calibrated? Protective steps should decay as trust accumulates. If a verified two-year customer hits the same gate as a stranger, that’s not security — it’s a system that never learned anything about them.

4. Why personal AI setups don't survive an org and what a shared context layer fixes

Product leaders nowadays are asking, what are you actually doing with AI? A common answer is “I built my own personal OS.”

Kunal’s problem with that answer is that it doesn’t survive contact with an org.

“Everyone is building personal AI setups, but even at these dinners with product leaders leading the internal AI charge, very few are focused on what that operating system looks like at scale. When you start to build individual OSs, they’re pretty fragile, they’re inconsistent, they don’t have a centralized context layer — and a lot of the value just walks out the door when the person who built it leaves.”

So his team built a shared one. Claude Code, one GitHub repo, and non-engineers living in the terminal.

Product takeaway: The thing that makes an AI setup an asset instead of a personal habit is that the context lives somewhere other than one person’s laptop. And when you hit retrieval costs, reach for better routing before you reach for summarization — compressing your source material is how you quietly lose the details you built the system to find.

5. Research at scale, no handoff tax, and a feedback loop that compounds

The gains Kunal describes aren’t marginal speedups on existing work. They’re access to work that wasn’t previously possible.

The biggest one is research and validation. By piping Gong data into a database his agent can query, the team can sift every closed-lost conversation to find where deals died — and rank product gaps by how many sales each one cost. Same on the retention side, mining customer success calls for what churned users were vocal about.

“What we used to get was five to 10 user interviews. But now you’re getting it at scale and much quicker.”

The second change is to the shape of the PM role. Kunal frames the old model in terms of a tax:

“Every time you have to work with another cross-functional team, you’re paying that handoff tax of re-explaining that feature.”

When product marketing, sales ops, and data science all draw on the same context, that re-explanation mostly evaporates.

The third is a compounding effect that only exists in the shared version. When the AI drafts something and your judgment differs — a Slack message with the wrong point of view, say — you correct it in the system, not just in the message you send.

Product takeaway: A team OS isn’t a personal OS with more seats — it’s a different asset with a different payoff curve. The individual version improves at the speed of one person’s corrections. The shared version gets a feedback loop, and that loop is what turns a clever setup into institutional capability.

Chapters

0:00 Introduction
3:23 Why "remove every step" falls apart when the stakes are real
5:51 Three kinds of friction that actually help
6:39 Same verification steps, completely different framing
12:29 The two ways friction turns toxic
13:28 What a cancellation flow should tell you instead
14:39 When re-verification punishes your most loyal users
17:52 Everyone's building a personal AI OS, nobody's building one for the team
23:57 Using Claude Code to mine sales calls and cut the handoff tax
28:27 Why feedback loops get faster with every person you add
29:49 Conclusion

Links

• Kunal’s LinkedIn

• Insider Growth Group

• Houzz

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, Will discusses how experimentation evolves as organizations scale and why leadership mindset is the foundation of a successful experimentation culture. He talks about how GoPro reduced time-to-market while creating more capacity for experimentation, and shares his learnings from unexpected outcomes.

Building an experimentation culture

You’ve had experience in experimentation programs from several vantage points — as a consultant, as a transformation leader at Gap, and now leading GoPro’s Digital Product team for the ecommerce site. From your perspective, what’s changed about what makes experimentation successful?

The first thing that comes to mind is my early days as a consultant. I was fortunate to work at a boutique agency that specialized entirely in experimentation and personalization. We worked with organizations like Barnes & Noble, Ralph Lauren, Under Armor, and Fidelity.

At first, it was hard to understand what test to run and where to start. It was very confusing until I realized it really comes down to the customer. Every organization has unique customers who expect different things and want different experiences. The thread that’s remained the same throughout my career is understanding the customer and meeting their needs.

One thing that’s changed is my perspective on scaling. As a consultant, I used to think, “Why don’t these companies just double their experimentation output? We could go from four tests a month to eight tests a month tomorrow.” Then I worked at Gap, with four global brands, and now at GoPro. You realize the complexity of the organization itself often becomes the blocker to increasing experimentation velocity. As a consultant, I had the luxury of focusing on one objective. Within a large organization, you appreciate just how much coordination is required to scale experimentation.

When you’re driving experimentation, at what point does it become part of the culture?

I think a really important factor is leadership’s disposition toward data and experimentation. I’ve worked with leaders who know experimentation very well and are really gung-ho about it from the beginning. I’ve also worked with leaders who don’t have much experience but quickly understand the logic behind it. In both types of organizations, experimentation thrives.

Where it gets difficult is with leaders who have been in the business for a long time and think they already know how it works. They have a roadmap from past experience and come in ready to check the boxes because they believe they already know the outcome. In that kind of environment, there’s less room for experimentation.

Experience can absolutely inform decisions, but there’s got to be a real humility around the uniqueness of each organization. What worked somewhere else — or even what worked before in the same org — doesn’t necessarily translate to the current situation. That’s where experimentation becomes much harder to gain traction.

Many organizations say they want to be data-driven, but still make roadmap decisions based on the loudest voice in the room. What separates companies that run experiments from those that make decisions through experimentation?

I think the difference is what I call a culture of experimentation. That means making experimentation visible to everyone. Everybody can submit ideas and guess which experiment will win. Everybody can see the results. Sometimes that’s through emails or polls, and sometimes through more formal meetings or forums. Not everyone participates, but that openness and transparency are really important. In organizations that embrace that mindset, experimentation starts to replace the loudest voice in the room.

Learning from unexpected results

Throughout your career, you and your teams have driven significant improvements in conversions, engagement, and customer satisfaction. Can you share an experiment or product decision that surprised you?

Sure, there was one experiment that almost didn’t happen because so many people thought it wasn’t worth testing. The idea was to add a recommendation carousel to the order confirmation page. People said, “They’ve already made a purchase. Why would they buy again?”

What got people on board was the strategy behind it. There is no point during a visit when you know more about a customer than after they’ve completed a purchase. You know what they browsed, what they bought, how much they spent, and whether they’ve been there before. This was for Barnes & Noble, where the average order value is relatively low. We ran the test, and it produced a statistically significant increase in revenue. As far as I know, it’s probably still on their site today.

Again, it comes back to understanding the audience. These are readers — they’re much more likely to add another book to their order than someone who buys a product only once.

On the product side, one of the biggest changes at GoPro was the introduction of an NPS score for our ecommerce site. We had already measured NPS for our customer service call center, but we hadn’t measured it for the website experience itself. We implemented a quarterly NPS survey, and that gave us a consistent benchmark for the site’s experience. When the score improves or declines, we can pair it with behavioral analytics to understand why.

Your team has also significantly reduced time-to-market. How did you accomplish that?

It was a very focused effort, and I’d like to give credit to our principal product manager, Brandon Watts, who led much of this work. We started with a survey asking teams which parts of their work took the longest and how much time product launches required across UX, Merchandising, Engineering, and Studio.

The responses quickly pointed to one bottleneck in Merchandising. Creating product detail pages inside our CMS required navigating six or seven layers just to add images or content. We focused our effort there. By simplifying that workflow, we reduced the time required to create those pages by more than 50 percent, which was a huge win for the team. The Merchandising team now has more time to focus on higher-value work, including experimentation.

Scaling experimentation across organizations

At Gap, you had four distinct brands under the company umbrella, including Banana Republic, Athleta, and Old Navy. How does experimentation change when you’re optimizing for a diverse portfolio of customers vs. a single, deeply engaged community like at GoPro?

GoPro has one experimentation program with a tight group of stakeholders across Product, Merchandising, Studio, and Engineering. Because we all understand the same customer, company strategy, and KPIs, we can move very quickly.

Gap was very different. I led the personalization pillar across Gap, Banana Republic, Athleta, and Old Navy. Those customer personas are completely different. A win for Old Navy — something like promotional badging or urgency messaging — fits naturally with that brand. The same experience could feel completely out of place at Banana Republic and even weaken the brand.

That’s one of the biggest differences when you’re scaling experimentation across multiple brands. It’s not just about finding wins. It’s about getting stakeholder alignment while respecting each brand’s identity.

Many experimentation programs optimize conversion or click-through rate. How do you make sure teams are improving the overall experience?

I’m still surprised when I see roles focused exclusively on conversion rate optimization. Conversion isn’t the end-all metric for retail organizations. It’s actually fairly easy to increase conversion if you’re willing to sacrifice revenue. A retailer could push more people to buy less expensive accessories rather than higher priced flagship products. Conversion might improve, but the business will lose overall. The right KPI drives the right improvements. One metric I really like is revenue per visitor because it combines revenue and traffic into a single measure. It accounts for changes in average order value and conversion together, rather than optimizing one at the expense of the other.

I’ve also become a big believer in measuring NPS directly on the website. Customer lifetime value can also be valuable, but it’s less clear cut. Organizations calculate it differently. The important thing is making sure the calculation actually reflects the holistic value of your customers to your business.

AI, strategy, and scaling responsibly

As AI makes experimentation faster and cheaper, how do you distinguish productive experimentation from experimentation theater?

It comes back to strategy. Whether a test wins, loses, or ends up flat, you should learn something from it. If you’re not generating insights regardless of the outcome, you’re probably not spending your time wisely.

The second part is ensuring you can sustain the winning experience. Organizations often realize they can personalize experiences for 15 different customer segments. That’s exciting until you ask what it means for UX, Merchandising, Localization, Engineering, and Studio.

Before we run a test, we ask whether the winning experience is something we can realistically maintain over time.

Lastly, what’s the biggest mistake leaders make when trying to scale experimentation?

The biggest mistake is shortchanging strategy or analytics. AI can generate fifty creative variations in seconds. The bottleneck isn’t producing assets anymore, but if your tests aren’t strategic — if they aren’t designed to teach you something regardless of the outcome — you’re moving too fast.

The same applies to analytics. If your analysis starts to degrade because you’re running too many experiments, or you’re no longer using those insights to shape future tests, you’ve scaled beyond what the organization can support. The moment strategy or analytics begin to decline, I’d pause any further scaling.

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.

On a Friday, one of Miro’s architects pointed a bunch of agents at the company’s AI engine and rebuilt it. He demoed it Monday. There was a kickoff Tuesday. A few months later, it was the headline of Miro’s user conference.

What’s interesting is what Miro didn’t do in response. No reorg, no new framework, no AI-native process. Just the same three milestones they’ve always had: kickoff, solutions review, and pre-release review before launch.

Our guest today is Jeff Chow, Chief Product and Technology Officer at Miro. He leads product and engineering at Miro, which helps cross-functional teams work together, making it an unusually good place to watch what AI is actually doing to how teams build.

In this episode, Jeff shares:

• Why he froze Miro’s process on purpose and replaced the artifacts instead

• What problem with only working with an agent that agrees with everything you say (AKA the “yes-man” agent)

• How “process barnacles” build up as you scale

• And why saying “no” is about to become the hardest job in product

  ---

1. Don't change the milestones. Change what shows up at them.

Miro runs three milestones: kickoff, solutions review, pre-release review. Jeff has deliberately left them alone.

“A big part of our early tenets was we’re not gonna change that. It’s the shorthand of the organization. You can just say, ‘Oh, we have a solutions review next week’ and everyone gets it.”

What did change is the artifact. Jeff’s description of the old solutions review will feel familiar:

“The PRD plus maybe 50 art boards of a Figma file. Maybe you have a product manager reading off of slides, and then the designer goes through the art boards like it’s a flip book, and then 45 minutes pass, and we’re all a little bit dead in the eyes.”

Now, PMs show up with a working prototype on real data that a few teams have already tried, plus a vibe-coded fake landing page that forces them to tell the story.

Product takeaway: Before you redesign your whole process for AI, ask whether the meeting is the problem or the thing you bring to it usually is. The ritual is a shared context, is expensive to change, and is rarely the bottleneck.

2. Your agent isn’t a stakeholder. So don’t treat it like one.

Here’s a failure mode that didn’t exist a few years ago: someone spends a week building with an agent, walks into the kickoff, and is genuinely confused when the team still wants to debate it. They feel aligned. They’ve been collaborating for days — just not with any humans.

“Your agent’s like, ‘Great idea, Jeff. You’re a genius. Wow, why didn’t I think of that? You’re so wonderful.’ And clearly you didn’t put the contrarian skill in, so literally it’s just blowing smoke...”

The fix Miro landed on is being explicit about what a given conversation is for. The prototype is there to communicate why and what — not how. Early on, kickoffs kept turning into design crits, with people relitigating button placement in a meeting meant to decide whether the problem was worth solving at all.

“People are like, ‘Well, technically, is that the button you’d put there?’ And it’s like, wait, are we really doing this right now?”

Product takeaway: Easy agreement from a model isn’t validation. Build the disagreement back in — a critique step, a sub-agent told to argue the other side, a named skeptic in the room — and say out loud what you’re trying to decide before you show anything.

3. Most of your process exists to prevent expensive mistakes

Jeff’s read on why product orgs look the way they do is that almost every ritual is risk management wearing a rigor costume.

“Annual planning, OKRs, all the way down to certain roadmaps — it’s all about making sure that if we’re gonna really invest that much money on this project, it better work. Without realizing it, it becomes an optimization culture instead of an invention culture.”

That made sense when a bad bet cost a quarter of engineering time. It makes less sense now, but the process doesn’t update on its own.

“What we have to do is just embrace the fact that actually it goes so much faster. You should take more ambitious risks.”

The part Jeff seems most energized by isn’t ICs swinging bigger — it’s that his leaders are now pushing their teams to think bigger, which he says he never really saw before. The old default was five tweaks to a button because that’s what the conversion target asked for.

Takeaway: Go through your planning rituals and ask what each one was invented to protect you from, then check whether that thing is still expensive. Some of it is load-bearing. Some of it is a premium on a risk you stopped carrying.

4. The Friday refactor that became a keynote

Which brings us back to the story at the top. Miro’s big agentic push didn’t come out of planning.

“One of our AI architects just decided one day to get a bunch of his agents to work and refactor our AI engine, and then demoed it to us. It was basically a Friday. Monday, he’s demoed it, and we were like, ‘Okay. Here we go.’”

It unlocked something the team had assumed was years away. Ask Miro to run a retro now, and the agent pulls the full project history onto the board next to it — a week of human work — so the team can argue from actual data.

But Jeff is clear that the interesting part is the org’s response, not the tech:

“It’s not just technology helped create that, but an IC engineer invented it, brought it to the table, and then cross-functionally we were willing to yes-and that experience.”

He has a great name for what usually happens instead: process barnacles.

“You start developing the process barnacles where maybe it’s like, oh, here’s a big bet, and maybe it didn’t work the first time. And then your next thing is not to, like, let’s Apollo 13 and throw the scraps on the table and try to solve the problem. It’s to have a meeting and talk.”

Takeaway: Your constraint probably isn’t ideas — it’s whether an unfunded thing that already works has anywhere to go. When someone shows up with a demo nobody asked for, the useful question isn’t whether it was on the roadmap. It’s how fast you can get it a kickoff.

5. Saying “no” is the next organizational crisis

Here’s the flip side Jeff sees coming.

“If everybody can do something, how do you say no?

When building is cheap, everything looks one more push away from working. Someone has to call it.

His answer to who does that: he thinks of product orgs as fractals. An APM polishes one small rock. A GPM has more rocks. A director has more still. Jeff’s own job is the same shape, just at a bigger scale.

“There’s no, ‘Are you a top-down decision or a bottoms-up kind of organization?’ We’re collaborating at different altitudes.”

That’s why a solutions review at Miro isn’t a gate — the point is to let people cook. But when the answer is no, it comes with a reason a person can actually hear. Internally, they call it explaining it over beers.

“You need to have a human element where you’re explaining it to a normal person. No weird syntax.”

Takeaway: Scarcity used to do your prioritizing for you, and it isn’t anymore. Get explicit about who kills work, what evidence they need to kill it, and how that reasoning gets shared. A clear “no” costs you one uncomfortable conversation. A “no” that nobody's willing to give costs you the roadmap.

Chapters

0:00 Introduction
1:55 Jeff's product path: From founding three businesses, joining Google, TripAdvisor, InVision, and now Miro
4:20 Why Miro refused to rebuild its process around AI
7:20 What shows up at kickoffs and solutions reviews now
14:15 The false confidence trap: Say no to "yes-man" agents
16:30 From optimization culture to invention culture
20:20 How one IC's side project reshaped Miro's AI engine
24:30 "Product barnacles" and why saying no is the next crisis
29:30 Conclusion

Links

• Jeff’s LinkedIn

• Miro

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, Lisi talks about what it really takes for a smaller company to compete against dominant players — not by copying them, but by staying closer to customers, moving faster, and knowing when to say no to a feature request. She discusses the discipline behind Singular’s product decisions, the self-serve platform that helped drive 70% year-over-year growth in the mid-market, and how the company decided to invest ahead of Apple’s IDFA changes. Along the way, she reflects on what separates a good product manager from a mediocre one.

The David and Goliath advantage

What kinds of advantages can a smaller company realistically create through product strategy, rather than trying to out-build larger competitors?

This is a really fun question because it’s something we internally debate all the time. If you take a business class, they’ll tell you that if there’s a dominant player in the industry that owns anywhere between 60 to 80% of the market, that’s a total blocker — don’t go into the market. But you see throughout history over and over again examples where these disruptors come in and go from being the small player to being the dominant player. I think there’s a bit of a middle path where you can leverage your strengths to become a significant enough player within that market space. What’s really important is being very creative about your strategy and having a clear understanding of what your strengths are.

You can’t tackle things effectively by being a copycat company. If you’re going to continuously chase after that larger company, you will not succeed. You have to figure out what niche you’re going for and hack your way into that. But you have to have that disruptive mentality and really understand what the added value is, and what your unique take on the problem space is. If not, you’re always just going to be just chasing after the larger competitor and you’ll never be able to catch up because you won’t have the same resources that the larger competitor has.

Do you have explicit decision criteria that help keep roadmap decisions from becoming overly competitor-driven?

There’s theory and then there’s reality. It’s always funny because I hear all these product interviews and they’re like, “Yes, we have this framework and this is how we work.” But, to really be strategic about the product choices you make, you have to be able to pivot, which is the worst thing any product manager ever wants to hear because we do like to have that stability. The biggest strength you have as the smaller incumbent is that you can pivot and be more agile. So you do need to have a balance. If a new customer comes in and they’re willing to pay for whatever it is that you’ve figured out, you build that.

I know a lot of product managers will tell you that’s the wrong thing to do, that you don’t want to constantly be swapping out tasks and initiatives and having distractions as you go along. But I think it can also work to your advantage, because if you stick too much to a framework, it makes you too static. It doesn’t give you the flexibility you need to move fast. Especially in the marketing world, where the industry is changing a lot. Being agile is one of the really great things we’ve been able to leverage — working with our partners to understand what’s coming and being proactive about the changes we need to make.

So it’s not necessarily that we have an explicit framework, but it’s more about making sure we’re on top of all the changes coming through so we have a good position in the marketplace and we’re ready for it.

If a competitor makes a change, how do you decide whether it deserves a response or is just a distraction?

This is really what comes to the core of our product theory. Our biggest focus as a product team at Singular right now is that no matter what, we’re always obsessed with our customers. That’s originally an Amazon quote, and I really love it, because it means we are constantly prioritizing customer calls, joining whatever QBRs or sales calls we need to go to, and really listening to our customers.

This does two things. One, it’s understanding when there’s a feature out there that we need to determine if we also need to have it versus it’s just noise. Is it actually being adopted? Is it actually providing value to customers? You will not know until you talk to a thousand of those customers to understand if there’s really value there.

Having a competitor build something out first also gives you the ability to really analyze what they did well and what they didn’t do well, and then you can iterate and come out with a better solution. It’s not that you’re just being a copycat for whatever’s coming out — you understand the problem that was solved and then figure out how to do it better. Sometimes it’s better to be second to market and have a better product for it.

Saying no to the loudest requests

Can you give an example of a time you intentionally chose not to build a feature customers were requesting, because it would have diluted your product’s positioning?

This happens a lot with features that are buzzwords. Specifically in the marketing industry, we’ve been hearing the word “incrementality” for several years now. How do you measure incrementality? What’s your incrementality report? But when you start having conversations with customers to really try to tackle it and break it down — “What does incrementality mean to you?” — you realize it’s not one thing. It’s the same with AI: what does AI mean, or AI analysis? We can say it because it’s part of the hype, but if you’re not really breaking it down to the core of what you’re trying to solve, then it’s just a buzzword.

It’s more than just listening to what people are talking about — it’s also being able to really synthesize the information you’re hearing from all these calls with different customers to come up with a product that’s going to serve them best. A lot of times, the issue with customer calls is you can’t take the feedback at face value. You have to understand what’s underneath it. That’s really the difference between a good product manager and a mediocre product manager — especially in this AI world. OK, you take amazing notes and really listen to what they have to say, but what are they actually saying?

How do you validate whether something is worth building — probing questions, or watching users in action?

Ideally, it would be great to validate that by putting out a prototype or some sort of beta and having customers actually use it. That’s the real key: you know a product works if people come back and use it over and over again. But a lot of times, you may not have enough time to validate things as much as you’d like. That’s where I’m a big believer in being able to break things fast — launching with smaller MVPs and seeing if that small version is good enough, then iterating from there, because it doesn’t make sense to work on something huge and then find out nobody wants it.

Is moving fast ever a detriment?

For sure. Internally, sometimes we become sort of myopic. I hear this feedback a lot: “We’re putting out a lot of betas but then we don’t finish fully going to market with a complete feature.” I don’t actually see that as necessarily a bad thing, because you’re trying things out and seeing what works, and that’s what it means to be agile.

The downside is making sure that, internally, you’re keeping the right motivation, because working like this can sometimes feel chaotic. You need to be clear about what the objectives are, what you’re moving toward, and what the logic is behind some of the decisions you’re making. Sometimes you pivot in a way that isn’t so classic and it feels a bit random, but I think that really marks the strength of being able to think outside the box.

Building a culture that can pivot

Is it easier to push new tools through in an earlier-stage company?

It’s definitely that startup mentality where it’s an organized chaos. You give everybody the freedom to do whatever it is they need to do to get it done — we don’t necessarily have an organized process. We have certain values we know are important to us as an organization, but you have to give people the freedom to explore, try things out, and get things done on their own, as long as they’re accountable for the outcomes of their actions. And it works.

A lot of what I’m saying might be going against the classic way of doing product, but I feel like it’s really critical to be able to see the long-term — to understand the problem you’re trying to solve and not focus so much on the day-to-day task, the feature you’re working on at hand. To do that, you need to be a little bit more disruptive in how you think things through. Sometimes it’s having uncomfortable conversations, because people get very attached, in a good way, to what they’re building, and it hurts to have to pivot to something completely different.

Is it harder for product people with a background at a more traditional, enterprise company to move into an experimental environment, or the other way around?

Yes, definitely. I suffered that at first when I started working at Singular. I came from a much larger, enterprise-style company and I didn’t understand the chaos. Now I’ve fully embraced the chaos.

Sometimes we get too caught up in the process and it’s not an efficient use of our time. Sometimes it is, and you have to be able to make a decision and understand: is this providing value or not? But if you can’t back it up, you can’t articulate the value of it, and nobody else agrees with you, then you should toss it out.

Winning the mid-market

You launched a self-serve platform that helped drive roughly 70% year-over-year growth in the mid-market. How different is the product strategy when you’re trying to win customers who could very easily choose a much larger vendor?

It’s two completely different personas. Especially in the B2B space, if you’re working with very large enterprises, the decision-making they do — “I need to find a new vendor; how do I choose a new vendor?” — they’re never going to get criticized for choosing the industry standard, the go-to for everyone. But people from smaller-scale, more mid-market companies that are just starting out, especially in the mobile world, are looking for value for free or value for very little money. They don’t want the same features, they don’t want the same pricing, they don’t want the same plans. You have to understand what they want to be able to serve them differently.

Did that experience change how you think about different customer segments?

Yeah, definitely. This is a common B2B dilemma: What do you focus on to win an account over? If someone’s waving money in your face, you’re like, “Yes, let’s do it.” But if it’s a feature request where only one enterprise customer is going to be using it, it doesn’t make so much sense to build it out. It really depends — you have to weigh the decision. But, generally speaking, if we get a product feature request from one customer, we do our best to validate it with other customers. If it’s useful for them as well, we try to determine if we can build something that serves more than just one customer. That really helped us change our mindset, because we realized we needed to stop overly customizing the product specifically for enterprise and build something that has more value for different segments.

When you focus on it as segments, you’re not customizing to fit one customer — you’re building out a product that serves more than just one.

Reading industry shifts

Attribution, privacy regulations, AI, and platform policies are constantly reshaping the mobile marketing landscape. How do you distinguish between changes that warrant a strategic pivot and short-term disruptions that simply create noise?

Sometimes it’s really hard to tell. That’s where being small also helps because the communication isn’t as diluted in a small company. If there’s going to be a big change in the industry, we try to figure out how it’s going to affect partners and potential customers. We can go to the different teams and get feedback right away.

For example, when Apple initially released the changes where they removed the IDFA, the device model ID used for attribution, everyone was panicking. We knew it was coming and we invested quite a bit. A year or two after that, things changed again, but I don’t think it was a waste of our time, because it put us in a position where we were considered an industry leader, because we were ahead of the curve.

Sometimes you invest in things that don’t catch on, but having the right marketing around it still puts you in a good position in the market — it’s kind of like making lemonade out of your lemons. Sometimes you take a gamble and it doesn’t necessarily work out, but if you can spin it and use it to your advantage, show the market that you’re prepared, that still wins you a lot more credit than you realize.

Are there specific signals that give you confidence that an emerging trend is worth paying attention to, versus just buzz or hype?

We do regular check-ins both with our customers and with our partners, including an annual NPS. That’s been really important for us, because a lot of times you get feedback from customers, but you can’t put a number to it. Doing an NPS has been incredibly valuable for us to put numbers around things and make decisions based on what’s most important to our customers.

In the marketing space, you have very dominant partners — if Facebook, Google, TikTok, Apple care about something, then it’s important to us. Sometimes they make mistakes and gamble on things that don’t work out, but it warrants paying attention if it’s something they’re validating as well.

Finding white space

Product leaders often talk about finding white space, but in mature software categories those empty markets are rare. What techniques have you found most effective for identifying opportunities that larger competitors overlook?

It’s going back to being obsessed with your customers. A lot of times the big aha ideas come from these conversations you’ve been having over and over and you hadn’t realized it. That’s really hard to do — you need to be a little bit obsessive about certain subjects. For us, our ideal persona is either a VP of marketing or the head of BI, so I put myself in their shoes and actually go through the exercise of running the reports they need, looking for the data they need. That’s when I feel like I get a better understanding of that white space.

I also think there’s an idealized notion of what white space is. The marketing industry is changing all the time, so you have to constantly be reflecting and digesting all the changes that are happening for new opportunities to come up. That’s really what’s interesting and keeps us relevant — being able to stay on trend more than necessarily a magical white space. It’s about figuring out how the industry has changed and finding an opportunity that didn’t exist before.

Do your biggest wins come from solving entirely new problems, or from looking at a familiar problem through a different lens?

I think it’s from looking at the existing problem through a different lens.

Sometimes our CEO will get on a call with the randomest BI person from one of our customers, just because he liked the guy when he met him at a trade show or something. Then they start talking, and he’ll come up with this genius idea for something, a new way of tackling the same problem. And we take it and run with it.

There’s so much value in that, even though you’re rehashing and having the same conversation — and sometimes it’s very frustrating. But doing your best to have these conversations in a healthy way, one-on-one with people, getting their opinions on things and breaking thor input down over and over again, sometimes leads to really great ideas. You need to be patient.

When we hire for product, we look for people who have that mentality of how to tackle a problem, and then how to have a conversation around it, and how do you explain themself around it. That’s the skillset of a really good product manager — being able to not only define the problem, but also to have a dialogue and debate around 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, Zach talks about identifying careers that will remain resilient as AI reshapes work and why Penn Foster focuses on preparing learners for tomorrow’s version of a job. He also discusses using AI to individualize education at scale and how Penn Foster is designing AI tutors that encourage productive struggle and simulation-based learning. Zach also shares why adaptability and lifelong learning are becoming increasingly important.

Viewing careers in terms of AI-resiliency

As AI changes the nature of work, how do you determine which careers are worth building education and training products around?

Some people are far smarter than I am who spend all day thinking about how AI is going to reshape work, so I don’t pretend to know where all this is headed. My opinion on AI is fairly nuanced, whereas others tend to think in extremes, from “AI will replace everyone” to “AI changes nothing.”

Our job at Penn Foster is not to predict the future perfectly, but to build education that can adapt as that future becomes clearer. People often start with the question, “Which jobs will AI replace?” We actually start with, “How is this specific career changing? And then what will employers expect someone to be able to do in three or five years from now?”

We spend a lot of time talking directly with employers, looking at labor market trends, trying to understand hiring needs and how those are changing, and identifying the careers that continue to offer real opportunity and show signs of strong demand in the labor market. Though we’re still preparing people for jobs, which is core to who we are as a business, we’re preparing them more for tomorrow’s version of that job.

What do the roles you see as most resilient to AI have in common?

I like the framing around AI resilience — it’s a more useful way to think about careers. I don’t know that anything is truly AI proof anymore. That said, the careers that seem more resilient combine technical expertise with a lot of human judgment and interaction. They involve working with people, whether they’re coworkers, customers, or patients; making decisions in uncertain situations where there is no clear right answer; communicating effectively; and interacting with the physical world in some shape or fashion.

One example that is near and dear to our hearts at Penn Foster is a veterinary technician. For pet owners, this is the person who assists the veterinarian, performs many of the tests, and handles animals at the clinic. For them, I think AI will help interpret information and streamline documentation. But when somebody has to calm a nervous pet owner, notice subtle changes in an animal’s behavior, or work with the rest of the clinical team, that is still going to take a human being who’s trained in that profession.

AI is becoming incredibly good at generating answers. Humans are still going to need to decide which answers matter in the moment. For that reason, I believe many of these professions will continue to show demand and growth.

Keeping education aligned with a changing workforce

You build a product that helps with training in entry-level healthcare professions, such as medical assistants, dental assistants, pharmacy technicians, and more. As job requirements change, how do you make sure a training program evolves quickly enough to keep pace?

Anyone who’s worked in education knows that, historically, academic timelines don’t necessarily match the real world. I’ve seen areas where it can take years for a program to move from the conceptual phase to full deployment, and then years again for changes to be made once the curriculum is live with a set of learners. The world of work has always changed much more rapidly than that, and now those timelines are accelerating.

We’ve known at Penn Foster that we needed to change our operating model to keep up. One of the things that I’m most excited about is the work we’re doing on cohort-based learning experiences. This is different from our historical model, which is more self-paced. Instead of treating a program as something you update every few years, we’re creating environments where we learn alongside the students we’re serving.

If we see friction in one week of a cohort, or learners consistently struggling with one particular concept, we can make improvements while that cohort is still progressing, rather than months or years later. That’s a completely different operating model than the one we’ve deployed in the past. From one cohort to the next, we can make a curriculum change where we see skills starting to shift in the profession.

As product leaders, it’s exciting because it starts to look more like continuous product development than traditional curriculum development. We’re learning, iterating, and improving results in something a lot closer to real-time than has ever been possible before.

As AI changes what employers expect people to know, how do you identify foundational skills that need to be added before the market explicitly demands them?

There’s a real balance here, because “before the market demands them” is a risk. We don’t want to wait until every employer explicitly asks for something, but we also don’t want to get too far out in front of the market; otherwise we’ll end up teaching things that employers don’t yet actually value.

We source expertise from anywhere we can get it: employers that are putting people through our programs; industry and job-specific advisory boards where we invite experts in from the industry; labor market data; certifying bodies in these various fields; and our own learners and graduates. With all of that put together, we can paint a picture of how industries and careers are evolving.

A good example of not getting ahead of the market is our medical billing and coding program. Since 2023, we’ve been hearing from pundits that this job was going to be more or less wiped out by AI. While it’s true that AI is changing the workflow for people in these positions, it’s not reducing the need for people this many years later.

Medical coders increasingly need to validate and work alongside those kinds of intelligent systems, rather than simply producing every code manually as they used to. Still, the demand for the core knowledge hasn’t disappeared. If anything, we’ve actually seen it grow over that time. For us, that means the difference between adapting an existing program versus looking for the next best thing and maybe retiring an old program.

Across industries and roles, we are looking at how we can teach AI literacy, not just the tools themselves, because the tools are going to change. The same AI platforms that you and I are using today are going to be different in five years. But understanding how to evaluate the output AI is giving you, recognizing when it’s wrong, and using it responsibly — that’s one of the new, durable skills we need to incorporate in all of our programs.

Individualizing learning at scale

When you design an AI tutor, how do you build an experience that knows when to answer, when to ask a question, and when to guide the learner toward an answer themselves?

This gets at one of the stickiest problems in AI and education so far. If you ask someone what makes a great tutor, they’ll usually say someone who knows the subject matter better than anybody else. Frankly, that’s wrong. Great practitioners do not always make great teachers because teaching is a skill in its own right.

A great tutor is somebody who knows you, the student, better than anyone else, because they can understand how you learn. They can understand what motivates you, recognize where you get stuck, and understand when you’re frustrated or ready for a new challenge. We’re not completely there yet as an industry, but we’re getting remarkably close to being able to do what a great tutor does with AI. The tooling allows us to design around the individual in a way that’s never really been possible before.

The reason it’s taking more time than people may have expected with a tutor, compared to something like a general customer service bot, is important to call out because the goal here isn’t simply answering questions faster. A really good tutor knows how to probe your thinking in different ways, when to ask follow-up questions, where to provide hints, and when to let you struggle on your own to answer the question, because learning is hard. There has to be some struggle involved for real learning to occur.

I’ve seen a lot of examples so far of chatbots that just give students the answer. That might help someone complete an assignment or pass a test, but it’s a real disservice to actual learning. I’ve definitely seen pieces of this AI tutor done well. I have yet to see anyone put it all together, but I do think we are very close.

How is AI changing the learning experience itself?

Historically, Penn Foster achieved scale through standardization. We are serving hundreds of thousands of learners a year, and the only way to effectively do that was to make operating those programs efficient. Think about things like standard courses that we can use across multiple programs, or a single support model that every learner engages with.

In the last few years, we’ve been able to turn that concept on its head. Technology now allows us to deliver individualized learning experiences at scale. We’re adapting program pacing so some people can move faster and some can move slower. We can give examples to different kinds of learners depending on their experience, offer more practice or remediation where it’s most needed at an individual level, and recognize when someone is ready to move on or move ahead. For the first time, personalization or individualization and scale don’t have to be competing priorities for us.

For product leaders, anytime you’re in an industry where that kind of paradigm shift is happening, speed matters, but I would say what matters even more than speed is your willingness to question old assumptions. I’ve seen a lot of companies get stuck and get in their own way because they don’t realize how quickly this is changing. They assume what’s worked for them in the past will always work in the future, and it’s not always true. If you can’t spot those trends and shift accordingly, then somebody else is going to do it before you do.

Practicing the human side of work

When you’re building interactive experiences for learners, how do you decide which parts of a job need to be practiced rather than simply explained?

Practice is so important, no matter what we’re talking about. This is classic learning science — reading about something and becoming fluent in it are two completely different things. We know that people learn through a series of practice, feedback, reflection, and repetition. That’s the model of a good learning experience. That’s especially true for career education, where you’re trying to master new skills, not just remember new facts.

If your future job involves interacting with patients or customers, or working with equipment, machinery, or software — which, let’s face it, describes most jobs — you have to practice those situations before you encounter them on the job. It’s really a prerequisite to success.

Technology is making this much easier to do at scale. At Penn Foster, we began investing in real simulations and interactive experiences a few years ago, and we can build them even faster today with new tools that our product team is building. We want to present learners with a real situation, the kind that they might encounter on the job, and then present them with decisions they need to make and give them feedback in real-time as they make those decisions.

Then we want them trying again and again, because that’s what’s going to build confidence before they’re ever in the real workplace. We can couple online learning experiences with simulations or scenario-based learning.

We still take on-the-job learning experiences very seriously as well. Nothing really beats getting into a clinical setting, having some supervision, and actually getting a chance to use your hands and do the job.

Can you share an interactive experience your product team has built?

One of the best examples I can give is in our HVAC technician program. This is somebody who’s learning how to respond to a service call and fix an air conditioner that’s gone down. We can give them an interactive simulation where they work with the equipment, choose the right tools for the job, and identify different parts of the unit and how to take them apart and inspect them. They do this with a 3D model they engage with on the screen.

Each time they’re asked to make a selection or perform an action, they’re getting feedback. If they got it wrong, we prompt them to try again and give them a little bit more information. If they got it right, we reinforce the knowledge involved and help them understand where that would come into play in an actual service call environment.

Students don’t even realize their progress because they’re used to learning by reading static text or watching a video. When they’re actually doing, they’re learning better than in any of those other environments, but it feels more like play. It feels more like getting a chance to practice, which creates more engagement. Our student satisfaction scores have gone up once we’ve started introducing more of this. It’s a win-win because it gives students what they want and also helps them learn the material better.

Which interpersonal skills will help one worker win out over another as AI takes on more technical work?

Skills like effective communication, curiosity, empathy, and human judgment are becoming increasingly valuable and skill-defining. I want to be careful not to create a false choice between the interpersonal and the technical — many of the careers that we serve still require a person to pass a certification exam, and those certification exams measure deep technical knowledge associated with the field. Technical mastery still matters, but the opportunity is to layer increasingly authentic practice experiences on top of that knowledge. That way, when someone shows up to work on day one, whether it’s in an office setting or a clinical setting, they feel more like a seasoned professional.

That’s where simulations become incredibly powerful. We have scenarios where you’re practicing difficult customer conversations or explaining a diagnosis to a pet owner, going back to the vet tech example. We can use those simulations, technology, and real-time feedback to get people comfortable with more of that interpersonal element of a career.

It’s one of the few ways to safely practice human interaction at scale. You can do it online in ways you didn’t use to be able to. As AI handles more of the routine, technical work, those interpersonal moments become even more important. If you can show a potential employer that you’re competent and confident on the job, and have an ability to work with a team and work with customers effectively, that’s what they’re going to look for and how they’re going to make their hiring decisions.

Building a career that evolves with AI

What does it mean for a career to be AI resilient now, and how do you expect that definition to change over the next decade?

My answer to this has changed in the last couple of years. If you asked me that a year or two ago, I probably would have talked more about choosing the “right professions.” Today, I think it’s a little bit more about people’s mindsets. Even working with the product managers on my team, the people who will thrive aren’t necessarily the ones who know the most today. They’re the people who stay open and willing to learn and adapt as technology changes the roles that we’re all in.

You can’t assume that your job, or even your career in the field that you’re in, will look the same in five or 10 years the way that you used to. That’s scary, but the one thing I know for sure is that change is inevitable. Resisting change is not going to get you anywhere. It’s about acknowledging that and getting comfortable evolving alongside it. As new tools come along, work with them, practice them, get to know them, and make your own judgments about how valuable they are in your day-to-day.

I also think that changes how we think about education. Education can’t be something that you’re ever really finished with. It’s not the thing that comes before the career phase of your life. It has to evolve with you and your career over time. That means it’s a lifelong endeavor, a lifelong process.

At Penn Foster, we hope to become a lifelong partner for workers in these fields and employers in these industries — a trusted source of knowledge, information, and skills that they can continue to come back to as this technology changes and as these roles change over time.

Can you share any advice you’d offer to an 18-year-old high school graduate, and would that differ for someone who’s mid-career?

A big part of our work at Penn Foster is our large online high school program. We are working with 15-, 16-, and 17-year-olds every day, and they’re working toward their high school diploma. As you would expect, a lot of them want us to help them make those decisions about what comes next.

For the last 30 years or so, as a society, we’ve been sending one message: college for all. The only surefire way to get a middle-class lifestyle is to get your four-year degree, and that probably has always been wrong. It’s more wrong today than ever because a lot of these professions that can lead to a stable career don’t require a college degree.

None of the careers that we’re preparing people for, outside of a few associate degrees, require college. They require a set of skills, and they often require a certification to get started, but then they can lead to a successful career.

My biggest piece of advice is to ignore the people who tell you that there’s only one way. Broaden your exposure to different careers and different fields, and don’t be afraid to try something. It’s not the biggest risk in the world to do something for a couple of years and then decide that you want to go a different way.

People get hung up on: I have to make this choice at 18, and it’s the only time I get to make this choice. The stakes are super high. I think the stakes are lower than a lot of people realize. As education becomes something that you come back to again and again throughout your life, it’s also that recognition that you can change your mind and try different things.

What does LogRocket do?

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

In this episode, we’re joined by Parul Goel, most recently Senior Director of Product Management at Indeed, where she led the orders and billing platforms behind a multi-billion-dollar business. Before that, she spent nearly nine years at PayPal, building a zero-to-one payments platform for marketplaces that landed clients like AliExpress and Facebook Marketplace.

About a year ago, Parul hit the same wall a lot of senior product leaders are sitting behind right now: reading everything about AI, absorbing none of it. So she started building. The result is PM OS: an open source system she and three other product leaders built with Claude Code to automate four core PM functions. This episode is also a LaunchPod first: Parul screen-shares and demos the OS tool live!

In this episode, Parul shows:

• A live demo of the PM operating system she built with 3 fellow product leaders and the four-layered architecture behind it

• Why the “context library” and codifying company identity, stakeholders, and voice is the layer most people skip, BUT the one that matters most

• And how the system handles core PM workflows like exec updates, cross-functional communication, customer interview synthesis, and PRD drafts

1. The cure for AI FOMO is to start building with it

Parul’s entry into building with AI wasn’t a strategy offsite. It came after a year of obsessive reading that left her feeling worse, not smarter.

“When AI showed up, I was like everybody else. I would read every LinkedIn post. I would read every article obsessively. And then I realized it’s not giving me conviction – it’s giving me anxiety. It’s giving me FOMO.”

Her fix was to stop consuming and start shipping. She now spends time building almost every day — PM OS plus a handful of personal tools.

“The only way to really feel what AI can do, where your job would stay versus what parts would disappear, is to have hands-on experience.”

Product takeaway: You can’t read your way to AI fluency. If your leadership team is still debating AI strategy in the abstract, the fastest path to conviction is for the people making the decisions to build something. Start small, and use it on real work. The anxiety most leaders feel isn’t a knowledge gap — it’s an experience gap.

2. The idea started as grunt work, not strategy

When Parul’s co-builders proposed PM OS, she knew immediately which piece she wanted: the exec update. Because, thanks to her experience, she knew what it was like to write the same one over and over.

“I was just doing the same status update for different audiences. And I realized that I am just doing the thinking once. A lot of it is just re-projecting, changing the tone and the length and just going and talking about what they care about.”

Once she framed it that way – thinking once, re-projecting five times – it stopped being an unavoidable tax on the job and became something she could build an automated process for.

The team picked four core PM functions and automated most of each:

• Executive updates

• Cross-functional updates

• Customer interview synthesis

• PRD drafting

They built the first version over a weekend.

Parul also picked this problem for a specific reason:

“One of the reasons why I thought this was a good problem to solve via AI is it’s low risk. I’m always going to check before I send something out. It’s never going to be automatically sent.”

Product takeaway: The best first AI use case in your org is probably not your most valuable workflow. It’s the one where the thinking is already done, the output is repetitive, and a human reviews it before it goes anywhere. Look for tasks where you do the reasoning once and reformat it many times — those are where AI compounds, and where a bad draft costs you nothing.

3. The context library is the actual product

The PM OS has a four-layer architecture:

• perception (what it knows)

• execution (the four skills)

• critique (how it evaluates its own output)

• continuity (what it remembers)

Parul calls this the soul of the system, but she’s blunt about which layer matters most and which one people skip.

The context library is a folder of markdown files describing the company’s business model, target clients, past decisions, user personas, the company voice, and – most importantly – the stakeholders.

“This is an interesting one because it’s beyond just the name and role. It’s what do they care about? What are their pet peeves? Things you actually learn about people as you work for them, things you actually think about before sending them something.”

That’s why the same status update comes out differently for the CEO than for the CTO. In the demo, the system doesn’t just relabel the audience – it reframes it appropriately.

“If you’re building something like this, don’t skip [the context layer]. It is the most important.”

Product takeaway: Generic AI output is almost always a context problem, not a prompt problem. The unglamorous work – writing down what your stakeholders care about, how your company actually talks, which decisions have already been made – is the part that determines whether output sounds like your team or like a language model. Budget real time for it and treat it as infrastructure.

4. Make the AI critique itself before you ever see it

The most interesting moment in the demo isn’t the draft. It’s what happens after.

Parul defined three sub-agents — an engineer, a designer, and an exec — that review every update before it reaches her.

“These are your coworkers weighing in before you send something out.”

In the live demo, the engineer sub-agent flags that the team has already missed this date twice, and that claiming high confidence in the new date without explaining why will read as overstating. Which is exactly the question she’d have gotten in the meeting.

She also built in a hard constraint on the input side. The skill can ask clarifying questions only once.

“When you are in the process of working on something, the last thing you want is to get into a back-and-forth with an AI assistant. So we limited this. You can ask questions only once, and then you have to draft.”

Product takeaway: Adversarial review is a design pattern, not a nice-to-have. Instead of asking a model to write well, ask it to predict how a specific reader will push back – then fix that before you ship. And design your interaction budget deliberately: an assistant that interrogates you is worse than one that drafts something imperfect and flags its own gaps.

5. The build got easier, but the judgment didn’t

When asked how she thinks AI will affect the PM role going forward, Parul’s clearest evidence that PMs aren’t going anywhere came from an AI-drafted email she caught just in time – one that told the recipient the meeting had been more useful than she’d anticipated.

“Thankfully, I didn’t send it. But that’s where the judgment is so off. That gave me a lot of comfort that my job is not going anywhere soon.”

Her broader read: the engineering has gotten dramatically easier, but deciding what’s worth building and what’s safe to send has not.

“AI can give you options, it can give you ideas, it can tell you the trade-offs. But the actual judgment, the actual decision, still needs to live with the person – because a lot of times these decisions are made based on company values or an individual’s values.”

She does expect the shape of the job to change. Teams will get smaller, the work will get higher-leverage, and writing the same status five times will disappear.

Product takeaway: The threat to your PM org isn’t AI doing the judgment. It’s your PMs spending so much of the week on re-projection and reformatting that they never get to the judgment. Automate the grunt work first, then measure whether the reclaimed hours actually go toward better decisions.

Chapters

00:00 Introduction
04:38 Why Parul and her collaborators built a PM OS using Claude Code
09:05 Exec update live demo
15:18 The importance of the context library
22:28 The future of PM with AI
23:36 Conclusion

Links

• PM OS GitHub project

• Parul's LinkedIn

• Parul's collaborators:

  • Vidya Sarangapan

  • Priyanka C.

  • Bhagyashree Prabhakar

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, Aaron makes the case for why every PM should build a personal agent, not just a work one. He talks about how doing so has changed the way he uses the internet, what it teaches him about the agent-using customers now showing up to every product, how to pick a first project, what he’s learned from his own agent failures, and what it actually costs to get started. He also makes the case that, underneath all the practical upside, it’s just fun.

Why build a personal agent?

You’ve argued that every PM should build their own personal agent. What changes in the way someone thinks about products after they’ve actually built one for themselves?

I think it will blow their mind. It’s just such a different way of using a product. As a PM, you’re sometimes detached from the outcome. You build the thing, you wait to see users use it, you might watch user tests, you go to learn and you observe. The thing with personal agents is you’re a feedback loop of one — if you build the thing and it breaks, you’re in trouble immediately. In some ways that reminded me of originally playing with Tamagotchis, except the stakes are way higher. So it’s a very different way of building, but it also gives you such a perspective into the things that engineers go through and what your teammates go through.

You now have, not accountability, but you’ve got to take care of everything. The agent is the thing you’re interacting with, but you have to think a lot more about the prompts and the logic and the context. That’s why I use the Tamagotchi analogy — you used to have to water it, play with the thing. Where if you build an agent and give it no context and no tools, it’s like, “Well, it’s just a chatbot.” There is no difference. It’s kind of stupid.

But if you build yourself an agent and go through that exercise — think about what context you can give it, what you can teach it so it could be more useful for you, what tools you can give it so it can enrich itself further — that’s when your mind is blown. It becomes really, really useful, and it’d be hard to go back. I don’t want to do this manual thing over and over anymore.

How has it changed the way that you use the internet?

Obviously, the introduction of LLMs changed people from using search behavior to using chatbots. That was step zero. A lot of folks have already shifted to using ChatGPT and Anthropic to do search queries with a chatbot. The agent way of changing the way I use the internet is going beyond just search.

Here’s such a stupid example, but it’s fun: I was with my wife and we were recently looking at toys from the 1980s, just pulling things out of a pile. Before you might do a Google image search and then try to figure out how much a thing costs, but I already have these agents built. So instead we’re snapping pictures, sending them to the agents and just saying, “Go figure out how much this is. Go find the eBay listings. Go find the conditions,” and we’re sitting there feeding this to the agent — we’re just talking. I’m not even on the internet. I’m just snapping a photo, sending it off to the agent, and using voice to chat. And every few seconds we’d get back a response like, “That toy’s worth five bucks. That toy’s worth three bucks.”

It was so silly, but instead of me having to sit there and Google search and reverse image and then pull all this information together, you can delegate this little minion to go get the information and bring it back. It didn’t interrupt the flow of the conversation, and I think that’s the ideal. The goal is this should supplant and amplify the thing I’m currently doing without being disruptive.

What building an agent teaches you about your users

Many PMs are experimenting with AI through prompts and chatbots. What do they learn by building an agent that they wouldn’t learn just from using AI tools?

I think it’s incredible that PMs are experimenting, period. I think curiosity shouldn’t stop at just the chatbot. The thing they’re interacting with is an end product. There’s a lot to be learned by building an agent because it makes you understand what goes into it. It goes back to giving it context, and being responsible for it staying alive, for lack of a better term. How does an agent fail? And once you understand that it failed, you start to build things differently, because you need something that fails out loud. It can’t fail silently.

A person doesn’t expect to keep learning UIs. We’re seeing that change already. If you only interact with the chatbot, this little box is where the work occurs. The thing with agents is you’re bringing the agent to wherever you’re doing the work, which is very different. A chatbot lives in the chatbot’s window. So if you’re downloading Claude Desktop, you’re working in Claude. When you start to build agents, the agent goes with you where you need it to be. If you’re working in a terminal and you’re looking at financial data privately on your computer, you didn’t have to upload that to Claude and put it in the cloud. You can do that on your machine and your agent can be with you on that journey.

Even in the way I use products — if you have an agent, one of the first things you think about is, well, how do I get my agent to help me explore this product? People are less like, “Go build me a B2B product that I need to learn how to use.” Instead they’re saying, “I want to use your product. Can I bring this to this other thing I’m doing where my agent already exists?” An agent becomes a first-class product need. And if you’ve never built an agent, how the hell do you build for that? You don’t understand the user you’re building for if you’ve never built one. It’s like you’re blind.

Finding your first project

How do you identify the right first project? What makes a problem a good candidate for an agent?

What annoys you? I think that’s always where I start. The project most people recommend is to build a daily morning briefing; even I built tutorials telling people to do that as a starting point. But maybe that doesn’t annoy you, and so maybe you won’t do it. I think it’s great to build an agent for something that you find deeply annoying or deeply repetitive, and you’re like, “I don’t want to do that anymore.” That’ll motivate you to get through the learning to get to building the context so you don’t have to do it again.

How many agents do you have? What’s a good number?

I think one is a great starting point. Building one that is on and persistent and gets to know you is what I advocate for. One held for a really long time.

My Discord channels setup — being able to bifurcate an agent’s access to different channels and loading contacts in different channels — one agent can handle that. We just remind it what memory it should load when it’s in that channel. For instance, if I’m interacting with an agent in the inbox alerts channel, it’s flagged that we’re talking about email. I’ve given it a memory. It’s the same agent, but it’s saying which set of memories apply.

But I do have two agents now, and there was a reason for the second agent. The first agent is on a Raspberry Pi, and the RAM and the storage on that device is much less than a computer. I’m very interested in using more local models, and I’d like to give it more advanced use cases, like analyzing my finances, and I’d like to be able to give a more powerful machine with more storage so I can keep the thing inside my house, versus pushing this information to someplace that I have no control over and no visibility. So the second agent I’ve added — which, again, is just the name of the computer, it’s an M1 MacBook — is called Agent M1.

It has different tools. The first agent has general access, less tools. It can answer questions, it could work across channels, but it can’t cause too much damage. This second agent I built has more tools. M1 can self-administer my GlutenOrNot application. It can access the logs, it can file error reports, it can push code to fix it without me overseeing it. I’ve given that machine more power, piece by piece, as I trust it more and more.

Learning from loud failure

Can you talk about some of your agent failures that have taught you the most?

All the time, nonstop, 24/7. Using OpenClaw when it first came out, I probably spent hundreds of hours tinkering, and it was fail after fail after fail. But the ones I can pull better patterns from — I think letting agents fail silently is a big mistake, and I’ve learned a lot from it.

A great example: if I’m using an agent powered by Claude or Anthropic and the agent gets logged out, or the API key expires, it’s really hard, if you let that fail silently, to understand what went wrong. You could spend a lot of time chasing what’s actually a really basic error, like you’re logged out — that’s the error. But if you build the webhook or a notification to say, “Agent X has been logged out,” you save yourself from wasting a ton of time trying to debug.

A big mental shift for me was making sure agents fail loudly, making sure how they think is visible. So then if I send something to them and there’s an issue happening, we have some sort of log of the thinking and the dialogue and the interaction.

Another pretty big failure point for me: at first, I spent a lot of time trying to approve every single thing. Because I didn’t know what I was doing at all, I thought, “Oh, if I read all the interactions, I’ll figure it out.” I think that was not the best use of time. I learned more from letting an agent try a thing and screw it up than from trying to read the code it was writing.

The better approach was to understand: success for this thing is being able to classify emails, read emails and triage them. I decided I’d do an experiment where I give it 5% of my email for a week. Then, if it stinks, we fix it. If it doesn’t do a good job, we’re just going to work on it. It’s iterative versus, “It’s got to be perfect.” I would’ve gotten much faster learnings earlier on in working with agents if I was just willing to let it fail in a contained environment.

What it costs to get started

What should a PM who wants to build their own agent budget for?

Personally, I currently am using a Claude Max subscription, the $100-a-month one, and that is ample to power the two agents, because I’m using Claude Channels as a setup. Claude Channels is the thing that allows a persistent session to stay alive, and I can access it via Discord. You don’t necessarily need that. I know plenty of folks that are using OpenRouter and using different models and different setups, and they’re spending less than $50 a month. So I would say budget $100 to get started, get up and running, and then pretty quickly, once you figure things out, you could swap out anything you want with different models and setups.

I didn’t mention hardware, though. You can use old computers, that’s worth saying. I’m fortunate I had an M1 MacBook I was not using for this new agent, but originally I did buy a Raspberry Pi. You don’t need the newest one — you can get a Raspberry Pi 4 or 5 for, I think, between $100 and $200. I always recommend Raspberry Pis. They’re super cool personal computers that do all sorts of fun stuff besides building agents. It’s really small, barely consumes power and it can do everything a computer can do. But it’s slow.

Why it’s fun to build agents

If a PM spent a weekend building a personal agent, what would you hope they walk away understanding about the future of software that they didn’t understand on Friday?

I’m hoping by Saturday they get the agent alive, Saturday and Sunday they spend some time figuring out what tasks they’re going to give it, then Monday comes and maybe they’re reflecting. What I would hope for them is they enter Monday understanding that the internet and the way we’re using it is changing. No matter how you feel about it, I don’t think agents are going away. They’re so convenient, and as soon as people get convenience, they’re very unlikely to put it back in the box. So a transformative outcome for a PM would be just feeling that in some capacity.

That’s why I always advocate for finding something that annoys you, because the minute you offload one thing that annoys you to an agent, you’re like, “Oh, what else annoys me?”

Apart from the learning aspect, is it just fun to do something that’s not work-related?

One-hundred percent. That’s why I advocate for personal agents — I am not here to offload building an agent for work. Software tools are going to do that for you. Every freaking company’s building an agent at this point. But building a personal agent — who’s doing that for you? The fun here is you are building something for yourself that can benefit you in your life. It’s a piece of technology, so as excited as I get, it doesn’t replace the human side. I like building things. That’s why I got into product management. I just knew I like to build stuff, and I’m not a real engineer, and building agents scratches that itch of building something.

I am the user of the thing I am building, and I’m continually surprised with the things I can do with an agent. At first, I was having an agent watch my email. Sure, that was cool. Then I was figuring out how to build another agent that can watch Twitter using a Twitter API to give me information I want. You start to stack these things up, and piece by piece you’re like, “Oh wow, each of these little functions in my life that required some form of overhead or mental capacity, I can now offload back onto an agent.” It’s a bit freeing.

So, it’s fun to build, and then it’s fun to get time back, and have more time for the stuff you want to do. I needed to figure out a part for a cabinet in my house that broke, and I did not have the time to fix it. Instead of having to go log into Claude and sending a photo and doing all that stuff, it was just a conversation. I flipped it to my agent, came back, and had three Amazon links with the dimensions, assessed off the photo. That is a thing that would’ve gone on my to-do list and sat there for two weeks. Instead, in conversation, in flight, handed off, got back a result, able to order the part, not a beat missed.

My to-do list that used to be 20 items long, maybe there’s still three items on the list, but they’re really the ones I should do. I’m throwing the rest to the agents — let them get on those things that would’ve just sat there.

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, Ephie discusses the differences between leading UX in enterprise and nonprofit environments. He shares how AI is changing the role of designers rather than replacing them, as well as how creativity and storytelling shape better product experiences. Ephie also talks about building and designing trustworthy technology in the age of AI.

Building products around real user needs

You lead UX across large enterprise platforms while also leading product strategy for a much smaller nonprofit. How has moving between those two environments changed your perspective on what great product and UX leadership actually looks like?

There are major distinctions between the two. In a large enterprise company, things take longer to build because there are so many moving pieces, including the number of customers with active accounts. You’re working with so many different people and creating new technology, so you can’t just do things on a whim. You have to plan ahead, be strategic, and ensure what you’ve built is well-vetted and tested before you ship anything.

It’s refreshing to work in a small nonprofit space where we can ship things quickly and experiment. There’s a lot of fun about that, but at the end of the day, it’s the same principle — we’re working to solve real user needs and deliver a product that works for them.

In either space, it’s easy to fall into the trap of thinking that everybody will want a specific feature or product. You can go ahead and build it, only to realize that nobody actually wanted it in the first place. That’s where strong UX leadership comes into play. You have to ask, “Who’s asking for this and why? What’s going to make our users’ lives better?” It’s important to think about the whole workflow.

This is also how I approach AI — you don’t want to build an AI product or feature just because it’s trendy and cool. You need to think about the biggest pain points. Whether it’s a massive company processing millions of dollars per day or a small nonprofit using your software sparsely, what tasks are tedious for them? This is true across all industries, and this is where AI can come in.

Do you have any learnings from working in a smaller space that you leverage in an enterprise role?

One thing I oversee in both spaces is leveraging AI for auto-filling forms. You may think that’s a no-brainer, but it isn’t. AI has to understand the various ways people answer the same question across different forms, so you have to train it for your industry. Working in the nonprofit space gave me an appreciation for how difficult seemingly simple problems can be. We had people handwriting forms, writing in the margins, and drawing little sketches of what they meant. It made me appreciate the broader AI challenges we’re solving in the enterprise, and it gave me better language to work with our AI developers.

Do you feel that running product has made you a better UX leader, or has leading UX made you a better product leader?

I’d say it’s a blend of both. My background is primarily in UX, and bringing that experience into product leadership has been incredibly useful.

People will say, “We’re facing this huge product problem we’ve got to solve.” I can put on my UX hat and think, “We could solve this very easily.” The user might be asking for some elaborate feature that will involve months of work, but maybe we only need to move one interaction or change one button. Suddenly, we’ve gone from months of development to a couple of days.

It’s been fun bringing that mindset into product leadership. You don’t just want to build something viable — you want it to be usable and simple. That’s my UX mantra with everyone I manage: “Keep it simple.” The elegant solutions that look obvious are often the hardest to arrive at.

Enterprise software especially gets complicated over time because every customer requests something new. The customers who pay the most are often the ones who want something built specifically for them. That’s when I wear my product hat, even though my official role is UX. For example, early in my time at Applied Systems, we had a customer with a long list of requested features. Instead of trying to solve all 30 requests, I asked, “What have they consistently told us are their biggest problems?” We reframed the conversation around outcomes instead of outputs. Rather than talking feature by feature, we focused on what would actually make their team’s life better. That one larger outcome was going to move the needle far more than checking off dozens of individual requests, and the shift changed our relationship with the customer.

Why AI makes UX more valuable

Are there UX practices that have become less valuable because of AI? Which have become more important?

The days of what we used to call “pixel pushing” are coming to an end. Think about spending endless hours making a prototype look perfect — AI can do a lot of that now. That begs the question: what should the UX designer be doing?

I’d argue the role of UX is more important than ever because AI can generate so much so quickly. We had a product manager take something that had been on a six-month roadmap and come up with a working solution in just two days using vibe coding. The developers spent another two weeks validating and refining the product before it shipped.

Where did UX come into play? We stepped back and asked, “What is the user trying to accomplish? What are their biggest pain points? How can we smooth those over?” That’s where UX adds value.

Right now, we’re seeing roles start to blur. Even though a product manager may wear a UX hat and a developer hat, that doesn’t mean those responsibilities become their job. We still need specialists, but we also need to be willing to move outside our lanes.

I like the idea of T-shaped professionals. You go deep in your own discipline, but you broaden what you’re capable of across others. I’m seeing more of that at my company, and I’m doing it myself. Recently, I’ve been pushing code for the first time in my life. For example, one of my hobbies is doing blind wine tastings with friends. I wished there was an app for it, so I vibe-coded one. It’s improving so quickly that I’m now planning to release it.

The most important thing UX professionals can do today is stay connected to real users. Talk to real humans; don’t just rely on AI. AI-generated work might earn a passing grade, but it’s rarely A-level work. For example, my wine app looked great at first, but once I actually started using it, I realized the database wasn’t very good, and parts of the experience didn’t work well. After iterating, I got it much closer, but I still had to test it with real people.

One friend I tested with is in his 60s. He immediately needed to zoom the screen, and that completely broke the experience. I never would have discovered that sitting at my computer. You don’t know what you’ve missed until you watch someone use your product. The important lesson here is that AI gets you started, but it doesn’t get you finished.

How do you quantify whether design is creating business value?

Measuring UX value is difficult because it’s closely tied to product success. One of the biggest successes I’ve seen was when a designer did user research on a roadmap initiative that already had designs, planning, and development scheduled. The research showed users simply didn’t need it, so we decided not to build it. To me, that’s an enormous UX success. We saved weeks of engineering time, product time, UX time, release effort, adoption work, and, ultimately, a tremendous amount of money.

Instead, the research uncovered something users actually wanted — and it was much simpler. Sometimes the greatest value UX delivers isn’t launching a feature. It’s preventing the wrong one from being built.

Creativity as a competitive advantage

There’s a growing narrative that AI is commoditizing design. Do you agree? Are there parts of the discipline becoming even more valuable?

Absolutely. AI is creating many solutions, and if you aren’t pushing beyond those initial ideas, everyone will produce the same things. There’s something positive about that because users benefit from familiar patterns. If somebody has seen a particular interaction before, they’ll probably understand yours immediately.

What worries me is that it can stifle the human creativity that’s required to solve problems in better ways. Sometimes the right answer isn’t the big, flashy solution — it’s the simple change that removes friction. Those are the kinds of solutions that still require human creativity.

My brother recently opened a restaurant and was frustrated with the software he was using. My first instinct was to imagine building an entirely new inventory and recipe management system. Then I actually talked with him, and found that his software worked fine. All he wanted was for his recipes to print differently.

My brain had immediately jumped to a huge, exciting project when all he really needed was one small improvement. That’s the opportunity — talk to the user before you start building.

How do you stay creative as AI becomes more capable, and how does that creativity influence your work as a product and UX leader?

I’ve recently caught myself thinking, “I’ll just ask AI,” only to realize AI doesn’t actually know the answer — I just need to think. We have to be intentional about protecting our creativity.

For me, that happens outside of work. I’m an author, and I love building worlds and characters. That creativity carries back into my product work.

Storytelling helps in two ways. One is communicating vision and helping people understand a product direction in a relatable way. The other is thinking about the user’s story. What’s their journey today? Where are the pain points? What’s the ideal journey? What’s the gap between those two? I think about that the same way I think about writing novels. There’s a beginning, some conflict in the middle, and a successful ending.

I’m also a big fan of Jeff Patton’s user story mapping. Just like a movie storyboard lays out every scene, you can map a user’s journey with sticky notes. As you walk through it, you start asking, “Do we really need these steps?” If someone can accomplish the same goal with four steps instead of 20, everybody wins. Less is more.

That way of thinking is influencing the work my teams are doing around agentic AI. We’ve already built several AI capabilities into our software, like autofill, but that’s only one step. Our vision is for AI agents to assist throughout the workflow while keeping a human in control.

Imagine an email arrives. An AI agent reads it, moves it into the system, identifies which form is needed, autofills it, identifies what’s missing, drafts a response requesting the remaining information, and then pauses for human review. Instead of a user completing six different steps, they review one workflow.

Further, I try to disconnect every day. I’ll take a walk at lunch, get away from the screen, look into the distance, maybe walk with my wife. When I come back, I usually have better ideas. You have to give your brain space to do its work.

Designing AI people can trust

That’s good advice. What are the biggest mistakes you’re seeing product or UX teams make as they integrate AI into their work?

The biggest mistake is trusting AI the first time through. People generate a summary, a prototype, or some research synthesis and immediately share it because it looks impressive. Someone else will read it closely and discover that the conclusions are wrong or that the sources were misunderstood. The first draft is rarely A-level work.

The other mistake is the opposite: not using AI enough. People get overwhelmed because it’s capable of so much. I’m experimenting with using AI to analyze financial markets. It can process more information than I ever could, but many people still use it only as a chatbot.

Start connecting it to your analytics platform. Connect it to your research repository. Ask it questions about user behavior. Those are the kinds of workflows where AI becomes incredibly powerful.

How do you build trust into AI experiences?

Trust is the biggest challenge. Everyone we’ve shown our concepts to says the same thing: “I don’t trust AI.” Honestly, I don’t blame them — we’ve all seen AI make mistakes. That’s why we’re focused on principles like transparency, keeping a human in the loop, making actions explainable, and allowing people to undo or edit what AI has done. Those things have to be designed intentionally.

For large enterprise software, that’s a significant effort, and a large portion of our UX team is focused on AI experiences because getting trust right takes a lot of work.

What advice would you give UX designers who are early in their careers on the skills they should focus on building?

First, learn how to do real user testing. Talking to real people is becoming the most important part of the job. Second, don’t be afraid of AI — but don’t trust it blindly either. I’ve seen AI produce impressive-looking work that completely fell apart once I verified it. I even tried using AI to organize my taxes. It made enough mistakes that I eventually started over, but I still used AI where it was appropriate. I used Expensify to scan receipts and compile the information, for example, and it worked flawlessly because it was designed for that purpose.

Use the tools and be smart about them. Don’t accept AI slop. I’ve told my whole team that if they don’t embrace these new tools, they’ll get left behind. The people who are learning how to work with AI are already doing things they couldn’t have done just a few months ago. We’re living through a true revolution in what people are capable of, and it’s a very exciting time.

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.