dooopSoftware · Strategy · 13 min

How to Use Customer Interviews in AI Strategy

Understand how to conduct AI interviews starting from real tasks, frictions, and evidence before discussing solutions or automation.

Published on September 6, 2026

CENTRAL THESIS

Asking about AI too early contaminates discovery. The best signal appears in the work that got stuck.

Useful interviews start from real episodes. AI comes later, competing with simpler solutions.

Customer interviews about artificial intelligence work better as reconstructions of work episodes. The conversation should raise real tasks, frictions, decisions, exceptions, and consequences before discussing any solution.

If you ask too early whether the customer wants AI, you get a preference for technology. If you ask about the work that gets stuck, you get evidence to decide whether AI, traditional product, integration, or process deserves investigation.

Start with the work scene, not the AI question

The first trap in customer research for AI is arriving with the solution dressed as a question. "Would you use an AI assistant for this?" seems like an open question but already pushes the customer to imagine a technology, an interface, and a value promise that may have no relation to the real problem.

The best starting point is a concrete work scene. Instead of "how do you analyze requests?", ask "tell me about the last time a request took longer than it should to be analyzed." This exchange forces the conversation to leave the ideal process and enter the real episode.

In the first formulation, the customer tends to describe the ideal process. In the second, they reconstruct an episode: who participated, what information was missing, where they looked for data, which system they had to open, what decision was at stake, who waited, and what happened afterward.

This reconstruction protects the interview from two common distortions. The first is the aspirational answer: the customer says they want to modernize, automate, or "use AI" because it sounds right. The second is the polite answer: they agree with the idea presented to avoid disappointing the questioner.

A good AI product discovery interview should take the opposite path. First, observe the work. Then, understand the friction. Only then formulate solution hypotheses.

This order also aligns better with a responsible strategy view. The presentation of the DORA 2025 report describes AI as an amplifier of existing strengths and weaknesses in the organization and highlights the importance of the organizational system for return on investment. The practical implication for a software company is simple: if you do not understand the customer's work system, you may amplify the wrong friction.

This discussion connects to the broader topic of how to create a business-connected artificial intelligence strategy, but here the decision is more specific: how to conduct the conversation without inducing demand for technology.

Separate task, friction, and solution before the interview

Before interviewing, define three different objects of investigation: task, friction, and solution.

Task is what the customer needs to complete. It can be approving a request, classifying an occurrence, preparing a response, prioritizing a ticket, reviewing information, or deciding the next step of an operation.

Friction is the resistance that delays, increases cost, raises risk, reduces quality, or concentrates knowledge in few people. Friction may appear as rework, waiting, manual checking, uncertainty, specialist dependency, excessive message exchange, or difficulty finding reliable information.

Solution is a possible way to solve. It may involve artificial intelligence but can also be a clearer business rule, a system integration, an interface improvement, better documentation, process change, or training.

Mixing these levels is costly. When the interview starts with "we want to create a copilot for your team," the solution occupies the center of the conversation. The customer starts to give opinions about the copilot, not the task. When it starts with "what decision does your team need to make when this case arrives?", the conversation produces strategic material.

A useful phrase to guide the team before interviews is this: AI does not enter the agenda as a likely answer. It enters as a later hypothesis, competing with simpler alternatives.

This stance avoids two opposite errors. The first is treating all friction as an AI opportunity. The second is discarding AI because an interview did not bring explicit enthusiasm for the technology. The customer does not need to ask for AI to reveal a task where interpretation, search, classification, or draft generation deserves investigation.

Use questions that retrieve facts, not technology preferences

Good questions retrieve episodes. Weak questions collect preferences.

Avoid opening with:

"Would you use AI to speed up this analysis?"
"Would a chatbot help your team?"
"How much would you pay for intelligent automation?"
"Do you find it interesting to have a copilot at this stage?"

These questions may have a place later, when there is a prototype, clear alternative, or designed experiment. In initial discovery, they contaminate the conversation.

Prefer questions such as:

