dooopSoftware · Strategy · 13 min

How to Choose a Segment for an AI Solution

Learn how to define an AI segment by user, routine, context, consequence, and quality criteria before building the solution.

Published on September 6, 2026

CENTRAL THESIS

A segment that is too broad becomes a nice demo. A useful segment appears in a routine that can be observed and judged.

Choose the first segment by user, moment, recurrence, context, and consequence. Then test the hypothesis.

Product segmentation with artificial intelligence begins when you stop choosing a broad market and start delimiting a recurring usage context. "Retail," "industry," or "operations" are still too broad. A good initial segment combines a specific user, work moment, recurring need, available context, understandable consequence, and a criterion to evaluate whether AI improved a decision or execution.

Choose the Segment by Repeated Work, Not by Sector

The question "In which segment should we apply AI?" is often answered too early. Leadership looks at familiar sectors, competitors doing demos, and internal areas pushing for novelty. The result is a list of possibilities that does not define user, routine, necessary data, or quality criteria.

Sector is a commercial category. Usage context is a concrete work situation.

A company might say it wants to create an AI solution for logistics. That still defines almost nothing. Logistics includes routing, carrier service, demand forecasting, document checking, delivery tracking, parts replenishment, supplier negotiation, and many other routines. Each has different users, data, risks, and quality criteria.

AI product segmentation becomes more useful when the cut changes from "logistics" to something like: operational planning teams that need to prioritize exceptions in recurring deliveries, using order data, transport status, and existing service rules.

This cut may still be wrong but already allows investigation of routine, context, risk, and decision criteria.

The point is not to choose the narrowest possible niche. It is to choose a cut where AI can be incorporated into an observable routine. Without routine, the solution becomes a demonstration. With routine, you can ask who uses it, when they use it, what they need to know, what changes after the recommendation, and how the result will be judged.

This distinction also avoids a common mistake: choosing the segment because the technology seems ready. A model can summarize texts, classify messages, or suggest responses. That does not mean any area with text is a good segment. The product question is different: is there a recurring need where summarizing, classifying, or suggesting really changes a decision, reduces friction, or increases consistency within a workflow?

If the answer does not appear clearly, maybe you do not have a segment yet. Maybe you only have a technical capability looking for context.

Define Who Decides, Who Uses, and Who Suffers the Consequence

An AI solution rarely affects only one person. Before choosing a segment, separate the roles involved.

The buyer may be the area leadership. The user may be an analyst, supervisor, or attendant. The domain expert may be the one who defines rules, exceptions, and quality criteria. The affected person may be a client, supplier, employee, or partner who receives the decision, recommendation, or communication generated with AI support.

Mixing these roles impoverishes segmentation. When you say "product for managers," you may be talking about those who approve budgets, not those who use the solution daily. When you say "product for service," you may be looking at the internal team but ignoring that the end client suffers the consequence of a wrong, incomplete, or off-tone response.

A segment cut needs to answer at least:

Who will frequently use the solution?
Who authorizes adoption or pays for the solution?
Who defines if the recommendation is sufficiently correct?
Who will be affected if the AI errs?
Who can interrupt, review, or reject the suggestion?

This separation is especially relevant because AI tends to amplify what already exists in the organizational system. The presentation of the DORA 2025 report describes AI as an amplifier of existing strengths and weaknesses and highlights the importance of the organizational system for return on investment. This does not prove one segment will be better than another. But it reinforces a practical warning: if roles, criteria, and responsibilities are confused before AI, automation can make the confusion faster and harder to perceive.

Good segmentation is designing responsibility before designing functionality.

Look for Recurring Needs with Controllable Variation

AI is easier to evaluate when the need repeats but cases are not all identical. If everything is the same, maybe a simple rule solves it. If everything is unique, maybe there is no basis to compare results. The interesting ground is usually between these extremes: recurring tasks with enough variation to require interpretation, prioritization, synthesis, or recommendation.

