dooopSoftware · Strategy · 13 min

How to Connect AI to the Customer's Problem

AI strategy in software should start from the customer's outcome, not the technology, to define hypotheses, metrics, and boundaries.

Published on September 6, 2026

MAIN THESIS

Useful AI originates from a customer outcome, not a technical showcase.

Technology comes into play only after the task, risk, metric, and responsibility are clear.

In an AI strategy for software, models, agents, copilots, or architecture only enter the conversation effectively after leadership chooses which customer outcome they intend to change. The customer does not buy the technology itself. They buy an observable change in their work: a less delayed decision, an avoided loss, an action with higher quality, less operational effort, or more confidence in a critical process.

When the AI Conversation Starts with the Wrong Technology

This scene is common. The team meets to discuss artificial intelligence in software and within minutes the conversation is already about models, agents, vector databases, copilots, automations, and integrations. There is enough technical knowledge to propose paths. But the question that should organize the decision has not yet appeared: which customer work will improve if this works?

When this order is reversed, the company tends to produce impressive demos but weak product decisions. The demo impresses because it answers, summarizes, classifies, or executes something. The product decision remains fragile because it is unclear whether it reduces a relevant friction for the customer, fits into the real workflow, whether the error is acceptable, or if someone will trust the recommendation when it matters.

Technology becomes the starting point. The customer's problem becomes a subsequent justification.

This risk increases when the strategic discussion mixes three different things: technical capability, perceived value, and operational outcome. An intelligent feature can be technically feasible, visually convincing, and still have little relevance to the customer's decision. The opposite also happens: a simple intervention, with limited AI and human review, can have more value if it acts at the right point in the flow.

The DORA 2025 report describes AI as an amplifier of existing organizational strengths and weaknesses and highlights the importance of the organizational system for return on investment. In dooop's reading, this shifts the question from "which tool will we adopt?" to "which organizational capability will be amplified?" In product, this capability needs to find a concrete customer task.

If you are designing an AI strategy for software, it is worth separating this decision from broader discussions about business transformation. A guide like How to Create an AI Strategy Connected to Business helps address corporate direction. Here, the unit of analysis is more specific: the customer outcome within a product, service, or software flow.

The Customer Outcome Is More Specific Than the Declared Problem

"I want to use AI in customer service" is not yet a product problem. It is a vague intention, perhaps a commercial demand, perhaps a reaction to competition. To become an AI product strategy, this phrase needs to be translated into an observable outcome.

There is a difference between complaint, demand, and outcome.

The complaint is the discomfort expressed by the customer: "service takes too long," "triage is poor," "no one finds information," "the team wastes time on repeated cases." The demand is how the customer imagines the solution: "add a chatbot," "make an agent," "create an intelligent dashboard." The outcome is the change that needs to happen in the work: reduce rework in triage, anticipate cancellation risk, increase consistency in repetitive responses, prioritize exceptions before they cause delays.

This distinction seems simple but changes the strategy design. If the desired outcome is consistency, AI might suggest responses based on internal policies and require human review. If the outcome is triage speed, AI might classify requests and route cases. If the outcome is trust, the solution might need to explain the origin of the recommendation and record the decision, rather than just respond faster.

The customer's problem is not a nice phrase in a presentation. It is a verifiable change in the workflow.

A good question to test the maturity of the opportunity is: if the AI feature is removed from the description, do we still know which outcome needs improvement? If the answer is no, the strategy is still too dependent on technology.

How to Turn an AI Opportunity into a Value Hypothesis

After choosing a customer outcome, the opportunity can be written as a value hypothesis. Hypothesis here is not a promise. It is a clear formulation of what you believe can change, in whom, in which task, under what limits, and with what minimum evidence to proceed.

A useful value hypothesis usually answers six points:

Who is the user affected by the problem?
Which decision or task will be altered?
What friction exists today?
What outcome does the customer need to perceive?
What error is acceptable and what error requires blocking, review, or fallback?
What minimum evidence will indicate it is worth continuing?

