AI Product Strategy
Deciding what AI to put in your product, what it is worth to the people using it, what it costs per user at scale, and what the experience does on the requests the model gets wrong.
Two questions decide whether an AI feature succeeds, and neither is about the model. What does the user do when it is wrong, and what does it cost when a heavy user runs it four hundred times a month. Roadmaps that skip both produce features that demo well and are quietly removed a year later.
AI product strategy decides which AI capabilities belong in a product, how they are surfaced, what they are worth to users and to the business, what they cost per user at realistic volumes, and how the experience behaves when the underlying model is uncertain or wrong.
The questions that actually decide it
| Question | Why it decides the feature | Common failure |
|---|---|---|
| Is the task one people want done? | AI does not create demand | A capability nobody asked for, built because it was possible |
| Does an error cost more than the win? | Sets the whole interaction design | Automating something users cannot afford to have wrong |
| What does a heavy user cost? | Determines whether the pricing survives | Flat pricing over variable, unbounded inference cost |
| Is it a feature or the product? | Different bar entirely | A wrapper positioned as a platform |
| Will it still be a differentiator? | Platform vendors ship fast | Building what your stack will include next quarter |
| Who is accountable when it is wrong? | Determines trust and liability | Nobody, discovered during an incident |
Cost per user is the strategy question people skip
Traditional software has near-zero marginal cost per user. AI features do not. A heavy user of a generative feature can cost more than they pay, and unlimited-use positioning against variable inference cost is how promising products become unprofitable at exactly the moment they succeed. We model this before it is committed to publicly.
Design for the error rate, not the demo
Establish what accuracy is achievable, early
A quick evaluation on real data tells you whether the honest ceiling is 95 per cent or 70, and those imply different products. Strategy written before that number exists is written in the dark, so we run a cheap evaluation in the first weeks rather than assuming.
Choose the interaction pattern to match it
High accuracy with cheap errors can be automated silently. Moderate accuracy with expensive errors needs suggestion and confirmation. Low accuracy with high value needs the model to widen the options rather than choose. Getting this pairing wrong is the most common product-level AI failure.
Decide what happens on the bad cases
Not as an edge case, as a designed path: what the user sees, what they can do, whether they can correct it, and whether their correction improves anything. Products whose failure path was designed feel trustworthy at the same accuracy as products whose failure path was not.
Set the trust budget deliberately
Users extend trust early and withdraw it fast. Launching a feature that is impressive four times in five spends that budget quickly, whereas a narrower feature that is nearly always right builds it. Scope is a trust decision, not only a delivery one.
Price it against how it is used
Included in the tier, metered, credit-based, or a separate product — each changes behaviour and each interacts with the cost model. This is settled with commercial leadership rather than left to be discovered by the finance team.
What we produce
- A shortlist with the rejections explained. The features we recommend not building, and why, are usually the most contested and most useful pages.
- Feasibility evidence per candidate, from a quick evaluation on your real data rather than from a vendor's benchmark.
- Interaction pattern per feature, chosen against the achievable accuracy and the cost of error.
- Unit economics: cost per active user and per heavy user at realistic volumes, with the levers that move it. See inference optimisation.
- A build, buy or wait recommendation per capability, including where your platform vendor is likely to ship it. See build vs buy.
- A sequenced roadmap with the smallest first release that would prove or disprove the thesis.
How the engagement runs
A cheap feasibility check runs early, because strategy without an accuracy figure is guesswork.
Opportunity and users
Where users lose time or fail; candidate capabilities gathered from the product, support and sales.
Feasibility
Quick evaluation on your real data to establish achievable accuracy per candidate.
Economics and patterns
Cost per user modelled; interaction pattern and failure path chosen per feature against its error profile.
Strategy and roadmap
Shortlist with rejections argued, build-buy-wait per capability, sequenced with a first release that tests the thesis.
Handover
Walkthrough with product, engineering and commercial leadership.
What you receive
A shortlist you can fund, with the economics modelled and the rejected ideas argued.
Opportunity assessment
Where AI would change a user outcome, and where it would only be impressive.
Feasibility evidence
Achievable accuracy per candidate, measured on your own data.
Interaction design direction
The pattern and failure path per feature, matched to its error profile.
Unit economics model
Cost per active and heavy user at realistic volumes, with the levers.
Build, buy or wait recommendation
Per capability, including where platform vendors are likely to ship it.
Sequenced roadmap
With the smallest first release that would prove or disprove the thesis.
Is this the right engagement?
Worth being direct. AI Product Strategy is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- AI features are on the roadmap and the case for each is assumed rather than argued.
- A feature was built and is not used, and nobody can say why.
- Pricing is being set for an AI capability with unmodelled costs.
- Investors or the board are asking for an AI product position.
- You need to know what to build first rather than what is possible.
Choose something else if
- The decision is which AI initiatives to run across the business. See AI strategy and consulting.
- The feature is decided and you need it built. See AI MVP and prototyping.
- No engineering capacity exists to act on the outcome this year.
- The strategy must conclude that a pre-chosen feature is a good idea.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
How do we know an AI feature is worth building?
By checking three things before committing: whether users want the task done at all, whether the achievable accuracy is high enough that the errors cost less than the wins, and what a heavy user costs at realistic volume. A feature that fails any of the three usually gets built anyway and quietly removed a year later.
Why does cost per user matter so much?
Because AI features break the assumption that marginal cost per user is near zero. A heavy user of a generative feature can cost more than they pay, so unlimited-use positioning against variable inference cost turns success into a loss. It is modelled before anything is announced publicly.
Should we build it or wait for our platform vendor?
Sometimes wait, and we will say so. Platform vendors ship AI capability quickly, and building what your stack will include next quarter is a common and expensive mistake. Custom builds earn their place where the capability depends on your data or your process specifically.
What if the model is not accurate enough?
Then the interaction pattern changes rather than the feature being abandoned. Moderate accuracy with expensive errors becomes suggestion-and-confirm; lower accuracy with high value becomes a tool that widens the user's options rather than choosing for them. Matching pattern to error rate is most of this work.
How is this different from AI strategy consulting?
AI strategy and consulting decides which AI initiatives the business should pursue across operations, service and analytics. This decides what goes into your product and how users experience it, including pricing and the failure path. Product companies usually need this one.
Often paired with this
Most clients combine two or three engagements from the AI Product and Experience Design pillar. These are the ones that most often run immediately before or after.
AI MVP and Rapid Prototyping
A prototype built to answer one question, with a kill criterion agreed before it starts.
Read more →UX Design for AI Interfaces
Designing for probabilistic output — uncertainty shown usefully, failure paths designed, correction made easy.
Read more →AI-Native SaaS Development
Multi-tenant AI done properly — data isolation, per-tenant cost, evaluation gating releases, pricing that holds.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.