"Tell me about the last time this task was delayed."
"What information did you need to check manually?"
"Which systems, documents, or people were involved in the process?"
"What happens when the decision is wrong?"
"Who first notices that there was a problem?"
"What kind of case does the team hesitate most with?"
"When the work goes well, what was different?"

These questions do not prove demand for AI. They help form better hypotheses.

The difference is critical. Interviews are not a plebiscite on technology. They are a way to reduce uncertainty about customer tasks, operational frictions, and consequences. The decision to build, buy, integrate, or abandon a hypothesis comes later.

The update from METR on productivity measurement limits considers new data an unreliable signal of AI's current effect on productivity and points out difficulties such as participant and task selection, as well as challenges in measuring time with competing agents. This caution reinforces a methodological point of this article: do not treat a declared preference in an interview as sufficient evidence of operational gain.

If the interview suggests a task looks promising, the next step is to design a small, measurable comparison, not promise productivity.

Identify opportunity signals for AI without forcing automation

After interviews, some patterns may indicate that an AI hypothesis deserves investigation. They do not require AI adoption but help separate technological curiosity from concrete opportunity.

Favorable signals often appear when the task involves:

interpretation of texts, messages, descriptions, or documents;
classification of cases with partially subjective criteria;
search in dispersed knowledge;
comparison of alternatives with many contextual elements;
generation of drafts that will be reviewed by someone;
detection of exceptions in repeated flows;
support for recurring decisions, with known criteria and possible review.

Even in these cases, automating everything may be the wrong answer. Many better opportunities start as support for human judgment: highlighting excerpts, suggesting priorities, summarizing context, pointing out inconsistencies, or preparing a first version.

There are also contrary signals. As a practical criterion, AI tends to be a weak hypothesis when friction comes from a simple rule not yet implemented, lack of integration between systems, poorly designed fields, slow authorization, confusing governance, or low case volume. In these scenarios, traditional software or process change may solve with less risk.

Another caution signal is high error cost without well-defined human review. If a wrong recommendation can affect a critical operation, the question is not only "does the model get it right?" The question is: who reviews, at what moment, with what criteria, and with what information available?

Human review needs to appear in the flow design: review point, responsible person, criteria, and available information.

This distinction also helps in portfolio prioritization. An inventory of opportunities, like the one discussed in AI roadmap, is stronger when each opportunity arises from an observed task and not from a list of desired technologies.

Record evidence in decision language

The interview loses value when notes become a collection of loose phrases. To turn conversation into AI strategy in software, record each finding in three separate fields: observed evidence, team interpretation, and product hypothesis.

Fictional example: a software company for technical assistance operations interviews customers about delays in ticket prioritization. Instead of asking if they want AI to classify tickets, the team asks about the last ticket that was stuck longer than it should.

The conversation reveals that some attendants need to open equipment history, previous messages, support contract, and field comments before deciding if the case should be escalated. In some episodes, the doubt is not in the formal rule but in context interpretation.

The record could be like this, in simple language:

Evidence: customers reported that prioritizing certain tickets requires consulting equipment history, previous messages, and field observations before deciding the next routing.
Interpretation: friction seems to be in gathering and interpreting context, not just in the lack of an automated queue.
Hypothesis: a triage feature could gather relevant signals and suggest priority for human review.
Alternative without AI: improving the ticket screen, standardizing input fields, or creating a more visible escalation rule may solve part of the friction.
Uncertainty to measure: whether triage reduces manual steps without worsening perceived quality by the reviewer.

Notice the care: the example does not claim a result. It formulates a hypothesis to be tested.

This format prevents the team from turning the interview into a retrospective justification for an idea they already wanted to build. It also helps leadership compare opportunities with less noise. Instead of discussing "will we have AI in the product?", the conversation becomes "which friction deserves an experiment and which solution competes better?"

Compare opportunities by friction, risk, and learning capacity

Not every finding deserves to become an experiment. After some interviews, the team needs to compare opportunities with explicit criteria.

A practical criterion may consider:

