dooopSoftware · Strategy · 13 min

How to Choose AI Opportunities in Software

Learn to prioritize AI in the software portfolio by evaluating observable problems, available evidence, risk, and learning within the cycle.

Published on September 6, 2026

CENTRAL THESIS

Flashy ideas compete poorly with traceable problems. Evidence decides what enters the product cycle.

Prioritize AI by comparing observable pain, evidence, and risk. The best test learns even when the hypothesis fails.

In a software portfolio, artificial intelligence ideas often arrive in a queue: copilots, summaries, predictions, triage, automations. The choice improves when leadership compares where there is an observable problem and sufficient evidence to test an intelligent intervention against the current way of working.

The best opportunity in the portfolio is not necessarily the flashiest in the demonstration. It is the one that appears in real use, leaves verifiable traces, and allows learning in the next product cycle.

Start with Behavior That Already Happens in the Product

When leadership looks at the portfolio, it is common to find several plausible ideas at the same time: summarizing interactions, classifying documents, suggesting next steps, generating reports, supporting support, anticipating risks, organizing internal knowledge. Almost all can yield a good demonstration. Few start from recurring behavior.

The first cut is simple: observe where someone already decides, interprets, corrects, waits, copies, checks, or asks for help inside or around the product. The AI opportunity in software products usually becomes clearer when you find a task that already exists, consumes attention, and has operational consequences.

The criterion shifts from fitting AI into the product to locating the decision that deserves support. Leadership begins to ask:

Who makes a decision today?
At what point in the flow does this decision happen?
What does the person consult to decide?
What happens when the decision is wrong, late, or inconsistent?
What traces does this situation leave in the product, support, or operation?

This approach also avoids a common mistake: treating AI as an aesthetic layer over a poorly understood pain. The DORA 2025 report presentation 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. For a software company, this is a useful warning. If the flow is confusing, if the decision criteria are unclear, or if no one knows how to measure the consequence, AI tends to amplify ambiguity, not just capability.

If the company is still organizing its broader direction, it is worth connecting this analysis to the inventory of initiatives. An AI roadmap helps transform scattered ideas into a sequence of decisions. But within the software portfolio, the choice of opportunity needs to be more granular: which problem deserves to advance to investigation, design, and experiment?

Separate Observable Problem from Interesting Idea

An interesting idea sounds desirable. An observable problem can be pointed out in real work.

"Generate reports with AI" is an idea. "Coordinators spend time consolidating ticket information because data is scattered in open fields, attachments, and comments" is closer to an observable problem. The difference lies in the ability to describe user, moment, consequence, and evidence.

An observable problem appears in signals such as:

recurring support tickets;
usage records showing abandonment, repetition, or return to the same step;
rework between areas;
analysis queues;
exceptions handled manually;
decisions recorded in free-text fields;
frequent requests for explanation, verification, or prioritization;
complaints associated with a specific step in the flow.

The question is not whether the idea seems modern. It is whether you can point to where the friction appears today.

For founders, CEOs, and CTOs, this criterion protects the portfolio against initiatives born strong in discourse and weak in operation. An intelligent feature can be technically feasible and still not solve a relevant pain. It can also solve a real pain but at such a peripheral moment in the flow that it does not justify priority.

A good problem statement has four parts:

Who suffers or performs the task.
At what moment in the product or process this happens.
What consequence arises when the task fails, is delayed, or requires excessive effort.
How this situation appears today in data, records, conversations, or observation.

Without these four parts, the opportunity is still in the realm of vague hypothesis. It can remain on the radar but should not compete equally with problems that already leave marks in the product.

Assess Whether Evidence Exists Before Promising Intelligence

The second criterion is access to evidence. Pain alone is not enough. There must be some material to compare the AI suggestion with current practice.

Evidence here does not mean only structured databases or ready material to train a model. It can include decision histories, annotated examples, documents used in the process, acceptance criteria, result records, usage logs, support conversations, samples reviewed by experts, or exception patterns.

