We’re two years into the great AI awakening, and enterprise software teams are still trying to separate signal from noise. Every vendor claims their product now has “AI-powered” something-or-other. Every conference presentation shows a chart going up and to the right. But in the actual trenches—in the code reviews, sprint planning meetings, and production incidents—what’s really changing?

The honest answer is more nuanced than either the evangelists or the skeptics admit. Some problems that plagued enterprise teams for years are genuinely getting better. Others are becoming more complex. And some are just getting repackaged with new technology labels while the underlying challenges remain untouched.

After watching how enterprise teams actually use machine learning in production over the last few years, a clearer picture has emerged. It’s time to talk about what’s real.

Where Machine Learning Actually Delivers Value

Let’s start with the good news: there are specific categories of enterprise problems where machine learning genuinely outperforms traditional approaches. Understanding these categories matters because it’s where you should focus your investment.

Pattern Recognition in High-Dimensional Data

This is the clearest win for ML. When you have problems that involve recognizing patterns across hundreds or thousands of features, where the relationships between variables are non-linear and complex, machine learning beats hand-coded rules every time.

Real example: detecting fraudulent transactions in financial systems. A traditional rule-based system might catch obvious cases—”transaction from known fraud location”—but it breaks down fast. ML models can learn subtle combinations: the time of day plus the merchant category plus the user’s device plus their historical pattern plus seventeen other factors. When you retrain that model monthly on new data, it adapts to evolving fraud tactics in ways a rules engine never can.

Same story with anomaly detection in infrastructure. Knowing that “CPU > 90%” is bad is elementary. Knowing that “CPU at 75%, but traffic is down 40%, and memory is stable, and this pattern happened on this day last month” is something only learned models do well. Enterprise teams are seeing real value here—catching issues before customers do, reducing MTTR significantly.

The key characteristic: the problem has volume, the ground truth is available for training, and traditional rule-based approaches have hit diminishing returns.

Ranking and Recommendation Under Constraints

Enterprise software often needs to rank or recommend something under multiple competing constraints. Allocating resources, prioritizing work, suggesting next steps—these are ML-friendly problems.

Consider resource allocation in a large organization. You have projects, people, skills, constraints, deadlines, and organizational goals that sometimes conflict. A traditional approach creates spreadsheets and committee meetings. ML models can learn to balance these factors in ways that improve outcomes measurably.

One financial services company retrained a recommendation model quarterly that suggested which client relationships their sales team should prioritize. It considered account size, growth trajectory, risk metrics, account manager capacity, and competitive threat level. The model didn’t make decisions, but it surfaced the highest-opportunity accounts much more reliably than the existing process of “accounts over $1M get attention.” Client engagement metrics improved 23% in the first year.

The constraint-based ranking problem is different from pure recommendation systems (which often oversell their value in enterprise contexts). When you have clear business constraints and measurable outcomes, ML wins.

Classification with Imbalanced or Evolving Classes

Enterprise software frequently deals with classification problems: is this a high-priority incident? Does this data require regulatory review? Is this a churn risk? Traditional rules struggle when the positive cases are rare, when definitions shift, or when patterns change seasonally.

ML shines here. You can train on historical data, account for class imbalance, and retrain regularly as definitions evolve. A healthcare software company built a model to flag potential adverse drug interactions for pharmacist review. The ground truth was sparse—most interactions aren’t problems—but the cost of missing real interactions is high. The model achieved 0.92 precision at 0.85 recall, which meant pharmacists reviewed 50% fewer cases while catching 85% of the real interactions. That’s a genuine operational win.

These problems have something in common: they generate continuous data, the ground truth is available for feedback, and the relationship between inputs and outputs is sufficiently complex that coding rules breaks down.

Time Series Forecasting with Seasonal and Trend Components

Enterprise planning relies on forecasts: capacity planning, demand forecasting, revenue projections. Traditional statistical methods (ARIMA, exponential smoothing) work fine for stable systems, but they break down when you have multiple seasonal patterns, trend shifts, or unusual events.

ML models handle this better. Gradient boosted models and neural networks can capture complex temporal patterns, automatically handle multiple seasonality, and incorporate external features (holiday calendars, marketing campaigns, etc.). One SaaS company used an LSTM-based model for usage forecasting that reduced their planning error by 18% compared to their previous statistical approach. That 18% translated directly to better resource allocation and fewer surprised stakeholders.

But—and this is important—the improvement is incremental, not revolutionary. You’re going from 85% accuracy to 87%. You’re still getting forecasting wrong sometimes. The value is real but measurable, not transformational.

Where AI/ML Adds Overhead Without Commensurate Value

The inverse is equally important: understanding where ML is worse than simpler approaches, or where the overhead costs exceed the benefits.

When Rule-Based Systems Still Win

In many enterprise domains, the rules are actually well-defined and stable. Compliance rule engines, specific business logic, configuration validation—these have clear conditions and clear actions. Adding ML here is complexity theatre.

A payments company spent eight months building an ML model to route transactions to different processing systems based on transaction characteristics. The model achieved 96% accuracy on test data. But the existing rule-based router achieved 98% accuracy, deployed in seconds, and anyone could read the rules. The ML model required a data science team to maintain, created a dependency, and added latency to processing. It was abandoned after two quarters.

The principle: if you can express the decision rules clearly, and the rules are stable, and accuracy is already high, don’t use ML.

Classification Problems with Small, Stable Datasets

Not every classification problem has volume. When you’re dealing with a stable problem with limited training data—say, categorizing 500 support tickets monthly into 8 categories—a well-trained human with a decision tree beats ML with all its overhead.

