Where AI Actually Belongs in Your Product — and Where It Doesn't

The Pressure to Ship Something AI-Shaped

By the time a software company gets to the third pillar — Productise AI — there's usually real external pressure behind it: a competitor announced an AI feature, a prospect asked about the product's 'AI capability' in a sales call, a board member wants an AI story for the next update. That pressure is real, but it's a poor basis for a product decision. Shipping an AI feature because the market seems to expect one, without a clear view of what problem it solves for the customer, tends to produce shallow functionality that looks impressive in a demo and disappoints in actual use.

Productising AI well starts with a much narrower question than 'should we have AI in our product': does AI make a specific, real part of the customer's job meaningfully better, in a way they'd actually pay for or stay for? If the honest answer is unclear, that's the signal to keep working the first two pillars — building enablement and operational fluency — rather than force a product bet the organisation isn't ready to support.

Four Places AI Can Actually Show Up

AI in a product isn't one decision — it's several distinct decisions that get conflated. It can be a feature: a discrete capability that does something the customer explicitly asked for, like automated summarisation or drafting. It can be a packaging lever: a way to differentiate tiers, where AI capability is reserved for a higher plan. It can be a pricing input: usage-based AI features often carry their own cost structure that needs to be reflected in what's charged, not absorbed silently into an existing plan.

It can also be an experience layer: AI woven into the UX itself — smarter defaults, predictive suggestions, adaptive interfaces — rather than a labelled 'AI feature' at all. Each of these has different implications for engineering effort, cost exposure, customer expectations, and how it should be marketed. Treating all four as the same decision is how companies end up with an AI feature that's technically live but doesn't fit anywhere sensible in the pricing model or the UX.

The Reliability Bar Is Different for Product Than for Internal Use

An AI workflow that's 90% reliable can still be a genuine internal win, because a human is in the loop reviewing the output before it matters. A customer-facing AI feature at 90% reliability is a different proposition entirely — the customer is the reviewer, whether the company intended that or not, and a wrong or strange output becomes a trust problem rather than an internal inefficiency. This is why the reliability bar for productised AI needs to be set deliberately higher, and why teams with real operational AI experience from pillar two are usually better judges of where that bar actually sits than teams making the call from theory.

This doesn't mean waiting for perfection — very few AI features ship at 100% reliability, and customers are increasingly used to AI features that are good but not infallible, provided expectations are set honestly. The failure mode isn't imperfection; it's overselling certainty the feature doesn't have, which turns a reasonable limitation into a broken promise.

Deciding, Deliberately, Not Defaulting

The healthiest version of this pillar produces a deliberate decision — including, sometimes, the decision that AI doesn't belong in the product yet, or belongs only in a narrow, well-bounded way. That's a legitimate strategic position, not a failure to keep up, provided it's an active choice rather than something the company backed into by avoiding the question.

Use the Productising AI Decision Framework to work through where, if anywhere, AI belongs in your product, packaging, and pricing — and to set a reliability bar and go-to-market plan for whatever you decide, rather than shipping something AI-shaped because the market seems to expect it.