Why AI Products Might Miss the Mark 

AI has created a new kind of pressure inside product organizations. Teams see a powerful model, a new capability, or a competitor launching an AI feature and immediately begin asking what they can build with it.

That excitement is understandable. AI can summarize information, generate content, classify data, predict outcomes, automate decisions, and support entirely new product experiences.

The problem begins when technology becomes the starting point.

A product team that begins with the model often ends up searching for a customer problem that justifies using it. That can lead to impressive demos that solve weak problems, features that users try once and abandon, or products that perform well technically without creating meaningful business value.

Strong AI products begin with the same discipline that strong products have always required: understanding the customer, identifying a problem worth solving, and defining what a better outcome should look like and then figuring out the right technology.

Start with the task or decision

The first question for an AI product should be simple: What is the user trying to accomplish?

That question forces the team to look beyond the capability of the model and understand the actual workflow. A customer may spend hours reviewing documents because the information they need is scattered across multiple sources. A support agent may repeatedly search for the same policy information. A financial analyst may need to identify anomalies across thousands of transactions. A manager may spend too much time turning operational data into a usable summary.

Each of those situations could potentially benefit from AI, but the value comes from improving the task. Product teams need to understand where users struggle, how often the problem occurs, what the existing workaround looks like, and what happens when the task is performed poorly.

Product teams need to understand where users struggle, how often the problem occurs, what the existing workaround looks like, and what happens when the task is performed poorly.

That human context matters because AI behavior can be unpredictable. A feature that works well in a controlled demonstration may become frustrating when users encounter uncertainty, incomplete information, or an incorrect output during real work.

Microsoft Research’s Guidelines for Human AI Interaction emphasize the importance of designing around how people actually interact with AI systems, including setting clear expectations, supporting correction, and helping users understand what a system can and cannot do.

Product discovery should include questions such as

• What decision or activity are we trying to improve?
• How much time, money, or effort does the current problem consume?
• What level of accuracy does the user actually need?
• What happens when the system is wrong?
• Can the user recognize and correct a bad output?
• Would a simpler technology solve the problem effectively?

That last question is especially important. Some problems need better search, rules, workflow automation, or data quality rather than AI.

Early in my career, I worked on a university technology commercialization program with a small team of Ph.D., MBA, and J.D. students. Our goal was to commercialize a new technology that could detect a wide range of gestures on a wearable device. Our first instinct was to build a product around the technology itself, treating the full gesture set as the offering.

Customer research changed that. Users rarely interacted with their devices beyond checking notifications, and not because the screen was small. Nothing on offer was practical enough to change their behavior. The companies we wanted as partners weren’t looking for more features either. They needed a way to differentiate without adding cost or complexity.

So we scoped down. Instead of pitching the entire gesture vocabulary or building a full stack, we picked a handful of the most useful interactions, like answering or rejecting a call with a single tap, and built our go-to-market plan around those. 

Define success before evaluating the model

AI teams naturally pay attention to technical metrics. Accuracy, precision, recall, response time, and model quality all matter.

Product success requires another layer of measurement. A model can become more accurate without improving the customer experience. A generative feature can produce higher quality responses while users continue completing the task manually. An automation system can process more cases while creating additional review work elsewhere.

Teams should define business and user metrics before development progresses too far. If an AI assistant is intended to reduce research time, measure whether users actually complete the task faster. If the product is designed to improve support operations, look at resolution time, escalation rates, repeat contacts, or agent productivity. If the goal is better decision support, examine whether users reach decisions faster or with greater confidence.

The NIST AI Risk Management Framework reinforces the importance of understanding context and measuring outcomes throughout the AI lifecycle. Its framework includes mapping the context in which an AI system will operate and measuring performance and risk rather than treating technical development as a separate exercise.

This is product discipline as much as it is risk management. Teams need metrics that connect the AI system to the outcome that justified building it.

This is product discipline as much as it is risk management. Teams need metrics that connect the AI system to the outcome that justified building it.

I generally think about success across three levels. First, does the model perform well enough for the specific task? Second, does the user actually adopt the experience and continue using it? Third, does that usage create the intended business result?

Those layers prevent teams from declaring victory because the model benchmark improves while the product itself remains unnecessary.

I worked on an identity and access governance product used by enterprises to manage compliance risks such as SOX segregation of duties violations. We moved detection from static rule sets to a smarter AI-based model, and it worked, catching genuine violations faster with fewer false positives.

But detection accuracy wasn’t the metric enterprises actually cared about. Compliance teams still had to investigate and clear every flagged risk, and a more accurate model just meant more findings to review in the same audit cycle.

The outcome that mattered was how fast a team could resolve a flagged risk with confidence, not how many risks got flagged. So we shifted the focus of the approach with some key features. We added simulation and versioning to the workflow, letting compliance officers test an access change before it caused a violation and clear existing flags faster. Audit efficiency, not detection accuracy, became the real measure of success across the enterprises using it.

Accurate measurement also helps teams decide when to stop. If repeated improvements to model performance do not change user behavior or business results, the team may be optimizing the wrong thing.

One shared outcome

AI products also fail when the teams building them optimize for different goals. Product managers may focus on user adoption and commercial value. Engineers may prioritize reliability, latency, scalability, and integration. Data scientists may focus on model quality and experimentation.

All of those priorities are legitimate. Problems emerge when the teams are working toward separate definitions of success. AI product development requires earlier and more frequent collaboration because product choices are often constrained by technical realities.

A product manager needs to understand what the model can reliably do. A data scientist needs context about how users will interpret an output. Engineering teams need to know how the experience should behave when the model is uncertain, unavailable, or wrong.

Microsoft’s HAX Toolkit was designed specifically to help multidisciplinary teams think through AI product behavior early in the design process, including expected capabilities, failure conditions, and user interaction.

Those conversations should happen before the feature is largely built.

Teams can improve alignment by agreeing on a few things early:

• The customer problem being solved
• The user behavior the product should change
• Acceptable error and failure conditions
• The role of human review
• Technical performance requirements
• Business success metrics
• Conditions that would cause the team to change direction

For instance, I was the product manager on a growth initiative for an enterprise collaboration product. I wanted to simplify the trial signup flow to increase conversions, and the funnel data analysis from data science showed exactly which steps caused the most drop-off. Engineering flagged an issue I hadn’t accounted for: Some of those steps also fed downstream account provisioning, and cutting them could leave certain enterprise accounts incompletely set up.

When engineering flags a downstream risk to a product change, it’s often a sign the metric is incomplete, not that it is wrong.

That led me to rethink the goal. A completed signup wasn’t the real outcome, a working trial account was. Once we collaborated and redefined success that way, it was clear which steps were safe to cut, which needed to stay but could be simplified, and which just needed an engineering fix. The result was a meaningful lift in signups without the setup issues a conversion-only fix would have caused.

When engineering flags a downstream risk to a product change, it’s often a sign the metric is incomplete, not that it is wrong.

AI expands what product teams can build, but possibility alone is a weak product strategy.

The strongest opportunities come from finding problems where AI creates a meaningful improvement in an existing task, decision, or customer experience. Once that problem is clear, teams can evaluate the right technology, establish useful metrics, and design an experience around the way people will actually use it.

Product teams should remain curious about new models and capabilities. They should also be disciplined enough to ask whether those capabilities solve a problem customers care about.

That discipline becomes even more valuable as AI becomes easier to add to almost any product. The competitive advantage will increasingly come from knowing where AI deserves to be used and building around a customer outcome that is worth improving.