AI features PM questions show up in every shipping AI feature review — here are the 10 every product manager asks before deployment. 10 is a useful number here because most AI launches fail on the same handful of product questions, not on model access. PMs still have to decide whether to build or buy, how to measure quality, what latency users will tolerate, how to disclose uncertainty, and what happens when the model is wrong, slow, or unavailable. This Q&A is built for that moment: the cross-functional meeting where product, engineering, design, legal, and support need plain answers before an AI feature ships.
1) Should we build the AI stack ourselves or buy it?
Buy unless your product advantage truly depends on owning the full stack. Most teams do not need to train frontier models, run custom inference infrastructure, or build safety systems from scratch when commercial APIs and managed cloud services already cover those layers. OpenAI, Anthropic, Google Cloud, AWS, and Microsoft all provide model access plus tooling for evaluation, observability, and deployment, which usually gets a PM to market faster than a ground-up build.
Build selectively where differentiation is real. That often means your orchestration logic, retrieval layer, domain-specific prompts, evaluation datasets, policy rules, and user experience rather than the base model itself. Anthropic’s API docs, OpenAI’s API platform, and managed services such as Vertex AI and Amazon Bedrock make that modular approach practical.
The PM question is less ‘can we build it’ and more ‘what do we gain by owning this layer.’ If the answer is speed, reliability, and lower operational burden, buying is usually right. If the answer is durable product differentiation or regulatory control over data handling and deployment, then owning more of the stack can make sense.
📌 PM shortcut. If the feature is a workflow enhancer rather than your core moat, buy the model layer and invest your team in UX, evaluation, and guardrails.
2) How do we measure quality when AI output is probabilistic?
Stop looking for a single accuracy number. AI features usually need a basket of metrics: task success, factuality, policy compliance, user satisfaction, and refusal behavior where the model should decline. OpenAI’s evaluation guidance and Anthropic’s prompting and safety documentation both point toward structured evals rather than intuition-driven reviews.
A PM should define quality at the task level before launch. For summarization, that may mean coverage and faithfulness; for support drafting, it may mean policy adherence and edit rate; for search answers, it may mean citation quality and answer usefulness. Google Cloud’s Vertex AI evaluation tooling and Microsoft’s Azure AI guidance both reflect this idea that quality has to map to the actual user job.
You also need human review, especially early. Automated evals are useful for regression testing and scale, but they miss tone, edge cases, and subtle trust failures. The practical rule is simple: if a bad answer creates user harm, support burden, or brand damage, put humans in the loop long enough to learn what your automated metrics are missing.
| Feature type | Primary quality metric | Secondary metric | Failure to watch |
|---|---|---|---|
| Summaries | Faithfulness | Coverage | Invented details |
| Support drafts | Policy compliance | Edit rate | Unsafe or off-policy advice |
| Search answers | Answer usefulness | Citation quality | Confidently wrong responses |
| Writing assistants | User acceptance rate | Tone match | Off-brand language |
3) What latency budget should we design around?
Your latency budget should start with user patience, not model marketing. A user asking for autocomplete or inline assistance expects near-immediate feedback, while a user requesting a long-form report will tolerate more delay if progress is visible. That distinction matters because model choice, context length, retrieval steps, and tool calls all add time.
PMs should force one decision early: is this a real-time interaction or a background job. If it is real time, keep the workflow narrow, stream output where possible, and avoid chaining too many model calls. OpenAI and Anthropic both support streaming responses, and cloud platforms such as Azure AI, Vertex AI, and Bedrock are designed to fit into service architectures where response-time budgets matter.
Do not optimize average latency alone. Tail latency is what users remember, and the slowest 5 percent of requests often determine whether a feature feels broken. The right PM move is to set a target for median and a hard ceiling for the worst acceptable experience, then design a fallback when requests exceed it.
⚠️ Common mistake. Teams often approve an AI feature on demo latency, then discover production latency spikes once retrieval, moderation, logging, and tool calls are added.
“Users forgive delay when they understand the system is working. They do not forgive silence.”
Editorial guidance for AI product UX
4) How should we handle hallucinations in a user-facing product?
Assume hallucinations will happen and design the product accordingly. The PM job is not to promise perfection; it is to reduce the chance of wrong answers and limit the blast radius when they occur. Retrieval from trusted sources, constrained generation, citations where appropriate, and scoped tasks all help, but none remove the problem entirely.
OpenAI, Anthropic, and Microsoft all publish guidance that model outputs can be incorrect or incomplete, especially in open-ended tasks. That means user-facing AI should avoid pretending to know more than it does. In practice, that often means showing source links, labeling generated content, and routing high-risk cases to deterministic systems or human review.
The strongest PM stance is to separate low-risk convenience from high-risk authority. Drafting a first pass of copy is one thing; giving legal, medical, or financial advice is another. If the feature touches decisions with material consequences, the product should either narrow the scope dramatically or require a human checkpoint before action.
5) What does cost per user actually look like for an AI feature?
Cost per user is usually a usage question before it is a pricing question. Most commercial model providers price around tokens, requests, or compute consumption, so the real PM work is estimating how often users invoke the feature, how long prompts and outputs are, and whether retrieval or tool use adds extra infrastructure cost. OpenAI, Anthropic, and cloud marketplaces publish pricing pages, but those numbers only become meaningful when mapped to your product behavior.
You should model at least three scenarios: light, typical, and heavy usage. A feature that looks affordable at launch can become expensive if users discover a high-frequency workflow, if context windows expand, or if the team upgrades to a more capable model to fix quality complaints. AWS and Google Cloud both make it straightforward to meter service usage, but they do not decide your product economics for you.
PMs should also treat cost as a design variable. Shorter prompts, smaller models for simpler tasks, caching, rate limits, and asynchronous workflows can all reduce spend without hurting the user experience. If the unit economics only work when usage stays low, that is not a healthy AI feature. It is a hidden liability.
6) How do we communicate uncertainty without making the feature feel weak?
The trick is to communicate uncertainty in the interface, not in apologetic marketing copy. Users do not need a lecture on model limitations every time they click a button. They need cues that help them judge confidence, inspect sources, and understand whether they should verify the output before acting.
That can mean labels such as ‘generated draft,’ visible citations, confidence language that is tied to evidence, or UI patterns that ask the user to confirm before high-impact actions. Microsoft’s responsible AI materials and Google Cloud’s generative AI guidance both emphasize transparency and user control rather than overclaiming certainty. Good PMs make that a product habit, not a legal afterthought.
What you should not do is fake confidence. A polished answer that sounds definitive but lacks grounding is more dangerous than a modest answer that shows its work. Trust grows when the product is candid about what it knows, what it inferred, and what still needs human judgment.
7) What is the fallback if the model fails, times out, or gets blocked?
Every AI feature needs a non-AI failure path before launch. That could be a cached answer, a traditional search result, a rules-based workflow, a saved draft, or a simple message that preserves user progress and invites retry. If the only experience is ‘the model failed,’ the PM has not shipped a product. They have shipped a dependency.
This matters because failures come from many places: provider outages, rate limits, safety filters, malformed prompts, retrieval errors, and internal networking issues. Cloud providers publish reliability and architecture guidance, but your users will still blame your product, not the model vendor. The fallback should therefore be designed as part of the core journey, not as an edge-case banner.
The best fallback is one that still helps the user complete the job. If your AI writing assistant fails, preserve the user’s input and offer templates. If your answer engine fails, return ranked documents. If your support copilot fails, hand off to a human queue with context attached.
📌 Launch rule. If a PM cannot explain the fallback in one sentence, the feature is not ready for general availability.
8) How do we A/B test an AI feature when outputs vary from one run to the next?
You can still run experiments, but you need to test outcomes, not just outputs. Traditional A/B testing assumes deterministic behavior, while AI systems introduce variance even under similar prompts. That means the PM should focus on user-level metrics such as task completion, retention, acceptance rate, edit rate, escalation rate, and support contacts rather than trying to compare every generated sentence.
It also helps to freeze more variables than you would in a normal experiment. Keep the prompt template, model version, retrieval policy, and UI treatment stable during the test window where possible. Providers update models and platform behavior over time, so documenting the exact setup matters if you want the experiment to mean anything later.
Run offline evals and online experiments together. Offline evals catch regressions before users see them, while online tests reveal whether the feature actually improves behavior in the product. If the AI output looks impressive but users do not complete tasks faster or with fewer errors, the PM should treat that as a failed experiment.
9) What telemetry do we need before we can responsibly scale?
At minimum, you need telemetry for usage, latency, cost, quality signals, safety events, and failures. Usage tells you whether the feature matters, latency tells you whether it feels usable, cost tells you whether it scales economically, and quality signals tell you whether users are accepting or correcting the output. Without all four, a PM is flying blind.
You should also log enough context to debug issues without collecting more sensitive data than necessary. That usually means request metadata, model version, prompt template version, retrieval status, tool invocation status, moderation outcomes, and user feedback events. Microsoft, Google Cloud, and AWS all provide observability tooling around AI services, but the PM still has to define what the team will review every week.
The most valuable telemetry is often the simplest: thumbs up or down, copy rate, edit distance, retry rate, abandonment, and escalation to human support. Those signals reveal whether the feature is genuinely useful or merely novel. If you cannot tell why users reject outputs, you cannot improve the product in a disciplined way.
10) How do we keep the model from going off-brand or off-policy?
You will not solve this with one perfect system prompt. Brand and policy control come from layers: prompt instructions, curated examples, retrieval from approved sources, output filters, UI constraints, and human review for sensitive workflows. Anthropic, OpenAI, and Microsoft all document methods for steering model behavior, but none suggest that prompting alone is enough for high-stakes use cases.
PMs should define what ‘on-brand’ means in operational terms. That could include banned claims, required disclaimers, approved vocabulary, escalation triggers, and examples of acceptable tone. Once those rules exist, the team can test them in evals instead of arguing about taste after screenshots hit social media.
The strongest safeguard is to narrow the task. A model asked to ‘write anything in our voice’ will drift more than a model asked to ‘rewrite this support response using approved policy language and a friendly tone.’ Scope is a product decision, and it is one of the most effective safety controls a PM has.
Frequently asked questions
Start with the user outcome the feature is supposed to improve, then map quality metrics to that job. For example, a drafting tool may need acceptance rate and edit rate, while an answer engine may need usefulness and citation quality. OpenAI’s platform guidance on evaluations is a good starting point for structuring that work: https://platform.openai.com/docs/guides/evals.
Yes, especially for user-facing features that can fail because of latency, provider outages, safety blocks, or retrieval errors. A fallback can be a deterministic workflow, search results, saved progress, or a human handoff, but it should exist before launch. AWS’s guidance on building with managed AI services is useful context for dependency planning: https://aws.amazon.com/bedrock/.
Use narrower tasks, retrieval from trusted sources, clear instructions, and product UX that exposes sources or asks for confirmation before high-impact actions. That approach aligns with guidance from providers such as Anthropic and Microsoft, both of which stress scoped use cases and transparency. See https://docs.anthropic.com/ and https://www.microsoft.com/en-us/ai/responsible-ai.
Primary sources
- OpenAI API platform — OpenAI
- OpenAI platform docs — OpenAI
- OpenAI evals guide — OpenAI
- Anthropic documentation — Anthropic
- Google Cloud Vertex AI — Google Cloud
- Amazon Bedrock — AWS
- Microsoft Responsible AI — Microsoft
- Azure AI Foundry documentation — Microsoft
Last updated: May 21, 2026. Related: Agent Infrastructure.
