A $20 seat can earn a 90% margin on one customer and lose money on the next. Nothing about the model changes between the two; only usage does.
That gap, worked through further down, is why an AI product needs a different business model from ordinary SaaS. Costs rise with usage. The model's quality slips over time. "Does it work?" has no plain yes or no: it works most of the time, and how often matters. And what sets you apart is your data and the system you build around the model.
Market sizing, personas, value propositions and competitor research still matter. But they stop exactly where AI gets hard. A product manager now has to decide four things together: product strategy, what the data costs and earns, how to judge a model that is sometimes wrong, and what each request costs to run. The result has to be something a finance team would fund. That work starts before anyone picks a model.
Deciding what problem AI is genuinely better at
Strategy starts with a valuable problem. The trap is to pick the model first (which API, RAG or not, agent or not) and then go looking for somewhere to point it.
AI earns its keep on a fairly narrow set of problem shapes, and recognising them early saves quarters of wasted work. High-volume classification and prediction qualify; so does anything built on unstructured data (text, images, audio, logs) that conventional software handles badly. Personalisation at scale, knowledge retrieval and summarisation, and workflow automation where every case differs slightly belong to the same family, along with decision support where a better probability estimate genuinely changes the outcome.
They all pass the same three-part test. The problem happens often, solving it has real impact, and you have data to learn from. If a problem fails any one of the three, it is usually better solved without AI. This simple check kills more doomed AI projects than any technical review.
Value comes from a handful of distinct sources, and naming the one that applies is what separates a business model from a demo. Some products cut cost or compress a workflow; others raise accuracy or surface risk that used to slip through; a third group improves the experience itself through personalisation; and a fourth creates something that did not exist before: a copilot, generation, reasoning across a corpus no person could read end to end.
Whichever source applies becomes the economic engine, and it sets everything downstream: which metric is worth instrumenting, what the buyer will actually pay for, and how pricing should be shaped. A product whose real value is hours saved should not be priced on tokens consumed.
Where defensibility comes from once the model is commoditised
Rivals copy whatever works, so the engine needs protecting. Model choice makes a poor moat, because whatever you picked is available to everyone else on roughly the same terms, and the next base-model release can erase a lead overnight. Durable advantage accumulates elsewhere: in proprietary datasets and the domain pipelines that keep them usable, in retrieval tuned to one specific corpus, and in specialised model families that only make sense inside a single industry.
The rest of the moat is organisational. Deep workflow integration raises switching costs, infrastructure that lets a team run experiments quickly compounds into a learning advantage, and internal knowledge loops turn every deployment into an input for the next. That is why "we have a chatbot" or "we added summarisation" describes a feature: a competitor calling the same API can ship it next month.
A capability map turns strategy into four costed layers
A feature list (add a copilot, a search box, a recommender) does not tell you whether the product is scalable, maintainable or economically real. A capability map does: the strategy broken into layers, each layer tied to a workflow, a data dependency, a cost and an evaluation method.
Four layers usually cover it. The data layer holds pipelines, feature stores, embeddings and vector search, and the labelling that feeds them. The model layer holds base models, any fine-tuning, retrieval-augmented pipelines and the evaluation harness that says whether they work. The orchestration layer decides how models are actually called in production: prompt templates, agentic flows, routing, and the fallback for when a call fails. The experience layer is what the user sees: the copilot, the automation, the dashboard, the recommendation.
The map forces a shift from "what features do we have" to "what capabilities support them".
It also makes every capability answer four questions: who gets value from it, what technical limits it has, what it costs to run, and how you will know it works. With those answers on the table, technical debates (look up documents or retrain the model, small model or large, reuse saved answers or generate fresh ones) become cost-and-benefit questions with real answers. They stop being matters of taste.
Ranking capabilities takes different questions from a classic backlog. Does a model actually suit this problem, and is there enough data? Can it hit its speed and accuracy targets with real users, not just in a test notebook? How many other parts does it depend on, what compliance risk does it carry, and does it still work when traffic grows? Asking these in order often pushes the demo that impressed everyone down the list. The dull capability that actually pays moves up.
The instrumentation the model needs to prove itself
An AI product has to be watched on two axes at once, because the outcome is a product of user behaviour and model behaviour together, and either can move.
On the user side the familiar measures still apply: activation, engagement depth, task completion, time saved, long-term retention, and the adoption curve of the specific feature. These say whether anyone is getting value. On the model side are numbers a PM should be able to read without help. Precision and recall (and F1, which combines them) show whether the output can be trusted: how often its answers are right, and how many of the right answers it finds. Hallucination rate and drift show how that trust wears off. Look at the spread of response times, not the average, because users remember the slowest answers. And cost per request decides whether you can offer the feature at its current price at all.
The job is to read these against each other. A two-point accuracy gain that triples cost per request can be the worse product decision, and only a PM looking at both columns will catch it. Followed all the way through, the same instrumentation shows AI's effect on the funnel: onboarding that activates faster, personalisation that holds retention, predictive triggers that reduce churn or open upsell.
Instrumentation tells you what happened; an experiment tells you whether you caused it. In ordinary software an experiment asks whether users prefer a variant. In AI it has to validate three things at once: that users want it, that the model is safe and reliable enough, and that the economics survive contact with real traffic.
Tests on past data are for quick sorting: compare candidates and drop the weak ones cheaply. You need them, but they are never enough. Only real users bring new kinds of requests, odd inputs, rare cases, heavy load and creative misuse. A model that wins on past data can still lose live if it answers more slowly or trips on inputs the test set never had. So a live test has to track several things at once: user results, model quality, safety, speed under load and cost. That is more demanding than a plain A/B split.
A test set (the examples you check the model against) needs the right size, like any experiment. Suppose the true hallucination rate is 5%. On a 50-example test set the margin of error, at the usual 95% confidence, is roughly ±6 points (1.96 × √(0.05 × 0.95 / 50) ≈ 0.06), so the set cannot tell a 3% model from an 8% one. To pin the rate within ±2 points you need about 1.96² × 0.05 × 0.95 / 0.02² ≈ 460 labelled examples, and more for every segment you intend to report separately. Teams that compare two prompts on thirty hand-picked cases are reading noise. They usually pick the variant whose errors they happened not to sample.
Guardrails belong in that design from the start: the highest hallucination rate you will accept, content that is never allowed, limits on how often each kind of failure may happen, and the confidence level below which the system falls back to a safer answer on its own. Set them before launch, because they, not the average-case quality, decide whether the thing can go live at all.
A flat seat price inverts margin as usage deepens
Passing experiments says nothing yet about margin. AI drags in variable cost structures that traditional SaaS rarely carried to the same degree. Inference, the cost of each answer the model generates, is the first. It grows with model size, how much text you send in, how much comes out, how often people ask, when traffic peaks and how often a saved answer can be reused. So a change that looks harmless, like doubling how much text the model reads per request, can quietly rewrite unit economics. Forecast it against scenarios before there is any traffic; after launch you can only react to it.
A short worked example (illustrative figures) shows how quickly that bill moves. Suppose a summarisation feature is sold at a flat $20 per seat each month, and every request costs $0.01 in inference. A light user runs 200 requests a month: $2 of cost against $20 of revenue, a 90% margin after inference costs alone, before the other costs of delivering the feature. A power user on the identical seat runs 2,500 requests: $25 of cost against the same $20, so the account now loses $5 before any other expense is counted. The model did not change; usage did. Hence the rule: a flat seat price with no usage ceiling inverts margin as adoption deepens, which is why the heaviest-user cohort has to be modelled before launch, not discovered on the invoice afterwards.
The margin a finance team sees is a blend, and cohort mix sets the blend. With 80% light users at $2 of cost and 20% power users at $25, average cost per seat is 0.8 × 2 + 0.2 × 25 = $6.60 against $20, a 67% blended margin that looks healthy in a board deck. If deeper adoption moves the power share to 40%, average cost becomes 0.6 × 2 + 0.4 × 25 = $11.20 and the margin falls to 44%, while every product metric on the dashboard says the feature is succeeding.
Three levers change that curve, and each has a price. An allowance with overage (1,000 requests included, $0.015 for each one beyond) turns the power user into $20 + 1,500 × $0.015 = $42.50 of revenue against $25 of cost, a 41% margin, at the risk of making heavy users ration the feature that hooked them. Caching attacks cost instead, and model vendors discount cached input heavily. If 30% of the power user's requests can be served from cache at negligible cost, the bill drops to $17.50 and the flat seat is profitable again, provided answers can safely repeat. Routing simple requests to a smaller model at, say, a fifth of the price works the same way, and it needs an evaluation set proving the small model is good enough for the requests it receives. The decision rule: if the top usage decile costs more to serve than it pays, fix that with one of these levers before spending on acquisition.
The bigger bill is the cost of keeping the model running, and it usually dwarfs the first training run: preparing and labelling data, fine-tuning, testing every new version, scaling servers, and watching for quality slipping over time. A feature that can only hold its quality through constant retraining is a feature whose margin has to be re-examined.
Six tabs make the model readable by finance
Every number above belongs in one spreadsheet, and the layout matters more than the formulas. Six tabs, in this order, let a finance partner trace any margin figure back to the assumption behind it:
- Drivers. Every input someone has to guess, on one sheet: seats, the split between light and power users, requests per user per month, price per seat, allowance and overage rate. Nothing on later tabs is typed in by hand.
- Cost-to-serve. Cost per request built bottom-up: tokens in and out times the model price, retrieval, the share of requests that fall back to a larger model or a human, and the cache hit rate. In the example it comes to $0.01 per request.
- Lifecycle. Monthly costs that do not move with a single request: annotation, evaluation runs, retraining, monitoring, the engineer on call. Spread per seat, they decide whether a small cohort can ever be profitable.
- Revenue. What each cohort pays under the mechanics you chose: flat seat, allowance with overage, or a usage tier. How tiered and usage-based options compare is a separate question; this tab only has to reflect the one you picked.
- Scenarios. Three columns: the launch mix (20% power users), deep adoption (40%), and the same mix with a cheaper model or a cache in place. Each recomputes blended margin from the drivers.
- Sensitivities. For each driver, the margin change caused by one plausible move.
Read the sixth tab first. With the numbers above, average cost per seat is 2 + 23 × (power-user share) dollars, so every ten points of power-user share cost about 11.5 points of blended margin. Halving the cost per request lifts margin from 67% to about 84%. A 30% cache hit on power users alone lifts it to about 75%. Ranked that way, the model tells the team where the next sprint goes: into usage mix and request cost, well before anyone argues about list price.
ROI, finally, has to be shown in a form finance recognises (labour hours removed, accuracy gained, risk avoided, capacity added, new revenue opened) and pressure-tested against the quarters that go badly, not just the launch demo.
When shipping first beats modelling first
Teams that have shipped AI products quickly push back on all of this. Before launch you know neither how people will use the feature nor what a request will cost once prompts settle, so any money model is a spreadsheet of guesses. Per-token prices for a given level of capability have also fallen fast, year after year. A margin problem modelled today may solve itself by the time the cohort exists. On that view the rational move is to ship to a small group, measure real usage, and model afterwards.
They are right in a specific situation: before product-market fit, with a design-partner cohort of tens of accounts, and with a feature whose worst-case cost per account is a rounding error next to the contract value. There, a week spent on a pricing model is a week not spent learning whether anyone wants the thing. The argument fails as soon as a flat price is published to a self-serve market. Prices are sticky in a way architecture is not. A seat announced at $20 with no ceiling is hard to take back, and the users most annoyed by a new cap are the most engaged ones.
A practical compromise keeps both camps honest. Ship to a limited cohort without public pricing, log tokens and requests per account from day one, and set a review trigger in advance, for example when any account's monthly cost exceeds 50% of what it would pay. Model the price when the trigger fires or before general availability, whichever comes first.
Why the order matters more than the steps
Written down, the process fits on one page: name the problem and its measurable value; check whether the data can carry the idea before drawing anything; map the capability layers; agree in writing what "good enough" means on quality, cost, latency and safety; stand up the experiment loop and run it with statistical rigour; assemble the money model (inference cost, lifecycle cost, pricing, ROI); stress-test it against scaling limits and the strategic moat; and confirm that the organisation (product, data science, engineering, governance) can actually carry it.
The sequence earns its keep because each step is a cheaper place to kill an idea than the one after it. A problem that fails the frequency, impact and data gate costs one meeting to drop. The same problem discovered during an online experiment costs a quarter of engineering time and a team that has grown attached to it.
The money model is the exception. It sits near the end of the list because it needs real numbers from the experiments, yet a rough version belongs at the very start: the $20 seat that loses $5 on a power user is visible on a napkin before a line of code exists. What the sequence really does is pull judgment that normally scatters across teams and stages back into one product-management frame.
Two answers are worth carrying into any review of the model. Defensibility comes from data advantage, model specialisation, system-level capability, experimentation velocity and governance maturity, the things a competitor cannot clone by calling the same API; experimentation velocity is the one teams underrate, because a team that runs more valid tests per quarter ends the year knowing what its rival can only guess. And before scaling, the heaviest users must not be the least profitable ones. If they are, the model has a structural flaw that tiers, limits or repricing must fix first, and more growth only makes it larger.
That last answer pushes the pricing decision into the same review as the capability map and the experiment plan, at definition time, long before the product ships. A team that cannot yet say what its heaviest-user cohort will cost to serve, whether the data can carry the idea, and which capabilities will be reused across features is still in discovery, whatever the roadmap says. If any of the three is missing, run another discovery sprint: it costs less than a launch that loses margin on every new power user.