ML requires data. Lots of it. It requires infrastructure. It requires monitoring. When your dataset has 1,000 positive examples and hasn’t changed in two years, traditional methods work fine. Don’t build data pipelines and retraining infrastructure for this.

Problems Requiring Explainability as a First-Class Requirement

In regulated industries—healthcare, finance, public sector—explainability often matters more than accuracy. “The model decided this” doesn’t cut it when someone needs to understand why.

A healthcare company spent significant effort building a deep learning model to predict patient no-shows. The model was 4% more accurate than logistic regression. But explaining why the neural network predicted a no-show required complex visualization and interpretation tools that ultimately confused the clinicians. They switched back to interpretable models. The 4% accuracy difference wasn’t worth the explainability tax.

Sometimes interpretable approaches (logistic regression, decision trees, linear models) are the right tool. The enterprise tendency to reach for fancy algorithms regardless of constraints costs real money.

Data Quality Problems Masquerading as Model Problems

Here’s an underrated challenge: many enterprise teams blame model accuracy when the real problem is data quality. They collect messy data, train models on it, get mediocre results, and conclude they need more sophisticated algorithms.

What they actually need is better data pipelines. A financial services company wanted to predict customer churn using ML. They spent months on model selection, reaching 73% AUC. Eventually they realized their “customer churn” labels were inconsistent—different business units defined churn differently. Fixing the label definitions (no new models required) got them to 81% AUC. The ML wasn’t the bottleneck; the data was.

This is where enterprise ML projects often fail silently. You build something, it works okay, you move on. But you’ve left 20% of value on the table because you never fixed the underlying data problems.

How ML Is Changing the Product Manager’s Role

The emergence of usable ML is reshaping what product management means in software organizations.

The New Skill: Understanding Your Metrics

When your product is rule-based, a PM needs to understand business logic. When your product includes ML, a PM needs to understand metrics in a different way. Not statistics necessarily, but the relationship between model performance, business outcomes, and user behavior.

A PM at a B2B SaaS company with an ML-based recommendation system needs to understand: “Our model has 0.87 precision but only 0.62 recall on our tail categories. What does that mean for user experience? Should we retrain on more recent data? Should we adjust the confidence threshold?” These aren’t strictly data science questions, but they require thinking like one.

The best PMs managing ML features are developing this skill. They’re not building models, but they understand precision/recall tradeoffs, feature importance, model staleness, and data drift. They know enough to ask the right questions.

Feature Management Becomes a Product Responsibility

In traditional software, the product scope is clear: this screen does this, this API returns this. In ML systems, the feature engineering—what data feeds the model—is a product decision with business implications.

Should we include the user’s entire history or just recent activity? Should we use real-time data or batch-processed data? Should we include competitive data, demographic data, external signals? These are product questions that affect model behavior and business outcomes.

Some organizations add a “feature product manager” role—someone who owns what data flows into ML systems. Others distribute this responsibility to PMs managing specific features. Either way, someone needs to think about feature decisions as product decisions, not implementation details.

Continuous Learning Becomes the Operating Model

Rule-based software has release cycles: you ship something, it’s stable until you change it. ML systems drift. Models need retraining. Performance degrades gradually. The operating model shifts to continuous monitoring and iteration.

This changes how PMs think about releases. You’re not shipping a fixed feature; you’re launching an ongoing process. You need monitoring in place before launch. You need metrics dashboards. You need a feedback loop. You need to know when your model’s performance is degrading and understand why.

The best PM practice: define the success metrics and monitoring upfront. Don’t wait until after launch to figure out how you’ll know if it’s working. With ML, that’s too late—you’ll have already shipped something you can’t easily evaluate.

The Expectation Problem

Here’s the hardest part of the PM’s job with ML: managing expectations. Marketing wants to call every ML feature “AI-powered.” Executives expect dramatic improvements. Customers expect magical results.

The reality is more mundane. An ML recommendation system might improve engagement by 12%. A churn prediction model might identify 40% of churners in advance (meaning you miss 60%). An anomaly detection system might reduce false positives by 30% while catching 85% of real issues.

The PM’s job is setting realistic expectations and celebrating real but unglamorous wins. This is harder than it sounds when everyone else is talking about “AI transformation.”

The Organizational Muscle Required to Use ML Outputs

Here’s what doesn’t get discussed enough: making ML useful requires organizational capabilities beyond the algorithm.

Decision-Making Velocity and Structured Processes

A churn prediction model is only valuable if you act on it quickly. A demand forecast only helps if you can adjust resource allocation based on it. An anomaly detection system only matters if you have a process to investigate anomalies.

Enterprise organizations often lack this. They want the prediction but they don’t have a clear process to act on it. The model surfaces 100 high-risk accounts, but the sales team’s process for handling this information is undefined. Do they call everyone? Do they invest in reengagement campaigns? Do they concede the account? Without a clear process, the model output creates noise, not value.

The organizations that get value from ML are the ones that first define how they’ll use the predictions, then build the model. Not the other way around.

Data Pipeline Maturity

ML models are useless without data. And enterprise data pipelines are often a mess—fragmented across systems, inconsistently defined, unreliable.

Building ML in an immature data environment is like building on sand. You need:

  • Single source of truth for key definitions (what is a customer? what is a transaction?)
  • Reliable data movement from source systems to analytics infrastructure
  • Data quality monitoring and validation
  • Documented data lineage so people know where numbers come from
  • Appropriate data governance and access controls

Many organizations skip this and jump to ML. Then they’re surprised when model performance is mediocre and they can’t explain why. The real bottleneck wasn’t the algorithm—it was the foundation.