This formulation prevents AI from becoming a generic layer of the product. Instead of "let's add AI to the customer service module," the hypothesis would be closer to: "for the support team, we want to reduce rework in triage of repeated requests by suggesting category, priority, and initial response, with human review before sending."

Note that technology has not yet been chosen. This is deliberate. The hypothesis describes the intervention on the customer's task. Later comes the decision between semantic search, classification, summarization, recommendation, flow automation, third-party model, own model, or a combination of these possibilities.

This logic also protects the company from confusing initial enthusiasm with value perceived by the customer. Usage, curiosity, and demonstration are useful signals but not enough. A feature can be heavily tested because it is new and little adopted when it enters the real process. Therefore, minimum evidence must be linked to the intended outcome: less rework, better triage quality, lower exception volume, more reliable decision, less operational effort.

The page about AI Roadmap deepens the passage from inventory to plan. Before that, however, each opportunity needs a sufficiently clear value hypothesis to deserve inclusion in the roadmap.

Criteria to Choose Technology After the Outcome

The same technology can be suitable for one problem and unsuitable for another. Therefore, the technology decision should come after defining the customer outcome.

Some criteria help order the choice:

Nature of the task: does the customer need to search, classify, summarize, recommend, predict, explain, or trigger something?
Available data: is there sufficient, accessible, and quality data compatible with the task?
Need for explanation: does the user need to understand why the suggestion was made?
Error tolerance: does an error cause only discomfort, rework, operational loss, or relevant risk?
Frequency of use: does the intervention appear in a recurring flow or rare cases?
Operating cost: does the solution require processing, monitoring, curation, or support at a scale compatible with the expected value?
Human responsibility: who approves, corrects, interrupts, or is accountable for the decision?

These criteria avoid two common simplifications. The first is treating "agent" as a universal answer. Agent, in this context, is a system capable of executing steps or triggering tools with some degree of autonomy. This can make sense when there is flow, context, permissions, and clear limits. But it can be overkill when the problem is finding information, summarizing history, or classifying a request.

The second simplification is assuming maturity requires own model. Mature products can integrate third-party models when architecture, governance, data, user experience, and operational responsibility are well designed. The decision should not start from technological pride but from the customer's task, risk, and ability to operate the solution.

The discussion about AI Maturity is useful precisely because it reminds that a tool does not replace organizational capability. For product, this capability appears in the quality of hypotheses, measurement, flow design, and clarity of responsibility.

Fictional Example: Before Creating an Agent, Choose the Decision It Improves

Imagine a fictional company that provides software for industrial maintenance management. Leadership decides to explore AI because customers deal with many work orders, scattered histories, and difficulty prioritizing what requires immediate attention.

The team's first formulation is: "let's create a maintenance agent." It sounds interesting but is still vague. Which decision does this agent improve? For whom? At what moment? With what autonomy limits?

Refining the opportunity, leadership chooses a more specific outcome: improve prioritization of critical work orders by maintenance supervisors. The task is not "use AI." The task is to help the supervisor distinguish requests that can wait from those requiring faster action, considering history, equipment type, described symptoms, and previous records.

With this outcome in hand, technological options stop competing by trend and start competing by suitability.

Semantic search can help the supervisor find similar orders and related manuals. Risk classification can suggest priority based on recorded patterns. Assisted summarization can condense equipment occurrence history. A flow with human review can allow AI to suggest priority but require supervisor confirmation before changing the queue.

None of these alternatives is a winner by definition. All are hypotheses. The choice depends on data quality, error tolerance, need for explanation, and impact of inappropriate prioritization. If the historical base is inconsistent, a better interface to record symptoms may come before AI. If wrong priority can generate relevant operational impact, the system should limit autonomy and record human review.

The point is that the chosen outcome changed the conversation. The question stopped being "which agent will we create?" and became "which intervention improves the prioritization decision without transferring undue responsibility to the software?"

This is the kind of change that makes an AI product strategy more concrete.

