"Product is already complex. Let's not make it more complex.” David Pereira on tomorrow’s PM skills

David Pereira shared his take on where AI is quietly working against product teams, not by breaking anything, but by making existing dysfunction faster and harder to catch.

David has spent almost two decades in product, and nearly 17 coaching product leaders through exactly the kind of disruption AI is causing now. He joined airfocus’ product manager, Spencer Cowley, for a live conversation on what product leaders need to leave behind to stay relevant.

Where AI tempts good product managers into skipping the hard work, why synthetic users can't replace talking to real customers, what "AI-proof" product management actually looks like, and why the best product leaders are just as clear about what they won't hand off to AI as about what they will.

Spencer Cowley: One of the big reasons we're here is to talk about AI-proof product management. What is top of mind for you when you hear that AI is changing product? 

David Pereira: AI is a means to an end. That's what comes to my mind. What is scaring me right now is that every conversation starts with "AI." But do we really know what we're trying to do, where we're trying to go? I'm not skeptical about AI; it helps, it gives us new possibilities, things we couldn't do in the past. It helps us as long as we are driving, not being driven by something we don't know where it's taking us.

Spencer: Where are you seeing people make mistakes?

David: I see some good product managers becoming bad product managers because they renounce thinking. They create agents that will do the hard work for them, then ship things, but it doesn't have the critical thinking they had before. And then there are some executives going, "We need to be seen as innovative, so we need to add AI to the product." This is dangerous because innovation is actually solving problems in other ways.

For example, one leader recently told me he updated the product, and the net promoter score went down. I started reading the reviews with this executive, and it was interesting. They had created a solution that nobody cares about, nobody asked for. They started with the solution, not the problem.

Spencer: You actually sat down and read through those reviews yourself, right, rather than just having AI summarize them? Is that another place where you're seeing too much of a turn toward summarization?

David: Yes, because summarization means someone else is doing the thinking work for you, categorizing it in the way you were doing. What I like doing is different – it's not faster, but it can lead to better results. I like doing the mundane job of looking at the reviews myself, one by one, until something clicks. I take notes, and I identify patterns. Then I look at AI and check what it identified. Sometimes it identifies something I didn't see, sometimes it doesn't identify what I saw, so I need to make the decision. I call this the brain workout: If you do the boring work first, you warm up your brain, and then you look at the AI results with a more critical, skeptical lens. If you look at AI's results first, it seems to make sense, and you get lazy. You don't want to go do the brain workout anymore.

Spencer: Is this new, product managers skipping the hard work, or something we've seen for a while?

David: Product managers always have more on their plates than they can possibly do. So we need either to sacrifice something, cut quality, or overwork – sometimes all three. We find shortcuts, and the problem with shortcuts is that we pay the price later.

One example: I had a survey to help people understand where they are – in the execution trap, the invisible contributor, or promotion-ready.. The response rate wasn't moving even after I used synthetic users to try to improve it. Then I had an insight while walking in the morning, watching people commute: These people are replying to my survey on the move. So I tried answering it myself on a moving train, one-handed, and learned what was actually happening. I interviewed people to confirm the hypothesis, then improved the survey, and it started working. I had to understand the reality, not what I wanted reality to be. Synthetic users gave me the shortcut, but missed the real thing that was happening.

Spencer: I had something similar happen this past week – I asked Claude to role-play a few different personas, giving feedback on a solution, and when I pushed for brutal honesty, even the AI said, "These are all saying the exact same thing, you probably shouldn't trust this." It's not that synthetic users can't be helpful, but there's a human touch that's easy to miss, and it's scary how easy it is to feel like you're doing something when you're not doing the hard, critical work that leads to better outcomes. This goes into product discovery too: What's going right with how people are approaching discovery differently with AI, and what's going wrong?

David: What's going wrong is simple: Some people decided we don't need discovery anymore. The explanation? When delivery is cheaper than discovery, why bother? I've seen this with companies that generate, let's say, tens or hundreds of millions in revenue per year.

Many companies think they can just do more delivery because it got cheaper. Others say we can do discovery behind the computer, create agents to do it all for us, but what product leaders actually need to do is make decisions. There's one thing – I don't know who created it, so I'm sorry, I cannot quote the person right now – but there is "NIHITO," which is our friend. NIHITO means ‘Nothing Important Happens In The Office’. We still need to get out and talk to people [the concept, popularized by the Pragmatic Institute].