Human-in-the-Loop Decision Making

Almost no enterprise ML system works in fully autonomous mode. You have recommendations, not decisions. You have alerts, not actions. You have predictions, not certainties.

Someone still needs to look at the output and make a judgment call. An anomaly detector flags something unusual—is it a problem or normal variation? A recommendation system suggests a product—should we show it? An algorithm surfaces a risk—is the risk real or a false alarm?

This means you need trained humans in the loop. They need to understand what the model is doing, what its limitations are, and how to interpret its output. Building and training this capability takes time and is often underestimated.

One financial services company built a nice predictive model for fraud. But the compliance team reviewing alerts didn’t understand the model well enough to trust it. They second-guessed every decision. The model was technically sound but operationally ineffective. After training and trust-building, it eventually added value, but it took six months of organizational work.

Feedback and Monitoring Infrastructure

Models degrade over time. Usage patterns change. Customer behavior drifts. The world is non-stationary. You need to monitor model performance continuously and understand when and why it degrades.

This requires:

  • Instrumentation to track predictions and outcomes
  • Dashboards showing model performance metrics over time
  • Root cause analysis when performance drops
  • Processes to retrain and update models
  • Alerting when something is wrong

Every data science team will tell you they want to build this. Most organizations don’t actually fund it because it’s less glamorous than building new models. So they deploy models, they degrade silently, and six months later people are confused why the predictions aren’t as good anymore.

The organizations that get sustained value from ML are the ones that treat

The post The Real Impact of AI and ML on Enterprise Problem-Solving: Beyond the Hype appeared first on David Ohnstad.

]]> https://davidohnstad.net/the-real-impact-of-emerging-tech-trends-on-everyday-problem-solving/feed/ 0 Edge Computing vs. Cloud Computing: Which is the Future? https://davidohnstad.net/edge-computing-vs-cloud-computing-which-is-the-future/ https://davidohnstad.net/edge-computing-vs-cloud-computing-which-is-the-future/#respond Wed, 20 May 2026 21:33:44 +0000 https://davidohnstad.net/edge-computing-vs-cloud-computing-which-is-the-future/ As businesses strive to improve efficiency, reduce latency, and leverage the power of data, understanding the strengths and limitations of these two computing paradigms is crucial.

The post Edge Computing vs. Cloud Computing: Which is the Future? appeared first on David Ohnstad.

]]> David Ohnstad is at the forefront of the ongoing debate between edge computing and cloud computing, a discussion that has captivated the tech industry as it looks toward the future. As businesses strive to improve efficiency, reduce latency, and leverage the power of data, understanding the strengths and limitations of these two computing paradigms is crucial. Both edge and cloud computing have their unique advantages, and each plays a significant role in the evolving technological landscape. However, the question remains: which one will ultimately dominate the tech landscape in the coming years?

Understanding Cloud Computing

Cloud computing has been the backbone of digital transformation for the past decade. By allowing businesses to store and process data in centralized data centers, cloud computing offers unparalleled scalability, flexibility, and cost-efficiency. Companies can access vast computational resources on-demand, without the need to invest in expensive hardware infrastructure. This has led to widespread adoption across industries, from startups to global enterprises.

The major cloud providers—Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform—have built extensive networks of data centers around the world, enabling businesses to deploy applications and services with global reach. The ability to scale resources up or down based on demand has made cloud computing the go-to solution for companies seeking agility and innovation.

However, despite its many advantages, cloud computing is not without its challenges. Latency, bandwidth limitations, and the centralized nature of cloud infrastructure can create bottlenecks, particularly for applications requiring real-time data processing. This is where edge computing comes into play.

The Emergence of Edge Computing

David Ohnstad and other industry experts recognize that edge computing is gaining traction as a solution to the limitations of cloud computing. Edge computing involves processing data closer to the source of data generation, such as IoT devices, sensors, or local servers, rather than relying solely on distant cloud data centers. By bringing computation and data storage closer to the user, edge computing reduces latency and enables faster decision-making.

One of the key benefits of edge computing is its ability to support real-time applications. In industries such as healthcare, autonomous vehicles, and industrial automation, milliseconds matter. Edge computing allows these applications to function with minimal latency, ensuring that critical data is processed and acted upon almost instantaneously.

Moreover, edge computing reduces the strain on network bandwidth by processing data locally. This is particularly important as the number of connected devices continues to grow, leading to an exponential increase in data generation. By filtering and processing data at the edge, only relevant information is sent to the cloud, optimizing bandwidth usage and reducing costs.

Edge vs. Cloud: A Complementary Relationship

While the debate between edge and cloud computing often positions them as competitors, the reality is more nuanced. David Ohnstad points out that the future of computing likely involves a hybrid approach that leverages the strengths of both paradigms. Edge computing and cloud computing are not mutually exclusive; instead, they can work together to create more efficient and resilient systems.

For instance, edge computing can handle real-time data processing and decision-making, while cloud computing provides centralized storage, analytics, and machine learning capabilities. This hybrid model allows businesses to take advantage of the best of both worlds: the low-latency performance of edge computing and the vast computational power of the cloud.

One practical example of this hybrid approach is in the realm of autonomous vehicles. These vehicles generate massive amounts of data from sensors and cameras, which need to be processed in real-time to ensure safe navigation. Edge computing enables this real-time processing, while the cloud can be used to store and analyze historical data, improving the vehicle’s performance over time.

Challenges and Considerations

Despite its potential, edge computing is not without challenges. One of the primary concerns is security. With data being processed at multiple edge locations, the attack surface for cyber threats increases. Ensuring that data remains secure as it moves between the edge and the cloud is a critical challenge that businesses must address.

