The Product Manager Role in the Age of AI: What It Now Requires

Why the product manager role is harder to enter and harder to stay in than it was five years ago

The standard description of product management—sit at the intersection of business, technology, and user experience; prioritize ruthlessly; say no often—has not changed. What has changed is everything around it.

In a recent episode of the Tech Effect podcast, we sat down with Boban Ljubinoski, product manager at Klarna, one of the world's largest buy-now-pay-later platforms, and a decade-long veteran of product roles across food tech and fintech. His path to product management was anything but direct. His mother suggested he try computers, he started in customer support at an internet company, moved into tech support, and was eventually told by a mentor that he would make a good product manager. He took the advice and did not look back. 

That path—customer support to tech support to product management—gave him something that formal routes often miss. Specifically, a genuine understanding of what end users experience when software fails them, and an instinct for problem-solving that came from having solved other people's problems before he was ever responsible for building anything. 

Ljubinoski's view of the role in 2026 is specific and unromantic. Product management has always been strategic, but it has never required as much technical fluency as it does now, and the organizations product managers operate in have never been as flat, as exposed, or as demanding of individual capability.

What the AI boom actually did to product teams

The shift that Ljubinoski identifies as the pivot point is not simply the arrival of AI tools. It is the convergence of post-COVID organizational restructuring with the AI capability explosion of 2022—two forces that hit simultaneously and permanently changed what a product team looks like.

"Orgs which were already very flat in the tech world in my opinion became even more flatter. And teams actually shrank a lot. A more traditional product team would have different people with different skills. Now it has mostly a product manager and a handful or less of engineers."

The practical consequence is that work that previously had dedicated owners, like prototype design, data analysis, pitch deck creation, API integration testing, and basic UI changes, now falls to the product manager by default. Not because product managers are uniquely qualified to do it, but because there is no one else.

The tools that make this possible are the same ones that made the headcount reduction feel viable: AI-assisted coding environments like Cursor and Claude Code, no-code and low-code prototyping, generative AI for content and design. A product manager who knows how to use these tools can produce a working prototype, a data query, a competitor analysis, and a presentation in the time it used to take to brief three different specialists. One who cannot is operating with a capability gap that becomes more visible every year.

Ljubinoski is direct about what this means for the barrier to entry. 

"I would say very soon, in the next 12 to 18 months, it would be very common that you need to present your own portfolio of vibe-coded projects. That would actually be something that would be required."

The right and wrong way to implement AI across an organization

The gap between companies that extract value from AI and those that generate noise from it often comes down to a single structural decision. Specifically, whether AI adoption is driven centrally or left to individual teams.

"The biggest mistake I have seen is that companies are implementing AI in a way that they say 'we have a new tool' and ask the teams to use it. That was early 2022 AI implementation. Right now, implementations should be driven more centrally by a very strong team that can actually start thinking about building AI from the bottom up, starting with your data and how you store the schema, how you store your customer data, how you store your partner data."

The reason decentralized AI adoption creates problems is not that teams make bad choices in isolation. It is that the problems created by inconsistent data structures, privacy approaches, and security implementations accumulate below the surface until they become expensive to fix. When every team stores its data differently, structures its customer records differently, and integrates AI tools with different assumptions about what data the model can access, the result is a system that cannot be improved coherently because there is no coherent foundation to build on.

The central team approach Ljubinoski advocates takes longer to show results. The payoff is an AI architecture that can actually scale. This is because the data layer, the thing AI learns from and operates on, was designed to support it rather than discovered to be inadequate after the fact.

Flat organizations and the end of the hierarchy hiding places

One of the less-discussed consequences of organizational flattening is what it does to visibility. In a traditional hierarchy, a product manager with moderate skills can navigate upward through political relationships, stay safely in their lane, and avoid the exposing moments where capability has to speak for itself. In a flat organization, that cover disappears.

"While orgs are becoming more flat, teams are becoming less autonomous. There is just much more stronger direction on what to do. The whole concept of each team is their own startup is basically dead."

This cuts in two directions. For strong product managers, flat organizations are an accelerant. Direct access to leadership, fewer layers of approval, and faster decision cycles. These are exactly the conditions that reward people who can think clearly, communicate well, and make things happen without needing a large supporting cast. The exposure that would have been threatening in a hierarchical organization becomes an advantage.

For weaker product managers, the same conditions are unforgiving. There is no org chart complexity to absorb mediocre work, no friendly manager to filter the feedback before it reaches the top. Performance is visible, and so is its absence.

The reduced autonomy that comes with flat organizations is counterintuitive. Flatter feels like it should mean freer, but it makes sense at scale. When teams can do whatever they want, large organizations become incoherent. When direction is centralized and execution is delegated, the organization can move consistently. Scope is decided at the top, while method is left to the team. That distinction matters for product managers because it changes the nature of the job: less evangelism for your own ideas, more excellent execution of shared ones.

