Standard prioritisation frameworks such as RICE break on AI features, because they ignore the two things that decide whether an AI feature survives contact with production: cost to serve per use, and how hard it is to tell whether the output is good enough. This matrix scores each idea on customer value, evidence, cost to serve and evaluation difficulty, then ranks your backlog.
RANKED ORDER
Leave your details and I'll review your top three AI features and tell you which one I would actually build first, and why.
THE FRAMEWORK
Traditional prioritisation assumes that once a feature is built, it works and it is free to run. Neither assumption holds for AI. A retrieval feature that costs eighteen pence per query is a pricing decision, not just an engineering one, and a generative feature with no evaluation harness is a support liability wearing a product costume.
The two extra axes in this matrix exist because those are the failures I keep being called in to fix. Teams shipped an impressive demo, then discovered either that gross margin fell through the floor at scale, or that nobody could say whether the output quality was getting better or worse release to release.
Evidence is scored separately from value on purpose. Founders consistently rate AI feature value highly because the technology is exciting. Separating 'how much would this help' from 'what proof do I have that they want it' exposes wishful thinking quickly.
Build now (70+) means the value is clear, you have evidence, and you can afford both the runtime and the quality assurance. These are the features that make the release.
Prototype first (50-69) means the idea is promising but one axis is soft. Build a throwaway version behind a flag, measure the real cost per use and the real quality, then re-score. A week of prototyping regularly changes the ranking.
Needs evidence (32-49) means the concept may be sound but you are guessing about demand. Go and ask ten customers before it consumes a sprint.
Not yet is usually an expensive, hard-to-evaluate feature with thin evidence. Agentic workflows land here more often than teams expect, which is not an argument against them, only against building them third.
Before you build an AI feature, work out the cost of a heavy user. Take the expected number of calls per active user per month, multiply by the blended input and output token cost, add retrieval and storage, and compare it with the revenue that user generates.
If a £29 per month plan contains a feature that costs £11 per month to serve for your most engaged customers, you have designed a product that punishes success. The fix is usually packaging: put the expensive capability in a higher tier, cap it, or cache aggressively.
This is the same discipline as any other product cost decision, and it belongs at the prioritisation stage rather than the incident review. The Crossley Method puts it in Prototype, before Build MVP, for exactly that reason.
Score each idea on customer value, strength of evidence, cost to serve per use and how hard the output is to evaluate. Features that are valuable, evidenced, cheap to run and easy to evaluate should be built first, regardless of which is technically most impressive.
RICE assumes effort is a one-off cost and that a shipped feature works reliably. AI features carry an ongoing cost per use and a quality distribution rather than a binary works or does not work, so both need to be explicit inputs.
It is how hard it is to build a repeatable test that tells you whether the model output is acceptable. Classification is easy to evaluate, summarisation is moderate, and open-ended agentic behaviour is difficult, which affects how safely you can iterate.
As a working rule, keep total inference and retrieval cost under 15% of the revenue from the plan that includes it. Above 25% you are effectively selling compute at a loss and need to change packaging or model choice.
Usually not. Agents score worst on cost and evaluation difficulty while carrying the weakest evidence. Start with a narrow, well-evaluated capability, learn what your users actually do with it, and expand from there.
One, done properly. An MVP with a single reliable AI capability that customers trust beats four impressive demos that each fail differently.
EXPLORE NEXT
Every stage from first idea to first revenue, mapped end to end.
Turning LLMs, RAG and agents into products that hold up in production.
Read moreAI-accelerated MVP delivery, scoped to one journey that earns.
Read moreWhat the role actually involves and how it differs from a classic PM.
Read moreThe seven-stage framework that takes an idea to first revenue.
Read moreContinuous discovery that tells you what to build next.
Read moreLong-form writing on AI product leadership and shipping MVPs.
Read more