For the last few years, one question has come up in almost every conversation about AI product strategy: where can we add AI?

It was a reasonable place to start. Companies already had mature products, established workflows, customers with existing habits, and roadmaps that were planned months or years ahead. When generative AI suddenly became capable enough to be useful, the fastest way to experiment was to add it to things that already existed.

We saw AI summarizing documents, drafting emails, generating content, answering questions, helping developers write code, and appearing as assistants inside almost every type of software. Some of those experiences created real value. Others felt more like a company needed an AI story, so an assistant appeared somewhere in the product.

I don’t think that is where the most interesting AI product work is heading.

The question I find myself asking now is different: if we were designing this workflow from scratch today, knowing what AI can understand and do, would we design it the same way?

That question moves the conversation away from adding AI features and toward reconsidering the work itself. For product leaders, I think that is a much more meaningful shift.

We started by making existing work faster

Most of the first generation of AI features didn’t fundamentally change what users were doing. They simply helped people do part of the job faster.

If I am writing an email, AI can help me draft it. If I have a long document, AI can summarize it. If I am searching through documentation, AI can often answer the question directly. If I am writing code, AI can suggest an implementation.

There is nothing wrong with any of this. Saving ten minutes on a task someone performs several times a day can create substantial value.

But look at what still happens around the AI.

The user recognizes that there is a problem, decides what information is needed, asks AI for help, evaluates the answer, moves somewhere else in the product, takes an action, and then checks whether the action worked.

AI may have made one step much easier, but the user is still coordinating the entire process.

This is where agents and more capable AI systems start to make product design interesting. Once AI can access context, interact with tools, and take actions within defined boundaries, it can potentially participate in much more of the workflow.

Imagine an administrator troubleshooting a configuration issue. Today, they might read an error message, search documentation, inspect several configuration screens, look through logs, compare settings, identify the likely problem, make a change, and then test whether it fixed the issue.

Putting AI beside that workflow could give the administrator a better explanation of the error.

That would be useful.

But a more capable product could go further. It could inspect the relevant configuration, correlate it with logs, identify the likely cause, explain what it found, recommend a fix, prepare the change, and ask the administrator to review it before anything is modified.

The customer still has the same problem. The difference is how much work the product takes responsibility for.

To me, that is the important shift in AI product strategy.

Start with the customer’s work, not the AI technology

One mistake I see with emerging technology is that we naturally begin with the technology itself.

Should this be an agent? Which model should we use? Do we need retrieval? Should we expose tools through MCP? Would a copilot make sense here?

Those can all become important questions, but they are usually not the first questions I would ask.

I would start by understanding what the customer is actually trying to accomplish. What information do they have to collect? Where do they switch between systems? What decisions require expertise? Which steps are repetitive? Where do mistakes happen? What part of the workflow consumes the most time without creating much value?

Once you understand the work, you can decide where AI belongs.

This distinction matters because not every difficult workflow needs an AI agent. Sometimes a better search experience solves the problem. Sometimes the answer is a simpler user interface. Sometimes traditional automation is more reliable. And sometimes AI is useful only for the ambiguous part of the workflow, while deterministic software should handle everything that follows.

Starting with “we need an agent” encourages teams to find a problem for the technology. Starting with the workflow gives you a chance to choose the right technology for the problem.

Good product management has always worked this way. AI doesn’t change that.

The useful question is not how autonomous the AI can become

There is a tendency to describe AI products as a progression toward greater autonomy. First the AI answers questions, then it recommends actions, then it performs tasks with approval, and eventually it operates independently.

That progression is useful for thinking about capabilities, but I don’t think greater autonomy automatically means a better product.

The right amount of autonomy depends on the task and the cost of being wrong.

If an AI system reformats a presentation badly, the consequence is minor. I can undo it and move on. If the same system changes a production security policy, removes someone’s access, sends money, modifies infrastructure, or deletes customer data, the expectations should be completely different.

So I would frame the product decision around delegation rather than autonomy.

There are situations where the product should simply explain something. In others, it should recommend an action. Sometimes it should prepare the work and let a person review it. For low-risk and highly predictable activities, it may make sense to let the system act automatically.