Additionally, edge computing requires significant investment in infrastructure, including edge servers, gateways, and networking equipment. For some organizations, particularly smaller businesses, this investment may be a barrier to adoption. However, as the technology matures and costs decrease, edge computing is expected to become more accessible.

David Ohnstad also highlights the importance of standardization in the edge computing space. Currently, the lack of standardized protocols and frameworks can create interoperability issues, making it difficult for businesses to integrate edge computing into their existing systems smoothly. Industry collaboration and the development of common standards will be key to overcoming these challenges.

The Future of Computing: Edge, Cloud, or Both?

As we look to the future, the question of whether edge computing or cloud computing will dominate the tech landscape remains open. David Ohnstad believes that both will play crucial roles, with the choice between them depending on the specific needs of the application or industry.

For latency-sensitive, real-time applications, edge computing will likely take the lead. On the other hand, for tasks requiring large-scale data processing, storage, and analytics, cloud computing will continue to be the preferred option. The true power of these technologies lies in their ability to complement each other, creating a more flexible and efficient computing environment.

The future of computing is not a matter of choosing between edge and cloud but rather understanding how to integrate them effectively. David Ohnstad’s insights suggest that a hybrid approach, combining the strengths of both, will be key to driving innovation and meeting the demands of the digital age.

More from David Ohnstad: David Ohnstad on leadership and career

The post Edge Computing vs. Cloud Computing: Which is the Future? appeared first on David Ohnstad.

]]> https://davidohnstad.net/edge-computing-vs-cloud-computing-which-is-the-future/feed/ 0 Building AI Products in the Enterprise: What Actually Works in 2025 https://davidohnstad.net/ai-and-web3-products/ https://davidohnstad.net/ai-and-web3-products/#respond Wed, 20 May 2026 21:21:21 +0000 https://davidohnstad.net/ai-and-web3-products/ Web3, the World Wide Web's third generation, is full of decentralization and blockchain technology. Artificial intelligence, otherwise known as AI, has the power to transform society. Put them together, and the world as it's currently known will be technologically revolutionized.

