Say “we will use AI” in a roadmap review, and you have quietly made five separate bets without naming a single one of them.
I have shipped three AI products across two companies. AdRoom, a creative-generation platform at Pixis, went from $0 to $10M ARR in five months with a 20-person team. Prism, a natural-language co-pilot I led on top of it, lifted trial-to-paid conversion by 25% and cut onboarding time by 40%. The Ask AI feature on this site is the newest one: a retrieval-augmented chatbot running on Gemini and NVIDIA NIM, answering questions about my own work from an index built out of this site’s content.
None of those three needed me to derive a gradient or tune a hyperparameter. All three needed me to know what I was buying when I said the word “AI,” because the shape of the technology sets the shape of the product: what breaks, what costs money, and what will embarrass you in production.
So that’s today’s post.
Today’s Post
Eight ideas that turn into product questions, in the order you will hit them on a real roadmap.
- Why AI behavior is probabilistic, and what that does to your test plan
- Supervised learning versus unsupervised learning
- Classification versus generation, and the temperature dial that sits between them
- Why an LLM is a next-token predictor, not a database
- Training versus inference, the cost split that shows up in your P&L
- Three levers you can pull: model, data, and fine-tuning
- Embeddings, tokens, and retrieval: how a model “knows” things, and what it costs
- Precision, recall, and why an offline win does not guarantee an online one
1. AI behavior is probabilistic, and that changes your test plan
Traditional software is deterministic. Same input, same code, same output, every time. That is why a test suite can pass or fail cleanly.
Most AI systems, especially the ones built on machine learning and large language models, are probabilistic. They learn patterns from data and generalize to new situations they were never shown directly. That is the power and the catch in one sentence: the same prompt can return two different answers, a classifier can misfire on a case that looks just like the one it got right yesterday, and “it worked in the demo” stops being a release criterion.
Prism, the co-pilot I led at Pixis, answers the same question about campaign spend a little differently each time a marketer asks it. That is not a bug in the traditional sense. It is the model doing exactly what it was trained to do.
Product implication: design for a distribution, and assume variance from day one. Build guardrails, fallbacks, and copy that does not overclaim certainty. Your job is to turn statistical behavior into a reliable experience, usually by combining the model with product mechanics: constraints, review steps, and honest failure states.
2. Supervised learning teaches by example, unsupervised learning finds structure
Supervised learning starts from labeled examples: inputs paired with the correct answer. Spam or not spam. Fraud or legitimate. The model learns the mapping from features to labels.
Unsupervised learning starts from data with no labels attached. The system looks for clusters, anomalies, or patterns that compress the information down to something usable. Customer segmentation with no predefined segments is a common example. So is anomaly detection, where “normal” is easier to describe than every possible way something can go wrong.
Product implication: supervised problems are easier to defend on a roadmap because success ties back to labels a stakeholder can argue about. Unsupervised outputs are usually exploratory, better framed to users as a suggestion than a verdict. If your team cannot write down what a good output looks like, you are promising a supervised feature you cannot yet build.
3. Classification versus generation, and the dial that sits between them
Classification sorts inputs into categories, or into probabilities across categories. Is this ticket urgent. Does this document violate a policy. Which intent does this message map to.
Generation produces something new: text, images, a code suggestion, a summary that paraphrases rather than extracts. Large language models are mostly generative. They predict the most likely next token in a sequence, which is exactly why they can draft, rewrite, and hold a conversation.
The two fail in different shapes. Classification fails in a bounded way, the wrong bucket, one tap to correct. Generation fails in an open-ended way, plausible nonsense that reads confidently and needs a real editor, not a tap, to fix.
Generative systems usually expose a temperature control. Turn it up and you get more variety and more inconsistency. Turn it down and you get steadier, sometimes more repetitive output. A brainstorming tool can run hot. A tool drafting customer-facing legal language cannot.
Product implication: match your evaluation plan to the failure shape you actually shipped, and set the temperature default from your risk posture, not from whichever number the engineer who wired up the API happened to leave in place.
4. An LLM predicts the next token, it does not look anything up
A large language model is trained to predict what comes next in text, given everything before it, at a scale large enough that the objective produces behavior that looks like reasoning, tool use, and fluency across languages.
What an LLM is not: a guaranteed fact store, a legal authority, or a stand-in for your own domain-specific check. It can sound completely confident while being wrong.
The Ask AI feature on this site does not let the model answer from memory alone. Every question first runs through an embedding step, a similarity search across a sharded index built from this site’s own content, and only the top handful of matching chunks get passed to the model alongside the question. Gemini is the default provider behind that call; NVIDIA NIM is the fallback.
Product implication: treat raw model output as a draft unless you have an independent check behind it, whether that is retrieval from a trusted source, a calculator, an API, or a human reviewer. If your product promises factual precision, your architecture matters as much as which model you picked.
5. Training happens once, inference happens on every request
Training is the expensive, offline phase where the model learns from data, often over days or weeks and a real GPU budget. Inference is the online phase, the one that runs every time a user actually hits your product.
Training shows up once, as a line item. Inference shows up on every request, as latency per call, tokens processed, and behavior under peak load. The free tier on this site’s own Gemini integration caps out at 15 requests per minute, shared across every visitor at once, which is inference cost made visible the moment more than a handful of people ask the chatbot something at the same time.
Product implication: separate “model work” from “serving work” on your roadmap. A better model you cannot afford to run at your traffic and your latency bar is not shippable. A PM who only optimizes offline accuracy can end up shipping something users never actually feel, because it is too slow or too expensive at the volume that matters.
6. Three levers: model, data, and fine-tuning
A model is the learned artifact plus the architecture behind it. Bigger models tend to be more capable and more expensive to run. Smaller models tend to be faster and cheaper, and more brittle outside the range of data they were trained on.
Training data is the bedrock. It defines what the system actually knows once it is running, not what the pitch deck says it knows. Gaps in the data become gaps in the behavior, and unrepresentative data becomes biased output, usually in ways nobody notices until a user does.
Fine-tuning adapts a base model to your own domain or tone with additional, smaller-scale training. It can tighten consistency on your vocabulary and your workflows. It does not manufacture ground truth you never had, and it does not stop the model from making things up.
This site’s Ask AI feature never fine-tunes anything. It leans entirely on the third lever instead, retrieval, feeding the model fresh, indexed content at request time rather than baking that content into weights.
Product implication: ask where your product’s differentiation actually lives. If it is generic language help, an off-the-shelf API is probably enough. If it is deep domain behavior, you likely need your own data, an evaluation harness, and possibly fine-tuning, or a hybrid built on retrieval.
7. Embeddings, tokens, and retrieval: how a model knows things, and what it costs
Embeddings are numeric vectors that place text, or images, or other inputs, into a space where distance approximates meaning. Close together in that space means semantically similar. Embeddings are what power semantic search, clustering, and retrieval-augmented generation, or RAG.
This site’s own index runs on a local embedding model, bge-small-en-v1.5, at 384 dimensions, chunking every piece of content marked ai: true into 200-word windows with 40-word overlap before it gets embedded and stored.
RAG combines a search step over trusted documents with an LLM, so the answer can cite something fresher and more specific than whatever the model happened to learn during training. It cuts down on one kind of hallucination and introduces a new set of risks: a bad chunk, a permission leak, a document that has gone stale since it was indexed.
Models process text in tokens, not words, and every extra token in a prompt or a response is more cost, more latency, and one step closer to the model’s context window limit, the cap on how much text it can attend to in a single request.
Product implication: ask how citations show up in the interface, how document freshness gets governed, and what the product says when retrieval comes back with nothing useful. A user blames the product, never the chunking algorithm. And every design choice about how much history you pass in, or whether you summarize before you send it, is a choice about your margin and your latency, not just an engineering detail.
8. Precision, recall, and why an offline win does not guarantee an online one
Accuracy is the headline number, and it can mislead the moment your classes are imbalanced. If 99% of events are benign, a model that always answers “benign” is accurate and useless in the same breath.
Precision asks: when the model predicts positive, how often is it actually right. High precision means fewer false alarms, which matters when a positive triggers something expensive, an auto-charge, an account lock, an escalation to a real person.
Recall asks: of everything that was actually positive, how many did the model catch. High recall means fewer misses, which matters when missing a case is the costly outcome, fraud, abuse, anything safety-related.
Teams also iterate fast on offline evaluation: held-out datasets, benchmarks, simulated scoring. That work is necessary and still incomplete. Production traffic behaves differently than an eval set. Incentives shift. Adversaries show up. Latency constraints force shorter prompts or smaller models, and quality erodes quietly in a way no offline number caught.
Product implication: pick the error your product can live with, then set thresholds and UX to match. Plan a bridging phase before a full launch, shadow mode running the model without touching real users, a canary release, an A/B test tied to a behavioral outcome, not just an offline score. If leadership wants to ship on offline accuracy alone, the team is accepting a risk nobody has actually named.
Takeaways
Eight concepts, one product implication each. Save the card, or reread the sections above the fold you actually shipped against last quarter.
Final Words
None of this requires you to do the math yourself. It requires you to translate a business constraint into something your ML partner can execute against: what to optimize, what to protect, and what a failure is allowed to look like. The vocabulary above is enough to ask a sharp question in a vendor pitch, and enough to catch sloppy thinking on your own team before it ships.
Next in this track: how to decide whether AI is the right tool for the problem at all, and how to keep discovery honest once the hype in the room gets loud.
Cheers, Hoshank