The goal isn’t to remove the human from as much of the workflow as possible. The goal is to decide where human judgment adds value and where requiring human involvement simply creates unnecessary work.

That is a much more nuanced product decision.

Human oversight has to be designed, not added

“Human in the loop” has become one of those phrases that sounds reassuring until you look closely at what it means in the actual product.

Imagine an AI agent that has collected information from several systems, interpreted what it found, made a series of decisions, and prepared five changes. At the end of the process, the interface presents a button that says, “Approve changes.”

There is technically a human in the loop. But does that person actually understand what they are approving?

Meaningful oversight requires more than an approval button.

The user may need to understand what the system is planning to do, why it reached that conclusion, which information influenced the decision, what will change, who or what will be affected, and whether the action can be reversed. If the agent plans to perform several actions, the user should be able to see them clearly and change the plan where necessary.

This is one of the areas where I think AI becomes a fascinating product and UX problem.

As software begins doing more on behalf of users, interfaces have to become better at communicating intent, activity, evidence, consequences, and uncertainty.

The interface is no longer only a place where the user tells the software what to do. It also becomes the place where the software tells the user what it is doing.

AI isn’t going to make the interface irrelevant

There is a popular idea that agents will eventually eliminate much of the traditional user interface because people will simply tell software what they want.

I think that will be true for some interactions, but I am skeptical that it means interfaces become less important, particularly in enterprise software.

Consider what happens when an AI system can act across a complex environment. Users suddenly need answers to a different set of questions.

What is the system doing right now? What has it already changed? What information did it use? Which actions are waiting for my approval? Did something fail? What changed yesterday? Can I undo an action? Is the system operating within the policies my organization defined?

Those questions require an interface.

Traditional enterprise software is often designed around navigation and configuration. We give users menus, forms, tables, switches, and settings because the user needs to explicitly tell the system what to do.

If AI begins handling more of that execution, some of those controls may become less important. But I expect interfaces for monitoring, supervising, reviewing, and correcting AI activity to become more important.

The UX isn’t disappearing. Its role is changing.

For product teams, I think this is going to become a significant design area over the next few years.

AI also changes what we mean when we say a product “works”

There is another difference between traditional software and AI products that product managers need to become comfortable with.

Traditional software is mostly deterministic. Given the same inputs and system state, we generally expect the same result. We write acceptance criteria, test expected behavior, handle known edge cases, and decide whether the feature is ready.

AI systems behave differently.

An agent might choose different approaches to the same problem. It might perform well on hundreds of examples and misunderstand the next one. Changing a model or a prompt might improve one class of behavior and unexpectedly degrade another.

This makes evaluation a much more important part of product development.

I don’t think product managers need to become machine learning engineers, but I do think PMs working on AI products need to understand evals.

The important questions are surprisingly familiar. Can the system complete the task the customer asked it to perform? Does it use the right information? Does it choose appropriate tools? Does it stay within the user’s permissions? Does it recognize situations where it should stop and ask for help? What types of mistakes are acceptable, and which ones are not?

Those aren’t merely model-quality questions. They are product requirements.

An evaluation set is ultimately a way of describing examples of good and bad product behavior. Product teams should have a strong role in deciding what those examples are.

If an AI product is supposed to solve a customer’s problem, model accuracy alone is not enough. The product needs to succeed at the customer’s task.

The best AI use cases may not look very impressive in a demo

One thing I would be careful about when creating an AI roadmap is prioritizing use cases because they look impressive.

Some of the most valuable applications of AI inside enterprise products may actually seem quite boring.

Imagine a system that reviews failed configurations overnight, gathers the relevant context from several services, groups similar issues together, identifies likely root causes, and prepares recommendations for the support team in the morning.

Or a system that looks at an incoming customer request, gathers account and product context automatically, and sends unusual cases to the right specialist.

Or an AI capability that reviews a configuration against company policy before it is deployed and explains exactly what needs attention.

None of these creates the same demo moment as asking a general-purpose AI assistant a clever question.

But they solve work that someone has to do repeatedly.

That is where I think product discovery around AI gets interesting.

