AI Product Strategy

3 MIN READ

What Makes an AI Product Different?

Why building AI products requires a different approach to traditional software products.

A study of light, shadow and structure in concrete architecture

Traditional software products are largely deterministic.

Given the same input, they generally produce the same output.

AI products are different.

The model is only one part of the product

An enterprise AI system might contain:

  • an LLM
  • retrieval
  • tools
  • permissions
  • validation
  • human approval
  • monitoring

The product manager therefore needs to think beyond model performance.

AI introduces uncertainty

One of the fundamental differences between traditional software and AI systems is probabilistic behaviour.

That changes how we think about:

  • testing
  • evaluation
  • risk
  • product requirements
  • monitoring

The product architecture matters

A useful way of thinking about an enterprise AI product is:

identity → permissions → provenance → guardrails → validation → human approval → monitoring → auditability

The model sits inside this wider system.

An example: regulatory research

Consider a hypothetical assistant that helps a compliance analyst find requirements for a particular jurisdiction. A fluent answer is useful only if the analyst can inspect the supporting regulation, check which jurisdiction it applies to and recognise when the evidence is incomplete.

The product requirements therefore extend beyond answering a question. They include preserving source links, displaying the scope of the search, handling conflicting evidence and giving the analyst a way to correct or reject the answer.

In LumiReg, these questions shaped the focus on conversational regulatory research with provenance. The case study describes the discovery and system design behind that approach.

Define success before choosing the model

For a research assistant, useful evaluation questions might include:

  • Can a user trace a claim back to its source?
  • Does the answer respect the requested jurisdiction?
  • Does the system flag missing evidence rather than fill the gap?
  • Can the user complete the workflow with less effort?

These are proposed product checks, rather than reported benchmark results. They make the intended behaviour concrete before model selection or prompt tuning begins.

For a broader framework for evaluating risks throughout an AI system’s lifecycle, see the NIST AI Risk Management Framework.