The point is this: if there is no evidence, the team will have difficulty knowing if AI helped.

The February 2026 update of METR considers new data an unreliable signal of AI's current effect on productivity and points out difficulties in measuring time with competing agents, as well as participant and task selection. This source does not authorize general conclusions about AI's commercial value but reinforces methodological caution: measuring AI effects requires care with task, context, and comparison method.

In practice, before discussing model, tool, or interface, classify each opportunity by the type of evidence available:

Are there real cases or only invented examples for demonstration?
Are there previous decisions that can serve as comparison?
Are the criteria for a good response explicit?
Are there sufficient records to understand variation, exception, and error?
Does the product already measure the behavior affected by the intervention?
Can someone review samples and say what would be acceptable?

This applies both to proprietary models and third-party models integrated into the product. Maturity does not require building everything internally. It requires knowing which decision the system supports, which evidence sustains the comparison, and which responsibility remains human.

If the company is at an earlier stage, the AI maturity diagnosis can help identify gaps in data, governance, and process. But to choose an opportunity in the portfolio, the central question is direct: do we have enough evidence to learn something useful in the next cycle?

Use a Simple Matrix to Compare AI Opportunities in Software

The most useful comparison combines two axes: clarity of the observable problem and access to evidence. It is not a universal prioritization formula. It is a filter to prevent the portfolio from being ordered only by enthusiasm, technical ease, or commercial pressure.

Clear Problem and Accessible Evidence

This is the best candidate to advance. The problem appears in the flow, affects a defined user, generates a perceptible consequence, and there is material to compare the intervention with the current process.

The decision is not "launch AI." The decision is to transform the opportunity into a product hypothesis, with scope, metric, review, and stop criteria.

Clear Problem and Weak Evidence

Here there is pain, but the company does not yet have enough basis to evaluate an intelligent solution. It may be a good candidate for investigation, product instrumentation, example collection, and process design.

Building before understanding the evidence tends to produce a convincing demonstration and a fragile operation.

Vague Problem and Accessible Evidence

This quadrant is tricky. The company has data, perhaps a lot of data, but still does not know which decision it wants to improve. The risk is looking for an AI use just because material is available.

In this case, use the data to research the pain better. Do not automate immediately.

Vague Problem and Weak Evidence

The opportunity may return in the future but should not consume priority now. It depends on opinion, trend, or abstract promise. It lacks a concrete situation and a way to compare.

This is the type of idea that tends to grow in presentations and shrink when it enters the backlog.

Use Prioritization Criteria Before Discussing Model or Interface

Short criteria help take the conversation out of personal preference. For each opportunity, respond with evidence, not just conviction.

Observable problem: is it possible to point to where the problem appears today in the workflow or product use? Strong signals include tickets, logs, rework, queues, exceptions, manual decisions, or recurring complaints.
Defined user and moment: is it clear who will make a better, faster, or more consistent decision with AI support? The opportunity should indicate role, process step, and consequence of the decision.
Available evidence: are there examples, records, or past results to compare the AI suggestion with current practice? These can be case samples, previous decisions, reference documents, or evaluation criteria.
Possible comparison: can it be measured whether the intervention improved something relative to the current process? The metric can involve accuracy, time, rework, conversion, escalation, satisfaction, or perceived quality, as long as linked to the flow.
Proportional risk: is the cost of a bad recommendation compatible with the level of supervision and control available? The design needs to foresee human review, usage limits, trust criteria, and exception handling.
Learning in the next cycle: will the team be able to learn something useful even if the initial hypothesis is wrong? A good test reveals usage patterns, data gaps, decision criteria, or process adjustments.

The phrase that separates a mature opportunity from a vague bet is this: AI must reduce a specific uncertainty at a specific moment, for a specific user, with possible comparison against the current process.

Test the Opportunity with a Fictional Example