I wouldn’t simply ask customers, “What do you want AI to do for you?” Most people shouldn’t need to understand the capabilities of the latest models to describe their problems.

I would ask how they work today.

What takes too long? What do they have to investigate manually? Where are they copying information from one place to another? Which tasks require an expert even though the underlying work is repetitive? What do they avoid doing because it takes too much effort?

One question I particularly like is: where does someone spend twenty minutes figuring out what happened before spending two minutes actually fixing it?

Those are often excellent candidates for AI-assisted workflows.

Understanding the workflow may become more valuable than having the best model

Models are improving quickly, and the capabilities that once differentiated one AI product from another are spreading rapidly.

That makes me skeptical that “we have AI” will remain meaningful product differentiation.

Many companies will have access to capable models. They will have access to similar infrastructure, developer tools, retrieval techniques, and agent frameworks.

What is harder to copy is deep knowledge of the customer’s work.

Which information matters in a particular situation? Which systems need to be consulted? Which actions are safe? What permissions should apply? What does a good outcome look like? What unusual situations only become obvious after serving customers in a market for years?

That knowledge matters much more when AI begins participating in workflows instead of merely generating text.

An agent that understands language but doesn’t understand the business process isn’t particularly useful.

This is why I think established products can have an interesting advantage in AI, provided they actually use the knowledge they have accumulated about their customers.

The opportunity isn’t just to connect a model to the product. It is to combine AI capability with an understanding of the workflow that the model alone does not have.

Sometimes software should still just be software

There is another point that is easy to lose in the excitement around agents.

Not everything needs AI.

If a task is predictable, well defined, and easily represented with deterministic logic, normal software may be faster, cheaper, easier to explain, and far easier to test.

In many cases, the best architecture will probably be a combination of the two.

AI can handle ambiguity. Traditional software can handle precision.

For example, AI may interpret a loosely worded customer request, determine the customer’s intent, and identify the action that needs to happen. Once that intent has been translated into a known operation, deterministic software may be the better way to execute it.

I expect a lot of good AI products to work this way.

The agent doesn’t need to control everything. It needs to be useful in the parts of the workflow where intelligence, interpretation, and flexible reasoning genuinely improve the experience.

That leads to a much healthier product question than “How much of our application can we make agentic?”

I would ask: where does AI make this experience meaningfully better, and where are we better off keeping things simple?

How I would think about an AI product roadmap

If I were reviewing an AI roadmap today, I would look at the portfolio in a few different ways.

Some initiatives will improve individual tasks. Better search, summarization, content generation, recommendations, and conversational assistance can all provide immediate value. These are often relatively easy ways to introduce AI into an established product.

But I would also look for deeper opportunities.

Where can the product remove work rather than simply accelerate one step? Can it gather information the customer currently has to collect manually? Can it identify problems before the user goes looking for them? Can it prepare a solution rather than simply explain the problem? Can routine cases happen automatically while people spend their time on exceptions?

Most importantly, I would look at whether AI allows us to simplify the workflow itself.

If we add an AI assistant but leave every existing screen, field, decision, and navigation step exactly where it was, we may be underusing the technology.

Sometimes the better AI feature is removing a step the customer no longer needs to perform.

AI doesn’t change the reason customers buy products

There will continue to be new models, larger context windows, better reasoning, new agent frameworks, and new ways for AI systems to interact with tools. Product leaders need to understand these capabilities because they expand what we can build.

But I don’t think chasing the technology itself is a durable product strategy.

Customers generally don’t wake up wanting an AI agent. They don’t wake up wanting RAG, MCP, a copilot, or a larger language model.

They have something they need to accomplish.

They want it to take less time. They want fewer mistakes. They want the product to understand enough context that they don’t have to explain everything repeatedly. They want routine work to disappear, and they want control when a decision actually matters.

That is why I think the move from AI features to AI workflows is important.

The first stage of generative AI asked us to look at our existing products and find places where AI could help.

The next stage should make us more ambitious.

Instead of asking “Where can we put AI?”, I think product teams should ask:

“What work should the product be doing for the customer now that it is capable of doing more?”

The answer to that question is much more likely to lead to a useful product than another AI button.