Recurrence does not mean huge volume. It means enough repetition for the team to learn from use, feedback, error, review, and context change. This learning can happen in product design, rules, data, interface, operation, and, when appropriate, in model configuration or improvement. It does not necessarily depend on proprietary models. Mature products can integrate third-party models, provided context, criteria, and governance are well designed.

To evaluate recurring need, observe four dimensions:

Task frequency: does it appear regularly in the workflow?
Case diversity: is there enough variation to justify intelligent support?
Available context: would the solution have access to the necessary material to suggest something useful?
Comparability: is it possible to compare one output with another, or with a previous human decision, without inventing artificial metrics?

Measurement care matters. The February 2026 update of METR considers new data an unreliable signal of AI's current effect on productivity and points out difficulties such as participant selection, task selection, and time measurement with competing agents. This source does not authorize concluding that AI improves or worsens productivity in any context. It serves here as a reminder: measuring AI effect requires careful task and evaluation method design.

Therefore, the segment should not be chosen just because "it seems it will save time." Time can be a criterion but rarely the only one. In many products, consistency, traceability, rework reduction, better prioritization, or less dependence on individual memory may be more appropriate criteria. The criterion needs to arise from real work, not the generic promise of technology.

Test the Cut with a Concrete Case

Imagine a fictional example: a software company wants to create an AI solution for field operations. The initial idea is broad: "use AI for external teams." It seems promising but still vague.

External teams do technical visits, installations, preventive maintenance, evidence collection, asset inspection, incident recording, communication with centers, and system updates. Each routine has a different need.

Upon investigation, the company narrows the cut to: building maintenance supervisors who need to review recurring inspection records made by technicians in distributed units before prioritizing corrections for the following week.

Now the segment is more examinable.

The daily user may be the supervisor. The person producing part of the context is the field technician. The buyer may be operations management. The affected person may be the unit manager awaiting correction. The recurring need is to review records, identify inconsistencies, group similar occurrences, and suggest follow-up priority. The quality criterion may include classification consistency, clarity of justifications, adherence to internal rules, and usefulness of prioritization for the operational meeting.

None of this proves the solution should be built. But it shifts the conversation from market bet to a verifiable hypothesis of routine, data, risk, and adoption.

Instead of asking "Is AI in field operations a good market?" leadership starts asking:

Do the records have sufficient quality to support recommendation?
Do supervisors already review this material frequently?
Does current prioritization cause rework, delay, or decision conflict?
Is there an accepted criterion to say one occurrence is more urgent than another?
Does the workflow allow AI suggestion before human decision?
Is the risk of an inadequate suggestion understood and reviewable?

This is the gain of the cut. It does not eliminate uncertainty. It transforms generic uncertainty into a testable hypothesis.

Compare Cuts Without Depending on Meeting Enthusiasm

When there are two or three candidate segments, the worst outcome is choosing by meeting enthusiasm. The second worst is choosing the segment that yields the prettiest demo.

A simple decision matrix helps compare cuts without pretending precision. The proposal below is a practical tool from this guide, not a conclusion of cited sources. Assign 0, 1, or 2 points for each criterion, comparing candidate segments: 0 for absent, 1 for partial, and 2 for clear. More than the sum, observe where each cut is weak.

Segment Cut Checklist for AI Product

Specific user: is it possible to name the profile that will use the solution daily, without relying on broad terms like "companies," "managers," or "business areas"?
Work moment: does the need appear at a recognizable point in the flow, such as review, classify, prioritize, respond, compare, approve, or investigate?
Recurrence: does the task happen frequently enough to generate product learning and justify process change?
Available context: would the solution have access to the necessary material to produce a useful recommendation, analysis, or action?
Quality criterion: is there a practical way to evaluate if the output was better, faster, more consistent, or safer for that context?
Understandable consequence: are error risks known and is there someone responsible for accepting, reviewing, or rejecting the AI suggestion?
Adoption in flow: does the solution enter an existing routine or would it require the user to create a parallel process just to use AI?

Segments with good scores in recurrence, available context, and quality criterion deserve investigation first. Segments with high consequence and undefined responsibility should be postponed or redesigned, even if commercially attractive.