Speed vs. quality: Why the tradeoff is usually a myth

In any product organization under pressure to ship, the question of whether to sacrifice quality for speed is a constant. Ljubinoski's answer cuts through the usual framing.

"I feel like generally it's a myth that all the stakeholders are rushing through and trying to sacrifice quality for speed. I feel like no one in the right mind would actually sacrifice quality. Usually sacrificing quality happens by accident where you miss something and then you have to fix it. Usually it's scope that gets sacrificed first."

This is a useful reframe because it changes where the product manager's energy should go. If quality rarely degrades by design but frequently degrades by omission—because something was missed, because testing was inadequate, because a dependency was not considered—then the defense against quality failures is not better negotiation with stakeholders. It is better discipline in the development and testing process itself.

His personal rule is direct. Fix what is broken before building what is new. Building on top of a known problem compounds the problem. Fixing the foundation first creates a base that new features can actually stand on, and it builds the user trust that makes customers willing to tolerate the occasional rough edge that accompanies genuinely new capability.

The exception, and it is a hard line, is anything touching payments or user trust in a fintech context. In those areas, there is no acceptable risk level, no argument about speed that outweighs getting it right, and no stakeholder who would knowingly sign off on a compromise. Trust is the product. Compromising it is not a speed-quality tradeoff, it is destroying what the business is built on.

The US vs. Europe product management gap

Ljubinoski has worked across both American and European tech companies and draws a precise distinction in how product management is practiced in each.

American companies carry a higher tolerance for risk. The "do it now and say sorry later" orientation that moves faster to market but accumulates more technical and product debt in the process. American product managers are more likely to genuinely own the P&L, to be accountable for revenue impact rather than just product output.

European companies tend to build more in-house, move more deliberately, and ship with more polish, but at the cost of speed. The P&L ownership is less direct and the sense of commercial accountability is more diffuse.

Neither is simply better. Higher risk tolerance produces faster market entry but more catching up afterwards. More deliberate execution produces more stable launches but slower competitive response. The important thing for product managers is knowing which environment they are operating in, because the skills and behaviors that succeed in one do not automatically transfer to the other.

What comes next: Agentic commerce and the redesign of the PM role

The near-term shift Ljubinoski sees coming to fintech and e-commerce is specific enough to plan for.

"We're looking basically at agentic commerce—people spending less time browsing for products and more or less working with agents doing the shopping on their behalf. And dynamic UI—the UI is going to dynamically change for each customer in each context."

This is not speculative. The trajectory from targeted content personalization to full on-the-spot page redesign, driven by AI agents responding to individual context in real time, is already underway. The product manager's job in that world shifts from designing pages and user flows to designing the interactions between agents and APIs—the rules, the guardrails, the handoff conditions that determine how an AI agent behaves on behalf of a user.

That shift, Ljubinoski notes, will arrive within 12 to 18 months in meaningful form. For product managers in fintech and e-commerce, it is not a horizon event to prepare for eventually. It is a change already in progress that requires building fluency now.

Essentially, the product manager role has not changed in its strategic essence. It has always been about making the right things happen at the right time for users and the business. What has changed is the technical depth required to operate credibly, the organizational conditions that determine how visible and how exposed the work is, and the AI-native skills that separate product managers who are accelerated by new tools from those who are threatened by them.

→ Listen to the full conversation with Boban Ljubinoski on the Tech Effect podcast

Key takeaways

The hard skills bar for product management has moved significantly since 2022. Flat organizations and smaller teams mean product managers now handle work that previously belonged to designers, engineers, and analysts. Proficiency with AI-assisted coding tools, prototyping, data querying, and API integration is increasingly expected, not optional.

Decentralized AI adoption creates consistency, privacy, and security problems that compound over time. AI strategy must be driven centrally, from the data layer up, rethinking how customer, partner, and operational data is stored and structured before building applications on top of it.

Flat organizations expose product managers in both directions. Strong ones gain direct visibility to leadership and faster decision cycles. Weak ones lose the org chart cover that previously made mediocre work survivable. There is no longer anywhere to hide.

Quality almost never degrades by design, it degrades by omission. Stakeholders rarely consciously sacrifice quality for speed; they sacrifice scope. The product manager's job is to maintain discipline in the development and testing process, and to fix what is broken before building on top of it.

Anything touching payments or user trust in fintech is a hard line. There is no acceptable risk level in those areas, and no speed argument that outweighs getting it right. User trust is not one consideration among several, it is the foundation everything else is built on.

Agentic commerce is arriving within 12 to 18 months. AI agents making purchasing decisions on behalf of users will shift the product manager's job from designing pages to designing agent-to-API interactions. Building fluency in that model now is not preparation, it is catching up.