The post Building AI Products in the Enterprise: What Actually Works in 2025 appeared first on David Ohnstad.

]]> “`html

Building AI Products in the Enterprise: What Actually Works in 2025

By David Ohnstad

Published in 2025

I’ve spent the last six years building AI products inside large enterprise software companies. I’ve watched hundreds of millions in budget allocated to AI initiatives. I’ve seen brilliant machine learning teams build technically perfect solutions that nobody used. I’ve watched pilots fail, products get shelved, and executives lose confidence in AI altogether. But I’ve also seen what works. This is what I’ve learned.

The Enterprise AI Graveyard: Why Most Pilots Fail

Let’s start with the uncomfortable truth: most enterprise AI pilots fail. Not technically fail. They produce models with acceptable accuracy. They generate reports. They run without crashing. But they fail at the thing that actually matters—getting used by real people solving real problems.

I watched one team spend fourteen months building a predictive model for customer churn. The model was genuinely good—88% accuracy on a holdout test set. When they rolled it out, the customer success team glanced at it once and went back to their spreadsheets. Why? Because the model couldn’t tell them what to do about it. It was a prediction, floating in space, disconnected from their actual workflow.

The root problem is almost always the same: wrong success metrics.

Most enterprise AI pilots are measured on technical metrics. Model accuracy. AUC scores. Training time. Inference latency. These matter, but they’re not why you built the product. You built it to change business outcomes. A churn prediction model that’s 88% accurate but saves zero customers is a failure, regardless of what your confusion matrix says.

Here’s what actually gets measured in successful enterprise AI projects:

  • Adoption rate. What percentage of eligible users actually use the feature weekly? If it’s under 20%, something is wrong. If it’s under 5%, you failed.
  • Time saved per user per week. Measure this in minutes. Be precise. A feature that saves three minutes per user per week on a team of 500 is worth $150K annually in labor costs. This number is your north star.
  • Business outcome change. Did churn go down? Did deal close rates go up? Did support tickets decrease? These are the only metrics that matter to your CFO.
  • User satisfaction with the specific feature. Not NPS. Not general satisfaction. “Does this AI recommendation actually help you make better decisions?” If more than 30% say no, go back to the drawing board.

I’ve never seen a successful enterprise AI product that didn’t obsess over adoption metrics from day one. Not day 100. Day one.

This is where most AI teams go wrong. They optimize for launch, not for usage. They build the minimum viable model instead of the minimum viable product. The distinction matters.

When your success metric is model accuracy, you optimize for that. You add more features to your training data. You tune hyperparameters. You ensemble five models together. You get your accuracy to 92%. Meanwhile, your feature is confusing, slow, buried in a UI that nobody sees, and requires users to change their workflow to accommodate it.

When your success metric is adoption, everything changes. You design for speed. You put the feature where users already are. You make it a confirmation tool, not a replacement for human judgment (more on this later). You make it impossible to ignore. You measure weekly adoption, not monthly. You identify non-users and ask them why.

The best enterprise AI products I’ve seen start not with data science, but with a user problem so painful that an 70% accurate AI recommendation is better than the current alternative (usually a blank screen or a spreadsheet).

The Organizational Changes Nobody Wants to Talk About

Here’s the uncomfortable organizational truth: building AI products in enterprises requires structural changes that most organizations resist.

Most large software companies still organize around engineering disciplines. Product teams. Data teams. ML teams. Analytics teams. These teams have separate reporting lines, separate goals, and separate budget. This structure is poison for AI product development.

I worked at one company with 40 data scientists and zero shipping AI products. Why? Because the data science team reported to the VP of Analytics, not to product leadership. Their job was to answer questions and run analyses. When they built an ML model, they owned it, but product didn’t prioritize it, and engineering didn’t want to support it in production. The model was technically impressive. Nobody used it.

Here’s what actually works:

1. Embed Data Scientists in Product Teams

Your data scientist should be part of the product team, reporting through product leadership. Not matrixed. Not “shared.” Embedded. One person, full-time, working on one problem.

This is organizationally inefficient and expensive. You’re not leveraging your data science resource across multiple projects. Good. That inefficiency is a feature, not a bug. In a world where 80% of AI pilots fail, the margin is in focus.

When the data scientist is embedded in the product team, they go to user research sessions. They hear the problems firsthand. They understand why a 10-second inference latency is a dealbreaker but 85% accuracy is fine. They sit next to the engineer building the UI and actually understand what the AI needs to output to be useful.

2. Create a “Product + Data + Engineering” Trinity

Successful enterprise AI projects have three core roles that move together: product manager, data scientist, and engineer. These three people should have a standing weekly meeting that’s sacred. No cancellations. No replacements.

That meeting is where disagreements surface. It’s where the engineer says “that inference latency is impossible,” and the product manager says “the user won’t wait more than 500ms,” and the data scientist says “I need 10 seconds.” Then you negotiate. But you negotiate as a unified team with shared goals, not as siloed functions.

3. Give Someone Authority Over the Full Lifecycle

Someone needs to own the entire AI feature from launch through long-term maintenance. Not the data scientist (who usually moves on to the next problem). Not the product manager (who optimizes for the next release).

This person owns monitoring. Owns model drift. Owns retraining. Owns the user education. Owns the metrics dashboard. In most companies, this role doesn’t exist, and it shows. Models go stale. Users stop trusting them. Features get disabled. Money disappears.

This role should be compensated well. It’s not glamorous, but it’s essential.

4. Accept That AI Features Need Different Support Models

Your customer support team is going to struggle with AI products. A user sees a recommendation and doesn’t understand why. They click it and get a result that seems wrong.

Most enterprises funnel these questions to support, who have no training in machine learning and can’t explain why the model made a particular prediction. This creates churn. Users lose trust.

Successful companies train their support teams specifically on how to explain AI decisions in simple language. They also create paths where the data scientist is available for escalations on genuinely confusing cases. And they instrument their product to collect examples of predictions that users found unhelpful—this is your best signal for model drift or misalignment.

This is expensive. But it’s worth it, because it’s how you maintain user trust when something goes wrong (and something will).

Scoping an AI Feature That Gets Used vs. Shelfware

The difference between a successful AI feature and shelfware often comes down to scope. Not technical scope. Product scope.

I’ve seen this pattern over and over: product teams want the AI to solve the entire problem. A sales team is struggling to prioritize leads. So they want an AI system that ingests company size, industry, fit signals, historical conversion rate, budget indicators, and competitor signals, then produces a single ranked list of leads that the team should focus on.

Technically, this is buildable. But it’s a disaster from a product perspective.

Why? Because there are too many ways it can be wrong, and users won’t have the context to understand why. They’ll see their favorite lead buried in the list and stop trusting the ranking. They’ll ignore it. It becomes shelfware.

Here’s the framework that works:

Start Narrow

Your first AI feature should solve one specific, well-defined problem. Not a general problem. A specific one.

Instead of “rank all leads,” try: “Of the leads we’ve marked as high-priority, which ones are most likely to close in the next 30 days?” Now you have user intent baked in. Users have already done the heavy lifting of determining which leads are worth focusing on. You’re just adding a secondary sort.

Or instead of a predictive model for churn, try: “Of the customers whose usage dropped more than 30% in the last month, which ones are likely to churn in the next 60 days?” Now the model is working with a warm audience. Users already know something is wrong. You’re not asking them to trust your prediction alone; you’re asking them to prioritize within a set of signals they’ve already identified.

Make It Confirmation, Not Replacement

Your AI feature should confirm what users already suspect. Not contradict it.

A sales manager is already pretty good at identifying which leads are worth focusing on. She has instincts built from hundreds of interactions. When your model ranks a lead differently than her instinct, she’s skeptical. She should be. Her instinct is probably right.

But when your model confirms her instinct, and explains why (this lead has similar signals to our highest-value closed deals), she trusts it. And more importantly, she uses it to move fast. “Yes, I thought this was a good lead, and here’s why the model agrees.”

The highest-adoption AI features I’ve seen don’t replace user judgment. They accelerate it.

Measure Adoption Before You Measure Accuracy

Launch your feature in a limited way. Don’t roll it out enterprise-wide. Pick one team. Measure whether they use it weekly. Get weekly adoption to 50%+ before you worry about making the model more accurate.

If adoption is low, improve the product, not the model. Is it too slow? Is it in the wrong place in the UI? Is the explanation confusing? Is it recommending things users already know? Fix these first.

Once adoption is high with a mediocre model, then invest in model improvement. You know the product works. Now you’re polishing.

Build the Feedback Loop First

Before you launch, instrument your product so that users can tell you whether the AI recommendation was helpful. Not NPS. Not satisfaction. Simple binary: “Was this recommendation helpful?” yes/no.

This is your feedback signal for model retraining. If you’re getting 70%+ “yes,” you’re on the right track. If you’re under 50%, your model is misaligned with user needs, and you need to investigate why.

Most enterprises never build this feedback loop, and it shows. Their AI features ship, users ignore them, and they have no idea why.

Plan for Monotony

Here’s something nobody talks about: after launch, your AI feature becomes boring. Users stop thinking about it. They use it if it’s useful, and they ignore it if it’s not.

This is actually a sign of success. If your AI feature is consistently generating questions or surprises, something is wrong. Users shouldn’t be thinking about the AI. They should be thinking about their job.

But this monotony means you need a long-term ownership model. Someone is checking metrics weekly. Someone is monitoring for model drift. Someone is retraining when performance declines. Someone is explaining results to support teams when users are confused. This is boring, critical work.

The Data Infrastructure Problem That Everyone Faces

Every enterprise AI project I’ve worked on has hit the same wall: data infrastructure is worse than you think it is.

I don’t mean this as an exaggeration. I mean it literally. You will discover that your data is worse than you currently believe. Usually around month three of development.

Here are the specific problems you will encounter:

Your Data Is Dirtier Than You Think

Your company’s CRM has been around for ten years. In that time, 200 different people have used it, each with their own data entry practices. Sales reps copy data from one field to another. Marketing automation systems dump data without validation. Support teams use text fields for structured data.

You’ll want to build a model to predict which support tickets will be resolved quickly. You’ll look at historical ticket data. You’ll find that “resolution time” is sometimes the actual time, sometimes the date closed, sometimes notes like “resolved via phone,” and sometimes blank. You can’t use this field directly. You need to clean it first.

Cleaning data is 60-70% of AI project work. Not building models. Not training. Cleaning and validating data.

Budget for this. Seriously. If you’re planning a six-month project, assume three months will be data cleaning. This is not a failure of your data team. This is the reality of 10-year-old enterprise systems.

Your Data Is Fragmented Across Systems

A customer’s journey lives in your CRM, but their support history lives in a different system. Their usage data lives in product analytics. Their billing history is in another system. Their NPS score in yet another.

To build a churn prediction model, you need to join data across all these systems. This is technically possible, but operationally painful. You need API access. You need data agreements. You need to handle systems going down. You need to handle latency.

Most enterprises don’t have good data infrastructure for this. You’ll end up batch-joining data and refreshing it nightly. Fine. But this means your AI inference can’t be real-time. You’re working with data that’s 12-24 hours old. This is fine for some use cases. It’s a dealbreaker for others.

Be honest with yourself about what freshness you need before you start building.

Your Historical Data Has Survivorship Bias

You want to build a model to predict which customers will have a successful implementation. You train on historical data. But your historical data only includes customers who purchased. It doesn’t include prospects who almost purchased but didn’t, because you didn’t track them carefully.

So your model trains on winners. It learns to predict characteristics of customers who already bought. But it can’t learn what makes someone not

The post Building AI Products in the Enterprise: What Actually Works in 2025 appeared first on David Ohnstad.

]]> https://davidohnstad.net/ai-and-web3-products/feed/ 0 Google’s Generative AI Search Revolution: What Enterprise Software Companies Must Do Now https://davidohnstad.net/googles-new-generative-ai-search/ https://davidohnstad.net/googles-new-generative-ai-search/#respond Wed, 20 May 2026 21:21:18 +0000 https://davidohnstad.net/googles-new-generative-ai-search/ Artificial Intelligence has certainly gained attention in recent years and shows no sign of attracting any less as multiple applications and uses for the digital marvel increase! The question is, how well does AI do in information retrieval? According to

The post Google’s Generative AI Search Revolution: What Enterprise Software Companies Must Do Now appeared first on David Ohnstad.

]]> “`html