What does AI enable now that we couldn't do before? In the past, exploring one solution for one problem took a long time. Today, we can create multiple solutions for the same problem and understand which works best, then scale it. Why does this matter? Because one thing hasn't changed with AI: the capacity of people to adopt new functionality. If you ship more, it doesn't mean people have the mental capacity to consume more. We still need to understand what to ship.

Spencer: That's a good point about the mental toll on users, and whether we lose their trust when the product feels different every time you open it.

David: Trust is a very important word. We need to step back and ask: What are we trying to achieve? Sometimes we don't answer that, and we end up measuring success by mileage – we don't know the direction.

Spencer: So it's about focusing on outcomes, not just outputs.

David: Yes. Leadership needs to clarify direction before choosing what to build. When direction is unclear, I see more users churning. I myself churned a product I'd used for years because it wasn't what I had signed up for anymore.

Spencer: The title of this webinar is about what leaders should leave in the past to survive the future. What are successful product leaders doing differently today?

David: In the past, product leaders stayed close to the team, providing process and direction. Today, the top priority is direction, followed by the empowerment of what we can do with AI and how. Many leaders just buy an AI license and say, "Let's use it." The real ones ask, “How are we going to use it, where are we not going to use it, and why? That takes a learning mindset. The best leaders I know are humble enough to say, “I don't have the answers, but I'm trying to find them with you.”

Spencer: I like that the good leaders are also saying what not to do with AI. Can you give examples?

David: If you don't make explicit what not to do, everything becomes a candidate for AI. For example, a junior product manager presents a very beautiful strategy to the whole company, while a senior product manager simply presents four bullet points. It turned out the junior's polished deck didn't survive two minutes of questions, because it was fully done by AI and the thinking wasn't built through. The senior had solid thinking behind those four bullets; that's the difference. With AI, you can make everything shine, beautiful infographics, and they look cool, but do you understand how you got there? If not, don't bother. I've seen leaders say: Don't create infographics, show your reasoning first, and once we understand that, let's make it shine, let's make it transparent to everyone.

Spencer: These beautiful AI-generated reports are deceiving. We subconsciously think that if it looks polished, it must be true. But the thinking is what actually matters. How about PMs building full-fledged coded prototypes with a real backend? Is that part of their role?

David: This is my opinion, it's not the truth, I don't own the truth. I do think product managers should be trying AI tools now and learning to prototype. It will help them test solutions faster. I think it helps. But I don't think PMs should be worried about putting things live in production.

I recently saw three PMs working frenetically with Claude Code, as well as engineers and designers. I asked, " Everyone is here. Who is talking to customers?” Nobody said anything. Serious question: “When was the last time anyone in this room bothered talking to a customer? "We're building something based on the feedback we had some time ago." I said, “Some time ago?” Then they went on saying, “Yeah, but we learned all of this, we know what to build.” I said, “Good, you know what to build. Did you show them anything early to see if it resonates with them, if it lands?” It is helpful to create prototypes, but if you go to very high fidelity, you're going to get feedback on the colors, on the design, not on the flow you wanted to understand.

Spencer: So a polished prototype pulls focus to the wrong things.

David: Yes, and I think it's valuable if we step back and say, “this is a problem we're trying to solve, so I'm creating a solution for that,” and keep the problem in mind, because the danger is you get excited: You start coding, you're going to see an output, and then your mind will go, “We could do this, we could do that,” and then you end up solving a problem you don't know if that exists at all. And then you will create a solution that you have no idea if anyone needs. Maybe you like it, but you don't know if anyone needs that.

One thing you can do is time-box it. You can say we're going to spend the next two hours. In two hours, you build something you can present to a few customers and test how it solves the problem. Just two hours, that's it. I like going in a range of two hours to half a day, because sometimes I talk to people who get so excited, they were building for three weeks without talking to anyone, and the solution was very beautiful, everything AI-created. Then once they presented to the customers, they got feedback exactly on the color, on the tonality, and all of these things. The problem, nobody remembered anymore.