This checklist also helps differentiate segmentation from portfolio prioritization. Prioritization compares opportunities within a larger strategy, as discussed in AI Roadmap: from opportunity inventory to 12-month plan. Segmentation defines the operational cut where a solution can exist. One decision feeds the other but they are not the same.

If the company does not yet know what capabilities it has, it is worth connecting this analysis to the AI maturity diagnosis. Maturity here does not mean having everything internalized or developing proprietary models. It means knowing how to decide, operate, measure, and govern AI use compatible with risk and expected value.

Test the Segment Hypothesis as Product Learning

Choosing an initial segment is not declaring a market truth. It is formulating a product hypothesis.

A segment hypothesis can take this form: "We believe this user profile, at this work moment, faces this recurring need, with sufficient context for an AI solution to support this decision or execution, measured by this criterion."

This sentence seems simple but forces choices. Who is the user? What is the moment? What need repeats? What context will be available? What decision will be supported? How will quality be evaluated?

From there, testing can start small. Interviews help understand language, routine, and criteria. Prototypes help observe reaction and interpretation. Controlled pilots help compare real use with expectation. Metrics help separate perception from observable effect. None of these steps need to promise broad adoption.

Microsoft Research describes its ExP platform as a way to incorporate experimentation into the development cycle, validate hypotheses, measure impact, and iterate products. The reference is useful for the product management principle: hypotheses need to enter the development cycle. It does not support the idea that any feedback automatically retrains a model, nor guarantee positive impact.

For companies creating a broader strategy, this cycle relates to the need to connect AI to business, not just to the technical backlog. This point appears in How to Create an AI Strategy Connected to Business: the AI decision needs to consider value, risk, capability, and governance.

In practice, the first segment test should honestly answer a few questions:

Does the routine exist as described or was it imagined by the product team?
Does the user recognize the need without being convinced by technology?
Is the necessary context accessible at the moment of use?
Can the AI output be reviewed by someone competent?
Is the quality criterion accepted by those who decide and those who use?
Does the solution reduce friction or create another parallel step?

If these answers are weak, maybe the segment is not ready yet. This does not mean abandoning AI. It means returning to the cut.

When a Segment Should Not Be Chosen Now

Some segments are seductive because they have budget, visibility, or apparent pain. Still, they may be bad choices for an AI solution at this moment.

Postpone or redesign the segment when the need has low repetition. AI applied to rare events may make sense in some contexts, but evaluation will be harder, product learning slower, and error cost disproportionate.

It is also worth postponing when there is no criterion to evaluate output. If no one can say what makes a recommendation good, safe, useful, or acceptable, the solution will depend on unstable opinions. Without criteria, the discussion becomes preference.

Another warning sign is excessive dependence on tacit judgment. Some decisions depend on experience, political context, negotiation, or situational reading not recorded anywhere. AI can support parts of the work, like organizing information or raising inconsistencies, but maybe should not assume the main recommendation.

High risk without defined responsibility is an even clearer block. If a wrong suggestion can cause relevant damage but no one has authority to review, accept, contest, or interrupt use, the problem is not technical. It is responsibility design.

Inaccessible data also limit the segment. Sometimes the need is recurring and valuable, but the context is scattered, incomplete, unavailable, or locked in systems outside the usage flow. Before promising AI, leadership needs to decide if solving the information problem is worthwhile.

Finally, beware of segments where adoption requires a parallel process. If the user needs to leave the routine, copy information, open another tool, interpret a response, then return to the main system, friction may kill the solution before value appears. AI embedded in the product depends less on the isolated model capability and more on how the suggestion enters, is reviewed, and generates consequence in the flow.

The segment closure should fit in one sentence: who uses it, at what work moment, what recurring need will be supported, and what criterion will say the solution improved the decision or execution. If the sentence is generic, the segment is still too broad.

To take this cut to a product decision, contact dooop via contact.

Sources

To Continue This Reading

How to Use Customer Interviews in AI Strategy

NEXT DECISION

Discussing Application in the Company

Conversation about the software company context

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