Google’s Generative AI Search Revolution: What Enterprise Software Companies Must Do Now

By David Ohnstad, AI Product Manager at Veeam

The search landscape is transforming beneath our feet. Google’s AI Overviews—the company’s aggressive push toward generative AI-powered search results—represents the most significant disruption to enterprise software marketing since the rise of content marketing itself. For those of us building products and marketing enterprise software, this isn’t a minor update we can wait out. It’s a fundamental shift that demands immediate strategic response.

I’ve spent the last two years at Veeam watching how our product appears in search results, tracking how customers find us, and analyzing where our content performs. What I’m seeing in the early days of AI Overviews is both challenging and clarifying. The challenge is real: informational content that once drove qualified traffic is being cannibalized by AI-generated summaries. But the clarity is equally important: we now understand exactly what kinds of content, products, and companies will thrive in this new environment.

Let me walk you through what’s happening, why it matters for enterprise software, and most importantly, what you need to do about it right now.

The Cannibalization Problem Is Real and Immediate

Let’s start with the uncomfortable truth: Google’s AI Overviews are eating informational content clicks for breakfast.

When a user searches for something like “what is backup and disaster recovery” or “how to implement a disaster recovery plan,” they previously had to click through to an article to get that information. Maybe they’d click on our Veeam article, maybe they’d click on a competitor’s, maybe they’d click on an analyst report. But the click happened, and traffic flowed.

Now? Google serves up an AI-generated overview that synthesizes answers from multiple sources without the user needing to click anywhere. The AI Overview pulls together definitions, best practices, implementation steps, and considerations—all right there on the search results page. A user gets the information they need without ever visiting a single website.

Our analytics have borne this out. In the six months since AI Overviews rolled out more broadly, we’ve seen a noticeable decline in traffic to our foundational “what is” and “how to” content. The decline isn’t catastrophic—we’re not talking about 80% drops—but we’re consistently seeing 15-25% reductions in clicks on pages that target informational search intent.

What makes this particularly insidious is that the traffic that remains is often lower quality. The users who still click through tend to be either confused by the AI overview or looking for something more specific. This means we’re not just losing volume; we’re often losing the easier conversion opportunities and retaining the more difficult ones.