Spencer: It's always tempting with AI: You're 90% there, so what's 5% more? And often it's already good enough.

David: What PMs should not do is go into a silo, like a cave behind the computer, and do everything alone. If you're doing something, make it transparent: What is the problem you're trying to solve, how do you think you're going to solve it, and collect perspectives from other people. You may still do it alone, that's all right, other people will do other things also, but make your direction transparent. Because AI amplifies whatever is happening, and if you are not aligned, it will amplify misalignment.

Spencer: Let's talk about the collaboration and alignment piece, since that seems so critical now.

David: Marty Cagan wrote one article where he shared his view on the future of product. What he said back then was that the product trio would become the product team. And today I am really seeing that, because AI enables us to create more. But the word "team" here remains very important. What I see is still the same things, maybe faster – alignment is necessary.

Spencer: What does alignment actually look like for a successful product team today?

David: There are many problems we could solve. Alignment means agreeing on which problems make the most sense to solve right now. That can be a prioritization strategy, a framework, whatever.  Then, we move toward how we’re going to solve it, exploring different solutions. And then we need to review our assumptions: What do we know? “What don’t we know? Then we test our assumptions. That’s where we may start interviewing and creating something. And we may go into our silos after that – engineering is going to do that, design is going to do that – but we know what everyone is going to do, and then we come back and say, here's what we learned. They may decide to do it all together, they may decide to do it separately, that doesn't matter. What matters is that it's clear to everyone what's going to happen and why.

Spencer: How can teams can align better on which problems to solve, and where does AI fit?

David: First, define what makes a problem something worth solving. Sometimes it's based on opinions, even with AI – can help clarify, but we need to standardize. I have been using something I call Basics Plus, but in essence, it's about answering some questions: What is in it for the business, what is in it for the audience, what is the solution they have right now, customer win, business win, how satisfied they are, and how often do they have this kind of problem. Because it might be a problem that's very relevant, but it happens once a month, and then you have another that is like median relevance, but happens every day. So which makes the most sense? We need to align on this, and I'm not asking for scoring – it's about comparing apples to apples, oranges to oranges. Then we can choose. AI can help us with that.

Spencer: Let's talk about frameworks. I know you have thoughts on when they're good and bad.

David: All right, this is a fun topic for many people watching. I got promoted several times because I was the person in the room who knew the most frameworks. Today, I think this is not how you should promote people. It's not about knowing the most frameworks; it is about knowing what to use when, and, specifically, it might be a piece of a framework, not the whole framework itself.

For example, I have seen some people, including myself, arrive in a place, and there's a framework. They go, “I love it, I’ll start with that.” So what is the problem with this? The context. You have to start with the context: What challenge is this team facing? Maybe it’s communication, maybe it’s prioritization. A product leader needs to have the ability to read the scenario and, after doing so, try to solve it in a way that the team can accept. Only then can you bring something; you can bring a framework.

The best definition of frameworks for me comes from Randy Silver – he's the host of Mind the Product, and he said something, I don't remember it exactly, but good frameworks will improve collaboration and simplify decision-making. So they help you with how you work, and then lead to better decisions.

Spencer: How does a framework actually improve collaboration?

David: It removes some things. For example, if you don't have clarity on how we'll work on this prioritization, everyone will take a different approach. For example, for a designer, what matters most might be the usability. For a product manager, maybe it's keeping the cost down so we can ship something. An engineer is talking about reliability. Everyone is playing a different game, so we want to get back to the same game. When you use a framework and make it transparent, then the team can say, “Okay, this is how we collaborate, this is how we can move on.”

Spencer: It comes back to thinking a framework isn't bad, it might just be wrong for the situation.

David: This is an interesting analogy to look at. In the beginning of my career, whenever I would see someone apply a framework differently than “by the book”, I would tell the person they were wrong. Today, it doesn't matter because the framework was created in a particular context for a particular situation. Your context might be different, and that's okay. You may need to bend a little bit to your situation, and that's fine.

This connects me to one thought I had after a talk in Rochester, New York, a few weeks ago. Ovetta Sampson shared, “Humans are better than AI. You know why? Because AI is trained on everything that is known. AI can connect the dots, find the patterns. But we, humans, we have one power nobody has. We believe in things that don't exist, and we make them exist. In the sixties, we decided to put a man on the moon, and it was unimaginable. We imagined, we made it possible. We are imagining things that don't exist, and we create them. So the dream comes from the human, and then we can execute.” And then she said, very enthusiastically. “We still have our dreams, and that's what belongs to us.” That stuck with me.

