If you're a Product Manager working on AI products, you don't need to become an ML researcher.
\nBut you do need to understand what happens inside an LLM.
\nBecause sooner or later, you'll have to answer questions like:
\nYou don't need to understand every mathematical detail behind a Transformer.
\nYou need a good mental model.
\nThat's what this article is about.
\nWhat exactly is an LLM?
\nLLM stands for Large Language Model.
\nAt a high level, an LLM is a machine-learning model trained on large amounts of data to learn patterns in language and generate outputs based on its input.
\nThe simplest mental model is:
\n«An LLM takes tokens as input and predicts what token should come next.»
\nFor example:
\nThe capital of France is
\nThe model might assign probabilities to possible next tokens:
\nParis 92%
\nLondon 2%
\nBerlin 1%
\nMadrid 1%
\n...
\nIt selects a token, adds it to the sequence, and predicts the next token.
\nThis process continues until the model generates the response.
\nSo when an LLM writes a paragraph, it isn't necessarily creating the entire paragraph in one shot.
\nIt's generating a sequence of tokens.
\nThat simple idea explains a surprisingly large part of how LLMs work.
\nThe Big Picture
\nBefore diving into the details, here's the entire process:
\n USER\n |\n v\n "Explain RAG"\n |\n v\n Tokenization\n |\n v\n Tokens\n |\n v\n Embeddings\n |\n v\n +----------------+\n | Transformer |\n | |\n | Self-Attention |\n | | |\n | MLP |\n | | |\n | Many Layers |\n +-------+--------+\n |\n v\n Logits\n |\n v\n Probability\n Distribution\n |\n v\n Token Selection\n |\n v\n Next Token\n |\n +------+\n |\n v\n Repeat Generation\n |\n v\n RESPONSENow let's break this down.
\nWhen you type:
\nProduct management is interesting.
\nthe model doesn't directly receive those words as normal human-readable text.
\nThe text is first converted into tokens.
\nA tokenizer might represent it conceptually as:
\n["Product", " management", " is", " interesting", "."]
\nBut tokens aren't necessarily complete words.
\nA word can be split into multiple tokens.
\nFor example:
\ninternationalization
\ncould be represented as several smaller pieces.
\nThe exact result depends on the tokenizer and model.
\nThis is why:
\n«A token is not necessarily equal to a word.»
\nAnd this matters a lot in real products.
\nWhy should a Product Manager care about tokens?
\nBecause tokens affect:
\nImagine your application handles:
\n10,000 users
\n×
\n2,000 input tokens
\n×
\n10 requests per day
\nThat's:
\n200,000,000 input tokens/day
\nSuddenly, tokenization isn't just an ML concept.
\nIt's a product economics problem.
\nNeural networks work with numbers.
\nSo the tokens need to be converted into numerical representations.
\nThis is where embeddings come in.
\nConceptually:
\n"product"
\n|\n\nv[0.21, -0.73, 0.44, 0.18, ...]
\nThe actual vectors are much larger than this example.
\nYou can think of an embedding as a numerical representation that allows the model to work with relationships between pieces of information.
\nFor example, concepts that occur in similar contexts can have useful relationships in the model's representation space.
\n vector space\n apple\n *\n /\n /\n * fruit\n car\n \\\n *\n vehicleThis is only an intuition.
\nReal embedding spaces are high-dimensional and considerably more complicated.
\nThe important idea is:
\n«Embeddings convert discrete information into numerical representations that neural networks can process.»
\nNow we reach the most important part.
\nModern LLMs are largely built around the Transformer architecture.
\nThe Transformer architecture was introduced in the 2017 research paper:
\n"Attention Is All You Need" (https://arxiv.org/abs/1706.03762).
\nThe paper introduced an architecture based heavily on attention mechanisms rather than the recurrent architectures commonly used in earlier sequence models.
\nToday, Transformer-based architectures are fundamental to modern generative AI.
\nBut remember:
\n«Transformer ≠ LLM»
\nA Transformer is an architecture.
\nAn LLM is a language model that can be built using a Transformer-based architecture.
\nA simplified Transformer block looks something like this:
\n Input\n |\n v\n +------------------+\n | Self-Attention |\n +------------------+\n |\n v\n Residual Connection\n |\n v\n Normalization\n |\n v\n +------------------+\n | Feed Forward |\n | Network (MLP) |\n +------------------+\n |\n v\n Residual Connection\n |\n v\n Normalization\n |\n v\n OutputTwo components are especially important:
\nLet's start with attention.
\nConsider this sentence:
\n«"The developer put the laptop on the table because it was broken."»
\nWhat does "it" refer to?
\nA language model needs to understand relationships between different parts of the sequence.
\nSelf-attention allows the model to determine which tokens are relevant to one another.
\nInstead of processing every token completely independently, the model can calculate relationships between tokens.
\nA simplified mental model is:
\n"The developer put the laptop on the table because it was broken."
\n ^\n |\n What does "it"\n refer to?\n |\n +------------------+----------------+\n | |\n laptop tableThe model uses attention mechanisms to build contextual representations.
\nYou'll frequently hear:
\nor:
\nQ = Query
\nK = Key
\nV = Value
\nThe simplified attention equation is:
\nsoftmax(QKᵀ / √dₖ)V
\nAs a Product Manager, you don't need to derive this equation.
\nThe intuition is more useful:
\nQuery
\n|
\n+----> Compare with Keys
\n |\n\n v\n\n Attention Scores\n\n |\n\n v\n\n Weighted Values\n\n |\n\n v\n\n New RepresentationYou can think of it as the model asking:
\n«"Which other pieces of the context are relevant to this token?"»
\nImagine you're building an AI customer-support assistant.
\nA customer says:
\n«"I bought the phone two weeks ago. The battery is already failing. Can I get a replacement?"»
\nThe model needs to connect several pieces of information:
\nphone
\n|
\n+---- purchased two weeks ago
\n|
\n+---- battery failing
\n|
\n+---- asking about replacement
\nAttention helps the model build contextual relationships between these tokens.
\nThis is one of the reasons Transformer-based models are so powerful for language tasks.
\nTransformers generally don't rely on a single attention mechanism.
\nThey use multiple attention heads.
\nConceptually:
\n Input\n |\n +-----------+-----------+\n | | |\n v v v\n Head 1 Head 2 Head 3\n | | |\n v v v\n Pattern A Pattern B Pattern C\n | | |\n +-----------+-----------+\n |\n v\n Combined\n |\n v\n OutputDifferent heads can learn different relationships during training.
\nWe shouldn't think of them as manually assigned roles.
\nThe model learns useful representations from the training process.
\nConsider:
\nDog bites man.
\nand:
\nMan bites dog.
\nSame words.
\nVery different meaning.
\nSo the model needs information about the position/order of tokens.
\nTransformer architectures therefore use mechanisms for representing positional information.
\nYou may encounter terms such as:
\nThe exact technique depends on the model architecture.
\nThe key idea is simple:
\n«The model needs to know where tokens occur in the sequence.»
\nAfter attention, Transformer blocks also contain feed-forward neural networks, often called MLPs.
\nA simplified view:
\nToken Representation
\n |\n\n vLinear Layer
\n |\n\n v\n\nActivation\n\n |\n\n vLinear Layer
\n |\n\n v\n\n OutputA useful mental model is:
\n«Attention allows tokens to exchange contextual information, while the feed-forward network performs additional nonlinear transformations on those representations.»
\nThese operations are repeated across many layers.
\nOne Transformer block isn't the whole model.
\nLLMs contain many layers.
\nConceptually:
\nInput Embeddings
\n |\n\n v+----------------+
\n| Transformer 1 |
\n+----------------+
\n |\n\n v+----------------+
\n| Transformer 2 |
\n+----------------+
\n |\n\n v+----------------+
\n| Transformer 3 |
\n+----------------+
\n |\n\n v\n\n ...\n\n |\n\n v+----------------+
\n| Transformer N |
\n+----------------+
\n |\n\n vFinal Representation
\nEach layer transforms the representation further.
\nThis repeated computation is one reason large language models require significant computational resources.
\nYou've probably heard statements like:
\n«"This is a 7B model."»
\nor:
\n«"This model has 70B parameters."»
\nThe "B" means billion.
\nParameters are learned numerical values inside the model.
\nVery roughly:
\nModel
\n|
\n+-- Weights
\n|
\n+-- Biases
\n|
\n+-- Other learned parameters
\nDuring training, these parameters are adjusted so the model becomes better at its objective.
\nWhy does model size matter?
\nLarger models generally require more resources.
\nThat can affect:
\nBut:
\n«Bigger does not automatically mean better for your product.»
\nA smaller model might be preferable when your application needs:
\nThis is an important AI PM trade-off.
\nNow we get to training.
\nA simplified training pipeline looks like:
\nLarge Dataset
\n |\n\n vData Processing
\n |\n\n vTokenization
\n |\n\n vTraining Examples
\n |\n\n vTransformer Model
\n |\n\n vPrediction
\n |\n\n vCalculate Loss
\n |\n\n vBackpropagation
\n |\n\n vUpdate Parameters
\n |\n\n +----------------+\n\n |\n\n v\n\n RepeatThis process happens an enormous number of times.
\nOne of the fundamental training objectives for autoregressive language models is next-token prediction.
\nConsider:
\nThe product manager wrote a
\nThe model tries to predict the next token.
\nMaybe:
\nPRD 0.50
\ndocument 0.20
\nstrategy 0.10
\n...
\nThe actual training data tells the model what the target token should be.
\nThe model's prediction is compared with the target.
\nThe resulting error contributes to the training loss.
\nThe parameters are then adjusted.
\nThis happens repeatedly across massive amounts of training data.
\nLoss is a numerical measure of how far the model's prediction was from the desired target.
\nSimplified:
\nPrediction
\n|\n\nvCompare with target
\n|\n\nvLoss
\n|\n\nvCalculate gradients
\n|\n\nvUpdate parameters
\nFor language models, cross-entropy loss is commonly used for next-token prediction.
\nYou don't need to memorize the mathematical derivation to understand the product implications.
\nThe important idea is:
\n«Training uses errors to update the model's parameters.»
\nBackpropagation calculates how the model's parameters contributed to the error.
\nA simplified mental model:
\nPrediction
\n|\n\nvError
\n|\n\nvGradients
\n|\n\nvParameter Updates
\n|\n\nvBetter Future Predictions
\nModern model training also uses optimization algorithms to determine how those parameters should be updated.
\nAgain, the important thing for a PM is understanding the role of the process rather than memorizing every equation.
\nA pretrained model isn't automatically a great conversational assistant.
\nModern AI systems can involve additional stages such as:
\nLarge-Scale Training
\n |\n\n v\n\nPretraining\n\n |\n\n vBase Model
\n |\n\n vInstruction Tuning
\n |\n\n vAlignment / Preference Optimization
\n |\n\n vSafety & Evaluation
\n |\n\n vUseful Model
\nThe exact pipeline differs between model providers and model families.
\nAdditional techniques may include:
\nThis distinction is extremely important.
\nTraining
\nTraining means:
\n«Adjusting the model's parameters using data.»
\nData
\n↓
\nPrediction
\n↓
\nLoss
\n↓
\nBackpropagation
\n↓
\nParameter Update
\nInference
\nInference means:
\n«Using the trained model to generate an output.»
\nPrompt
\n↓
\nModel
\n↓
\nPrediction
\n↓
\nOutput
\nThink of it simply as:
\nTRAINING
\n"Learn"
\n↓INFERENCE
\n"Use what you learned"
\nFor most AI Product Managers, inference will be much more relevant to day-to-day product decisions than training a foundation model from scratch.
\nLet's say you ask:
\n«"Explain product-market fit in simple terms."»
\nA simplified inference flow is:
\nUser
\n|
\nv
\nApplication
\n|
\n+-- System Instructions
\n+-- Conversation History
\n+-- User Prompt
\n|
\nv
\nTokenizer
\n|
\nv
\nTokens
\n|
\nv
\nEmbeddings
\n|
\nv
\nTransformer Layers
\n|
\nv
\nLogits
\n|
\nv
\nProbability Distribution
\n|
\nv
\nToken Selection
\n|
\nv
\nNext Token
\n|
\n+------> Repeat
\n|
\nv
\nFinal Response
\nThis is the basic lifecycle of an LLM request.
\nAt the end of the model's computation, it produces scores called logits for possible next tokens.
\nImagine:
\nToken Score
\nParis 8.2
\nLondon 3.1
\nBerlin 2.7
\nMadrid 2.2
\n...
\nThese raw scores can be transformed into probabilities using softmax.
\nLogits
\n|
\nv
\nSoftmax
\n|
\nv
\nProbabilities
\n|
\nv
\nToken Selection
\nThe model then chooses a token according to the decoding strategy.
\nTemperature is one of the generation settings you'll encounter when working with LLM APIs.
\nGenerally:
\nConceptually:
\nLower temperature
\nA → 90%
\nB → 5%
\nC → 2%
\nD → 1%
\nversus:
\nHigher temperature
\nA → 45%
\nB → 25%
\nC → 20%
\nD → 10%
\nThese numbers are illustrative, not actual model behavior.
\nProduct implication
\nFor:
\nInvoice extraction
\nyou probably want controlled and consistent outputs.
\nFor:
\nCreative writing
\nyou may want more variation.
\nSo generation parameters can directly affect the product experience.
\nSuppose the model generates:
\nThe product is successful because...
\nConceptually:
\nThe
\n↓
\nThe product
\n↓
\nThe product is
\n↓
\nThe product is successful
\n↓
\nThe product is successful because
\n↓
\n...
\nEach generated token becomes part of the context for the next prediction.
\nThis is also why LLM applications can stream responses.
\nInstead of waiting for:
\n[4 seconds]
\n↓
\nEntire response
\nthe application can display:
\nThe...
\nThe product...
\nThe product is...
\nThe product is successful...
\nProduct implication
\nStreaming can make an application feel much faster, even if total generation time doesn't change.
\nThat's a UX decision, not merely an engineering optimization.
\nYou've probably seen:
\n«"This model supports a 128K context window."»
\nThe context window represents how much context the model can process within a particular interaction, according to that model's limits.
\nThat context may include:
\nSystem instructions
\n+
\nConversation history
\n+
\nUser prompt
\n+
\nRetrieved documents
\n+
\nTool results
\n+
\nGenerated output
\nConceptually:
\n+--------------------------------------+
\n| CONTEXT WINDOW |
\n| |
\n| System Instructions |
\n| Conversation History |
\n| User Input |
\n| Retrieved Information |
\n| Tool Results |
\n| Model Output |
\n| |
\n+--------------------------------------+
\nWhy should a PM care about context windows?
\nBecause context affects:
\nAnd here's an important distinction:
\n«Being able to fit information into the context window doesn't mean the model will use all of it effectively.»
\nMore context can also mean:
\nSo:
\n«"Can we fit the document?"»
\nand
\n«"Can the model effectively use the document?"»
\nare two different questions.
\nDuring autoregressive generation, the model repeatedly needs information from previous tokens.
\nRecomputing everything from scratch would be inefficient.
\nInference systems therefore commonly use a Key-Value cache, or KV cache, to reuse attention-related information from previously processed tokens.
\nSimplified:
\nPrevious Tokens
\n |\n\n vKey / Value Computation
\n |\n\n vKV Cache
\n |\n\n vNew Token
\n |\n\n vReuse Cached Information
\nKV caching matters for:
\nFor a technical PM working on AI infrastructure, this is an especially useful concept to understand.
\nHere's a common misconception:
\n«"The LLM searches the internet every time I ask a question."»
\nA basic LLM doesn't necessarily do that.
\nIts parameters contain patterns learned during training.
\nThat learned information isn't equivalent to a traditional database.
\nThis distinction becomes very important when building enterprise AI applications.
\nImagine your company has:
\nProduct Documentation
\nPricing
\nEmployee Handbook
\nCustomer Policies
\nInternal Wiki
\nSupport Articles
\nYou want your AI assistant to answer questions about them.
\nSimply having trained the foundation model on general internet data doesn't mean it knows your company's latest internal information.
\nThis is where RAG becomes useful.
\nRAG stands for:
\nRetrieval-Augmented Generation.
\nThe basic idea:
\n«Retrieve relevant information and give it to the LLM as context before generating the answer.»
\nA simplified architecture:
\n User Question\n |\n v\n Query Processing\n |\n v\n Retrieval Layer\n |\n +--------+--------+\n | |\n v v\n Vector Search Keyword Search\n | |\n +--------+--------+\n |\n v\n Relevant Docs\n |\n v\n Context Builder\n |\n v\n LLM\n |\n v\n AnswerSuppose a customer asks:
\n«"What's our current refund policy?"»
\nYour base model may not know your company's latest policy.
\nInstead:
\nQuestion
\n|
\nv
\nSearch company knowledge
\n|
\nv
\nRetrieve relevant policy
\n|
\nv
\nAdd policy to prompt
\n|
\nv
\nLLM
\n|
\nv
\nAnswer
\nThe model doesn't permanently learn the document.
\nThe application supplies the information at inference time.
\nProduction RAG systems can be more sophisticated:
\n User\n |\n v\n +---------------+\n | Query Process |\n +-------+-------+\n |\n v\n +---------------+\n | Retrieval |\n +-------+-------+\n |\n +------------+------------+\n | |\n v v\n Vector Search Keyword Search\n | |\n +------------+------------+\n |\n v\n +---------------+\n | Reranker |\n +-------+-------+\n |\n v\n Relevant Context\n |\n v\n +---------------+\n | LLM |\n +-------+-------+\n |\n v\n AnswerThis creates several PM questions:
\nThese aren't purely engineering questions.
\nThey're product decisions.
\nThis is one of the most common questions in AI product development.
\nRAG
\nProvide external information at runtime.
\nQuestion
\n↓
\nRetrieve Information
\n↓
\nLLM
\n↓
\nAnswer
\nFine-tuning
\nFurther train the model to specialize its behavior.
\nBase Model
\n↓
\nSpecialized Dataset
\n↓
\nFine-Tuning
\n↓
\nSpecialized Model
\nA simplified rule of thumb:
\nRequirement| Often worth considering
\nFrequently changing information| RAG
\nCompany knowledge| RAG
\nDocument-grounded answers| RAG
\nNeed citations| RAG
\nSpecific response style| Fine-tuning may help
\nSpecialized task behavior| Fine-tuning may help
\nConsistent formatting| Fine-tuning may help
\nIn some systems, you may use both.
\nThe correct choice depends on the problem you're solving.
\nThis is one of the most important concepts for AI PMs.
\nAn LLM isn't inherently a fact-checking database.
\nIt's generating outputs based on learned patterns and the information available to it.
\nTherefore, it can generate something that sounds extremely convincing but is incorrect.
\nFor example:
\nUser:
\nWho wrote the fictional book XYZ?
\nLLM:
\nXYZ was written by John Smith in 1987.
\nThe answer sounds plausible.
\nBut it could be completely invented.
\nThis behavior is commonly called a hallucination.
\nThere isn't one magic solution.
\nProduction systems can combine:
\nBetter instructions
\nClearly define what the model should and shouldn't do.
\nRAG
\nGive the model relevant source material.
\nGrounding
\nRequire responses to rely on provided information.
\nStructured outputs
\nConstrain the expected response format.
\nTool calling
\nLet the model retrieve information from reliable systems.
\nGuardrails
\nValidate or block problematic outputs.
\nEvaluations
\nContinuously test the system against representative examples.
\nHuman review
\nFor high-risk workflows, keep a human in the loop.
\nAn LLM by itself doesn't automatically have access to your:
\nBut your application can provide tools.
\nFor example:
\n User\n |\n v\n LLM\n |\n +------------+------------+\n | | |\n v v v\n Search DB Check Order Create Ticket\n | | |\n +------------+------------+\n |\n v\n LLM\n |\n v\n ResponseThe model can determine that a tool is needed.
\nThe application executes it.
\nThe tool result is returned.
\nThe model then uses that result to continue the interaction.
\nThis is one of the foundations of modern AI agents.
\nAn LLM and an AI agent aren't the same thing.
\nA basic LLM application:
\nUser
\n|
\nv
\nLLM
\n|
\nv
\nAnswer
\nAn agentic system:
\nUser
\n|
\nv
\nAgent
\n|
\nv
\nLLM
\n|
\nv
\nDecide what to do
\n|
\nv
\nTool
\n|
\nv
\nObserve Result
\n|
\nv
\nLLM
\n|
\nv
\nDecide Next Step
\n|
\nv
\nTool
\n|
\nv
\n...
\n|
\nv
\nFinal Answer
\nThe LLM provides much of the language and reasoning capability.
\nThe surrounding application provides:
\nThis distinction is important when designing AI products.
\nThis is probably the most important architecture to understand as an AI PM.
\n USER\n |\n v\n +----------------+\n | Frontend |\n +-------+--------+\n |\n v\n +----------------+\n | API Gateway |\n +-------+--------+\n |\n v\n +----------------+\n | AI Orchestrator|\n +-------+--------+\n |\n +------------+------------+\n | | |\n v v v\n Prompt RAG Tools\n Manager\n | | |\n +------------+------------+\n |\n v\n +----------------+\n | LLM Gateway |\n +-------+--------+\n |\n +------------+------------+\n | | |\n v v v\n Model A Model B Model C\n | | |\n +------------+------------+\n |\n v\n +----------------+\n | Guardrails & |\n | Validation |\n +-------+--------+\n |\n v\n ResponseNotice something:
\nThe LLM is only one component.
\nA production AI application may also need:
\nThis is why:
\n«Calling an LLM API is easy. Building a reliable AI product is much harder.»
\nThe model's API price is only part of the equation.
\nYour total AI cost could include:
\nInput Tokens
\n+
\nOutput Tokens
\n+
\nEmbedding Calls
\n+
\nReranking
\n+
\nLLM Calls
\n+
\nTool Calls
\n+
\nVector Database
\n+
\nCompute
\n+
\nStorage
\n+
\nMonitoring
\nConsider an AI support assistant:
\nUser Question
\n |\n\n vEmbedding
\n |\n\n vVector Search
\n |\n\n vReranking
\n |\n\n vLLM
\n |\n\n vTool Call
\n |\n\n vLLM Again
\nOne user interaction can therefore involve multiple computational steps.
\nThat's why AI unit economics are important for Product Managers.
\nImagine two applications.
\nApplication A
\nQuestion
\n|
\nWait 8 seconds
\n|
\nComplete answer
\nApplication B
\nQuestion
\n|
\nFirst token in 1 second
\n|
\nStreaming...
\n|
\nComplete answer in 8 seconds
\nThe total generation time could be similar.
\nBut the perceived experience can be very different.
\nThat's why AI products may track:
\nAI performance isn't just an infrastructure metric.
\nIt's part of the user experience.
\nImagine you have three models:
\nModel A
\nHigh capability
\nHigh cost
\nHigh latency
\nModel B
\nGood capability
\nMedium cost
\nMedium latency
\nModel C
\nLower capability
\nLow cost
\nLow latency
\nWhich one should your product use?
\nThere's no universal answer.
\nIt depends on the use case.
\nFor a high-value enterprise workflow, higher capability may justify higher costs.
\nFor a high-volume consumer feature, latency and cost might matter more.
\nFor a simple classification task, using the most powerful model available may be unnecessary.
\nThe better question is:
\n«Which model provides enough quality for this particular user problem at an acceptable cost and latency?»
\nThat's a product question.
\nWhen evaluating models, don't look at only one benchmark.
\nFor a real product, you might care about:
\nQuality
\n├── Accuracy
\n├── Factuality
\n├── Reasoning
\n├── Instruction Following
\n├── Safety
\n├── Consistency
\n└── Structured Output
\nPerformance
\n├── Latency
\n├── Throughput
\n└── Reliability
\nEconomics
\n├── Input Cost
\n├── Output Cost
\n└── Infrastructure Cost
\nA model can perform extremely well on a benchmark and still perform poorly for your particular product.
\nThat's why your own evaluation dataset matters.
\nSuppose you're building an AI customer-support assistant.
\nYou can create a dataset like:
\nQuestion
\nExpected Behavior
\nExpected Answer Characteristics
\nSafety Requirements
\nExample:
\nQuestion:
\nCan I return this product after 30 days?
\nExpected behavior:
\nUse the company's actual return policy
\nand provide the relevant source.
\nYou can then test the system against hundreds or thousands of similar scenarios.
\nPossible evaluation dimensions include:
\nThis becomes something like automated testing for your AI system.
\nPrompt engineering is useful.
\nBut production AI systems require much more than a clever prompt.
\nThink of the stack like this:
\nUser Experience
\n |\n\n vProduct Workflow
\n |\n\n vPrompt / Instructions
\n |\n\n vContext / RAG
\n |\n\n vTools
\n |\n\n vModel
\n |\n\n vInfrastructure
\n |\n\n vEvaluation
\nIf your AI feature isn't working, changing the prompt might not solve the real problem.
\nMaybe:
\nThis is why AI PMs should understand the whole system.
\nYou don't need to implement every component yourself.
\nBut you should understand how the pieces fit together.
\nA useful mental model is:
\n+-----------------------------------+
\n| USER PROBLEM |
\n+-----------------------------------+
\n| PRODUCT UX |
\n+-----------------------------------+
\n| AI APPLICATION LAYER |
\n| RAG | Tools | Agents | Memory |
\n+-----------------------------------+
\n| LLM LAYER |
\n| Tokens | Attention | Transformer |
\n+-----------------------------------+
\n| MODEL INFRASTRUCTURE |
\n| GPUs | Serving | Cache | APIs |
\n+-----------------------------------+
\nYour job as a PM is to make decisions across these layers.
\nI would break the learning path into five levels.
\nLevel 1 — Fundamentals
\nKnow:
\nLevel 2 — AI Product Development
\nKnow:
\nLevel 3 — Technical AI PM
\nUnderstand:
\nLevel 4 — Production AI
\nUnderstand:
\nLevel 5 — AI Product Leadership
\nEventually learn:
\nYou don't need Level 5 knowledge to get your first AI PM role.
\nBut knowing the roadmap is useful.
\nLet's put everything together.
\nImagine we're building an AI customer-support assistant.
\nA customer asks:
\n«"Where is my order?"»
\nThe architecture could look like:
\nCustomer
\n|
\nv
\nChat Interface
\n|
\nv
\nBackend
\n|
\nv
\nAI Orchestrator
\n|
\nv
\nLLM
\n|
\n|--- "I need order information"
\n|
\nv
\nOrder API
\n|
\nv
\nOrder Status
\n|
\nv
\nLLM
\n|
\nv
\nNatural Language Response
\n|
\nv
\nCustomer
\nThe LLM doesn't necessarily know the customer's order status.
\nIt needs to retrieve that information from the order system.
\nThis is an important distinction:
\n«The LLM reasons over information. Your application connects it to the systems that contain the information.»
\nProduction AI requires thinking about failure modes.
\nHallucination
\nThe model invents an order status.
\nPossible mitigation: Make the order system the source of truth.
\nAuthorization failure
\nThe system exposes another customer's information.
\nPossible mitigation: Strong authentication, authorization and tool-level permissions.
\nSlow API
\nThe order service takes five seconds.
\nPossible mitigation: Optimize the backend and design the UX around latency.
\nExcessive context
\nThe application sends the entire conversation on every request.
\nPossible mitigation: Context management, summarization and appropriate retrieval.
\nExcessive cost
\nThe system uses an expensive model for every request.
\nPossible mitigation: Model routing, smaller models for simpler tasks, caching and request optimization.
\nPrompt injection
\nA malicious input attempts to manipulate the model or its tools.
\nPossible mitigation: Defense-in-depth security, permission boundaries, tool authorization, validation and adversarial testing.
\nIf you're becoming an AI Product Manager, this is probably the most useful mindset:
\n«Don't think of an LLM as a magical brain. Think of it as one component inside a larger probabilistic software system.»
\nThe model is incredibly powerful.
\nBut it isn't perfect.
\nIt doesn't automatically know your company's private information.
\nIt doesn't automatically verify every statement.
\nIt doesn't automatically understand your business rules.
\nIt doesn't automatically have access to your APIs.
\nAnd it doesn't automatically produce reliable production behavior.
\nThe surrounding architecture matters just as much.
\nIf you remember only one diagram from this article, remember this:
\n USER\n |\n v\n PROMPT\n |\n v\n TOKENIZATION\n |\n v\n TOKENS\n |\n v\n EMBEDDINGS\n |\n v\n POSITIONAL INFORMATION\n |\n v\n +-----------------------+\n | TRANSFORMER |\n | |\n | Self-Attention |\n | | |\n | MLP |\n | | |\n | Many Layers |\n +-----------+-----------+\n |\n v\n LOGITS\n |\n v\n SOFTMAX\n |\n v\n TOKEN SELECTION\n |\n v\n NEXT TOKEN\n |\n +-----------+\n |\n v\n Repeat Generation\n |\n v\n RESPONSEAnd a production AI application:
\nUser
\n|
\nv
\nProduct Experience
\n|
\nv
\nApplication Logic
\n|
\n+------ RAG
\n|
\n+------ Tools
\n|
\n+------ Memory
\n|
\nv
\nLLM
\n|
\nv
\nGuardrails
\n|
\nv
\nEvaluation
\n|
\nv
\nResponse
\nThat second diagram is the one I would keep in mind as a Product Manager.
\nUnderstanding LLMs doesn't mean memorizing every equation behind a Transformer.
\nFor a Product Manager, the goal is to understand enough to answer:
\n«What is technically possible?»
\n«What will it cost?»
\n«How fast will it be?»
\n«How reliable will it be?»
\n«What can go wrong?»
\n«What architecture do we need?»
\n«And, most importantly, does this actually solve a user problem?»
\nThe simplest LLM mental model is:
\nText
\n↓
\nTokens
\n↓
\nEmbeddings
\n↓
\nTransformer
\n↓
\nAttention
\n↓
\nProbability Distribution
\n↓
\nNext Token
\n↓
\nRepeat
\n↓
\nResponse
\nAnd the production AI product is:
\nUser
\n↓
\nProduct Experience
\n↓
\nApplication Logic
\n↓
\nContext / RAG
\n↓
\nTools / APIs
\n↓
\nLLM
\n↓
\nGuardrails
\n↓
\nEvaluation
\n↓
\nResponse
\nOnce you understand these two flows, concepts such as RAG, AI agents, LLM gateways, model routing, prompt engineering, fine-tuning, AI evaluation and AI infrastructure become much easier to understand.
\nAnd that's the level of technical depth I'd recommend for an aspiring AI Product Manager:
\nKnow enough to understand the technology, challenge assumptions, work effectively with engineers, and make better product decisions — without trying to become a foundation-model researcher.
\nFurther Reading
\n