For enterprise software companies, this matters enormously. We’ve built our content strategies on the assumption that ranking for high-volume informational keywords would funnel users into awareness-to-consideration journeys. That funnel is broken now. We’re being bypassed by algorithmic middlemen.

What This Means for Enterprise Software SEO

The implications for SEO strategy in the enterprise software space are profound, but not universally negative. The key is understanding which searches are still worth targeting and how to position ourselves within them.

Informational Keywords Are Becoming Less Valuable

The traditional SEO funnel looked something like this: rank for broad informational keywords → capture awareness-stage traffic → nurture toward consideration → convert. This was the engine of content marketing for years.

That engine is sputtering. Informational keywords—the “what is,” “how do I,” “best practices for”—are increasingly being answered by AI Overviews. If your entire SEO strategy was built around ranking for these terms and converting that traffic, you’re going to feel the pain.

But here’s what’s important: this doesn’t mean informational content is worthless. It means that the ROI calculation has changed. You’re no longer optimizing for a broad funnel; you’re optimizing for precision and differentiation.

Navigational and Comparison Intent Remain Powerful

Meanwhile, some keyword categories remain largely untouched by AI Overviews, and these are disproportionately valuable for enterprise software.

Navigational searches—”Veeam backup software,” “Veeam vs Cohesity,” “Veeam pricing”—still drive clicks. When someone searches for a specific product or comparison, they’re past the awareness stage. They want to evaluate solutions. Google knows this, and AI Overviews largely don’t answer these queries with synthesized responses. They return direct links to product pages and comparison content.

Similarly, problem-specific searches that map closely to product capabilities remain valuable. A search like “how to backup VMware vSphere environment” might generate an AI Overview, but that overview will likely mention the need for specific solutions, and clicks to detailed technical guides remain high.

The lesson: shift your SEO emphasis toward keywords that map to consideration and decision stages. Invest in comparison content. Optimize for product-specific and problem-specific searches. These are the searches where enterprise buyers are actively evaluating solutions, and AI Overviews have less authority than the vendor’s own guidance.

Brand and Authority Matter More Than Ever

Here’s something subtle but crucial: when Google generates an AI Overview, it needs to cite sources. And increasingly, enterprise buyers notice which sources get cited. If your content appears in an AI Overview, you’re getting a form of attribution—your brand name appears next to that information.

This creates a new SEO dynamic: building authority and brand recognition so that your content is the source Google (and other AI systems) cite. You’re no longer just ranking for clicks; you’re positioning to be quoted by AI.

For Veeam, this means our technical documentation, analyst reports, and thought leadership need to be so authoritative and clear that AI systems reach for them when synthesizing answers. It’s a different kind of SEO, but it’s still SEO—still about visibility and influence.

Which Content Formats Actually Survive AI Search

Not all content is created equal in the age of AI Overviews. Some formats are increasingly invisible; others are actually getting more valuable. Understanding which is which is critical for restructuring your content strategy.

Formats Under Attack

Listicles and “Top X” content: These are being absolutely decimated. “Top 10 backup best practices,” “7 ways to improve disaster recovery,” “5 cloud migration strategies”—these are exactly the kind of content AI Overviews synthesize and present directly. You’re no longer getting the click.

Definition and explanation content: “What is ransomware?” “How does encryption work?” “Explain cloud storage”—these are being pulled into AI Overviews at scale. The traffic dries up quickly.

General best practices guides: Broad guides on “disaster recovery best practices” or “backup strategies” are being summarized by AI. If you’re not saying anything controversial or uniquely detailed, you’re being replaced by a synthesis.

Formats That Still Convert

Case studies and customer stories: This is where things get interesting. AI Overviews don’t synthesize customer success stories. They’re too specific, too particular to individual companies and situations. A case study showing how a 500-person company implemented disaster recovery with specific tools and faced specific challenges—that’s not something an AI Overview can credibly summarize. Users still click to read the full story because they want those specific details.

For enterprise software companies, this is massive. Case studies, which have always been valuable for consideration-stage buyers, are becoming relatively more valuable. They’re also increasingly resistant to commoditization by AI.

Detailed technical implementation guides: There’s a difference between “how to implement disaster recovery” (getting summarized) and “how to implement disaster recovery on vSphere 8.0 with 10,000+ VMs across three geographic regions with specific RTO/RPO requirements” (not getting summarized). Specificity survives AI Overviews.

The more technical, detailed, and specific your content, the less likely it is to be fully synthesized and presented without a click. A buyer looking to solve a specific technical problem still needs to visit the detailed guide.

Comparison content and product evaluations: “Veeam vs Cohesity” or “How Veeam compares to native hypervisor backup tools”—this content doesn’t get summarized by AI Overviews. Comparison is inherently subjective and would expose Google to bias complaints if they synthesized comparative evaluations. Clicks remain high.

Thought leadership and perspective pieces: Opinion-driven content, predictions, analysis of industry trends, arguments about the future of technology—these pieces are surfaced by AI Overviews but not summarized by them. Users click to read the author’s perspective directly. “Why disaster recovery is the most important IT function” or “The future of backup in the AI era” performs well because there’s no substitute for reading the actual argument.

Interactive tools and resources: ROI calculators, configuration wizards, comparison matrices, downloadable templates—these aren’t being replaced by AI Overviews because they require interaction. Clicks to these resources remain strong.

Video content and technical demonstrations: Google’s AI Overviews don’t surface video content in the same way. Video search results are still separated and remain click-heavy. For enterprise software, video demonstrations of product functionality, architecture walkthroughs, and technical training remain largely protected from AI cannibalization.