Spencer: What's critical for product leaders to learn going into 2026 and 2027, regardless of the AI conversation?

David: I've been working in product for almost two decades now. At some point, people would say, "You need to learn agility, the Spotify model, and so on." I still had the same thinking, and today I have the same: You need critical thinking, a strategic mindset. Good product managers understand the product inside out, they know perfectly how the products work. But the great PMs know the market, know how the product is positioned in the market, and why, and what to keep the product growing in the direction they want. 

This market understanding is often absent in product managers, and that ties to business savviness. You need to understand the business. It's not only about technology – technology is a means to an end – but it's about understanding who you serve and what matters for them, and then you figured out with the team how to make that happen. Yes, you will benefit from AI, yes, all of this will be good, but you are the brain behind the tool. So the best tool you can invest in is your mindset.

Spencer: A question from the chat: any guidance for stakeholder management, when we keep hearing speed to delivery is key, but our natural way of working takes time to evaluate properly?

David: Everyone's going to tell you that speed of delivery is key, and you can say, “Okay, let's accelerate delivery, and everyone will be happy in the short term.” But if you play the long-term game, you need to choose what you’re trying to optimize, what you’re trying to create. Working with stakeholders is not "managing" stakeholders; it is about reaching alignment. Often, stakeholders treat product teams as service providers. They expect you to deliver on their wants, and between quotes, you miss the customer's needs altogether because nobody took them into account. 

We play the same game; let's build partnership, not rivalry. We are not enemies of stakeholders – in reality, product people need stakeholders to create value together. First, let's get together, clarify what value is, what our best opportunities right now, and then decide why we are investing in that and align on how we make it happen. We need to make the hard conversations happen because often we just prioritize in parallel, we try executing more at the same time, at the cost of delivering less in the long term. So let's serialize, let’s say, “We get this done, and then we move to the next, and to the next.” It's a hard conversation, but it reaches alignment.

Spencer: That's the advice I got early on too: to come with an opinion backed by data, and show the trade-offs, the short-term versus the long-term.

David: Trade-offs are highly important. I once had 21 stakeholders in a room – and drew a number on the board (something like 533). Then I wrote a 30. Then I asked them, " Do you know what that is? It was the number of their combined requests.”  The 30 was the number of things we generally got to in a quarter. There was no way to deliver and satisfy everyone in that room. What we could do was name what was most important right now and work on that, and others had to accept it. It led to a serious conversation, because we showed reality. People don't see reality.

Spencer: Any thoughts on collaboration between product and sales, especially at "sales-led" companies?

David: It's the same as frameworks. I used to think product was all about frameworks, but eventually I acknowledged it’s all about people and collaboration. Now with sales, it’s the same. The first step is understanding how their success is measured: number of deals, what's going on, and so on. There is something they are measured against, and that is what they will do everything they can to achieve, because that's how they will get promoted, they will get their bonus, and so on – this is something you cannot compete against. So you clarify that, and then you figure out how to partner.

I got annoyed several times when sales promised something, and I started telling sales, how come you promise this? They said, “Oh, we had to close a deal.” I said, “What if we try to figure out something else? I would love to learn about reality with customers.” So I got to be part of some sales conversations, and we started partnering and being more involved: showing the future roadmap, not only the current one, so sales could help customers dream, going with sales to the potential leads. But understand what's success for them, and figure out how you can do the politics of product. This is trade: They have something they want, and there's something you can do for them to help them get there. If you figure out how to solve this equation, you improve collaboration and you partner instead of fighting each other.

Spencer: Any last thoughts for the audience?

David: My thought is the following: Product is already complex, let's not make it more complex. Sometimes people ask , “What can I add to make it better?” I would challenge you: What can you remove to make it easier? Think about it: something you're just doing because you have been doing it that way. Sometimes it's how you write product requirements, sometimes it's how you do these meetings. Think about removing something and see what happens.

eBook

The AI maturity gap:
Are product teams keeping up?

Read now