Then generative AI arrived and quietly vandalized the dashboard.
An AI product can have terrific engagement while giving people incorrect answers. It can achieve a wonderful conversion rate while taking 18 seconds to respond. It can delight users with beautifully written nonsense. It can even improve its benchmark score while becoming less useful in production.
That is what makes AI product management fundamentally different from shipping another CRUD app with a chatbot-shaped hat.
Traditional product metrics still matter. Revenue is still revenue. Retention is still retention. Nobody gets to tell the CFO, “Our ARR fell 30%, but coherence improved 7.2 points.”
But those metrics are now lagging indicators of something deeper. Before users retain, convert, recommend, or pay, an AI product must consistently answer three questions:
Can I trust what it tells me?
Did it actually help me?
Did it help me fast enough?
That gives us what I think of as the new PM Trinity:
Hallucination. Helpfulness. Latency.
Or, in less ML-flavored language: truth, utility, and speed.
The challenge is that these metrics are not independent. Improving one can damage another. More reasoning may improve accuracy but increase latency. Aggressive refusal policies may reduce hallucinations while destroying usefulness. Shorter answers may arrive faster but omit critical context. Longer answers may seem more impressive while creating more opportunities to invent things.
Welcome to AI product management, where every optimization comes with a small complimentary trade-off hiding behind it.
Why DAU Is No Longer Enough
Suppose you launch an AI research assistant.
Within six months:
weekly active users grow 40%;
session length increases 25%;
paid conversion rises from 4% to 6%;
users submit more prompts per session.
Celebrations occur. Slack fills with rocket emojis. Someone suggests ordering cupcakes.
But imagine that users are submitting more prompts because the first answers are unreliable. Session length is rising because people must repeatedly correct the assistant. And conversion is improving because power users desperately need the product despite its flaws.
Your dashboard says engagement.
Your users may be experiencing friction.
Generative AI introduces a peculiar measurement problem because the product behavior itself is probabilistic. Traditional software generally behaves deterministically: press the Save button and, bugs notwithstanding, you expect Save to do the same thing tomorrow.
Ask an LLM the same question twice and you may get two different answers.
That means PMs must measure not merely whether people use the product, but the quality distribution of what the product produces.
And averages are particularly dangerous.
If 99% of responses are correct but the remaining 1% includes fabricated legal citations, incorrect medical instructions, or imaginary financial regulations, an executive dashboard showing “99% quality” may be technically accurate and operationally insane.
The right AI dashboard therefore starts one level below engagement.
Metric 1: Hallucination — Measure Wrongness, Not Just Accuracy
The term “hallucination” is slightly unfortunate because it makes the behavior sound mysterious. NIST prefers the word confabulation, defining it in its Generative AI Risk Management Profile as systems generating and confidently presenting “erroneous or false content.” (NIST Publications)
That distinction matters.
A hallucination is not simply “the model failed a benchmark question.”
Consider these three answers:
A: “The answer is 47.”
B: “I’m not certain, but I believe the answer may be 47.”
C: “I don’t have enough reliable information to answer that.”
If the correct answer is 83, treating A, B and C as equivalent failures produces terrible incentives.
OpenAI made this point explicitly in its research on why language models hallucinate: many benchmarks reward guessing rather than uncertainty. Its SimpleQA example is striking. One model achieved 24% accuracy versus another model’s 22%—apparently better. Yet its error rate was 75%, compared with 26% for the more cautious model, largely because the latter abstained much more often. (OpenAI)
As the researchers put it:
“Errors are worse than abstentions.”
That should probably be taped above every AI PM’s monitor.
Stop asking, “What is our hallucination rate?”
There is rarely one meaningful hallucination rate.
Instead, break factual quality into several dimensions.
1. Claim-level factual error rate
Break responses into atomic verifiable claims:
False claims / total verifiable claims
This prevents one enormous response containing six factual mistakes from being treated exactly the same as a short response containing one.
Arena’s July 2026 Factuality in the Arena study does exactly this at enormous scale. Arena says it evaluated more than 2 million claims across roughly 170,000 battles. The marginal true-claim rate was 87% in its Text Arena and 89% in Search Arena. (Arena AI)
The important insight is not the exact percentages—they represent Arena’s particular traffic and methodology.
It is the unit of measurement.
The response is not the atomic unit of truth.
The claim is.
2. Response-level hallucination incidence
Users experience responses, not spreadsheets full of claims.
So also measure:
Responses containing ≥1 material factual error / factual responses
This catches an uncomfortable product reality: a response that is 95% correct may still be unusable if the incorrect 5% is important.
3. Severity-weighted hallucination rate
Now introduce risk.
A hallucinated restaurant opening hour and a hallucinated drug dosage are both factual errors. They are not remotely equivalent product failures.
Create severity classes, for example:
Severity
Example
Product response
S0
Cosmetic wording issue
Log
S1
Minor incorrect fact
Monitor
S2
Material error affecting task
Investigate
S3
High-stakes financial/legal/medical error
Immediate review
S4
Error capable of causing serious harm
Stop-ship / incident
Your headline metric should heavily weight S3 and S4 failures.
Otherwise your organization will eventually congratulate itself because the model became better at remembering movie release dates while occasionally inventing tax law.
4. Groundedness
For RAG systems, ask a slightly different question:
Does the answer actually follow from the retrieved sources?
This is not identical to factual accuracy.
A claim may happen to be true while still being unsupported by the documents the model was supposed to use.
Microsoft’s current AI evaluation framework therefore separates groundedness, relevance, task adherence, tool accuracy and other dimensions rather than pretending “quality” is a single number. (Microsoft Learn)
That is the right instinct.
5. Calibration and appropriate abstention
Sometimes the best AI answer is:
“I don’t know.”
Or:
“I need more information.”
Or:
“I can answer generally, but you should verify this detail.”
OpenAI’s hallucination research argues that evaluations should penalize confident errors more severely than uncertainty. (OpenAI)
So measure whether confidence matches correctness.
An AI that knows what it doesn’t know is often more valuable than one that knows slightly more but believes it knows everything.
There is a human equivalent. He is usually sitting beside you at a dinner party.
Metric 2: Helpfulness — The Danger of Beautiful Nonsense
Now we hit the harder metric.
What exactly is “helpful”?
Correctness alone certainly isn’t enough.
Imagine asking:
“Help me write a polite email declining this meeting.”
Model A produces:
“Decline meeting.”
Perfectly factual.
Spectacularly useless.
Model B writes a thoughtful two-paragraph response matching your tone and context.
No factual benchmark can distinguish those products properly.
Helpfulness therefore measures something closer to:
Did the AI successfully move the user toward the outcome they wanted?
The industry increasingly uses human preference as one proxy. Arena, for example, reported in June 2026 that its platform had accumulated more than 82 million human votes across hundreds of millions of conversations. Its evaluation model is built around people comparing AI outputs and choosing which response they prefer. (Arena AI)
That is enormously useful.
It is also insufficient.
Preferred does not necessarily mean correct
Arena itself recently demonstrated the problem.
When it compared factuality scores with human-preference scores, it found only a weak positive correlation. Its researchers observed that long, comprehensive answers may win preference votes while simultaneously introducing more factual errors. (Arena AI)
That should make every PM suspicious of a generic “AI quality score.”
Users reward:
confident language;
polished formatting;
comprehensiveness;
empathy;
decisiveness;
the appearance of expertise.
Unfortunately, confidence and expertise are merely casual acquaintances.
OpenAI discovered a related evaluation problem in HealthBench. Longer responses could earn better rubric scores simply because they had more opportunities to satisfy scoring criteria. Its August 2026 GPT-5.6 evaluation report therefore includes length-adjusted HealthBench scores. (OpenAI Deployment Safety Hub)
In other words:
Verbosity can game helpfulness metrics.
Who knew artificial intelligence would eventually discover the management-consulting business model?
Measure helpfulness in layers
A serious AI product should combine at least four signals.
Layer 1: Task completion
Did the user achieve the desired result?
Microsoft’s agent evaluation framework now explicitly measures task completion, task adherence, intent resolution and navigation efficiency. (Microsoft Learn)
For an AI coding tool:
Did the code compile?
Did tests pass?
Did the bug disappear?
For customer support:
Was the issue resolved?
Did the user reopen the ticket?
Was escalation required?
For an AI scheduling agent:
Was the correct meeting actually scheduled?
The closer your metric gets to the real-world outcome, the better.
Layer 2: Human preference
Run blind pairwise evaluations:
Candidate vs. current production model
Ask evaluators:
Which response better accomplishes the user’s goal?
Pairwise comparison is usually easier and more reliable than asking humans whether a response deserves 7.3 out of 10.
Anthropic has long used this style of evaluation and has also warned that there is an “inherent tension between helpfulness and harmlessness”. (Anthropic)
That tension generalizes.
More helpful may mean less cautious.
More concise may mean less complete.
More creative may mean less grounded.
Welcome back to the trade-off factory.
Layer 3: Rubric-based quality
Define product-specific dimensions.
A generic assistant might use:
relevance;
correctness;
completeness;
instruction following;
clarity;
tone;
conciseness.
A legal assistant might add citation validity.
A coding assistant might add executability.
A medical information product might add clinical appropriateness and uncertainty communication.
Do not copy someone else’s eval rubric simply because it looks scientific.
Your evaluation schema is effectively a coded definition of what your company believes “good” means.
Layer 4: Production behavior
Finally, observe what users actually do.
Useful signals include:
thumbs-up/down;
copy rate;
answer acceptance;
regeneration rate;
immediate reformulation rate;
undo rate;
escalation rate;
abandonment after answer;
successful downstream action.
But interpret them carefully.
A user copying an incorrect answer is not success.
It may actually be your scariest failure.
The LLM-as-Judge Trap
At production scale, humans cannot manually evaluate every response.
So teams increasingly use one model to grade another.
This is powerful, cheap and slightly circular.
Google’s Vertex AI evaluation guidance makes an important recommendation: compare model-generated judgments against human ratings and calculate whether the judge actually agrees with people. (Google Cloud Documentation)
That is the correct workflow.
Do not simply announce:
“GPT-Whatever rated our feature 4.8/5.”
Congratulations. A robot has given another robot Employee of the Month.
Instead:
Build a high-quality human-labeled dataset.
Define an explicit rubric.
Run the automated judge.
Measure agreement against humans.
Inspect disagreement cases.
Recalibrate the evaluator.
Continue human audits in production.
LLM judges are scaling infrastructure, not ground truth.
Metric 3: Latency — Faster Is Better, Except When It Isn’t
Latency seems simpler.
Surely lower = better.
Not quite.
OpenAI’s latency guidance notes that response time is strongly influenced by model choice and the amount of generated output. Its service guidance recommends examining metrics such as time to first token (TTFT), total request time and token generation velocity, and looking at percentile distributions rather than averages. (OpenAI Help Center)
That gives PMs at least four latency metrics:
Time to first token
How long before the product visibly starts responding?
This often dominates perceived responsiveness in streaming interfaces.
Time to useful information
More interesting.
Maybe token one is:
“Certainly!”
Tokens 2–64 are an enthusiastic recap of the question.
The useful answer arrives at second 8.
Congratulations on your 700-millisecond TTFT.
Time to completion
Critical when the output must finish before anything useful can happen—for example structured extraction, an agent action or executable code.
P95 and P99 latency
Never manage AI latency using averages alone.
If nine users receive an answer in 2 seconds and one waits 30 seconds, your average is 4.8 seconds.
Nobody met Mr. Average.
The tenth user met rage.
But faster can actually feel worse
Here is where AI latency becomes fascinating.
A 2026 CHI study, The Impact of Response Latency and Task Type on Human-LLM Interaction and Perception, experimentally varied time-to-first-token latency between 2, 9 and 20 seconds.
Counterintuitively, participants experiencing the 2-second response sometimes rated outputs as less thoughtful and less useful than those experiencing longer delays. Participants apparently interpreted some delay as evidence that the AI was “thinking.” (DOI)
That does not mean your roadmap should include:
Q4 Initiative: Make Product Slower.
Other research points the opposite direction. A 2025/26 chatbot study found that longer delays could lower satisfaction, although typing indicators reduced the damage. The research suggests perceived social presence changes how users interpret waiting. (Taylor & Francis Online)
And research on LLM-powered conversational agents found that latency above roughly four seconds significantly degraded experience in its particular experimental setting. (DOI)
The conclusion is not “four seconds good, five seconds bad.”
The conclusion is more useful:
Latency is contextual and psychological.
A user expects autocomplete to feel instantaneous.
They will tolerate longer waits for:
deep research;
complex code generation;
financial analysis;
image/video generation;
multi-step agents.
The correct latency SLO therefore depends on user intent, not merely infrastructure.
The Real Metric: Trusted Task Success
Now we can bring the Trinity together.
Most teams will be tempted to create something like:
AI Quality Score = 40% helpfulness + 40% factuality + 20% latency.
Please don’t.
Weighted averages allow absurd compensation.
Imagine:
99/100 helpfulness;
30/100 factuality;
100/100 latency.
A sufficiently enthusiastic spreadsheet can still produce a respectable composite number.
But a spectacularly fast wrong answer does not become good because the spinner disappeared quickly.
For consequential AI products, some dimensions should behave as constraints, not interchangeable points.
I prefer a north-star concept I call:
Trusted Task Success Rate
The percentage of eligible AI interactions in which the user’s task is successfully completed, without a material factuality failure, within an acceptable experience window.
Conceptually:
Trusted Task Success = Task Success × Trust Gate × Experience Gate
Not because the arithmetic must literally be multiplication, but because failure of a critical gate should invalidate the interaction.
For example:
An AI mortgage assistant that gives a gorgeous answer in 1.4 seconds but fabricates the interest rate has not achieved 85% success.
It has achieved zero success with excellent typography.
What an AI Product Scorecard Should Actually Look Like
Here is an illustrative production dashboard. The thresholds are examples—not universal industry standards.
Dimension
Metric
Why it matters
North Star
Trusted Task Success Rate
Captures useful, trustworthy outcomes
Hallucination
Claim factual-error rate
Measures atomic truthfulness
Hallucination
Responses with material error
Reflects user exposure
Hallucination
S3/S4 critical error rate
Protects high-stakes use
Hallucination
Appropriate abstention rate
Rewards calibrated uncertainty
Helpfulness
Task completion rate
Measures actual outcome
Helpfulness
Pairwise win rate vs. production
Detects quality improvement
Helpfulness
User acceptance/copy/action rate
Observes real behavior
Helpfulness
Reformulation/regeneration rate
Detects hidden dissatisfaction
Latency
P50 TTFT
Typical perceived responsiveness
Latency
P95 TTFT
Tail experience
Latency
P95 completion time
Full workflow performance
Latency
Abandonment during generation
Measures latency pain directly
Economics
Cost per trusted successful task
Connects AI quality to P&L
Business
Retention / conversion / revenue
Confirms quality creates value
Notice what happened.
DAU did not disappear.
Neither did conversion.
They moved downstream.
That is where they belong.
Build an Evaluation Flywheel, Not a Quarterly Benchmark
The bigger organizational mistake is treating evaluation as QA performed shortly before launch.
AI evaluation should operate continuously.
Step 1: Build the golden dataset
Collect representative prompts covering your major jobs-to-be-done.
Include:
common tasks;
difficult edge cases;
multilingual queries;
ambiguous requests;
historical failures;
adversarial prompts;
high-value customer workflows.
And keep refreshing it.
A static benchmark eventually becomes a school exam whose answers everyone has memorized.
Step 2: Slice everything
Never report only an aggregate quality score.
Segment by:
task;
customer cohort;
language;
model;
prompt length;
retrieval/no retrieval;
tool use;
risk class;
device;
geography;
conversation depth.
OpenAI’s August 2026 GPT-5.6 documentation makes a particularly important measurement warning: its challenging hallucination sets are intentionally designed around difficult and historically failure-prone cases, so the reported values should not be interpreted as production prevalence. (OpenAI Deployment Safety Hub)
That principle applies to your product too.
Your adversarial eval rate and your real-world incidence rate answer different questions.
Track both.
Step 3: Mine production failures
Your best eval set is tomorrow’s collection of yesterday’s embarrassing incidents.
Take:
thumbs-down responses;
regenerated answers;
support tickets;
escalations;
factuality complaints;
abandoned agent workflows;
human overrides.
Turn them into regression tests.
Every serious production failure should leave behind an eval.
That is how the product gradually develops institutional memory.
Step 4: Compare releases pairwise
Before shipping a prompt, model or retrieval change, compare the candidate against production.
Do not merely ask:
“Did candidate score 84?”
Ask:
“Does candidate beat production on the tasks our users actually perform—and where does it regress?”
Pairwise comparison makes changes legible.
Step 5: Validate offline with online behavior
Offline evals tell you whether the system should be better.
Experiments tell you whether users agree.
A new model may score higher offline but:
respond more slowly;
sound more robotic;
refuse too often;
generate unnecessarily long answers;
increase costs;
reduce successful workflow completion.
AI PMs must bridge both worlds.
Benchmark optimization without product telemetry is just competitive Pokémon for machine-learning teams.
Fun, perhaps. Not a strategy.
The Trinity Has Two Important Exceptions: Safety and Cost
At this point you may reasonably object:
“What about safety?”
Or:
“What about cost?”
Correct.
The Trinity is not intended to represent every metric in an AI business.
It represents the three central dimensions of user-perceived AI performance.
Safety is better treated as a non-negotiable guardrail.
Cost belongs in the economic layer.
For safety-critical categories, you should establish hard release thresholds independently of helpfulness. Anthropic’s observation about the tension between helpfulness and harmlessness matters here: a system that refuses everything may be extremely safe and completely worthless. (Anthropic)
Meanwhile cost should evolve from:
cost per request
toward:
Cost per trusted successful task
Suppose Model A costs $0.02 per interaction and completes 40% of tasks correctly.
Model B costs $0.05 and completes 90%.
Model A looks cheaper on the infrastructure dashboard.
Model B may be dramatically cheaper per successful outcome.
This is where AI product management finally reconnects with economics.
Tokens are not value.
Completed work is value.
Trust Is the Compounding Metric
There is one final reason to care about this framework.
AI quality failures compound.
A conventional UI bug often produces an obvious failure. The button does not work. The user knows it does not work.
Hallucinations are more dangerous because the interface may continue behaving beautifully.
The sentence is grammatical.
The formatting is pristine.
The citations look plausible.
The error may be invisible.
That creates a peculiar form of product debt: trust debt.
A large 2025 University of Melbourne/KPMG survey covering more than 48,000 people in 47 countries found that 66% regularly used AI, yet only 46% were willing to trust AI systems. Even more concerning, 66% reported relying on AI output without evaluating its accuracy, while 56% reported mistakes in their work associated with AI use. The global trust study puts numbers around the contradiction at the heart of the market: adoption can rise faster than trust. (KPMG)
Professor Nicole Gillespie, who led the research, put it succinctly:
“The public’s trust of AI technologies… is central to sustained acceptance and adoption.”
That is why trust should not be treated as branding.
It is product infrastructure.
The PM’s Job Has Changed
The old product-management question was often:
“Will users use this?”
The AI-era question is harder:
“Will users successfully use this, receive a reliable result, understand when the system is uncertain, and get that result quickly enough to come back?”
That changes roadmap conversations.
Instead of:
“Should we upgrade to Model X?”
ask:
“Which model maximizes trusted task success for this workload at acceptable latency and cost?”
Instead of:
“Prompt V7 scored 4% higher.”
ask:
“Which user segments improved, which failure modes regressed, and did production behavior confirm the eval?”
Instead of:
“Hallucinations dropped.”
ask:
“Which hallucinations dropped? In what tasks? At what severity? And did the model simply learn to refuse more often?”
Instead of:
“Latency is down 20%.”
ask:
“Did users notice, and did the faster configuration compromise answer quality?”
That is the conceptual shift.
AI product management is not about choosing the smartest model.
It is about engineering the best system-level trade-off among truth, usefulness and speed.
The New PM Trinity
If I were running an AI product review tomorrow, I would want three charts before looking at DAU.
1. Hallucination
How often are we confidently wrong—and how serious are those errors?
Track claims, material failures, severity, groundedness and appropriate abstention.
2. Helpfulness
Did the user actually accomplish what they came to do?
Track task success, pairwise preference, rubric performance and behavioral evidence.
3. Latency
How long does useful value take to appear?
Track TTFT, time-to-useful-information, completion time, tail latency and abandonment.
Then connect all three with:
Trusted Task Success
Because the ideal AI interaction is not merely accurate.
It is not merely helpful.
It is not merely fast.
It is helpful enough to matter, truthful enough to trust, and fast enough that the user doesn’t open another tab while waiting.
That is the new product-quality bar.
DAU can come afterward.
And yes, Finance may still ask about gross margin.
Some traditions survive every technological revolution.