AI & product strategy
Where AI actually belongs in a digital product
AI belongs at the points in a product where judgement is expensive and the input is unstructured — not spread evenly across the interface. A practical map of where it earns its place.
Need help with this?
Wondering where AI actually belongs?
Start with the workflow or decision, then use AI only where it genuinely improves the system.
AI is being added to products the way responsive design was added to websites in 2012 — broadly, quickly, and often without a clear reason. The result is a lot of interfaces with a chat panel bolted to the corner and very little change in what the product actually does for the person using it.
Key takeaways
- AI belongs where the input is unstructured and the judgement is expensive — not evenly across the product.
- Anything with a correct answer should be code, not a model.
- Value shows up at the seams between systems, where information has to be interpreted before it can move.
- Design the fallback path before the AI path; the product must still work when the model is unavailable or wrong.
Short answer
AI belongs where the input is unstructured, the judgement is expensive, and the output can be checked or reversed. Everywhere else, plain logic is faster, cheaper and more predictable.
Three conditions worth testing against
- The input is unstructured — free text, documents, images, speech, messy third-party data.
- The judgement is expensive — a person currently spends real time reading, interpreting or drafting.
- The output is checkable — a wrong result can be caught, corrected or reversed before it causes harm.
When all three hold, a model does work that code cannot do well. When any one of them fails, the AI step usually adds cost, latency and uncertainty to something that already worked.
Problem → workflow → decision → value
Where it tends to earn its place
| Layer | What AI does well here | What stays deterministic |
|---|---|---|
| Intake | Reading enquiries, documents and forms into structured fields | Validation, storage, notification rules |
| Triage | Classifying, prioritising and routing based on meaning | Ownership rules, SLAs, escalation thresholds |
| Drafting | First-pass replies, summaries, descriptions, briefs | Sending, publishing, pricing, commitments |
| Search | Interpreting intent and matching related content | Filters, permissions, ranking rules the business owns |
| Reporting | Explaining what changed and why it may matter | The numbers themselves |
Most of it should be invisible
The strongest AI work in a product is rarely a visible feature. It is a step in a workflow that used to require a person and now does not — an enquiry arriving already classified, a document already summarised, a record already populated. Users notice that the product feels fast and complete, not that a model is involved.
Chat interfaces are the exception rather than the default. They make sense when the task is genuinely open-ended and the user knows what they want to ask. For everything else, a chat box moves the work back onto the user.
Value collects at the seams
In most businesses the expensive gaps are between systems, not inside them — the website that does not talk to the CRM, the CRM that does not talk to fulfilment, the inbox that holds information no system ever sees. AI is useful at those seams because it can interpret what moves across them. That is the same structural problem described in from fragmented stack to integrated platform, and it is why we treat AI as part of automation and business systems rather than as a separate product line.
Where value collects in a workflow
Design the fallback before the feature
A model is a dependency with variable output and occasional downtime. Before an AI step goes into a product, three behaviours need to be defined: what happens when confidence is low, what happens when the service is unavailable, and who sees the result before it becomes an action. A product that only works when the model works is a fragile product.
Practical test
Remove the AI from your roadmap item and describe the remaining product. If it still solves the user’s problem, the AI is an improvement. If nothing is left, the AI was the idea — and that is a much riskier build.
The useful question is not where AI could be added. It is which decisions in the product are currently expensive, and whether a model makes them cheaper without making them unaccountable. That mapping is the first stage of AI and digital product strategy — before any model, tool or interface is chosen.
Frequently asked questions
- How do I decide which part of my product should use AI?
Look for steps where a person currently reads something unstructured — an email, a form, a document, a transcript — and turns it into a decision or a structured record. Those steps are where a model earns its place. Steps with a single correct answer belong in ordinary code.
- Is AI a feature or infrastructure?
Usually infrastructure. Most durable uses sit behind the interface: routing, extraction, drafting, classification, summarising. The distinction is covered in AI feature versus automation.
- What happens when the model gets it wrong?
That is a design question, not an accident. Every AI step needs a defined behaviour for low confidence: fall back to the deterministic path, escalate to a person, or hold the item in review. See human approval in AI workflows.
- Do we need our own model?
Rarely at the start. Most business products are better served by a hosted model behind a well-defined interface, so the model can be replaced without rewriting the product around it.
Next step
Have an AI idea but not sure where it belongs?
Define the use case, workflow and approval architecture before building.
Need help with this?
Trying to place AI in the right part of your product?
JMG can help turn an AI idea into a practical product and implementation plan.