Navigating the Future: David Ohnstad on the Top Data & AI Trends Reshaping Product Management in 2025-2026

“`html

The next eighteen months will be a turning point for product management. We’re moving past the “AI might change everything” phase into the “AI is fundamentally changing how we build, measure, and think about products” reality. I’ve spent the last few years working on data and AI initiatives at Veeam, and what I’m seeing across the industry tells me that PMs who don’t shift their thinking now will find themselves increasingly dependent on specialists they don’t fully understand—which is exactly the wrong position to be in.

Let me be direct: the trends shaping 2025-2026 aren’t just about adopting new tools. They’re about redefining what product managers actually need to know, how they spend their time, and where they’ll add the most value. Some of these shifts will feel uncomfortable. Good.

Table of Contents

The Shift from AI Experimentation to AI Production: What Actually Changes for You

For the last two years, AI exploration in product teams felt optional. You could run an experiment, see if it moved the needle, and move on. That era is ending.

By 2025-2026, every major product will have some form of AI embedded in it. Not because it’s novel anymore, but because it’s economically necessary. And that shift—from “let’s test AI” to “our product doesn’t work without AI”—fundamentally changes your job as a PM.

Here’s the hard part: you can’t ship experimental AI to production the way you shipped feature flags and A/B tests. The risk profile is completely different. An experimental feature that underperforms is a miss. An AI system that hallucinates, drifts, or makes biased decisions at scale is a liability.

What this means for your scope:

You own the quality threshold, not just the feature definition. In the experimentation phase, you could rely on your data team to tell you if something worked. In production, you need to define and monitor what “working” looks like—especially for AI. What’s an acceptable hallucination rate? When do we retrain? How do we catch drift in real time? These aren’t technical questions your ML engineer will answer in isolation anymore. They’re business decisions embedded in your product strategy.
Your release process has more gates. You’ll move slower than your non-AI competitors initially. That’s intentional. You’re building guardrails: testing for bias, establishing rollback procedures, setting up monitoring that catches problems before customers see them. This friction is actually competitive advantage.
You’re managing model lineage like you’d manage a critical dependency. Which training data version is live? When was this model last validated? What’s the fallback behavior if it degrades? You need to know this as readily as you know your API versioning strategy.
Your feedback loops need to be much tighter. With traditional software, you could wait a week or two to analyze user feedback. With AI in production, you need real-time signals that the model is behaving as expected. That’s not a nice-to-have. That’s table stakes for shipping responsibly.

The PM role in production AI isn’t less technical than it was in experimentation. It’s differently technical. You’re not writing code or training models, but you’re fluent in the constraints, capabilities, and failure modes of AI systems. You speak both languages—business and technical—because the production handoff requires it.

Data Mesh vs. Data Lakehouse: Which Architecture Actually Wins (And Why It Matters for Your Products)

This is going to be controversial, so let me lay it out plainly: the winner is neither pure mesh nor pure lakehouse. It’s pragmatic architecture that adapts to your actual product needs.

Let me unpack why this matters to you as a PM, because infrastructure conversations often feel distant from product decisions. They shouldn’t.

Data Mesh: The appeal is real. Distributed ownership. Teams own their data domains. Less bottleneck on a central data team. But mesh at scale requires organizational discipline that most companies don’t have yet. You end up with seven different ways to define “active user.” Data contracts that nobody maintains. Governance that’s aspirational rather than actual. The mesh works beautifully in theory and in well-run companies. It breaks down in companies where people are busy and corners get cut.

Data Lakehouse: Centralized, unified, easier to govern initially. But now you’re back to a bottleneck. Your data team becomes a service desk. Simple queries from PMs take weeks because the backlog is packed with engineering requests. And when you want to run that quick analysis to validate an assumption, you’re waiting or learning SQL well enough to do it yourself (which takes you out of product strategy work).

Here’s what I’m actually seeing work in 2025-2026:

Hybrid approach with clear layers:

Core lakehouse for operational data. Your source of truth for metrics, customer data, product events. Centrally managed, governed, monitored. This is non-negotiable. Everyone needs to trust this data.
Domain-owned data marts for specialized use cases. If the ML team needs custom features for their models, or the marketing team needs to build their own audience segments, they own that layer. They build on top of the core lakehouse, they don’t bypass it.
Real-time streaming layer for time-sensitive decisions. More on this below, but your core lakehouse architecture needs to support both batch and streaming without forcing a false choice.

Why this matters for your product strategy: your data architecture determines the speed at which you can test hypotheses and iterate. If getting to your data takes three weeks and involves a ticket, you’ll test fewer hypotheses. If you can query it in an afternoon, you’ll move faster and learn more. The best architecture for your team is the one that puts data closer to the people who use it while maintaining governance at the core.

My recommendation: audit your current data architecture through a product lens, not an engineering lens. Ask: “If I need data to answer a question about user behavior, how long does it take?” If the answer is more than a few hours, your architecture is slowing down product development. That’s not a technical problem. That’s a business problem.

The Rise of ‘PM as Data Steward’: You’re Owning Data Quality Now

This is one of the bigger shifts I’m emphasizing in my conversations with product leaders, because it’s subtle but consequential.

Historically, data quality was an IT or data engineering concern. Your job was to write clear requirements. Their job was to build the database that captured them. Simple division of labor.

That model is breaking down.

Why? Because data quality directly impacts product quality now in ways that weren’t true five years ago. A bad value in your production database might train a model that gives your customers poor recommendations. A bias in your training data might systematically disadvantage certain user segments. A schema change that nobody told the ML team about might cause inference to fail silently.

You can’t outsource responsibility for this to specialists. You have to own it.

What “PM as data steward” actually means in practice:

You define and monitor data contracts. What fields are required? What’s a valid value range? What’s acceptable freshness? These aren’t technical specifications. They’re product requirements, because they determine what your systems can reliably do. You own this with your data and engineering teams.
You audit the training data for your AI systems. Not exhaustively—that’s your ML team’s job. But you ask the questions: Where does this data come from? How fresh is it? Do we have blind spots? Could this data introduce bias? You can’t answer these alone, but you can’t skip them either.
You’re involved in data governance decisions. When there’s a tradeoff between data availability and data privacy, or between speed and accuracy, those are product decisions disguised as data questions. You need a seat at that table.
You understand your data lineage for critical features. If a critical metric suddenly shifts, you need to trace it back: Was it a code change? A data pipeline update? A schema change? You don’t debug it alone, but you ask smart questions and understand the answers.

The skills gap here is real. Most PMs weren’t trained to think this way. You were trained to focus on user needs and business metrics, not on the underlying data that feeds those metrics. Over the next two years, this skill will become as fundamental to product management as understanding conversion funnels or user retention. Start building it now.

AI Agents Are Redefining How You Think About User Journeys

This one will reshape product thinking more than anything else on this list.

Traditional product roadmaps assume humans make decisions. The user opens your app, sees options, thinks about what they want, and takes action. Your job is to optimize that flow—reduce friction, clarify options, get out of the way.

AI agents operate differently. An agent doesn’t just follow a user’s request. It decomposes goals into subgoals, figures out which systems to call and in what order, and acts autonomously. It might trigger five different operations across three different services to accomplish something that a human would have needed to do manually in five separate steps.

This changes how you need to think about product value and user journeys.

The old way: “How can I make it easier for users to X?” Answer: Streamline the UI, add search, etc.

The new way: “Can I remove the need for users to do X at all, because an AI agent can anticipate and handle it automatically?”

Example: Instead of building better tools for customers to manually manage their backup schedules, you build an agent that observes their infrastructure patterns, predicts their backup needs, and handles scheduling automatically—surfacing decisions only when humans need to override the default.

This shift requires different skills from you as a PM:

You’re designing for delegation, not just usability. What decisions can be delegated to an agent? Which ones should stay with the human? The right answer changes based on domain, risk tolerance, and the cost of errors. You need frameworks for making these calls.
You’re thinking about agent reliability differently than feature reliability. A feature that fails 1% of the time is annoying. An agent that fails 1% of the time might be actively harmful if it’s making autonomous decisions. Your quality bar changes.
You’re designing feedback loops between agents and humans. How does the agent learn from corrections? How does it surface uncertainty? How does a human take back control if something goes wrong? These aren’t edge cases. They’re core to the user experience with agents.
Your metrics change. You’re not just measuring “did the user accomplish their goal?” You’re measuring “did the agent accomplish the goal correctly without requiring human intervention?” “How often did the human override the agent’s recommendation?” “How much human effort did the agent actually save?” These are different questions.

The teams that win with agents aren’t the ones that slap an agent into an existing product. They’re the ones that rebuild the product architecture around what agents can do. That rethinking happens at the product strategy level, which means it’s your job.

Real-Time Data Products Aren’t Differentiation Anymore—They’re Admission Price

Five years ago, real-time dashboards and streaming data were competitive advantage. Now they’re baseline expectation.

I’m seeing this clearly in 2025: if your product doesn’t operate on current data, it’s at a massive disadvantage relative to competitors who do. Users have become accustomed to real-time information in consumer products. They expect the same in enterprise software.

Real-time data product requirements have shifted from “nice to have” to “table stakes.”

This creates pressure on your architecture and your team’s capabilities:

Streaming infrastructure is now baseline. You can’t build serious AI-powered products without the ability to process streams of data in real time. Not as a special feature. As part of your platform.
Latency becomes a business metric, not just a technical metric. How fast does data flow from event to insight to action? If your competitor can show customers real-time anomalies and you show them delays of hours or days, you lose on value. You need to know your latency and optimize it like you optimize conversion rate.
You’re managing freshness tradeoffs constantly. Real-time data costs more (more infrastructure, more complexity). Stale data costs less but loses value. For each data product you own, you need to decide: How fresh does this need to be? What are we willing to pay for that freshness? This is a product decision, not a technical decision.
Reliability and consistency matter differently in real-time systems. If a batch process fails, you can usually rerun it. If a streaming pipeline fails, you lose data and have no way to backfill. Your approach to observability and reliability changes.

What this means practically: you need to build streaming-first thinking into your data architecture now, even if you’re not using it yet. Don’t architect for batch and bolt on streaming later. Design for streams, use batch as a fallback. By 2026, this will be the default approach at most companies doing serious data work.

The Skills Gap PMs Need to Close in the Next 2 Years

I’m blunt about this because it matters: the PMs who stay relevant in this environment will be different from the PMs who dominated 2015-2023.

You don’t need to become a data engineer or ML researcher. But you do need to close specific gaps:

1. Data literacy fundamentals

You should be comfortable with:

SQL basics. Not query optimization. But you should be able to write a simple SELECT statement and understand joins, filters, and aggregations. Why? Because you’ll be your own first line of querying when you need data.
Understanding what “training data” means for AI systems. Where it comes from. How it shapes model behavior. Why bias in training data leads to bias in predictions.
Statistical thinking. You don’t need to run regressions. But you need intuition for causation vs. correlation, statistical significance, and how sample size affects confidence in results.

2. AI system thinking

You should understand:

The difference between a classifier, a recommender, and an agent—and which one you’re building.
What “prompt engineering” actually is and why it’s a form of product design.
The lifecycle of an AI system: training → evaluation → deployment → monitoring → retraining. Where does your product sit in that cycle?
Why hallucination happens in language models and what the realistic tradeoff between accuracy and capability is.

3. Data architecture literacy

You should be able to:

Draw your data flow: Where does data come from? Where does it live? How does it move between systems? What’s the latency at each step?
Understand the implications of architectural decisions. If we move to a data lakehouse, what becomes easier? What becomes harder?
Ask good questions about data quality, governance, and freshness without relying entirely on your data team to educate you.

4. Operational data thinking

This is probably the least obvious but most important shift. You need to think of data itself as a product you’re building.

What are the users of this data? (Usually other teams, but sometimes customers.)
What’s the interface? (APIs, dashboards, exports, real-time feeds)
What’s the quality bar? (Latency, accuracy, freshness, availability)
How do I know if this data is being used and adding value?

This is where “PM as data steward” becomes actionable. You’re not just consuming data to make decisions. You’re responsible for the quality and usability of data that others depend on.

How to actually build