Imagine, as a fictional example, a management software for building maintenance companies. The team considers three AI ideas for the portfolio: summarizing service order history, predicting delays in service, and suggesting responses to customer requests.

All three ideas are plausible. The matrix helps compare them without relying on the most impressive demonstration.

The first idea, summarizing service order history, may have an observable problem: technicians and supervisors need to quickly understand what has already been done before a new visit. Traces may be in previous orders, comments, attachments, and records of replaced parts. Evidence exists if there is sufficient history and if someone can evaluate whether the summary preserves relevant facts, omits noise, and does not create information. The hypothesis to measure could be: on a ticket reopening, the summary reduces supervisor uncertainty before forwarding the next action.

The second idea, predicting delays in service, may have greater operational impact but might depend on more complex evidence. It would require history of deadlines, schedule, travel, type of occurrence, team availability, and real reasons for delays. If these records are incomplete or inconsistent, the problem may be clear but the evidence weak. The prudent decision would be to investigate data collection and quality before building a prediction embedded in the product.

The third idea, suggesting responses to customer requests, may be easy to demonstrate with a language model. But the problem needs to be observed. Do current responses cause delay? Generate rework? Require consultation of service contracts, technical history, or internal policies? Are there examples of good responses and criteria to review tone, accuracy, and responsibility? If the team cannot answer, the opportunity is still vague, even if the demonstration works well.

In this fictional scenario, summarizing history may be the best initial candidate if it combines frequent problem, accessible evidence, and risk controllable by human review. Predicting delay may remain as data investigation. Suggesting responses may require additional research on real pain before entering the product cycle.

The decision does not arise from interface beauty. It arises from comparison between problem, evidence, risk, and learning.

Define a Hypothesis That Can Be Measured in the Product Cycle

After choosing the opportunity, transform the intention into an operational hypothesis. A useful formulation is: for a given user, at a given moment in the flow, AI should reduce uncertainty or anticipate a decision, and this will be compared by an observable indicator.

This formulation forces the team to separate three things that often mix: model capability, user experience, and process impact. A model can generate fluent text and still not reduce uncertainty. An interface can seem simple and still shift work to manual review. An automation can speed one step and create risk in another.

Microsoft describes its ExP platform as a way to incorporate experimentation into the development cycle, validate hypotheses, measure impact, and iterate products. This reference does not mean every product needs the same infrastructure, nor that feedback automatically retrains a model. The useful principle is to treat the intervention as a measurable hypothesis, not as a belief that AI will be better by definition.

For a company defining an artificial intelligence strategy connected to business, this discipline reduces waste. The chosen opportunity must explain which decision improves, how it will be observed, and what learning remains even if the first solution does not work.

Know When to Keep an AI Opportunity in Discovery

Keeping an idea in discovery can preserve focus, confidence, and execution capacity.

An opportunity should remain outside construction priority when:

the problem is described as "improving productivity," "modernizing experience," or "having AI in the product," without a concrete use situation;
there are no reliable examples to compare the AI suggestion with current decisions;
the consequence of the decision is vague or cannot be observed;
the risk of a bad recommendation is high and there is no proportional supervision;
the solution depends on human judgment, but that judgment has not been designed into the process;
the benefit appears only in the demonstration and disappears when exceptions, incomplete data, and real users enter;
the test teaches nothing beyond "the technology works in a prepared case."

It is also worth keeping in discovery when the company does not yet know if the problem belongs to the product, service, customer process, or internal operation. AI can be part of the answer but does not replace strategic choice. In some cases, reviewing flow, criteria, responsibilities, and data should come before automating.

The right opportunity to advance is one where you can say: this problem appears here, for this user, with this consequence, using this evidence, and we can compare the intervention with the current process.

If this sentence does not close yet, keep the idea in discovery. If it closes, the next decision is to design a product cycle that tests operational value, not just technical capability.

Priority should go to the opportunity that appears in real work, has sufficient evidence, and allows learning in the next cycle.

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

Sources

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.