What to Measure to Avoid Confusing Usage with Value

After the hypothesis goes to experiment, measuring usage is not enough. Usage shows exposure, curiosity, or frequency. Value requires observing whether the customer's decision or task changed in the expected direction.

Three groups of metrics help separate signals:

Adoption metrics: how many people access, activate, or return to the feature.
Operation metrics: response time, execution cost, recorded error rate, need for review, exception volume.
Customer outcome metrics: faster decision, more consistent triage, less rework, greater trust in the flow, reduced operational effort.

The February 2026 update of METR considers new data an unreliable signal about AI's current effect on productivity and points out difficulties such as participant selection, task selection, and time measurement with competing agents. For software leaders, the prudent reading is not to turn automatic productivity expectation into a product argument without own measurement.

Microsoft Research describes its experimentation platform as a way to incorporate experimentation into the development cycle, validate hypotheses, measure impact, and iterate products. Applied to an intelligent feature, we propose a practical criterion: experiments are not for confirming enthusiasm. They are for reducing uncertainty about impact.

This also helps protect the relationship with the customer. If the commercial promise speaks broadly of "intelligence," any demonstration seems sufficient. If the promise speaks of improving a specific decision, the conversation requires compatible evidence. The AI label alone does not demonstrate value perceived by the customer. It arises when the customer recognizes that a task became better, more reliable, or less costly within their process.

When Not to Choose AI Yet

There are situations where the best strategic decision is not to choose AI yet.

This decision avoids bringing technology to a flow that still lacks sufficient data, responsibility, or success criteria.

AI may be premature when data is insufficient, when the process changes weekly, when no one knows who is responsible for the decision, when economic impact is low, or when the risk of automated error is too high for the expected benefit. It may also be unnecessary when a simple rule, interface improvement, process change, or better governance solves the friction with less cost and more predictability.

A simple example: if the customer cannot find information because navigation is confusing, the first step may be to redesign the experience, not create an assistant. If the team records data inconsistently, the priority may be to improve fields, responsibilities, and input quality. If the decision requires sensitive contextual judgment, AI should support with search and summary, not decide.

Ambition becomes more defensible when the first step reduces uncertainty before automating.

Criteria to Connect AI to the Customer Problem Before Technology

Use these criteria before choosing model, tool, agent, or architecture. If the answer is weak on two or more items, the opportunity is not yet ready for a technology decision.

Observable Outcome

Question: what change will the customer perceive in their own work?

Good sign: the answer describes a decision, task, risk, or cost that changes for the customer.

Weak sign: the answer describes only an AI feature.

Affected User

Question: who changes behavior if the solution works?

Good sign: there is a specific role, such as analyst, manager, operator, salesperson, or support team.

Weak sign: the answer is generic, such as "the company" or "users."

Moment of Intervention

Question: at what point in the flow does AI help?

Good sign: the opportunity is located before, during, or after a concrete decision.

Weak sign: AI is placed as a general product layer.

Minimum Evidence

Question: what signal will show it is worth continuing?

Good sign: there is a comparable measure, such as analysis time, rework rate, triage quality, or exception reduction.

Weak sign: the only expected signal is number of accesses or initial curiosity.

Error Tolerance

Question: what happens when AI errs?

Good sign: the flow defines human review, fallback, decision recording, or autonomy limits.

Weak sign: error is treated as a later technical detail.

Technological Suitability

Question: does the chosen technology correspond to the task?

Good sign: the choice derives from the task: search, classify, summarize, recommend, predict, explain, or trigger.

Weak sign: the choice derives from trend, commercial pressure, or team preference.

The concrete decision is this: technology should only be chosen when the customer outcome fits in a phrase pointing to an observable task, decision, risk, or cost. Without this phrase, architecture should wait.

If you want to discuss this decision in the context of your company, talk to dooop.

Sources

NEXT DECISION

Discuss Application in Your Company

Conversation about the software company's context

Content by dooop. Registration allows linking this topic to the reader's journey and tracking interest in the subject.