Intensity of friction: does the problem cause delay, rework, error, waiting, or relevant coordination cost?
Task frequency: does the task occur frequently enough to justify investigation?
Error cost: does a bad suggestion cause mild inconvenience, moderate rework, or significant operational risk?
Data and domain knowledge: are there examples, documents, criteria, or experts able to guide the solution?
Ease of measuring improvement: is it possible to compare triage time, manual steps, rework, quality perceived by reviewer, or exceptions identified?
Need for human review: who needs to validate the output and at what point in the flow?
Simpler alternative: would a business rule, interface, integration, or process solve with less complexity?

This comparison forces the team to choose the initial uncertainty. The question stops being "which AI idea seems most attractive?" and becomes "which uncertainty is worth testing first?"

Microsoft Research describes its experimentation platform as a way to incorporate experimentation into the development cycle, validate hypotheses, measure impact, and iterate products. The source does not mean every feedback automatically retrains a model, nor that every product needs such a platform. The applicable point is different: hypotheses need to be formulated so they can be observed, compared, and reviewed.

In AI, this is even more relevant because a demonstration may seem convincing without solving the real work. A nice summary, a fluid answer, or an apparently correct classification are not enough. The experiment needs to show if the capability helps someone decide, act, or review better within the real flow.

This is a relevant difference regarding maturity. A company can integrate third-party models into mature products, as long as it knows the task, designs review, manages data, measures effects, and sustains operation. AI maturity does not necessarily require own model. It requires the ability to decide where intelligence enters and where it does not.

To deepen the organizational starting point, it is worth connecting this discussion to the diagnosis of AI maturity.

Close the interview without selling the solution

The interview closing also influences research quality. If the team closes saying "so we will build AI to solve this," the customer may leave thinking they approved a feature. Worse: they may adjust future answers to please the already suggested direction.

A better closing validates understanding without selling the solution.

You can say something like: "I want to confirm if I understood. The task is to prioritize tickets with incomplete context. The friction appears when the team needs to search history in different places and decide if the case should be escalated. We will still compare hypotheses, including process and product improvements. If possible, we would like to analyze more examples of this type of case."

This type of closing preserves trust. The customer understands they helped explain the work, not that they committed to a technology.

It also opens space for additional evidence: examples of real inputs, screens, documents, decision criteria, easy and difficult cases, exceptions, responsible parties, and consequences. When these materials cannot be shared, the team can still ask for more precise episode descriptions.

The interview ends well when it leaves three things clear: which task was understood, which friction seems relevant, and which uncertainty needs investigation. The solution remains open.

Review checklist for AI interviews without inducing technology demand

Use this checklist before preparing questions, during the conversation, and when reviewing notes.

Does the question start with real work? Replace AI questions with questions about the last occurrence of the task, involved people, inputs used, and decision made.
Was friction described as observable loss? Look for delay, rework, waiting, error, specialist dependency, coordination cost, or uncertainty. Avoid accepting "it would be more modern" as evidence.
Did the team separate fact, interpretation, and hypothesis? Record what the customer reported, what the team concluded, and which product hypothesis emerged. Do not mix the three fields.
Is there a clear consequence when the task fails? Prioritize tasks where error, delay, or low quality affect revenue, operation, risk, user experience, or scaling capacity.
Does the solution really need AI? Before proposing artificial intelligence, check if business rule, interface improvement, integration, documentation, or process change would solve better.
Is it possible to measure a small experiment? Define a comparison metric before building: triage time, rework rate, quality perceived by reviewer, number of exceptions identified, or reduction of manual steps.
Was human judgment designed from the start? When error cost is relevant, define who reviews, when, and with which criteria. Do not treat human review as late correction.

Before the next round, the product of the interview should be a map of tasks, frictions, and solution criteria: which tasks will be investigated, which questions will retrieve real episodes, and which criteria will separate AI from simpler solutions.

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

Sources

To continue this reading

How to record commercial learning from AI projects

NEXT DECISION

Discuss application in the company

Conversation about the software company context

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