How to Restructure Your Enterprise Content Strategy

Understanding which content formats survive is one thing. Restructuring your entire strategy around these insights is another. Let me walk through what this looks like in practice.

Step 1: Audit Your Existing Content Against the New Reality

Start by categorizing your existing content library by:

  • Content type: Is it a listicle, definition, how-to guide, case study, technical implementation guide, comparison, or thought leadership piece?
  • Search intent: Is it targeting informational, navigational, or commercial search intent?
  • Traffic impact from AI: Using your analytics, measure how much traffic each piece has lost since AI Overviews rolled out in your region. You’ll quickly see which pieces are being cannibalized.

This audit will show you which content is underwater. Some of it you’ll want to keep and repurpose. Some of it you’ll want to retire. Some of it you’ll want to completely restructure.

Step 2: Shift Your Content Creation Toward Resilient Formats

Going forward, bias your new content creation heavily toward formats that survive AI:

  • Case studies: If you’re currently creating three blog posts per month, consider shifting to two blog posts and one case study per month. Case studies drive fewer clicks than they used to, but they drive higher-quality clicks and can’t be synthesized by AI.
  • Thought leadership: Encourage your product leaders, engineers, and executives to write opinion pieces about the direction of your industry. These pieces get discovered through AI Overviews but drive clicks to read the full perspective.
  • Technical depth: When you write how-to content, go deeper. Instead of “how to implement disaster recovery,” write “how to implement disaster recovery with RPO targets under 15 minutes for a 500-person company with hybrid cloud workloads.” Specificity is your protection.
  • Interactive resources: Invest in tools that buyers interact with. ROI calculators specific to enterprise software use cases, configuration builders, comparison matrices—these are immune to AI cannibalization.
  • Video and demonstrations: Allocate budget to creating product walkthrough videos, architecture explanation videos, and technical deep-dive recordings. These are surfaced by search differently and perform well.

Step 3: Deemphasize Broad Informational Content (But Don’t Eliminate It)

I want to be clear: you shouldn’t eliminate broad informational content entirely. But you should dramatically reduce how much you invest in it relative to other categories, and you should think about it differently.

Broad informational content now serves primarily as a brand-building and trust-building function rather than a traffic-driving function. When someone searches for “what is disaster recovery,” you probably don’t need to rank #1. But you might want a strong result on page one that establishes your company as a knowledgeable voice. That result then serves as a citation source for AI Overviews and contributes to your overall authority.

The ROI model for this content is different. You’re not measuring success by clicks; you’re measuring it by brand lift, citation frequency, and how often your content gets pulled into AI Overviews with attribution to your company.

Step 4: Restructure Your Content Hub Architecture

Many enterprise software companies have built hub-and-spoke content architectures: a broad foundational article (the hub) that links to more specific pieces (the spokes). This made sense when every piece of content was competing for direct clicks.

In an AI Overviews world, this architecture needs updating. Consider restructuring around:

  • Specific problem-solution pairs: Instead of “disaster recovery best practices” (the hub), create “how to implement disaster recovery for specific use case X” (multiple specific pieces). These are more resilient to AI Overviews.
  • Buyer journey stages: Map your content explicitly to where buyers are in their journey. Awareness content can be lighter-weight (knowing it’ll be in AI Overviews anyway). Consideration and decision content should be high-depth.
  • Comparison clusters: Create comprehensive comparison content between your product and specific alternatives. These pieces drive consideration-stage traffic and are resistant to AI cannibalization.
  • Interactive decision trees: Guide buyers through questions that help them determine if your solution is right for their situation. These get traffic that otherwise would have gone to generic how-to content.

Step 5: Invest in Distribution Channels Beyond Organic Search

Here’s the truth: you’ve been over-dependent on organic search. Most enterprise software companies have. AI Overviews makes that dependency dangerous.

Shift some of your content investment toward:

  • Owned channels: Email newsletters, product in-app education, community forums. These channels can’t be cannibalized by AI.
  • Paid search: As organic traffic to informational content decreases, paid search becomes more attractive. Your ads still appear alongside AI Overviews.
  • Partnerships: Co-marketing with complementary products, analyst relations, industry publication placement. These drive qualified traffic without depending on organic search.
  • Community and thought leadership: Speaking engagements, podcast appearances, conference presentations. These build authority and generate traffic that AI can’t intercept.

What Product Managers Need to Know About AI Search Results

If you’re a product manager at an enterprise software company, AI Overviews should be on your radar not just as a marketing concern, but as a product strategy concern. Here’s what you need to understand.

Your Product’s Discoverability Is Changing

For years, customers discovered enterprise software products through a journey that often started with search. They’d search for solutions to a problem, find content about solutions in that space, and eventually discover your product.

That journey is now mediated by AI. When Google’s AI Overview discusses disaster recovery solutions, it’s likely to mention major vendors by name. If Veeam isn’t being cited in those overviews, we’re losing a layer of visibility. If we are cited, we’re gaining a form of endorsement.

This means your product’s searchability and how it’s discussed online has product implications. If your product is too niche or poorly documented, it might not show up in AI Overviews at all. If it’s well-documented and frequently cited, it’s getting algorithmic endorsement.

Documentation and Support Content Are Your Search Presence Now

Here’s something important: when Google synthesizes information for AI Overviews, it’s reaching for authoritative sources. For enterprise software, those sources are increasingly your documentation, your blog, and your support knowledge base.

The post Google’s Generative AI Search Revolution: What Enterprise Software Companies Must Do Now appeared first on David Ohnstad.

]]> https://davidohnstad.net/googles-new-generative-ai-search/feed/ 0