But here’s the truth… they’re playing a completely different game.

To dominate AI, companies need four things:

1. Infrastructure,

2. Models,

3. Data,

4. and Distribution.

Apple may be weak in AI models, but they are insanely strong in distribution.

They sell 200+ million iPhones every year.

And think about how we use phones.

We ask simple things — summarise emails, find photos, send quick messages.

So Apple’s strategy is simple: use our personal data to give hyper-personalised AI, and build the best interface on devices. and let others build the giant models.

For this, Apple is simply partnering with Google.

So Apple may never build the smartest AI… but they might build the most useful AI on our phone. Subscribe for more business strategy breakdowns.

Three days later, you buy a case for it. A week after that, you buy AirPods. Normal journey.

Your recommendation feed is doing its job.

Then life happens. You buy a birthday gift for your niece. A toy. Then a book for your dad. Then a yoga mat. Then some groceries.

Now you come back looking for a screen protector for that iPhone.

Here is the problem. Your recommender has forgotten about the iPhone.

The model remembers what you did most recently.
Toy. Book. Yoga mat. Groceries.
Based on that, it is now quietly convinced you are a gifting parent with a wellness streak. It is showing you more toys, more books, more yoga equipment.

Meanwhile, the single most important signal about what you want right now, the iPhone from three weeks ago, has been washed out.

This is not a theoretical problem. This is happening on most recommendation systems you use today.

Today, we are going to see how to fix that.

In our previous piece, we explained how TikTok uses session-based RNNs to predict your next swipe. At the end, we flagged three pitfalls. One of them was Catastrophic Forgetting. This article is a deep dive into the paper that solved it.

If you are preparing for AI PM interviews, recommendation system design is the most commonly asked system design topic at senior levels. We teach this in our course.

The iPhone Problem

Let us go back to your Amazon story. Why did the model forget the iPhone?

The reason lies in how most recommenders store your history.

An RNN-based recommender works like this. Every time you buy something, the model converts that item into a short numerical fingerprint. Then it mixes that fingerprint into a single vector called the hidden state. One vector. That is the model’s entire memory of you.

Think of the hidden state like a single sticky note. Every time you buy something, the model scribbles on that same note, and whatever was written before gets slightly smudged.

After your iPhone purchase, the note says “wants tech accessories.”

After the case and AirPods, it still says roughly that.

Then you buy a toy. The note gets rewritten. Now it says “tech accessories and a gift.”

Then a book. Yoga mat. Groceries. By the time you come back for that screen protector, the sticky note no longer mentions the iPhone at all. It says something like “parent on a wellness kick with household needs.”

The iPhone signal is not lost. It is buried. Smeared under four unrelated purchases.

This is called Catastrophic Forgetting. And it is not a bug you can fix by tuning the model. It is a fundamental flaw in the architecture. The sticky note itself is too small to hold what it needs to hold.

Why This Breaks Product Experience

This has two costs that hit you directly as a PM.

1. The first cost is performance. Your model misses the highest-signal moments in a user’s journey because they get washed out by noise. A user who bought an iPhone three weeks ago is an obvious candidate for iPhone accessories. Your model does not see it. Your revenue per user suffers.

2. The second cost is explainability. You cannot tell a user why something was recommended. You cannot tell your leadership why the model did what it did. A single hidden vector is a black box even to the people who built it.

If you have ever been in a meeting where your head of product asks, “Why is the model recommending this?” and your ML lead says, “The embeddings suggest...”, you have lived this problem.

How Humans Actually Remember

Here is the interesting part. You do not have this problem.

If someone asks you what to get for a new baby, you do not scan every memory from your entire life. You pull up the specific episode of buying baby stuff for your niece last year. You focus on that. Everything else stays quiet in the background.

You have episodic memory. You can pull up specific moments on demand.

Your recommender does not have this. It only has the sticky note.

What if we gave the recommender episodic memory?

The Fix: A Memory Box, Not a Sticky Note

Instead of the single hidden vector, can we give every user a small memory box?

Think of the box as a row of 20 labelled drawers. Each drawer holds one past purchase. When you buy something new, it goes into a fresh drawer. The oldest drawer gets emptied to make space.

At any moment, your box has your last 20 purchases, sitting side by side.
The iPhone is in drawer 17.
The case in drawer 16.
The AirPods in drawer 15.
The toy in drawer 14.
The book in drawer 13.

And so on.

Nothing is smudged. Nothing is averaged. Each purchase sits cleanly in its own drawer.

Now, when you come back looking for a screen protector, the model does something clever. It does not read all 20 drawers equally. It asks a question.

“Which of these past purchases is most relevant to a screen protector?”

It scans each drawer, scores the similarity, and pays attention to the ones that match. The iPhone drawer lights up. The toy drawer stays dim. The book drawer stays dim.

The model pulls out the iPhone signal cleanly and recommends the perfect screen protector.

This is exactly how attention works in modern AI. The model decides what to focus on based on what it is trying to do right now.

Two Versions of the Same Idea

Here this we can do in two ways, both use the same core idea. They differ in what they store.

1. The first version is called item-level RUM.
   Each drawer in the box holds an actual past purchase. iPhone in one drawer. AirPods in another. This is simple. It is also explainable. You can literally tell the user that we showed you this because of that iPhone you bought three weeks ago.

2. The second version is called feature-level RUM.
   Each drawer does not hold a purchase. It holds a preference. One drawer tracks your brand preference. Another tracks your price sensitivity. Another tracks your style preference. Every time you buy something, the drawers get gently updated. Buy an Apple product, and the brand drawer leans more towards Apple. Buy something cheap; the price is more budget-friendly.

The second version tends to perform better. The first is easier to explain.

How The Memory Updates

The item version is simple. New purchase comes in, oldest one gets kicked out. First in, first out. A 20-slot box always holds the last 20 purchases.

The feature version is more interesting.

When you buy something new, the model does two things.

1. First, it decides what to forget. If you just bought an Android phone, your brand preference for Apple should fade. The model computes a forget signal and uses it to gently erase the old preference.

2. Then it decides what to reinforce. Your brand preference for Android should go up. The model computes an add signal and writes it to the drawer.

The mental model is simple. Every time you buy something, the relevant drawers in your memory box get a small dusting-off followed by a small update.

The beautiful thing is that the model learns what to forget and what to reinforce on its own. You do not write rules. You show it millions of user sequences, and it figures out the pattern.

Thing which Product Manager needs to decide

Memory size

How many drawers per user? More drawers mean richer history, but more computing. 20 might work for e-commerce. For a content platform like TikTok, where users burn through items in seconds, you might want 50 or 100.

Item level or feature level

Explainability or performance. Pick one. You cannot have both.

Memory weighting

optimal weight for recent behaviour. Start there. Then an A/B test. Stable domains like books or music can push intrinsic weight higher. Volatile domains like news or short-form video need more memory weight.

Write strategy

For item level, first-in-first-out is fine. For the feature level, you need the forget-and-reinforce approach. It is more powerful. It is also harder to debug.

If this article changed how you think about memory, recommendation architectures, and AI system design, you will find much more depth in our AI PM course.

We cover these in 40+ Videos and 25+ Case Studies, along with AI PM interview questions from top AI companies.

Check our highest-rated AI PM course (Including AI PM Interview Preparation) · 4.9/5 · 600+ enrollments.

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. Weekly Live Webinars/MasterClass ( Here )

I would not open ChatGPT. I would not read a blog post about agents. I would not touch a no-code tool.

I would do something most PMs skip entirely.

I would learn how AI systems actually work before I try to build anything with them.

This sounds obvious. It is not what people do. What people do is jump straight to the shiny layer. They learn prompting. They learn vibe coding. They built a chatbot in an afternoon and updated their LinkedIn headline to “AI Product Manager.”

Then they sit in an interview. The interviewer asks how they would design evaluations for a RAG-based support system. They freeze.

They have no answer because they skipped the foundation that the answer sits on.

90 days is enough time. But only if you sequence things correctly.

Here is the exact sequence.

Weeks 1 to 3. The Foundation Nobody Wants to Build.

Most PMs hear about AI and start with Generative AI. This is backwards.

Generative AI is a layer that sits on top of machine learning. Machine learning sits on top of data systems. If you do not understand the layers below, you cannot reason about the layer above.

Week 1 is about machine learning at a PM level. Not math. Not code. Concepts.

1. What is supervised learning, & What is unsupervised learning?

2. What is the difference between a classification problem and a regression problem?

3. When your team says we trained a model, what does that actually mean?

4. What did they feed it? What did they optimise for? What could go wrong?

You are not learning this to become a data scientist.

You are learning this so you can sit in a design review and know whether the team picked the right approach.

If you cannot do that, you are not an AI PM. You are a project manager with a fancy title.

Week 2 is about the AI Flywheel.

This is the concept that separates AI products from regular software.

In regular software, a feature works the same way on day 1 and day 1000.

In AI, the product should get smarter the more people use it. Users generate data. Data improves the model. The better model creates better user experiences. Better experiences bring more users.

If you cannot design this loop for your product, you do not have an AI strategy.

You have a feature with an API call.

Week 3 is about data pipelines.

This is the week that will feel the most boring and will be the most valuable.

Your AI is only as good as the data feeding it.

Dirty data. Biased data. Missing data. Poorly labelled data.

These are not engineering problems. These are product problems.

The PM who understands data pipelines catches issues in the design phase. The PM who does not catch them in production, after users have already had a bad experience.

By the end of Week 3, you should be able to whiteboard a basic ML system. Data in. Feature engineering. Model training. Prediction. Feedback loop. If you cannot draw this, you are not ready for what comes next.

Weeks 4 and 5. Algorithms and Case Studies.

You do not need to derive the math behind logistic regression.

You need to know when to use it.

Here is a real scenario.

Your team is deciding between a decision tree and a linear model for a pricing feature.

The engineer explains the trade-offs. If you do not understand what either approach does, you are sitting in that meeting as a spectator.

You are waiting for someone else to make a decision that is yours to make.

Week 4: learn the three algorithms that cover 80% of PM-relevant AI decisions.

1. Linear regression for predicting continuous values.

2. Logistic regression for classification.

3. Decision trees for complex, non-linear problems.

For each one, learn what it does, when it works, when it breaks, and what the output looks like.

Do not learn these from textbooks. Learn them from product case studies. How Uber uses prediction models for pricing.

How Netflix uses collaborative filtering for recommendations.

How Amazon designs the data flywheel behind Alexa.

Week 5 is entirely case studies. Read 10 to 15 real company teardowns.

How does Lyft balance model accuracy against latency in real-time pricing, and how does Amazon show the next best category to the users? How does Netflix do creative personalisation on the Homepage? (You can find Case Studies Here)

Every case study you internalise becomes a mental model you can pull out in a conversation, a strategy discussion, or an interview.

The PMs who sound the sharpest in rooms are the ones with the deepest library of real-world references.

Weeks 6 and 7. Generative AI From First Principles.

Now you are ready for Gen AI. Not before.

Week 6 is about understanding generative AI, how it is different from the AI that we learnt in the last few weeks. How does Generative AI work? What are some of the applications that generative AI can solve?

Then go deeper into the hood of Generative AI

1. What is a transformer? What is a token? What is a context window?

2. What happens when you increase the temperature from 0.2 to 0.9?

3. Why does the same prompt give different outputs each time?

4. Why does the model hallucinate, and when is hallucination more likely?

These are not academic questions. If your AI feature is hallucinating and you do not know whether the problem is the prompt, the temperature, the model, or the retrieval layer, you cannot diagnose it.

You are dependent on an engineer to figure it out. That is a loss of ownership.

Week 7 is prompting. Not “write me a blog post” prompting. Structural prompting.

1. Chain of Thought. Tree of Thought. Few-shot examples.

2. System-level constraints. Prompt chaining for multi-step workflows.

These techniques are the difference between an AI feature that works 60% of the time and one that works 95% of the time.

If you are building a product used by millions of people, that 35% gap is the difference between a feature users trust and a feature users abandon.

By the end of Week 7, you should be able to write a multi-step prompt chain that produces consistent, reliable output for a defined product use case. Not a toy demo. A real workflow.

Weeks 8 and 9. Prototyping. The Phase That Changes Your Career.

Everything before this was understandable. This is where you start building.

The gap between PMs who understand AI and PMs who build with AI is the largest salary gap in product management right now. The difference is not 10% or 20%. It is 2x to 3x.

Week 8: build your first working prototype.

Not a mockup. Not a slide deck. A working thing where the AI takes an input, processes it, and returns an output a real user can interact with.

Use Cursor. Use Replit. Use Claude. The tools are too good now for any PM to say “I cannot build anything.” You do not need to write production code. You need to string together an API, a prompt, and a simple interface.

Pick a real problem you face at work. Build a tool that solves it in an afternoon. When you walk into a meeting and show your team a working prototype instead of a spec, the dynamic changes permanently. You stop being the person who requests things. You become the person who builds things.

Week 9: Make the prototype reliable.

This is where most vibe coding efforts die.

The prototype works 70% of the time. The PM calls it done. Post it on LinkedIn. Gets some likes.

But 70% reliability is not a product. It is a demo.

Week 9 is about model control. Temperature tuning. Choosing between a fast, cheap model and a slow, expensive one for different parts of the workflow.

Building a reliability framework. Understanding the cost-per-query math so you can tell leadership “this feature costs X per user per month” and mean it.

These are PM decisions. Not engineering decisions. The PM who owns these trade-offs owns the product. The PM who delegates them owns a spec.

Weeks 10 and 11. RAG, Agents, and Evals.

If you have done everything above, you are in the top 10% of PMs by AI fluency.

The top 1% knows three more things. RAG systems. AI agents. And evals.

RAG

Almost every enterprise AI product is a RAG system. The reason is simple. GPT does not know your company data. Claude does not know your Q3 metrics. No off-the-shelf model knows your customer support documentation.

RAG bridges this gap. It retrieves relevant chunks from your private data and feeds them to the model so it can generate answers grounded in your specific context.

If you are PMing an enterprise AI product and you cannot explain how RAG works, how chunking affects retrieval quality, or what a vector database does, you cannot debug the most common failure mode: the system returning wrong or irrelevant answers.

Agents

These are AI systems that do not just respond. They act. They plan a multi-step workflow, use external tools, and execute tasks autonomously. The PM challenge is different here. You need to design guardrails, failure states, and human-in-the-loop checkpoints for a system that makes its own decisions.

Now, the most important skill of all three: evals.

Evals are how you measure whether your AI system is good.

This sounds simple. It is the hardest unsolved problem in AI product management. You cannot use traditional metrics. Pass/fail does not work when the output is a paragraph of text. You need deterministic evals for things you can measure objectively. You need probabilistic evals where you use one AI model to judge another.

The PMs who understand evals ship with confidence. They set measurable quality bars. They can defend their decisions to leadership with data.

We have covered Advanced Evals here

Weeks 12 and 13. Interview Preparation & Portfolio

You can know all of the above. If you cannot communicate it under pressure in 45 minutes, none of it counts.

AI PM interviews do not ask you to design an alarm clock for the blind. They ask questions like these:

1. How would you measure the success of GPT 5.0?

2. Design a reliability framework for an AI shopping assistant.

3. ChatGPT’s regeneration rate has increased. How would you investigate?

4. How would you price Gemini?

5. Design a RAG system for TikTok content moderation.

6. Imagine Google made its model free, and it is better than paid GPT. You are Sam Altman. What do you do?

7. We have 20 such Real AI PM Interview Questions here

If you have never practised these questions, you will fumble.

Not because you do not know the concepts. Because you have not built the muscle of structuring an AI PM answer under time pressure.

The structure matters.

1. Start by clarifying the AI system architecture.

2. Define success metrics specific to AI products.

3. Address trade-offs unique to probabilistic systems. Show cost-per-query awareness.

4. Show eval thinking. Demonstrate that you can move between product sense and technical depth in the same answer.

Week 12 is practice. Answer questions out loud. Record yourself. Listen back. Find the moments when you hedged, when you went vague, when you lost the technical thread.

Week 13 is portfolio.

Document the prototype you built in Week 8.

1. Write up two case study analyses from Week 5.

2. Create a one-page eval framework for an AI feature.

3. This is your proof of work. It is the difference between “I learned about AI” and “I built with AI.”

This plan will make you absolutely beast after 12–13 weeks. 95% of PMs cannot do these things right now. The ones who can are not smarter. They just did the work in the right order. Most of this plan maps directly to what I teach. If you want to skip the self-study phase??

Check our highest-rated AI PM course (Including AI PM Interview Preparation )· 4.9/5 · 600+ enrollments → See testimonials and course details

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. For more, check out my Live Webinars, AI Product Management Course, PM Interview Mastery Course, Cracking Strategy, and other Resources

You just shipped Rufus. The AI shopping assistant that lives inside the Amazon app.

A user types: I am looking for running shoes for flat feet under 5000 rupees with good cushioning.

Your system does not just call an LLM and return a response. It runs a chain of operations.

1. First, it classifies the user’s intent. Is this a product search? A comparison request? A return query?

2. Then, it extracts structured attributes from the query. Category: running shoes. Foot type: flat feet. Budget: under 5000. Feature: cushioning.

3. Then, it calls the product search API with those attributes and retrieves 20 candidate products.

4. Then, it applies a reranking model to sort those 20 products by relevance to the original query.

5. Then, it feeds the top 5 products and the original query to an LLM, which generates a conversational response with recommendations.

6. Finally, it applies a safety filter to check for hallucinated claims. Did the LLM say a shoe has orthopaedic certification when the product listing never mentioned it?

Six places where something can go wrong.

The user sees the final response. It recommends three shoes. One of them is a basketball shoe. The cushioning claim on another is fabricated. The third recommendation is fine, but it costs 7200 rupees, which is above the stated budget.

Your VP asks what happened.

You look at the final output. It looks broken. But you have no idea which step broke it.

—> Was it the intent classifier?
—> The attribute extractor?
—> The search API?
—> The reranker?
—> The LLM? The safety filter?

This is where traces come in.

Why Traditional Evals Cannot Debug Multi-Step AI Systems

In the previous article, we covered RAG evals. Precision, Recall, MRR. Those metrics evaluate one specific component: the retrieval layer. They tell you whether your system pulled the right documents.

But modern AI systems are not single-component systems. They are pipelines. Chains. Agents. Multiple models calling multiple tools in sequence, where the output of one step becomes the input of the next.

Traditional evals look at the final output and ask: Was this answer good?

Traces solve this problem. A trace is a complete record of everything your AI system did to produce a single response. Every step. Every input. Every output. Every decision in that order.

If the final answer is wrong, the trace tells you exactly where the pipeline broke.

What Is a Trace?

A trace is borrowed from distributed systems. In traditional software engineering, when a user requests a web application, that request might travel through an API gateway, a load balancer, a backend service, a database, and a cache. A distributed trace records each hop, so engineers can see the full journey of a single request.

AI traces do the same thing, but for AI pipelines.

A trace represents the full lifecycle of a single user interaction with your AI system. From the moment the user sends a query to the moment the system returns a response.

A trace is made up of spans.

A span is one unit of work inside the trace. One step. One operation. One model call. One API request. One tool invocation.

Every span records four things.

1. What went in. The input to that step.

2. What came out. The output of that step.

3. How long did it took? The latency.

4. What type of operation it was. An LLM call, a retrieval step, a tool call, a function execution.

Spans are nested. A parent span can contain child spans. This creates a tree structure that shows exactly how your system executed.

This is the anatomy of a trace. A tree of spans, each recording the inputs, outputs, and timing of a single step.

Walking Through a Real Trace

Let us go back to Rufus. The user asked:
I am looking for running shoes for flat feet under 5000 rupees with good cushioning.

Here is the trace your system recorded. Six spans, in order.

Span 1: Intent Classifier

Input: I am looking for running shoes for flat feet under 5000 rupees with good cushioning.
Output: intent = product_search
Latency: 45ms
Model: Internal classifier v3

This span worked correctly. The intent is product search. No issues here.

Span 2: Attribute Extractor

Input: I am looking for running shoes for flat feet under 5000 rupees with good cushioning.
Output: {category: “running_shoes”, foot_type: “flat_feet”, max_price: 5000, feature: “cushioning”}
Latency: 120ms
Model: GPT-4o mini

This span also worked correctly. All four attributes were extracted accurately from the query.

Span 3: Product Search API

Input: {category: “running_shoes”, foot_type: “flat_feet”, max_price: 5000, feature: “cushioning”}
Output: 20 products returned. Product IDs: [A1, A2, A3, ... A20]
Latency: 230ms

Here is the first problem. When you inspect the 20 products returned, you find that product A7 is a basketball shoe. The search API matched on cushioning but ignored the running_shoes category constraint. The API treated the category as a soft filter instead of a hard filter.

You also find that product A14 costs 7200 rupees. The max_price filter did not work as a strict cutoff.

Two bugs. Both in the search API span. Neither is visible in the final output without the trace.

Span 4: Reranker

Input: 20 products from Span 3, original query.
Output: Top 5 ranked products: [A3, A7, A12, A14, A1].
Latency: 180ms
Model: Cross-encoder reranker v2

The reranker promoted A7 (the basketball shoe) to position 2 and A14 (the overpriced shoe) to position 4. The reranker matched on cushioning and boosted both products because they had strong cushioning scores.

The reranker did its job given the inputs it received. But those inputs were already contaminated by the search API.

This is a cascading failure. The search API lets in bad products. The reranker, operating on bad inputs, made the problem worse by promoting them.

Span 5: Response Generator (LLM)

Input: Top 5 products + original query
Output: Based on your requirements, here are three great options for flat feet with excellent cushioning: 1. Nike Revolution 6 (Rs 3,499) with orthopaedic-grade cushioning technology... 2. Adidas CourtSmash (Rs 4,299) with premium arch support... 3. ASICS Gel-Kayano (Rs 7,199) with superior gel cushioning...
Latency: 1,200ms
Model: Claude Sonnet Tokens: 340 input, 180 output

Multiple problems surfaced here.

1. The LLM included A14 (ASICS at Rs 7,199) despite the user asking for under 5000.

2. The LLM fabricated orthopaedic-grade cushioning technology for the Nike shoe.

3. That phrase does not exist in the product listing.

4. And the LLM recommended the Adidas CourtSmash, which is the basketball shoe (A7) that the search API should have filtered out.

Span 6: Safety Filter

Input: Generated response.
Output: Response passed. No safety violations detected.
Latency: 85ms

The safety filter checked for toxicity, PII, and explicit content. It did not check for factual accuracy against product listings. It did not catch the hallucinated orthopaedic-grade claim. It did not catch the budget violation.

The safety filter passed a response that contained two factual errors.

What the Trace Reveals

Without the trace, all you know is that the final answer was bad. With the trace, you know exactly what happened.

1. The search API had two bugs. The category filter was soft instead of hard. The price filter allowed products above the stated maximum.

2. The reranker amplified the problem. It promoted bad products because it optimised for feature match without respecting hard constraints.

3. The LLM hallucinated a product claim. It added orthopaedic-grade cushioning technology, which does not exist in any source data.

4. The LLM ignored a constraint. It recommended a product above the user’s budget.

5. The safety filter was incomplete. It checked for toxicity but not for factual grounding or constraint adherence.

Five distinct failure points. Three different components. Two cascading failures. One root cause (the search API) propagated through the entire pipeline.

You cannot find any of this by evaluating only the final output.

Span-Level Evals: Evaluating Each Step Independently

This is where traces and evals converge.

Traditional evals evaluate the system end-to-end. You compare the final output against a ground truth. That tells you whether the system worked, but not where it failed.

Span-level evals evaluate each span independently. You attach an evaluation metric to each span in the trace. Each step gets its own scorecard.

Let us apply this to our Rufus trace.

Eval for Span 1 (Intent Classifier)

Metric: Classification accuracy.
Ground truth: product_search
System output: product_search
Score: 1.0. Correct.

Eval for Span 2 (Attribute Extractor)

Metric: Attribute extraction F1.
Ground truth: {category: “running_shoes”, foot_type: “flat_feet”, max_price: 5000, feature: “cushioning”}
System output: Same.
Score: 1.0. All attributes correctly extracted.

Eval for Span 3 (Search API)

Metric 1: Category precision. What fraction of returned products match the requested category? 18 out of 20 products are running shoes. 2 are not. Score: 0.90.

Metric 2: Price constraint adherence. What fraction of returned products are under the stated max price? 17 out of 20 are under 5000. 3 are above. Score: 0.85.

Both scores reveal a leaky filter. Neither score would surface from an end-to-end eval.

Eval for Span 4 (Reranker)

Metric: NDCG (Normalised Discounted Cumulative Gain). Did the reranker place the most relevant products at the top?

If we define relevance as products that match ALL stated criteria (running shoes, flat feet, under 5000, good cushioning), then positions 2 and 4 in the top 5 contain products that violate at least one constraint.

NDCG@5: 0.72.

The reranker is optimising for partial relevance. It matches on some attributes while ignoring others.

Eval for Span 5 (LLM Response)

Metric 1: Faithfulness. Does every claim in the response have a source in the input products? The orthopaedic-grade cushioning technology claim has no source. Faithfulness score: 0.67.

Metric 2: Constraint adherence. Does the response respect all user-stated constraints? One product exceeds the budget.
Score: 0.67 (2 out of 3 recommendations within budget).

Eval for Span 6 (Safety Filter)

Metric: Hallucination detection rate. What fraction of factually unsupported claims were caught? The safety filter caught 0 out of 1 hallucinated claims. Score: 0.0 for factual grounding.

Now look at what you have.

A full diagnostic report. Each component was scored independently. You know that the intent classifier and attribute extractor are working perfectly. You know the search API has a filter leakage problem. You know the reranker needs constraint-aware scoring. You know the LLM has a faithfulness problem. You know the safety filter has a coverage gap.

This is an eval report built on traces. You cannot produce this without tracing your system.

The Trace-to-Eval Pipeline

Traces do not just help you debug individual failures. They create a flywheel for continuous improvement.

Here is how the pipeline works.

1. Step 1: Your system logs traces from production. Every user query generates a trace with all its spans.

2. Step 2: You sample traces. Not every trace needs evaluation. You pick a subset. Maybe 1 to 5 percent of production traffic. Maybe all traces where the user gave a thumbs down. Maybe all traces where the response latency exceeded a threshold.

3. Step 3: You run automated evals on the sampled traces. LLM-as-a-judge scores each span for faithfulness, relevance, constraint adherence, whatever metrics matter for your product. This is called online evaluation.

4. Step 4: Traces that score poorly get routed to a human review queue. Domain experts look at the trace, examine each span, and annotate where the system failed. These annotated traces become your golden dataset.

5. Step 5: You use the golden dataset for offline evaluation. Before shipping any change to any component, you run the new version against your golden dataset and compare span-level scores.

6. Step 6: The improved system goes to production. It generates better traces. Those traces get sampled and evaluated. The cycle repeats.

This is the trace-eval flywheel. Production traces become eval datasets. Eval datasets drive improvements. Improvements generate better traces. The system gets better every cycle.

Without traces, this flywheel does not exist. You cannot build a golden dataset if you do not know what each component did at each step.

End-to-End Evals vs Span-Level Evals

There is a common mistake teams make after they discover span-level evals. They stop running end-to-end evals entirely.

This is wrong. You need both. Here is why.

Span-level evals catch component failures. They tell you which step broke. But they cannot catch emergent failures. Failures that only appear when components interact.

Consider this scenario. The intent classifier outputs “product_search” correctly. The attribute extractor outputs all four attributes correctly. The search API returns 20 relevant products. The reranker ranks them well. The LLM generates a fluent response. Every span passes its individual eval.

But the final response is still bad. The LLM picked three products that are all from the same brand. The user sees no variety. The response feels like a sponsored advertisement.

No individual span failed. The failure is emergent. It exists only in the interaction between the reranker (which promoted similar products) and the LLM (which did not add a diversity constraint).

End-to-end evals catch this. They evaluate the final output as a whole. Diversity, user satisfaction, and task completion.

The framework is simple.

If you want to go deeper on Advanced Evals (Cohen’s Kappa, Matthew’s Correlation Coefficient), Evals for Agentic Architecture, AI Product Sense, AI Strategy, AI Pricing, AI Prototyping, Advanced Prompting, ML Systems, etc., check out my AI PM course (40+ Videos and 25+ Case Studies) [Certification Included]

Check our highest-rated AI PM course (Including AI PM Interview Preparation) · 4.9/5 · 600+ enrollments → See testimonials and course details

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. Weekly Live Webinars/MasterClass ( Here ), AI PM Resources

You just shipped AI Overviews.

The feature that puts an AI-generated answer right at the top of search results.

A user types: “Why does my iPhone battery drain fast after the iOS 26 update?”

Your system does two things.

1. First, it retrieves five web pages from Google’s index that it thinks are relevant.

2. Then, it feeds those pages to Gemini and generates a summary answer.

The answer looks clean. The formatting is right. Gemini’s language is fluent. Your VP sees it in a demo and says ship it.

But here is the question nobody in the room asked.

Were those five retrieved pages actually the right ones?

Because if your retrieval pulled garbage, Gemini just summarised garbage.

This is the problem every team building RAG systems runs into. And almost nobody evaluates it correctly.

Why Evaluating RAG Is Different From Evaluating LLMs

Traditional LLM evals test whether the model’s output is good. Did it answer correctly? Was the tone right? Did it hallucinate?

RAG evals test something upstream. They test whether the retrieval system fed the right inputs to the model in the first place.

A RAG pipeline has two components.

1. The retrieval layer that selects documents.

2. And the generation layer that synthesises an answer from those documents.

These are two separate systems. They fail in different ways. They need to be evaluated separately.

Most teams skip the retrieval evaluation entirely. They look at the final generated answer and if it is good, they assume the whole pipeline works.

That is a mistake. Because sometimes the model gets lucky. It generates a reasonable answer even from mediocre sources. And sometimes the retrieval is perfect, but the model fumbles the generation.

RAG evals separate these two failure modes. They tell you exactly where the pipeline broke.

And the retrieval layer? That is your job as a PM to get right. Because retrieval quality is a product decision.

—> How many documents to retrieve?

—> Which embedding model to use.

—> What similarity threshold to set.

These are all choices that show up in your PRD, not in a prompt.

The RAG Evaluation

Let us go back to Google. You are evaluating AI Overviews for the query: “Why does my iPhone battery drain fast after iOS 26 update.”

Your retrieval system pulls five documents. Here is what it returned, in the exact order it ranked them:

1. Position 1: Apple Support page on iPhone battery health settings.

2. Position 2: A CNET article titled “Best Android Phones With Long Battery Life in 2025.”

3. Position 3: A Reddit thread from r/iPhone where users share iOS 26 battery drain fixes.

4. Position 4: A MacRumors article covering iOS 26 release notes and known battery bugs.

5. Position 5: An Amazon product listing for an Anker battery case.

Now, you need a ground truth. You need to know, which documents in your entire corpus were actually relevant to this query.

Your human evaluators (or your golden dataset) say there are exactly four relevant documents in the whole index for this query:

1. Relevant Doc A: The Apple Support page on battery health settings.

2. Relevant Doc B: The Reddit thread with iOS 26 battery drain fixes.

3. Relevant Doc C: The MacRumors article on iOS 26 release notes and battery bugs.

4. Relevant Doc D: An Apple Developer Forum post about background app refresh causing battery drain in iOS 26.

So here is the picture. Your system retrieved five documents. Three of them are relevant (positions 1, 3, and 4). Two are irrelevant (positions 2 and 5). And one relevant document (the Developer Forum post) was not retrieved at all.

Let us now measure exactly how good or bad this retrieval was.

Precision@K in RAG: Are You Retrieving Junk?

Precision answers a simple question. Out of everything you retrieved, how much of it was actually useful?

The formula is:

Let us calculate it at different values of K.

Precision@1.

You look at only the top result.

Position 1 is the Apple Support page. That is relevant.

Precision@1 = 1/1 = 1.0

Perfect. Your top result is a hit.

Precision@3.

You look at the top three results.

Position 1: Apple Support page. — Relevant.
Position 2: CNET Android article. — Not relevant.
Position 3: Reddit iOS 26 thread. — Relevant.

Precision@3 = 2/3 = 0.67

Two out of three were useful. That CNET Android article diluted the quality.

Precision@5.

You look at all five results.

Position 1: Relevant.
Position 2: Not relevant.
Position 3: Relevant.
Position 4: Relevant.
Position 5: Not relevant.

Precision@5 = 3/5 = 0.60

Three out of five. 60%. That means 40% of what you fed to Gemini was noise.

Here is what this metric tells you as a PM.

A precision of 0.60 at K=5 means your context window is 40% garbage. Gemini has to work harder to ignore the Android article and the Anker battery case listing. Every irrelevant document increases the chance of a confused, diluted, or hallucinated answer.

If your precision is dropping, you need to look at your embedding model. Your similarity threshold is too loose. You are retrieving documents that are only tangentially related to the query.

Precision is a purity metric. It tells you whether your retrieval has a noise problem.

Recall@K in RAG: Are You Missing Important Documents?

Recall asks the opposite question. Out of everything that should have been retrieved, how much did you actually find?

The formula is:

We said there are four relevant documents total. Let us calculate.

Recall@1

You retrieved one document. It is relevant.

Recall@1 = 1/4 = 0.25

You found one out of four relevant documents, 25%. You are missing 75% of the useful information.

Recall@3

The top three results contain two relevant documents (positions 1 and 3).

Recall@3 = 2/4 = 0.50

You have found half the relevant information. Better. But the user is still missing context about the iOS 26 release notes and the developer forum post.

Recall@5

All five results contain three relevant documents.

Recall@5 = 3/4 = 0.75

75%, You captured most of the relevant information. But that fourth document, the Developer Forum post about background app refresh, never made it in.

And that missing document? It might have been the most important one. It contains the actual technical fix.

A user reading the AI Overview gets generic advice on battery health settings but misses the specific step to disable background app refresh in iOS 26. That is a coverage gap. And it is invisible if you only look at Precision.

Here is what Recall tells you as a PM.

Low recall means your users are getting incomplete answers. They are not seeing important perspectives.

In a search product, low recall is how you lose trust. The user tries your AI answer; it does not solve their problem. They scroll past it to the blue links, and eventually, they stop reading AI Overviews entirely.

If your recall is low, you need to retrieve more documents (increase K). Or you need a better embedding model that captures semantic similarity more broadly.

But notice the tension. Increasing K improves recall but can hurt precision.

You pull in more documents, and some of them will be junk.

This is the fundamental tradeoff you manage as a PM. And it is why you need both metrics, not just one.

The Precision-Recall Tradeoff in RAG Systems

Let us put the numbers side by side.

At K=1: Precision is 1.00, Recall is 0.25.
At K=3: Precision is 0.67, Recall is 0.50.
At K=5: Precision is 0.60, Recall is 0.75.

See the pattern? As K increases, precision drops and recall rises. You are pulling in more documents, which means you find more relevant ones (recall goes up), but you also let in more noise (precision goes down).

This is not a math problem. This is a product problem.

This is a classic PM decision. It lives in your PRD. Not in a prompt engineering doc.

Mean Reciprocal Rank (MRR): How Fast Does the User Find What They Need?

Precision and Recall measure quantity. How many relevant documents did you retrieve versus how many exist?

MRR measures something different. It measures speed. How quickly does the first relevant document appear in your ranked results?

MRR stands for Mean Reciprocal Rank. Let us break it down from first principles.

First, Reciprocal Rank.

Go back to our query. “Why does my iPhone battery drain fast after iOS 26 update.”

The first relevant document is at position 1 (the Apple Support page).

Reciprocal Rank = 1/1 = 1.0

Perfect. The user’s first result was relevant. No scrolling needed.

But MRR is a system-level metric. It averages the Reciprocal Rank across multiple queries. Because one query hitting position 1 does not mean your system is good. You need to see the pattern.

Let us say you are evaluating AI Overviews across three queries.

Query 1: “Why does my iPhone battery drain fast after iOS 26 update.” Your system retrieves five documents. The first relevant one is at position 1. Reciprocal Rank = 1/1 = 1.0

Query 2: “How to enable dark mode on MacBook Air.” Your system retrieves five documents. The results are: a Windows dark mode guide at position 1, an unrelated MacBook keyboard shortcut article at position 2, and an Apple Support page on macOS dark mode settings at position 3. The first relevant document is at position 3. Reciprocal Rank = 1/3 = 0.33

Query 3: “Is Apple Vision Pro compatible with prescription lenses?” Your system retrieves five documents. Position 1 is a generic VR headset comparison. Position 2 is Apple’s official Vision Pro page, mentioning Zeiss optical inserts. Relevant. Reciprocal Rank = 1/2 = 0.50

Now you calculate MRR:

MRR = (1.0 + 0.33 + 0.50) / 3 = 1.83 / 3 = 0.61

Your MRR is 0.61.

What does this mean?

An MRR of 1.0 means every single query gets its first relevant document at position 1.

An MRR of 0.5 means, on average, the first relevant document is around position 2.

Your score of 0.61 says users are typically finding a relevant result between positions 1 and 2.

Here is why MRR matters as a product metric.

In a RAG system, the order of retrieved documents affects the generated answer. Most LLMs pay more attention to the documents that appear first in the context.

This is called positional bias.

If your first relevant document is buried at position 3 and positions 1 and 2 are noise, the model might give more weight to the noise.

In a search product, position matters even more directly. Users skim from top to bottom. If the first result is irrelevant, many users bounce. Every position of delay costs you engagement.

MRR captures this. It rewards systems that put relevant results first. Not just systems that retrieve relevant results somewhere in the list.

Precision@K, Recall@K, and MRR Together: A Complete RAG Evaluation

Each metric tells you something different about your retrieval system.

Precision@K tells you: Are you retrieving junk? Is your context window polluted?

Recall@K tells you: Are you missing important documents? Is your coverage complete?

MRR tells you: Are the good results ranked at the top? Is your order right?

You need all three. Here is why.

1. A system can have high precision and low recall.
   It retrieves only two documents, both relevant. Great purity. But it missed eight other relevant documents. The user gets a narrow, incomplete answer.

2. A system can have high recall and low precision.
   It retrieves fifty documents and finds all the relevant ones. Great coverage. But it also pulled in forty irrelevant documents that confuse the model and waste tokens.

3. A system can have good precision and recall but bad MRR.
   It retrieves five documents; four are relevant. But the one irrelevant document sits at position 1. The model anchors on it. The answer starts wrong.

The PM’s job is to optimise all three simultaneously. That means choosing the right K, selecting the right embedding model, tuning the similarity threshold, and potentially reranking results after initial retrieval.

Why Most RAG Teams Skip Retrieval Evaluation

Here is what I see happen repeatedly.

A team builds a RAG pipeline. They use an off-the-shelf embedding model. They set K to 5 because someone saw it in a tutorial. They evaluate only the final generated answer. The answers look good in a demo. They ship.

Three months later, users complain. The AI answers are kind of right, but missing the point.

The team starts debugging the LLM. They try better prompts. They switch models. They add guardrails. Nothing helps consistently.

The problem was never the LLM. The problem was the retrieval. Nobody measured Precision. Nobody measured Recall. Nobody checked MRR. Nobody even built a golden dataset of relevant documents for their queries.

The retrieval layer determines the quality ceiling of your entire RAG system. If retrieval is broken, no amount of prompt engineering or model upgrades will fix the output consistently.

If you want to go deeper on Advanced Evals ( Cohen’s Kappa, Mathew’s Correlation Coefficient (MCC) ), Evals for Agentic Architecture, AI Product Sense, AI Strategy, AI Pricing, AI Prototyping, Advanced Prompting, ML Systems, etc., check out my AI PM course (40+ Videos and 25+ Case Studies ) [Certification Included]

Check our highest-rated AI PM course (Including AI PM Interview Preparation )· 4.9/5 · 600+ enrollments → See testimonials and course details

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. Weekly Live Webinars/MasterClass ( Here ), AI PM Resources

1. NVIDIA AI Strategy

2. Memory in AI

3. Spotify’s AI Strategy

Everyone in tech is asking the same question. Will AI replace product managers?

They are making a 160-year-old mistake. By the end of this article, you will see why the answer is the opposite of what they expect.

But first. Coal.

What Is the Jevons Paradox?

In 1865, an economist named William Stanley Jevons noticed something strange. James Watt had made the steam engine more efficient. Everyone expected coal consumption to fall.

Coal consumption exploded.

When each unit of coal did more work, the cost of useful work dropped. When the cost dropped, people found more work to do. Factories that could never afford steam power suddenly could.

Jevons called it a paradox. Make something cheaper per unit and you expect less total usage. That is almost never what happens.

Cars got fuel-efficient. People drove more.

LEDs used less electricity. People installed ten times as many.

AWS made servers cheap. Companies spun up thousands of microservices where they once ran five.

Efficiency does not eliminate demand. It creates it.

This paradox is about to hit product management. But to see how we need to answer a question most PMs have never thought clearly about.

What Does a Product Manager Actually Do?

Not the job description version. The first principles version.

A PM does three things.

1. Uncertainty reduction. Talking to users. Analysing data. Running experiments. All of it serves one purpose. Figuring out what to build and for whom.

2. Cross-functional coordination. Keeping engineering, design, data science, and marketing aligned on the same problem.

3. Tradeoff arbitration. Time versus scope. Revenue versus user experience. Short-term versus long-term. The PM makes the call and owns the outcome.

Which of these three does AI make cheaper?

All three. But not equally.

And the unevenness is where the future of this profession gets decided.

How AI Is Changing Product Management Work

Uncertainty reduction just collapsed in cost. AI synthesises 50 user interview transcripts in two minutes. It scans competitors, generates hypotheses, and drafts experiment designs. Cost per unit down 80% in 18 months.

Coordination got somewhat cheaper. AI drafts PRDs in minutes. Summarises meetings. Translates technical requirements into business language. Maybe 40% cheaper.

Tradeoff arbitration did not get cheaper at all.

AI can present options and model scenarios. But the decision where you weigh strategy against user needs against tech debt against team capacity and say “we are doing this and not that” remains human.

Two of three PM functions got dramatically cheaper. One stayed the same. You already know what Jevons would predict.

The specifics are wilder than you think.

Why AI Will Increase Demand for Product Managers?

Most people stop at step one. Existing PMs get more productive. One PM covers what three did. Fewer PMs needed.

That is the McKinsey argument. The LinkedIn influencer argument. It is step one of four. And the only step that reduces headcount.

Step two. Latent demand unlocks.

Every large company has problems that never got product thinking because it was too expensive. Shopify has over 400 internal tools. Before 2024, fewer than 30 had a dedicated PM. When an AI-augmented PM covers three times the surface area, those neglected tools suddenly deserve attention. Shopify added 15 internal-product PM roles in early 2025.

Step three. New AI product roles emerge.

Every AI feature needs a PM. Every agent workflow needs someone to define boundaries, failure modes, and user experience. A lot of companies did not have a PM for AI-driven personalisation in 2020. Now there is an entire team. Multiply that across every e-commerce, fintech, and SaaS company.

Step four. Non-tech industries hire PMs for the first time.

AI makes building software cheap enough that hospitals, banks, and governments now build their own products.

Step one reduces PM headcount by 30%. Steps two through four increase it by 200 to 300%.

Jevons was right. Again.

This is also why learning to work with AI as a PM is no longer optional. The PMs getting hired in steps two through four are not traditional PMs. They understand how AI systems work and how to build products around them.

Will AI Agents Replace Product Managers Completely?

The serious counterargument. AI agents will handle tradeoff decisions, too. PMs become redundant.

Three problems with this.

1. Processing is not judgment. Spotify’s AI knows podcast listeners churn%. That is a pattern. Whether to invest in podcasts versus audiobooks versus live audio depends on positioning against Apple, licensing economics, and creator dynamics. Data surfaces patterns. Judgment decides what to do with them.

2. Product decisions are not optimisation problems. Feature A serves power users but alienates new ones. Feature B grows the funnel but adds 15% support costs. Feature C needs a migration that slows everything for two quarters. No formula resolves this.

3. Who sets the goal in the first place? AI optimises toward objectives. Someone decides what those objectives are. Which metrics matter? Which users to prioritise? Which problems to solve? That is the core of PM work. It does not get automated. It gets more valuable.

But here is the part that should worry you if you are a certain type of PM.

The Future of Product Management: Three Tiers

The market is splitting. The value distribution is brutal.

Tier one - The Compression Zone.

Execution-heavy work. PRDs, dashboards, tickets, standups. AI compresses this by 70 to 80%. If most of your week looks like this, your leverage is deflating every quarter. Not your job. Your leverage.

Tier two - The Leverage Layer.

Systems-level work. Experiment design, metrics frameworks, and feedback loops. AI augments this but does not replace it. PMs here use AI to multiply their output. Their value goes up with AI.

Tier three - The Taste Premium.

The PM who sees what others miss. Who kills the feature that looks great on a spreadsheet but feels wrong? Who sets the vision that aligns everything else.

The Taste Premium does not get cheaper. It gets scarcer. When supply drops, and demand explodes, the price goes up.

Spreadsheets arrived, and people predicted the end of accountants.

Canva arrived, and people predicted the end of designers.

Design headcount exploded. But the premium for world-class brand work went up.

Democratisation of basic work expands the market. It also concentrates value at the top.

How Product Managers Can Prepare for the AI Era?

One question decides your next five years.

Are you building skills that get cheaper when AI improves or skills that get more valuable?

If you spend your time on uncertainty reduction and coordination, AI is compressing your value. The market will pay less because AI does a version of it for near zero.

If you spend your time on tradeoff arbitration and taste, the market for you is about to expand. Every new AI-augmented PM and every new product surface needs someone at the top making the calls.

Moving from the Compression Zone to the Taste Premium does not happen by accident. It requires understanding how AI systems work, how to build products around them, and how to develop the judgment that AI cannot replicate.

Jevons figured this out in 1865. Coal did not disappear. It powered an industrial revolution.

Product management is not disappearing. It is becoming how every company builds.

The question is which tier you will be in when it happens.

We created a course ( 40+ Videos and 25+ Case Studies ) for PMs who want to build in the right direction. How to think about AI as a PM. How to design AI-first products. How to build the judgment layer that AI cannot replace, AI Deepdive, AI Evals and AI Interview Preparation

Check our highest-rated AI PM course (Including AI PM Interview Preparation )· 4.9/5 · 600+ enrollments → See testimonials and course details

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. Weekly Live Webinars/MasterClass ( Here )

Technomanagers is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

If you have enough historical data on a user, you know exactly what they want. You build your collaborative filtering models. You map out their lifetime preferences. You assume your algorithm is bulletproof.

Then you look at TikTok.

And you realise historical data is often a trap.

If your AI relies on what a user did yesterday, it fails to understand what they crave right now. In platforms where intent shifts by the minute, historical profiling is dead. You need to predict the immediate future based on the immediate past.

This is the first principle breakdown of how to build the Rabbit Hole effect. We will move from traditional recommendation engines to Session-Based Recommendations using Recurrent Neural Networks.

If you are preparing for AI PM interviews, this is one of the most important system design concepts you can learn. We teach this and many more real interview scenarios in our course.

What is TikTok, Really?

From a product architecture standpoint, TikTok is not a social network. It is an AI-driven bipartite matching engine.

It does not care who your friends are. It does not care what you followed last month. It cares about one thing. Matching an infinite supply of highly fragmented content with highly volatile human attention.

The moment you open the app, you are a blank slate. Not because TikTok does not have your data. But your data from yesterday is almost useless for predicting what you want in the next 30 seconds.

This is already a fundamentally different product philosophy from Instagram or YouTube. Those platforms are built on the social graph. TikTok is built on the interest graph. And the interest graph is rebuilt from scratch every single session.

The Strategic Bet: Kill the Social Graph

This is the part most PMs miss entirely.

TikTok did not just build a better recommendation engine. It made a strategic decision to remove the social graph as the primary distribution mechanism.

On Instagram, your content reaches your followers first. Then the algorithm decides whether to push it further. On YouTube, subscribers see your videos first. Then the algorithm takes over.

On TikTok, follower count is almost irrelevant for distribution. The algorithm decides who sees what, independent of social connections. A creator with 200 followers can get 10 million views on a single video if the algorithm detects high engagement in the first few hundred impressions.

Why does this matter strategically?

Because it means TikTok does not need network effects to retain users. Traditional social platforms are sticky because your friends are there. You cannot leave Instagram because your social circle is on Instagram. That is a network effect moat.

TikTok replaced network effects with algorithmic effects. You do not stay on TikTok because your friends are there. You stay because the algorithm understands you better than any other platform. The algorithm itself is the moat.

This is why TikTok’s valuation swings wildly depending on whether the recommendation algorithm is included in the deal. Reports from the US sale negotiations showed that TikTok, without its algorithm, could be worth as little as 40 billion dollars. TikTok with its algorithm is worth closer to 200 billion dollars.

The algorithm is not a feature. It is the entire business.

The User Behaviour Problem

On traditional platforms like Netflix or Amazon, a user’s session is slow. They search. They read reviews. They watch a two-hour movie. You have time to understand them.

On TikTok, user behaviour is chaotic.

Users do not explicitly tell you what they like. They signal it through micro-actions. A two-second linger. A rapid swipe. A share. Finishing a 15-second loop twice. These are all implicit signals.

A user might open the app wanting comedy. Three swipes later, they see a video about fixing a sink. Suddenly, their intent shifts entirely to DIY home repair.

And here is the hardest part. Even if a user is logged in, every time they open the app, their current emotional state is essentially a cold start. They might have had a bad day. They might be bored. They might be curious about something they have never explored before.

Historical profiles cannot capture this. Only the current session can.

The Problem Statement

How do we accurately predict and serve the next piece of content to a user when their current intent is unknown, rapidly changing, and largely divorced from their long-term preferences?

If the system relies on long-term data, it will continue to show comedy even after the user has mentally shifted to DIY. The algorithm will feel clunky. Out of touch.

This is not a theoretical problem. This directly hits the business.

The Metrics Framework: Three Layers

Before we solve it, we must measure the pain. And we need to measure it at three distinct layers. Most PMs only think about one layer. That is a mistake.

Layer 1: Session Health Metrics (Does the user stay?)

Time to First Abandonment tells you how many videos a user swipes through before killing the session. If this number is high, the algorithm is slow to adapt. Think of it as the “cold start tax.” How many bad recommendations does the user tolerate before leaving?

Session Watch Time is the total minutes spent in a continuous app session. TikTok’s average is 95 minutes per day across multiple sessions. If a single session averages less than 8 to 10 minutes, the recommendation engine is leaking users.

Swipe-to-Completion Ratio is the ratio of videos skipped within three seconds versus videos watched to 80% or more completion. A bad ratio means the system is serving the wrong content. A healthy For You feed should have a completion ratio above 40% within the first 10 videos of a session.

Layer 2: Engagement Depth Metrics (Does the user care?)

Not all engagement is equal. TikTok’s algorithm weights signals differently because some signals are more honest than others.

Watch Time Percentage is the strongest signal. A user who watches 95 per cent of a 60-second video has expressed genuine interest. They did not tap a button. They gave you their attention. Attention is the most expensive thing a human can give.

Replay Rate tracks how many users watch a video more than once. This is a signal that the content was not just good but worth revisiting. Replays are weighted heavily because they are almost impossible to fake.

Share Rate is even more telling. A user who shares a video is doing free distribution work for TikTok. They are putting their social capital on the line by recommending content to their friends. This is the highest intent signal after a purchase.

Save Rate means the user wants to come back to this content later. This is a forward-looking intent signal that most platforms underweight.

Comment Sentiment is trickier. A comment can be positive, negative, or neutral. Raw comment counts are misleading. TikTok’s system analyses whether comments indicate genuine engagement or hate-watching. Both drive views, but only positive engagement drives long-term session health.

Layer 3: Business Impact Metrics (Does the algorithm make money?)

Revenue Per Session connects recommendation quality directly to dollars. If the algorithm serves better content, users stay longer, see more ads, and revenue per session increases.

Ad Completion Rate measures whether users watch the ads placed between videos. If the surrounding content is relevant and engaging, users are in a positive attention state and more likely to watch an ad through. If the content is poor, users are already in “skip mode” and will reflexively skip the ad too.

DAU Retention at Day 1, Day 7, and Day 30 tells you whether the recommendation quality is good enough to bring users back. A single great session means nothing if the user does not return tomorrow. This is the ultimate test.

Most PMs stop at Layer 1. The best AI PMs connect all three layers into a single causal chain. Better recommendations lead to better session health, which leads to deeper engagement, which leads to higher ad revenue and retention.

Why Traditional Recommendation Methods Fail Here

Most PMs are familiar with Matrix Factorisation, also called Collaborative Filtering.

It works like this. Users who liked video A also liked video B. So if you liked A, the system recommends B.

This approach has powered Amazon and Netflix for years. But it fails catastrophically on TikTok.

The reason is simple. It ignores the sequence of actions.

If you watch Video A, then Video B, then Video C, the order in which you watched them contains massive contextual clues about your shifting intent. Matrix Factorisation treats them as a disorganised bucket of likes. It does not know that C came after B. It does not know that the transition from A to B was a signal.

Sequence matters. And for sequence, you need a fundamentally different architecture.

Why RNN is the Way Forward

This is where the paradigm shift happens.

Recurrent Neural Networks, specifically architectures like GRU4Rec (Gated Recurrent Units for Recommendations), are designed exclusively for sequential data.

Think of it this way. An RNN treats a user’s session like a sentence. If you read the words “I want to eat an...” your brain predicts “apple.” An RNN does the same thing with user actions. It looks at the strict chronological sequence of the last 10 swipes and uses that sequential memory to predict the 11th.

This is fundamentally different from collaborative filtering. The RNN does not ask “what did users like you enjoy?” It asks “given the exact order of what you just did, what should come next?”

The PM Requirements Before Any Code is Written

Before the ML engineers write a single line of code, the AI PM must define the constraints. If you fail here, the model will be a theoretical success and a production disaster.

There are three critical requirements.

1. First is latency. The model must run online inference. When a user swipes, the RNN must update its state and fetch the next video in under 50 milliseconds. If inference takes 200ms, the user sees a loading spinner. On TikTok, a loading spinner is death.

2. Second is defining a session. Is a session defined by 30 minutes of inactivity? Or is it defined by a hard app close? This seems like a small decision but it fundamentally changes how the model trains. Usually, a 30-minute inactivity threshold works best.

3. Third is signal weighting. The PM must define what inputs matter and how much they matter. A like is an explicit signal. A video completion is an implicit signal. The model must ingest both. But watch-time percentage should be weighted highest because it is the most honest signal. People lie with likes. They do not pay attention.

These are PM decisions, not engineering decisions. If you get them wrong, no amount of model tuning will save you.

How the RNN Actually Works Under the Hood

Let us look inside the GRU, the engine of the RNN session model.

When a user interacts with a video, that video is converted into an embedding vector. Think of the embedding as a numerical fingerprint that captures everything about that video in a compact format.

The core magic of the GRU is its Hidden State. This hidden state acts as the memory of the current session up to the current point in time.

As the user swipes to a new video, the GRU updates its memory. It uses two internal mechanisms.

The Update Gate decides how much of the past session to remember. If the user’s recent behaviour is consistent, the gate stays mostly open, preserving the session memory.

The Reset Gate decides how much of the past to forget because the user’s intent has shifted. If the user suddenly jumped from comedy to cooking, the reset gate activates and says “Forget the comedy context, something new is happening.”

The formula for the memory update looks like this.

New Memory = (1 - Update Gate) X Old Memory + Update Gate X Candidate Memory

In plain language, the model blends the old session memory with the new signal based on how much the user’s intent has shifted. This blending happens after every single swipe. The memory is always fresh.

How the Model is Trained

You cannot train this like a normal classification problem. The video catalogue has millions of items. You cannot ask the model to predict the exact video.

Instead, we use a technique called Bayesian Personalised Ranking or BPR.

The idea is simple but powerful. Instead of predicting the exact next video, you train the model to rank the actual next video the user watched higher than a randomly sampled video the user did not watch.

You take the video that the user actually watched next. You call it the positive item. You randomly sample a video the user did not watch. You call it the negative item. Then you train the model so that the score for the positive item is always higher than the score for the negative item.

Over millions of such comparisons, the model learns what sequences of behaviour lead to what kinds of content. It learns the grammar of user intent.

Measuring Model Success: Offline and Online

You need two completely different sets of metrics here. One for the engineers during training. One for the business during A/B testing.

For offline ML metrics, you track Recall at K. Out of the top 20 videos the RNN predicted, was the actual next video the user watched in that list? If yes, the model is doing its job.

You also track Mean Reciprocal Rank. It is not enough to be in the top 20. Was it ranked number 1 or number 19? MRR heavily penalises the model if the correct prediction is buried at the bottom of the list.

For online product metrics, you track Next-Click CTR. Does the user actually watch the immediately next video served by the RNN? You also track Session Length Extension. Does the RNN variant increase the average session length compared to the control group?

If Recall at 20 is high but Session Length is flat, your model is technically accurate but not creating the Rabbit Hole effect. Both metrics must move together. This is where AI PMs earn their salary. Bridging the gap between what the ML team optimises and what the business actually needs.

The Three Pitfalls That Will Destroy Your Product

If you implement this blindly, you will destroy your user experience. There are three pitfalls every AI PM must guard against.

1. The first is the Echo Chamber problem. RNNs are almost too good at detecting immediate intent. If a user pauses on a sad video for two seconds too long, the RNN might plunge them into a depressive rabbit hole, serving nothing but sad content for the rest of the session. The solution is to inject random exploration videos using multi-armed bandits. You intentionally break the sequence to test for new intents. This is a PM decision, not a model decision. TikTok’s own algorithm does this. It deliberately injects novelty and diversity into the feed to prevent monotony and to protect users from harmful content spirals.

2. The second is Catastrophic Forgetting. Standard RNNs heavily weight the most recent clicks and forget the beginning of the session. If a session is 100 swipes long, the intent from swipe 10 might still be relevant. But the GRU might have forgotten it entirely. This is why some teams use attention mechanisms on top of GRUs, allowing the model to look back at any point in the session, not just the most recent swipes.

3. The third is Cold Start on New Items. The RNN is great at handling new users because it builds understanding from the very first swipe. But it struggles with brand-new videos that have no embeddings yet. You still need content-based filtering to push new creator videos into the system until they accumulate enough interaction data. TikTok solves this through a tiered distribution system. Every new video is first shown to a small, highly targeted test group. If engagement is strong within that group, the video gets pushed to a larger audience. This is how a creator with 200 followers can wake up with 10 million views.

AI Product Management is not about throwing LLMs at every problem. It is about understanding the structural reality of your user data and connecting it to the business's strategic goals.

If this article changed how you think about recommendation systems and product strategy, you will find much more depth in our AI PM course. We cover system design for recommendations, RAG architectures, AI metrics, agentic systems, and real interview questions from top companies.

Check our highest-rated AI PM course (Including AI PM Interview Preparation )· 4.9/5 · 600+ enrollments → See testimonials and course details

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. Weekly Live Webinars/MasterClass ( Here )

Technomanagers is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

They read about LLMs. They learn to write better prompts.

They update their resume with words like “generative AI” and “responsible AI.” They think they are ready.

The job descriptions say otherwise.

I spent three weeks reading 50 AI PM job postings. Google, Meta, OpenAI, Eightfold, and a few high-growth AI-native startups.

I was looking for one thing: what skills are companies actually asking for versus what PMs are actually building.

The gap is larger than I expected.

What Everyone Is Preparing For

The standard AI PM preparation list looks like this.

→ Learn how LLMs work at a high level. Understand transformers.
→ Read about RAG and fine-tuning.
→ Practice writing product strategy documents that mention AI.
→ Build a portfolio project, preferably a chatbot.

This is not wrong. These things appear in JDs.

But they appear the same way “strong communication skills” appear in a generic PM role. As table stakes.

As filters that remove clearly unqualified candidates, not signals that separate good candidates from great ones.

The companies I looked at are past the point where “I understand what an LLM is” is a differentiator. They are hiring for people who have operated at the intersection of AI and product. Operated, not studied.

Three skills kept appearing across JDs in a way that most candidates are not building.

Skill 1: Evals

This is the biggest gap I found.

The OpenAI CPO, at Lenny’s Podcast conference in 2025, said something that should have become required reading for every PM preparing for an AI role. He said, “The most important thing a product manager can learn to do is write evals.”

Most PMs I speak to do not know what an eval is. They think it means user testing. It does not.

An eval is a structured test suite for an AI system. You define a set of inputs, the expected output or behaviour, and a scoring method. You run the system against those inputs. You measure how often it performs correctly. When the model changes, when you change the prompt, when you change the data, you run the evals again. You see what broke.

In traditional software, a bug is a bug. The system does the wrong thing, and you fix it.

In LLM-based products, the system does the wrong thing in some cases, the right thing in others, and something ambiguous in a third set. Without evals, you have no way to know which category a new change falls into. You are shipping blind.

A sample question can be something like this:

1. How would you measure the reliability of Rufus, the e-commerce AI Assistant?

2. How would you measure the success of MultiAgentic Workflow?

Every time you change anything about the system, you run the evals again. If the score drops, you do not ship.

This might help you to prepare in detail about Evals

Skill 2: Model Selection Logic

The second skill is the ability to choose between AI approaches, not just use them.

A year ago, “AI feature” meant “integrate GPT-4 via API and ship.” That is no longer a differentiated product decision.

Today, hiring managers want PMs who can reason through the following question: for this specific problem, what is the right approach and why?

The options a PM now needs to reason through include prompt engineering alone, RAG with a vector database, fine-tuning a smaller model, training a purpose-built model from scratch, or using a rule-based system instead of AI entirely. Each option has a different cost structure, latency profile, accuracy ceiling, maintenance burden, and failure mode.

A PM who cannot reason through this tradeoff is not a PM for an AI product. They are a PM who happens to have AI on their roadmap.

Let me make this concrete. Say you are building a feature that answers customer queries about an e-commerce return policy. Your choices are:

Prompt engineering: fast to build, but the model will hallucinate policies that do not exist in your documentation. You have no grounding.

RAG: You retrieve the relevant policy sections and inject them into the prompt context. The model can now answer accurately against your actual policy. Build time is higher, but accuracy is significantly better.

Fine-tuning: you train a smaller model specifically on your policy data and support conversations. Latency is lower, cost per query is lower, but you now have a maintenance responsibility. When your policy changes, you need to retrain.

Rule-based: for simple, high-volume queries like “what is your return window,” a rule-based system has zero hallucination risk and near-zero latency. AI adds no value here.

Real AI PM Interview Questions Click Here

Skill 3: Failure Mode Thinking

Traditional products fail in predictable ways. If a button does not work, it does not work. You find it in QA. You fix it. It works.

AI products fail in ways that are probabilistic, context-dependent, and sometimes invisible until they are very visible.

The failure modes that appear repeatedly in AI PM JDs are: hallucination (the model generates confident false information), latency degradation under load, context window limits causing incomplete reasoning, prompt injection attacks in user-facing LLM features, and confidence calibration problems where the model is wrong but sounds right.

PMs who can map failure modes before a feature ships are rare.

Most teams discover failure modes after launch because they were not built into the product definition.

Hiring managers know this and look for candidates who proactively think about what can go wrong.

In an interview, this shows up as questions like: “How would you define done for an AI feature?” or “Walk me through how you would monitor this after launch.”

A PM who only talks about launch metrics and A/B tests is signalling that they have not thought about probabilistic failure.

A PM who talks about confidence thresholds, fallback logic, latency monitoring, and a human-in-the-loop escalation path for low-confidence outputs is signalling operational maturity.

What This Means for Your Preparation

The JDs are not asking for people who know about AI. There are thousands of those.

They are asking for people who have operated AI products. Who have thought through eval design, made model selection decisions, and mapped failure modes before launch. These are skills you build by doing, not by reading.

If you are preparing for an AI PM role right now, I would stop spending time on LLM theory and start spending time on the three skills above.

That work is what separates candidates who know AI from candidates who have worked with AI. The JDs are very clear about which one they want.

AI Product Management is the future; you can keep ignoring but this will become the baseline in 8 to 14 Months.

You should take action to kill the anxiety — Start today only, Learn about AI Product Management, start from basics to Advance with the Flagship AI PM Course.

You can also check out our highest-rated AI PM course ( Including AI PM Interview Preparation )· 4.9/5 · 600+ enrollments → See testimonials and course details

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. Weekly Live Webinars/MasterClass ( Here )

Your VP walks into your Monday standup and says three words: “Build Ask Maps.”

What is “Ask Maps”: Users can type or speak a natural language query directly into Maps and get intelligent, context-aware answers. “Find me a rooftop restaurant near Koramangala that’s open after 10 PM and has good reviews for cocktails.” No filters. No manual search. Just ask.

Everyone in the room is excited. The engineers want to start prototyping immediately. Someone has already opened Cursor.

And this is exactly where most AI-era product development goes wrong.

Because what happens next is what the industry has started calling “vibe coding.” Someone fires a prompt into an AI coding tool.

The tool generates a working prototype in 20 minutes. Everyone is impressed. The demo looks great.

Three sprints later, the codebase is a mess, the AI feature behaves inconsistently across edge cases, and no one can explain why it sometimes returns results in Tamil Nadu when the user is searching in Telangana.

Spec-driven development is the structured alternative.

And in this article, I want to walk you through exactly what it looks like: not in abstract terms, but through the Ask Maps feature, end to end.

Before we go deep into Spec Driven Development, you can find out our articles on the following

1. Uber’s AI Strategy

2. Memory in AI

3. Spotify’s AI Strategy

What Spec-Driven Development Actually Is?

Spec-driven development (SDD) is a methodology where you write a formal, machine-readable specification before any code is generated.

This specification defines the behaviour, constraints, success criteria, and edge cases for a feature. The AI coding agent then generates code that must satisfy the spec. If the generated code does not meet the spec, the build fails automatically.

This is different from how most teams use AI tools today.

In the traditional AI-assisted workflow, a developer writes a prompt, the AI generates code, the developer reviews it, finds gaps, re-prompts, and this cycle repeats until something “feels right.”

There is no contract. There is no explicit definition of what the feature must and must not do. The AI guesses. The developer hopes. Technical debt accumulates silently.

SDD flips this. You start with the contract. You define what Ask Maps must do before you decide how it should be built. The code is a downstream artefact of the spec, not a starting point.

Three levels of SDD exist: spec-first (the spec guides the AI workflow), spec-anchored (the spec is continuously updated as the feature evolves), and spec-as-source (only the spec is ever edited by humans, never the code directly). For most product teams, spec-first or spec-anchored is the practical operating mode.

Now, let us apply this to Ask Maps, step by step.

Phase 1: Strategic Alignment Before Writing Anything

Most PMs think the spec is the first output of the discovery process. It is not. The first output is alignment with what you are actually building.

Before anyone writes a spec for Ask Maps, the product team needs to resolve a set of foundational questions. These are not design questions. These are strategy questions.

What is the primary job to be done?

Ask Maps could solve multiple problems. It could be a discovery tool (help users find places they did not know existed). It could be a planning tool (help users build a full day itinerary). It could be a real-time assistant (give live, context-aware answers based on current traffic, weather, and availability).

These are three different features. They share a surface but diverge completely in their backend requirements, data dependencies, and success metrics.

At Google Maps, this decision has massive downstream consequences. A discovery-focused Ask Maps integrates deeply with Google’s restaurant and business index. A planning tool needs multi-stop optimisation logic. A real-time assistant needs live data pipelines for weather, traffic, and business hours APIs.

The team needs to pick one primary job. Everything else is scope creep.

What is the explicit scope boundary?

What will Ask Maps not do? This is equally important as what it will do. Will it handle transactional requests (”book a table at this restaurant”)? Or is it purely informational? Will it work offline? Will it support voice input at launch? What languages will it support on day one?

Scope boundaries are not limitations. They are the spec’s load-bearing walls.

What are the success metrics?

Before a single line of spec is written, the team defines what success looks like. For Ask Maps, this might be: query satisfaction rate above 80% (user rates the answer as helpful), mean response latency under 2 seconds, and a 15% increase in session length compared to the current Maps search flow.

These numbers are not arbitrary. They will directly inform the non-functional requirements in the spec later.

Practical SDD tool behaviour at this stage:

In tools like Agent OS, this phase is handled by a “spec researcher” sub-agent. It ingests your product brief and roadmap, then surfaces clarifying questions with suggested default answers.

The PM does not write long paragraphs in response. They respond with “yes” or minor corrections. The agent synthesises the answers into a structured requirements brief.

For Ask Maps, the output of this phase is something like:

• Primary job: Place discovery through natural language

• Scope: Informational only, no transactions, English-first

• Input modes: Text and voice

• Success metric: Query satisfaction above 80%, P99 latency under 2 seconds

• Out of scope for v1: Itinerary building, multi-stop optimisation, transactional bookings

This is not the spec. This is the raw material for the spec.

Phase 2: Writing the Ask Maps Specification

Now the spec is written. And this is where SDD requires discipline, because the instinct is to write a technical spec. SDD requires a behavioural spec.

A behavioural spec defines what the system must do and how it must behave from the user’s perspective and from a system contract perspective. It does not prescribe the implementation.

Here is what the Ask Maps spec looks like:

Feature: Ask Maps Version: 1.0 Owner: [PM Name] Last updated: [Date]

Goal: Enable Google Maps users to discover places and get location-aware answers through natural language queries, without using traditional filter-based search.

User Stories:

1. As a Maps user, I want to ask a natural language question about places near me, so that I can discover options I would not find through manual filters.

2. As a Maps user, I want to ask follow-up questions in the same session without re-entering my original context, so that I can refine my search conversationally.

3. As a Maps user, I want Ask Maps to consider my current location, time of day, and day of week automatically, so that I get contextually relevant answers without explicitly stating these.

Functional Requirements:

1. FR-01: The system must accept natural language queries of up to 500 characters via text input.

2. FR-02: The system must accept voice input and convert it to text before processing.

3. FR-03: The system must use the user’s current GPS-confirmed location as the default geographic context for all queries.

4. FR-04: The system must return a minimum of 3 and a maximum of 10 place results per query.

5. FR-05: Each result must include: place name, distance from user, rating, a one-line AI-generated reason for the recommendation, and a direct CTA to navigate.

6. FR-06: The system must support follow-up queries within the same session, preserving the context of the initial query.

7. FR-07: If the system cannot find relevant results with confidence above 0.75, it must surface a “limited results” state rather than hallucinating low-quality matches.

Non-Functional Requirements:

1. NFR-01: P50 response latency must be under 1 second. P99 must be under 2 seconds.

2. NFR-02: The system must handle a minimum of 10,000 concurrent queries.

3. NFR-03: The AI recommendation layer must not surface results from businesses that have a Google rating below 3.5 unless explicitly asked by the user.

4. NFR-04: The system must not store the user’s query text beyond the active session without explicit consent.

Edge Cases and Failure Modes:

1. EC-01: User is in a location with no GPS signal. The system must prompt the user to manually enter a location rather than defaulting to a stale cached location.

2. EC-02: User queries a category with no matches within a 10km radius. The system must expand the radius to 25km and inform the user of this expansion.

3. EC-03: Query contains a language other than English. V1 must return a graceful “English only” message. V2 will address multi-language support.

4. EC-04: Query is ambiguous (for example, “good food near me”). The system must ask one clarifying question before returning results, not make an assumption.

Out of Scope:

• Transactional bookings (restaurant reservations, ride bookings)

• Multi-stop itinerary planning

• Queries not related to physical places (for example, “what is the capital of France”)

Notice what this spec does not contain: no database schema, no API structure, no infrastructure decisions. Those are implementation choices. The spec is silent on them intentionally. The AI coding agent gets to make those decisions within the constraints of the spec. The spec defines what must be true. The implementation decides how.

Phase 3: The Design Document

The spec is human-readable. The design document is agent-readable.

Once the spec is approved (and this approval step is non-negotiable in SDD, the PM and engineering lead both sign off before any code is generated), the AI agent translates the spec into a structured design document.

This document contains:

API Contract (from FR-01, FR-02, FR-04):

The Ask Maps endpoint accepts POST requests.

Input schema:

• query (string, required, max 500 characters): The natural language query

• location (object, required): Contains lat (float) and lng (float) from GPS

• session_id (string, optional): For follow-up query context preservation (FR-06)

• input_mode (enum: “text” | “voice”, required)

Output schema:

• results (array, min 3, max 10): Each object contains place_id, name, distance_km, rating, ai_reason, navigate_url

• state (enum: “success” | “limited_results” | “clarification_needed” | “error”)

• clarification_question (string, nullable): Populated only when state is “clarification_needed”

Confidence Gate (from FR-07):

The AI recommendation layer must include a confidence score per result. Results with confidence below 0.75 are excluded from the final output array. If this exclusion brings the total results below 3, the system sets the state to “limited_results” and returns whatever results passed the threshold.

Radius Expansion Logic (from EC-02):

Initial query radius: 10km. If the results count is below 3 after confidence filtering, expand to 25km. Append a radius_expanded: true boolean to the response object. The UI layer uses this flag to surface the “We expanded your search area” message.

Security Constraints (from NFR-04):

Query text must not be written to any persistent store. Session data lives in ephemeral cache only, with a TTL of 30 minutes.

This design document becomes the to-do list for the AI coding agent. Each requirement maps to a specific implementation task. Nothing is left to interpretation.

Phase 4: Breaking It Into Testable Tasks

In SDD, the design document is decomposed into discrete, independently testable implementation units. This is where the workflow starts looking like traditional engineering project management, except that AI agents are executing the tasks, not humans writing the code from scratch.

For Ask Maps, the task breakdown looks like this:

Task Group A: Core API Layer

• A1: Implement the POST /ask-maps endpoint with input validation (FR-01, FR-02)

• A2: Implement GPS location ingestion and validation. Fail gracefully if coordinates are malformed (EC-01)

• A3: Implement session management with 30-minute ephemeral TTL (NFR-04, FR-06)

Task Group B: AI Recommendation Engine

• B1: Integrate with Google Places API for candidate place retrieval

• B2: Implement confidence scoring model with 0.75 threshold gate (FR-07)

• B3: Implement radius expansion logic: 10km base, expand to 25km with flag (EC-02)

• B4: Generate AI-written one-line reasons per result using the LLM layer

Task Group C: Edge Case Handling

• C1: Implement ambiguity detection. If query is flagged as ambiguous, return clarification question instead of results (EC-04)

• C2: Implement rating filter: exclude results with Google rating below 3.5 from candidate pool (NFR-03)

• C3: Implement “English only” language detection for V1 (EC-03)

Task Group D: Non-Functional Requirements

• D1: Load test to confirm P99 latency under 2 seconds at 10,000 concurrent queries (NFR-01, NFR-02)

• D2: Security audit on query storage to confirm no persistent writes (NFR-04)

Each task has a direct reference back to a specific requirement in the spec. This is the core discipline of SDD. You can always trace any line of code back to a business requirement. If you cannot, that code should not exist.

Phase 5: Execution Under Constraints

The AI coding agent now generates code. But this is not vibe coding with a spec document sitting nearby. The spec is an active constraint.

In practice, this means:

The CI/CD pipeline has automated spec validation checks embedded.

If the AI agent generates code for the Ask Maps endpoint that does not include the confidence threshold gate, the build fails. Not a code review comment. A hard build failure.

If the agent generates a response schema that returns results without the ai_reason field, the build fails. Because FR-05 explicitly mandates it.

If the agent writes query text to a database table (even a logging table), the build fails. Because NFR-04 says it cannot.

This is what “executable specification” means. The spec is not a document someone reads. It is a contract that the system enforces.

One critical challenge at this phase is what practitioners call context fragmentation. Most AI coding tools understand a single repository. But Google Maps is not a single repository.

The Ask Maps feature will touch the core Maps search service, the Places API integration layer, the user session service, the UI component library, and the AI/ML serving infrastructure. These live in different codebases, owned by different teams.

If the AI agent only sees one of these repositories, it will generate code that is locally correct but architecturally inconsistent. It will reinvent session management that already exists in the session service. It will create a new confidence scoring library instead of using the existing ML inference wrapper.

This is why enterprise SDD needs a context engine that maps semantic dependencies across repositories.

For a team without access to enterprise tooling, the practical workaround is explicit cross-repo documentation injected into the AI agent’s context at task time.

Phase 6: Debugging the Spec, Not Just the Code

This is the phase most PMs never hear about, and it is arguably the most important.

In SDD, when the AI generates code that is wrong, you do not fix the code directly. You fix the specification.

Here is why: AI code generation is non-deterministic. If you fix a bug in the generated code without updating the spec, the next time you regenerate (for a refactor, a new feature, or a regression fix), the AI will reproduce the exact same bug. It is following the spec. The spec said nothing about this case. So the AI guessed.

Concretely: Imagine the Ask Maps agent generates code that sometimes returns results from a different city when the user is near a city boundary. The radius expansion logic triggered, expanded to 25km, and pulled in results from an adjacent city without informing the user.

In vibe coding, a developer patches this edge case in the code and moves on.

In SDD, the PM goes back to the spec, adds a new edge case:

EC-05: When radius expansion crosses an administrative city boundary, the system must segment results by city and surface a separator in the UI indicating “Results from [adjacent city]”.

The spec is updated. The design document is updated. The CI/CD validation check is updated. The AI agent regenerates the affected module. The fix propagates correctly and permanently.

This is the compounding benefit of SDD. Every bug you find and fix in the spec makes the entire feature more robust, not just the one line of code that was wrong.

Why This Matters for Product Managers Specifically

SDD is not just an engineering methodology. It is a PM leverage tool.

In the traditional development model, the PM writes a PRD, hands it to engineering, and then spends the next three sprints in spec review meetings clarifying requirements that were ambiguous in the document. The PM is a translator, repeatedly.

In SDD, the spec is the single source of truth that both the PM and the AI agent operate from. When engineering asks, “Why does the endpoint behave this way?” the answer is always FR-07 or NFR-03. Not “I think I mentioned it in the PRD somewhere.” The spec is precise. The behaviour is traceable.

For PMs building AI-powered features specifically, this precision is not optional. Research shows AI LLMs generate vulnerable code at rates between 9.8% and 42.1%, and a significant fraction of those vulnerabilities are rated Critical severity.

A PM who cannot articulate the exact constraints their AI feature must operate within is not doing product management. They are doing product wishful thinking.

SDD forces PMs to be specific. That specificity is the PM’s highest-leverage contribution in an AI-first development environment.

The Learning Curve Is Real, But It Pays Off

When I first started working through SDD workflows, the upfront planning phase felt slow. Writing behavioural requirements instead of just describing the feature in prose felt overly formal. Defining edge cases before writing a single line of code felt premature.

Three sprints in, the compounding became obvious. The Ask Maps spec, once written, became the source for the engineering scoping document, the QA test plan, the security review checklist, and the launch readiness criteria. The spec was written once and used six times. Every clarifying question in sprint planning was answerable by pointing to a requirement ID.

The slow part upfront makes everything downstream faster.

Where to Go From Here

AI Product Management is the future; you can keep ignoring but this will become the baseline in 8 to 14 Months.

You should take action to kill the anxiety - Start today only, Learn about AI Product Management, start from basics to Advance with the Flagship AI PM Course.

You can also check out our Highest rated AI PM course · 4.9/5 · 500+ enrollments → See testimonials and course details

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. For more, check out my AI Product Management Course, PM Interview Mastery Course, Cracking Strategy, and other Resources

1. NVIDIA AI Strategy

2. Memory in AI

3. Spotify’s AI Strategy

Many people think Uber is competing with Waymo and Tesla to build the best self-driving car.

This is a flawed way to look at the business.

Uber is not building a car company.

Uber is building the software layer for physical mobility.

Let us break down the Uber autonomous vehicle strategy using first principles.

The Utilisation Problem

Why does Uber not just buy a massive fleet of self-driving cars and keep all the profit?

We need to look at the fundamental unit economics of a transportation marketplace.

Ride hailing demand fluctuates drastically. A Saturday night has massive demand, while a Tuesday morning has very low demand.

If a standalone robotaxi company builds enough cars to serve the Saturday night peak, then most of their expensive cars will sit idle on Tuesday morning.

Idle hardware destroys profitability because you still pay for depreciation and maintenance.

If they only build enough cars for Tuesday morning, then wait times on Saturday night will be too long, and users will leave the platform.

Uber solves this problem through a hybrid network.

They use self-driving cars to serve the base load.

The base load is the predictable, continuous demand that happens every hour of the day. Uber then uses human drivers to handle the burst capacity.

Burst capacity is the sudden spike in demand during bad weather or weekends. By pushing the volatile demand to human drivers, Uber ensures that its partner autonomous vehicles stay constantly utilised.

High utilisation directly leads to profitability.

The Big City Myth

Will autonomous vehicles just take over the major cities?

Software scales instantly, but physical infrastructure scales very slowly.

People assume that cities like San Francisco and Los Angeles generate all the rideshare money.

The latest Uber financial data shows something completely different. Trips in the top twenty US cities represent only twenty five percent of their overall profits.

The vast majority of Uber profits come from smaller cities and suburbs. It will take a very long time for autonomous vehicle companies to map every rural road and complex suburban driveway.

Uber already has human drivers covering these areas. Uber owns the demand in these highly profitable long tail markets while the hardware companies take on the massive capital expense of mapping physical geography.

The Aggregator Advantage

If cars can drive themselves, why do hardware companies need the Uber platform at all?

When a technology becomes a commodity, the company that aggregates customer demand captures the most value.

If Waymo dominates one city and another startup dominates a different city, the end consumer will have a terrible experience.

Users do not want to download five different apps and compare wait times.

Uber is positioning itself as the universal marketplace for mobility.

It does not matter if the vehicle has a Google brain or a Tesla brain. The expensive robotaxi needs a rider to generate revenue. Uber has hundreds of millions of active users. By acting as the aggregator, Uber forces hardware companies to plug into its routing algorithm.

Uber does not need to win the artificial intelligence race. Uber just needs to be the default platform where all the artificial intelligence models come to find their customers.

Commanding The Pricing Power

Whoever controls the user interface controls the pricing power.

If a customer opens the Uber app, they do not care who manufactured the car. They just want the cheapest and fastest ride possible.

This consumer behaviour gives Uber total negotiating control over the hardware companies. Uber can force the different self-driving companies to compete directly against each other on the same screen.

If one hardware company wants a higher cut of the fare, Uber will simply send the customer a cheaper vehicle from a different hardware maker. This dynamic will force the hardware companies to lower their prices to win the ride, while Uber maintains its high profit margins on every single transaction.

What do you think, what’s the future of mobility?

For Full Detailed cases Studies and AI & Strategy — Download this Book ( 5/5 Rated )

Download the Book

You can also check out our Highest rated AI PM course · 4.9/5 · 500+ enrollments → See testimonials and course details 60% OFF for a limited time — Code: NYE26

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. For more, check out my AI Product Management Course, PM Interview Mastery Course, Cracking Strategy, and other Resources

Jensen Huang, speaking to Stratechery's Ben Thompson right after his GTC 2026 keynote, said this: “It’s not just gonna be people banging on our SQL database now, it’s gonna be a whole bunch of agents banging on it. They’re gonna need to do it way faster.”

That is not a hardware announcement. That is a product warning.

Here is why I think that.

Every piece of software you have ever used was designed with one assumption baked in at the foundation. A human is on the other side.

Not just any human. A slow human. A human who reads, pauses, gets distracted, reopens the tab, waits for the page to load, and tolerates 400 milliseconds of latency without complaint.

Software was optimised for this human. The entire architecture of modern software products, rate limiting, pricing tiers, API design, and query performance budgets were calibrated to serve this specific use case.

That creature is no longer the primary user. And most products have not noticed yet.

Why Tools Break When Agents Show Up

Think about what actually happens when you plug an AI agent into an existing software tool.

The agent does not browse. It does not think about whether to click. It does not go to lunch.

It executes at machine speed, in a loop, with no downtime. A human sales rep might open your CRM 30 times in a workday.

An agent doing the same research task will hit your CRM API 30,000 times in an hour. The tool was never tested for this. The rate limit was never designed for this. The pricing model was never imagined for this.

The interesting thing is that this does not break gradually. It breaks at a threshold. Below it, everything works fine, and nobody notices. Cross it, and your authentication server is overwhelmed, your database connection pool is exhausted, your cost per customer quadruples overnight, and your support queue fills up with confused enterprise customers who say “we did not change anything.”

They did not change anything visible. They shipped an agent. That is the invisible change that breaks everything at once.

The moment when an AI agent becomes the dominant user of a system that was designed for humans, and all the original design assumptions fail simultaneously. It is not a gradual migration. It is a cliff.

The reason it is a cliff and not a slope comes down to something simple. Human tools were built on human time. Agents operate on machine time. These are not just different speeds. They are different operating philosophies.

When you build for human time, you tolerate latency because the human tolerates it. You accept occasional errors because the human catches them. You design for sessions because humans use things in sessions. You price per seat because humans use things individually.

None of that works in machine time. Latency compounds in a chained agent pipeline. A 10-step workflow where each step waits half a second end-to-end takes 5 seconds. Run 1,000 instances of that workflow for an enterprise customer and you are delivering 1,000 simultaneous calls that each need a sub-500ms response. The tool was tested for 50 concurrent users, not 1,000 parallel agents.

This is not a scalability problem in the traditional sense. You cannot just throw more servers at it. The fundamental design logic of the product is wrong for the new user.

The CPU Comeback Explains Everything

Here is something that most people found confusing at GTC. Jensen Huang, the man who spent years arguing that CPUs are bottlenecks and everything should be GPU-accelerated, is now selling CPUs. He announced the Vera CPU architecture, specifically designed for AI agent workloads. Why?

The answer reveals something deep about how agents actually work.

An agent does not run on a GPU the whole time. An agent reasons, then calls a tool, then waits for the result, then reasons again.

The reasoning part wants a GPU. The orchestration, the sequential decision making, the “what should I do next” part, runs on a CPU. One step at a time. Single-threaded. You cannot parallelise “what should I do next” because each decision depends on the previous one.

So here is what happens without a fast CPU. The agent reasons on the GPU, calls a tool, and then has to coordinate the response through a slow CPU before the next GPU operation starts.

The GPU sits idle.

You have bought millions of dollars of inference hardware that is waiting for a single-threaded CPU bottleneck.

Huang puts it directly: if the CPU is not fast, it holds back the GPU. The most expensive accelerators in the world are bottlenecked by the cheapest component in the chain.

The data centre was designed for a workload profile that no longer exists. Now it needs to be rebuilt around the actual agent workflow, which is not “run fast in parallel always” but “reason sequentially, then execute in parallel, then reason again.”

The product lesson here is not about CPUs. The lesson is that agent workloads expose hidden dependencies throughout the stack. Components that looked fine under the old workload become the binding constraint under the new one. This is true for hardware, and it is equally true for your product’s architecture.

The Inference Pricing Split That Nobody Has Built Yet

The Groq acquisition is more interesting than it looks.

Groq’s hardware is built for one thing: generating tokens extremely fast with very low latency. It trades raw throughput for speed. More tokens per second per user, fewer users served simultaneously. This is the opposite of what most inference providers optimise for.

Huang’s explanation of why Nvidia bought them is worth sitting with. He says there are two fundamentally different products in inference. One is throughput. The other is intelligence per token, and the willingness to pay for speed.

Let me translate that into product terms.

If your AI product is running document summaries overnight, processing invoices in batch, or generating reports on a schedule, you want cheap tokens. You are not time-sensitive. You will happily queue your requests. Cost per token is the only metric that matters. This is the utility pricing model.

If your AI product is powering a coding agent that a senior engineer is actively waiting on, the economics flip completely. That engineer costs the company somewhere between INR 3000 and INR 4000 per hour of productive time.

If your AI responds in 2 seconds instead of 8 seconds, you are not just providing a better experience. You are directly multiplying the productivity of the most expensive person in the building. At that point, cost per token is irrelevant. You will pay a significant premium for speed, because the alternative is wasting an engineer’s time.

These are not two tiers of the same product. These are two different products that happen to use the same underlying model.

Most AI companies today sell one product. Maybe they have a “basic” and “pro” tier differentiated by model quality or rate limits. Almost none of them have structured pricing around the latency-throughput tradeoff in a way that captures the actual economic value being delivered.

This is a large gap. The teams that close it first will find that their best customers are willing to pay multiples of what they are paying today for the fast tier, while their cost structure for the slow tier can be dramatically reduced through batching and scheduling.

Groq gives Nvidia the architecture to serve both ends of this spectrum simultaneously. The strategic insight is not that Groq is better hardware. It is that Nvidia is acknowledging that inference is not one product and building a system to serve both.

The Five Layer Problem: Where Your Moat Actually Lives?

There is a framing that Huang uses, which I want to push back on slightly, because I think the standard interpretation leads PMs in the wrong direction.

He describes AI as a five-layer stack: power, chips, infrastructure, models, and applications. The usual takeaway from this framing is “figure out which layer you are in and defend your position in it.” That is fine as far as it goes. But it misses the more important question.

Where does your customer’s willingness to pay land, and who captures it?

Consider what is actually happening in AI applications right now. An enterprise pays 50 dollars per user per month for an AI writing tool. The tool spends 30 dollars of that on inference costs, 10 on engineering and hosting, and makes 10 dollars of margin. Now the model provider raises prices because the new model is smarter. Inference cost goes to 40 dollars. Margin goes to zero. The application layer captured the customer, but the model layer captured the economics.

This is not a hypothetical. This is the P&L reality for a large number of AI startups right now.

The moat in the application layer is not the AI. I want to say that again because it is not obvious enough.

The moat in the application layer is not the AI. The AI is available to everyone. The moat is everything that makes your AI better than anyone else’s in a specific context: proprietary training data, deep workflow integration, switching costs built from user behaviour over time, regulatory or compliance advantages, and domain expertise baked into your prompting and evaluation infrastructure.

Strip the AI out of your product and ask what is left. If the answer is “not much,” you do not have a moat. You have a feature built on someone else’s moat.

The model layer is also not as safe as it looks from the outside. The frontier models compete on capability. The efficient models compete on cost. Everything in the middle is getting squeezed from both directions.

A mid-tier model that costs 3x a commodity open source model and is 1.2x smarter is not a sustainable business unless that 1.2x maps directly to a specific high-value task that customers cannot accomplish with the cheaper option.

The infrastructure layer has the most durable economics, and also the highest capital requirements to enter.

The companies winning here are not winning on features. They are winning on integration depth. The harder it is to extract your data from their system, the more your workflows depend on their primitives, the stickier the business. This is not glamorous. It is the most important thing.

What You Should Actually Do

If you are a PM reading this, here is where first principles land for each situation.

1. If you are building a tool with an API, audit it right now for Tool Inversion risk. Not in theory. Actually simulate what happens when an AI agent hits your API at 100 times your current peak load. Your rate limits, your database connection pooling, your authentication flow, your pricing model, all of it was calibrated for humans. Most of it will not survive an enterprise customer deploying a serious agent workflow. Find the cliff before your customers fall off it.

2. If you are pricing an AI product, separate your latency-sensitive and throughput-sensitive use cases. They have different economics and different willingness to pay. If you are charging a flat per-seat fee for a product that some customers use for async batch work and others use for real-time agent workflows, you are simultaneously undercharging your highest-value users and overcharging your lowest. That is not a pricing model. That is a cross-subsidy that your competitors will eventually arbitrage.

3. If you are defining your moat, be honest. Not to your investors. To yourself. Which layer does your advantage actually sit in? Domain data and workflow lock-in are durable. Model quality is not. UI differentiation is not. Feature parity is obviously not. If your honest answer is “our moat is that we were early,” that is not a moat. That is a head start, and head starts expire.

The SQL database was not broken. It worked perfectly for everything it was designed for.

The problem was that it was designed for the wrong future.

If you enjoy reading this article, you will absolutely love our AI Tech and Strategy Book

For Full Detailed cases Studies and AI & Strategy — Download this Book ( 5/5 Rated )

Download the Book

You can also check out our Highest rated AI PM course · 4.9/5 · 500+ enrollments → See testimonials and course details 60% OFF for a limited time — Code: NYE26

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. For more, check out my AI Product Management Course, PM Interview Mastery Course, Cracking Strategy, and other Resources

1. The LAST Product Manager

2. Memory in AI

3. Spotify’s AI Strategy

Everyone talks about AI agents these days.

But very few product teams talk about how these agents actually connect to company data.

To understand why the Model Context Protocol, or MCP is a breakthrough, we first need to look at the main problem in AI development today.

The Integration Bottleneck

Right now, building an AI product requires writing custom code to connect to every single external tool.

If you want your AI to read a map you write an API integration.If you want it to read your database you write another one.

This limits how fast product teams can ship.

Developers spend all their time writing and maintaining this custom code instead of building core features.

Every time an external API changes your team has to fix the connection.

How MCP Changes the Equation?

MCP solves this bottleneck.

It is a new open source standard that unifies how AI agents connect to data sources.

It creates a standard interface between the AI application and external servers.The ecosystem relies on three main parts.

1. First is the host which is the application the user interacts with like a chat interface or a code assistant.

2. Second is the protocol itself which acts as the standard transport layer in the middle.

3. Third are the servers built by data providers like Google or Yahoo.

A single host can connect to many servers at the same time.

When developers build an MCP server it exposes three main capabilities to the client.

First are tools.

These are executable functions like fetching a website or searching a map.

The server provides standard descriptions so the language model knows exactly how to use them.

Second are resources.

These are knowledge bases or plain files in a drive that the AI can read to pull context.

Third are prompts.

These are pre-written templates provided by the server developers, making it easier to interact optimally with specific APIs.

The End to End Workflow

So how does this actually work when a user makes a request?

The process follows a highly structured workflow. It starts with initialisation.

When the app opens, it connects to its configured servers and asks them to list their capabilities. The servers return detailed descriptions of everything they can do.

Then comes the user query.

Imagine you ask your AI assistant for details about a hiking trip.

The host application takes your question and bundles it with the descriptions of all available tools.

It sends this combined information to the language model. The model uses its intelligence to evaluate the request.

It reads the tool descriptions and determines which specific tool to call. It is smart enough to extract the required parameters.

It maps the location to the exact longitude and latitude required by the map tool. The host then calls the appropriate server to execute the operation. The server fetches the data from the API or database and returns the response in a standardised format.

Finally, the model reads this retrieved information and generates the comprehensive answer for the user.

How to Set Up an MCP Server?

Setting up an MCP server is straightforward for developers. You do not need to write complex API wrappers anymore.

If you are using Claude Desktop, you only need to edit one configuration file. On a Mac you navigate to your Library folder —> Application Support —> Claude and open the claude desktop config json file.

On Windows, you look in your AppData folder to find the same file.

You open this file and add a block of text specifying your mcpServers.

Inside this block you tell Claude the specific command to run your local server. You might point it to a local file system or a database connector.

Once you save the file and restart Claude Desktop, it automatically connects. You will see a small plug icon showing the connection is live. If you use a code editor like Cursor, the process is even easier.

You just open Cursor settings and look for the MCP section. You click to add a new server and paste in the command. The editor handles everything else.

This simple setup is exactly why MCP is gaining traction so quickly.

What can be some of the challenges?

This implementation is not going to be easy. There are some very real problems product managers have to solve.

Giving an AI standard access to databases means you need strict security and permissions in place. You have to ensure the AI cannot access sensitive user data it is not supposed to see.

The second challenge is reliability. Standardising responses from hundreds of different APIs requires robust error handling. If an external server fails, the AI needs to fail gracefully instead of breaking the user experience.

MCP has actually lowered the barrier to entry for building complex AI products.

For product managers, lower effort means faster shipping. Faster shipping brings us back to solving core user problems instead of managing infrastructure.

If this framing changed how you think about AI product design, and if you want the full structured path — from AI foundations to RAG, Evals, AI strategy, and interview prep — built specifically for PMs, that is what our course covers.

Highest rated AI PM course · 4.9/5 · 500+ enrollments → See testimonials and course details 60% OFF for a limited time — Code: NYE26

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. For more, check out my AI Product Management Course, PM Interview Mastery Course, Cracking Strategy, and other Resources

MARCH 18, 2028 · LINKEDIN

It received 4,200 applications in 48 hours. The job it replaced was posted 2 years earlier, almost to the day

MARCH 14, 2026 · LINKEDIN

Nobody noticed the titles had changed. They were too busy applying.

We Asked the Wrong Question

For three years, every PM newsletter, every conference panel, every anxious LinkedIn post asked the same question: Will AI replace product managers?

It was the wrong question.

The right question was simpler, and more brutal: What happens when the things product managers do become free?

Not cheaper. Free.

The PRD that took 7 days of procrastination and 1 day of real work? It now takes 12 minutes.

McKinsey estimated in November 2025 that AI agents could perform tasks that account for 44% of US work hours today. Not in 2030. Today, with the tools already deployed, already running inside your company’s tech stack.

That 44% is not random. It is the exact centre of a product manager's role.

The Execution Collapse

For the longest time, building software was an expensive and slow process.

A PM was essential to sit between business and engineering, managing the roadmap and prioritising tasks.

That constraint has vanished. Today, AI tools can build functional prototypes in mere hours. A competent engineer with an AI assistant can replicate core SaaS functionality in weeks.

This leads to a velocity inversion. Previously, engineers needed PMs for customer context, and PMs needed engineers to build. Now, engineers can spin up prototypes without a spec, and PMs can validate concepts using AI mockups without an engineer. The bridge is no longer required because both sides can cross alone.

When execution becomes free, the bottleneck moves upstream.

From “can we build it?” to “should we build it at all?”

The PM who spent their career answering the first question is now competing with a tool that answers it faster and cheaper

The Knowledge Moat Dissolved Overnight

Ask any senior PM what their real competitive advantage is. They will not say ‘I write good PRDs.’ They will say something like: I know this market. I know these customers. I’ve seen what works and what doesn’t. I have judgment that took years to build.

That was true. It was also the moat.

Previously your knowledge of the market, the technology, your own product was valuable. Why? Because it was difficult to get. That barrier is gone.

— Reforge, 2025

LLMs arrived. And the barrier fell.

The specialised knowledge that previously took multiple quarters to develop can now be accessed, synthesised, and applied in minutes or hours. A junior PM with Claude has the same market intelligence that a decade of experience used to produce. Not better. Not worse. The same.

When knowledge stops being scarce, experience stops commanding a premium.

The 10-year PM and the 2-year PM now start their research from the same baseline.

Demand for AI fluency in job postings has grown 7x in two years, which is faster than any other skill. Workers in AI-fluency-required roles grew from 1 million in 2023 to 7 million in 2025.

Companies are not asking for more PM experience. They are asking for a different kind of PM entirely.

What Survives —>The Taste Premium

Here is what the data does not tell you, and what the panic misses entirely.

When execution is free, and knowledge is commoditised, one input becomes more valuable, not less.

Taste.

Taste is editorial judgment. It is knowing what “good” feels like before the data confirms it. It is the ability to look at two technically valid product decisions and know which one will resonate with users and which one will not.

Here is the uncomfortable truth about taste: it cannot be automated because it is not information. It is a judgment about information.

It is the PM who kills the feature AI says will win because she talked to 50 users last week and heard something the data didn’t capture.

It is the PM who sees that the engagement metric is going up but the product is getting worse and has the credibility to say so in a room full of people whose bonuses depend on the metric going up.

That is the Taste Premium. It compounds in an AI world. It does not depreciate.

The Three-Tier PM That Survives

By 2028, the PM role will not disappear. It has forked.

Tier 1: The Orchestrator

Manages fleets of AI agents building products. Thinks in systems, not features. Writes agent instructions instead of PRDs. Evaluates output instead of producing input. This is the most in-demand PM role in 2028. It requires less traditional PM experience and more systems-design thinking.

Tier 2: The Taste Maker

Sets the vision, the feeling, the why this and not that. Cannot be replaced because the job is inherently about human preference, cultural context, and aesthetic judgment that no model has been trained to simulate. This PM earns the Taste Premium. There are fewer of them than there used to be. They earn more.

Tier 3: The Domain Expert

Understands a vertical so deeply, like healthcare, fintech, e-commerce, and logistics, that no horizontal AI agent can replicate the judgment. The PM who spent five years building checkout flows at a major e-commerce company knows something no model trained on general internet text knows. Domain depth is a moat that compounds.

Your job title still says, Product Manager. The 244,000 tech layoffs from last year haven’t hit your team yet. The 44% of work hours that AI can technically automate today are still mostly being performed by humans.

The canary is still alive.

But the feedback loop has started. The knowledge moat has already dissolved. Vibe coding already exists. The Velocity Inversion is already underway. The signals are not weak. They are just early.

You have approximately 18 months before the three tiers become obvious to everyone.

Right now, only the people paying close attention can see them.

Three Things to Do This Week

Not next quarter. This week.

1. Open Claude Code or Cursor today. Build one prototype of one idea you’ve been writing specs about. Ship it to three users before Friday. Feel what it means when execution is free. That feeling is data.

2. List everything you did last week as a PM. Tag each item: knowledge (research, synthesis, analysis) or taste (judgment, vision, direction). Then count. If your taste column has fewer than 5 items, you are primarily operating in the 44% that AI is already automating.

3. Name the one insight that only you can generate, the thing that comes from your specific context, your specific users, your specific domain history. That insight is your Taste Premium. If you cannot name it in one sentence, you do not have it yet.

The window is open. The question is which tier you are building toward.

The Tier 1 and Tier 2 PMs reading this will act on it. The rest will bookmark it and forget it by Monday.

The three action items above are free and enough to start. If you want to fast-track ( step by step ) and want to do it in detail, I built a course for exactly this. Advance AI Product Management + AI Interview Prepraration (40+Videos + 25 Case Studies)

Top Rated 4.9/5 from 600+ PMs · Use NYE26 for 60% off → See testimonials and course details

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. For more, check out my AI Product Management Course, PM Interview Mastery Course, Cracking Strategy, and other Resources

Context × Reasoning × Memory = Perceived Intelligence

We named four memory types. In-context. External. In-weights. KV Cache.

But naming them is not the hard part.

The hard part is this: which memory type do you use, for which feature, and why?

That is what Part 2 answers. And we will answer it using a product your users open fifteen times a day — Instagram.

Instagram is not a single product.

It is a bundle of features, each with a different job, each running a different memory strategy — sometimes on the same screen.

Open Instagram right now. You will find:

• Reels — a feed that knows exactly what keeps you watching

• Meta AI — a conversational assistant built into the search bar and DMs

• Explore — a discovery surface that learns your taste over time

Each of these features has a different answer to the same question: what should the AI know about you, and when should it know it?

Most PMs look at these as three different features.

The right way to look at them is as three different memory architectures producing three different product outcomes.

Let’s discuss Meta AI on Instagram

When you type a message into Meta AI inside Instagram, four memory systems activate simultaneously. Most users see none of this, and most PMs don’t either.

In Context Memory

In-context memory handles everything in the current conversation. Your message. Meta AI’s reply. The follow-up question you ask three messages later. All of it lives in a single context window for the duration of that session. When you close the chat, it is gone.

In Weight Memory

In-weights memory is the foundation. Meta AI’s base model was trained on billions of documents. It knows what pasta is. It knows the difference between a North Indian restaurant and a Italian restaurant. It understands that something exciting for a Friday night means something different in Bangalore than it does in Paris. None of that required you to explain it. It is baked into the model’s parameters from training.

External Memory

External memory is where it gets interesting. When you ask Meta AI for restaurant recommendations in your city, it does not guess. It retrieves. Meta’s interest graph — built from your likes, saves, follows, watch history, and search patterns — gets injected into the prompt before the model responds. The model did not learn your preferences. It looked them up.

KV Cache Memory

KV cache memory is invisible to you but critical to Meta’s infrastructure. The system prompt that tells Meta AI how to behave — its tone, its safety rules, its persona guidelines — is the same across hundreds of millions of user sessions. Rather than re-processing that system prompt from scratch for every conversation, the model’s intermediate computations are cached and reused. This is not a product feature. It is a cost and latency optimisation. But at Meta’s scale, it is what makes the economics work.

Now look at Reels — a completely different memory stack

Reels does not have a context window problem.

It does not forget you when you close the app. It does not start from zero when you open it again tomorrow.

That is because Reels does not use in-context memory at all.

Everything Reels knows about you lives in external memory — a continuously updated store of your engagement signals.

Every video you watch to completion is a signal. Every video you skip after two seconds is a signal. Every creator you follow, every sound you save, every comment you leave — all of it writes into an external memory store that the recommendation engine reads from the moment you open the app.

This is why Reels feels more intelligent over time than Meta AI does. It is not because the recommendation model is smarter than the language model. It is because Reels was architected with persistent external memory, and Meta AI largely was not.

The Goldfish Problem from Part 1? Reels solved it. Meta AI has not.

The PM decision framework: Memory Fit Matrix

So how do you decide which memory type to use for a given feature? Here is the framework.

Ask three questions about each piece of information your feature needs to work well.

1. How often does it change?
   Information that changes every message belongs in in-context memory. Information that changes over weeks or months belongs in external memory. Information that almost never changes can be baked into the model via fine-tuning.

2. Is it shared across users or specific to one user?
   A system prompt is shared. Your interest graph is not. Shared, stable information is a candidate for KV caching. Personalised, dynamic information needs external retrieval.

3. What breaks if you get it wrong?
   If you stuff the wrong information into the in-weights memory through premature fine-tuning, you cannot fix it without a full retraining cycle. If you miss something in in-context memory, the damage is limited to that session. The higher the cost of being wrong, the more you want the information in an editable, retrievable external store rather than baked into weights.

A PM who understands this will make better architectural calls than one who only asks can we use RAG for this?

If this framing changed how you think about AI product design, and if you want the full structured path — from AI foundations to RAG, Evals, AI strategy, and interview prep — built specifically for PMs, that is what our course covers.

Highest rated AI PM course · 4.9/5 · 500+ enrollments → See testimonials and course details 60% OFF for a limited time — Code: NYE26

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. For more, check out my AI Product Management Course, PM Interview Mastery Course, Cracking Strategy, and other Resources

But very few product teams understand what actually makes AI feel intelligent.

It is not the model. It is not the UI. It is not even the speed.

It is memory.

Right now, most AI products operate on a single memory variable.

What the AI knows = What’s in the current conversation window

The session ends. The knowledge disappears. The next conversation starts from zero.

To understand why, we need to examine what determines whether an AI product feels magical or mediocre.

First Principle Breakdown of AI Usefulness…

AI product value depends on three multiplied factors.

Context × Reasoning × Memory = Perceived Intelligence

Most teams obsess over Reasoning. They chase better models, bigger parameters, faster inference.

But there is a problem. Reasoning without memory is like hiring a brilliant employee who forgets everything at the end of every day.

You get a fast answer. But you never get a useful relationship.

This is the gap that separate AI tools people demo from AI tools people actually rely on. Because an AI product with well-designed memory compounds. The longer the user stays, the more context the AI holds. The more context the AI holds, the more useful it becomes. The more useful it becomes, the harder it is to leave, basically you are increasing the switching cost.

So what does it mean by Memory in AI?

Before we go further, let’s understand what memory is because it is being used very loosely nowadays.

When we talk about memory in AI systems, we are really talking about one question: What does the model know, and when does it know it?

There are four distinct types of memory in LLM-based products. Each works differently. Each has a different cost and a different product implication.

In-Context Memory

This is the most immediate form of memory. The AI reads everything in the active session like your messages, its responses, any documents you've pasted and uses that to respond. When the session ends, it's gone.
Context windows have token limits. You can't fit infinite history into them. And the longer the context, the more expensive the inference.

External / Retrieval Memory

External memory is like a database outside the model that gets queried at runtime and injected into the context.

The AI doesn’t store anything itself. Instead, relevant information is retrieved from an external store like a vector database, a CRM, a document store and inserted into the prompt before the model responds.

Here the response quality is determined by the retrieval quality.

In-Weights Memory

This is the kind of memory where the knowledge is baked into the model during training or fine-tuning. It lives in the billions of parameters of the model itself. You can’t “update” it without retraining and retraining is expensive.

Fine-tuning makes sense when your domain has a consistent, learnable structure .i.e legal, medical, financial. It's a long-term investment, not a quick feature. Don't reach for fine-tuning when retrieval will do the job.

In-Cache / KV Cache Memory

This is the most technical type and the most invisible to users. When the same system prompt or document is used repeatedly, the model's intermediate computations (Key-Value cache) can be stored and reused. The model doesn't re-read it from scratch every time.

The Goldfish Problem

Let’s look at what happens when a product team ignores these memory types and relies entirely on a blank-slate session, the Goldfish Problem.

Imagine a user spends twenty minutes interacting with an AI financial planner. They input their salary, their risk tolerance, and their goal to buy a house in three years. The AI gives them a brilliant, personalised breakdown.

The next day, the user logs back in and asks, How much should I allocate to index funds this month?

The AI responds: I can help with that! To get started, what is your current salary and risk tolerance?

The magic is instantly broken. The user realizes they aren’t talking to an intelligent assistant; they are talking to a calculator that resets every time the screen turns off. That right there is a churn event.

If this article raised more questions than it answered — that is a good sign. It means you can see the gap.

If this article made you think differently about AI products, Part 2 and Part 3 will go deeper into memory architecture.

And if you want the full structured path — from AI foundations ( ML Algorithms, Systems) to Vibe Coding, RAG, Evals, AI Strategy, AI Pricing to interview prep — in one place built for PMs, that is what our course covers.

Highest rated AI PM course · 4.9/5 · 500+ enrollments → See testimonials and course details 60% OFF for a limited time — Code: NYE26

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. For more, check out my AI Product Management Course, PM Interview Mastery Course, Cracking Strategy, and other Resources

He had 7 years of product experience, two successful product launches, and a strong portfolio. He was confident going in.

He came out completely blank.

The interviewer had asked him:

How would you write evaluation metrics for a travel booking agentic workflow?

He had never heard the word “evals” before that moment.

Here is the thing.

The PM interview is not what it was two years ago.

Most people preparing for PM roles in 2025 and 2026 are still reading the same prep material from 2021. Decode PM, Cracking the PM Interview, a few mock interviews, and some STAR format practice. That was enough back then.

It is not enough anymore.

And the people who figure this out late are paying a real price.

Not just rejection, but the particular sting of rejection after you genuinely thought you had prepared.

That is a harder thing to recover from.

So let me walk you through what is actually changing, and why most candidates are not ready for it.

The interview shifted

When companies like Google, Meta, Notion, and a hundred AI-first startups started hiring AI PMs, they did not just add a couple of AI questions to the existing format. They rewrote the format.

You now get questions that sound like this:

• “How would you measure the success of GPT 5.0?”

• “Design a RAG system for an enterprise knowledge base. What are your eval criteria?”

• “Your AI feature has a 12% hallucination rate. Walk me through how you would reduce it.”

These are not strategy questions dressed up in AI language.

These are technical product questions. And the interviewer is not looking for a vague answer about leveraging AI to improve user experience. They want to know if you actually understand how these systems work.

Most candidates do not.

Why is this happening now?

AI products are not just features anymore.

They are the product. When the core of what you are building is a language model, a recommendation engine, or an agentic workflow, then the PM sitting on top of that needs to speak the language of the system.

Think about it from the hiring manager’s side.

They need someone who can sit in a technical review and understand why the model is degrading.

Someone who can write a proper evaluation framework.

Someone who can tell the difference between a precision problem and a recall problem, and what each one means for the user experience.

If you cannot do that, you are not really managing the AI product. You are just writing user stories on top of it.

That is the gap most candidates have right now. And it is not their fault entirely. The material to prepare for this simply was not available in any structured form until very recently.

The supply and demand reality

Here is something that makes this more urgent than it might seem.

AI PM roles are genuinely sought after right now.

Everyone with any product experience is pivoting toward AI. You have traditional PMs rebranding themselves.

You have engineers trying to move into product. You have MBA graduates who did an AI course on Coursera.

Everyone is showing up to the same interviews.

The companies on the other side are few. The good roles are fewer. And the bar for what counts as AI PM ready is rising every quarter.

When supply is high and the bar keeps moving up, the margin between getting the role and not getting it becomes razor-thin.

One bad answer on an eval question. One moment where you stumble on what RAG actually means. That is sometimes all it takes.

What the unprepared candidate looks like

Let me be specific about where people go wrong, because it is not always obvious.

The first mistake is thinking that using AI tools makes you an AI PM. It does not.

Using ChatGPT, playing with Midjourney, and building a quick Notion AI workflow, these are user experiences.

They have nothing to do with building AI products. Interviewers have become very good at separating the two.

The second mistake is treating AI PM prep like traditional PM prep with a few AI keywords added.

You study product sense, execution, metrics, and then you memorize a few things about large language models. That does not hold up when the interviewer goes one level deeper.

The third mistake is not knowing what you do not know. This one is the most dangerous.

Many candidates feel ready because they have been in tech for years and have absorbed some AI knowledge by proximity. But there is a difference between ambient knowledge and working knowledge. The interview exposes that gap quickly.

What you actually need to prepare

The honest answer is that you need to understand the systems you would be managing. Not at an engineer’s depth, but at a PM’s depth. There is a difference, and it is a specific kind of knowledge.

• You need to understand how retrieval-augmented generation works well enough to answer a system design question about it.

• You need to know what model evaluation actually involves, what an eval framework looks like, and why it matters for product quality.

• You need to understand agentic workflows at a conceptual level, because that is where AI products are going in 2026.

• You also need the strategic layer.

• AI pricing is a distinct problem from traditional software pricing.

• AI success metrics are different because the outputs are probabilistic.

• AI product sense requires thinking about reliability, not just usability.

And if you want to stand out, vibe coding helps. Being able to prototype an AI idea quickly, without waiting for engineering bandwidth, is something that impresses interviewers and actually makes you a better PM on the job.

None of this is impossible to learn. It just requires learning it in the right sequence, with the right depth.

Where most people look for this, and why it does not work

The usual routes are scattered and incomplete.

YouTube has surface-level content. Blog posts cover individual concepts but not the full picture.

Existing PM courses were built before AI PM was a real category.

What you need is something that moves from AI foundations to technical architecture to advanced systems like RAG and agents, and then into interview-specific preparation. That whole path, in one place, built specifically for PMs.

Our Course is TopRated 4.9/5, that too from more than 500 People.

It has 40+ Videos & 25+ Case Studies. Click here for Testimonial and Description of the course. ( 60% flat Discount for limited time frame)

If the gap I described in this article sounds familiar, this course was built for you.

The gap is real. The good news is it is closable. But it takes more than watching a few YouTube videos about generative AI.

Start with understanding what you actually do not know. That is usually where the real preparation begins.

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. For more, check out my AI Product Management Course, PM Interview Mastery Course, Cracking Strategy, and other Resources

1. Spotify’s AI Strategy

2. AI Product Metrics ( AI PM Interview Question )

3. AI Product Management 2026 — Winner’s Playbook

In our last article, we discussed the massive Context Windows of modern LLMs; it’s time to upgrade ourselves.

Imagine you are a Senior Product Manager at YouTube.

You are in charge of building a new “Ask this Video” Generative AI feature.

Ask this Video - feature is an AI-powered conversational tool on YouTube that allows viewers to interact directly with the content they are currently watching.

By analysing the video's transcript in real-time, it enables users to request summaries, extract specific facts, or clarify concepts without interrupting playback.

You have a massive problem: AI models are incredibly smart, but they know absolutely nothing about the 3-hour podcast a creator uploaded five minutes ago.

When a viewer clicks the “Ask” button and types, “Summarise the part where they discuss the new camera features and skip the sponsor read,” the AI cannot just guess the answer.

It needs the exact, up-to-the-minute context of that specific video.

How do you build a system that accurately leverages millions of hours of dynamic, unstructured video data without breaking the bank?

Option 1: Prompt Stuffing (The Context Window)

With new models boasting massive context windows, you could try to inject the entire 3-hour transcript, the uploader’s channel history, and the top 1,000 comments into the prompt every time a viewer asks a question.

But this has terrible Unit Economics. You pay per token. Stuffing a massive transcript into every single query will charge you a fortune, and it takes the model excessive time to process.

Plus, the model might get lost in the middle, confusing something said in minute 10 with something said in minute 150.

Option 2: Fine-Tuning the Model

You could retrain the underlying weights of the LLM on your massive database of YouTube transcripts.

But it misses Dynamic Context. Over 500 hours of video are uploaded to YouTube every single minute.

Fine-tuning is expensive, slow, and static. If a creator uploads a breaking news video at 2:00 PM, your fine-tuned model won’t know about it until the next massive training run.

Now, let’s see how RAG (Retrieval-Augmented Generation) solves the Problem.

But before that, let’s understand: What is OpenRAG?

OpenRAG is an open-source platform where all the necessary tools are tightly integrated, making it super easy to set up an effective agentic RAG system in just a few minutes.

Instead of spending months building a custom data pipeline to connect your AI to your video servers, OpenRAG gives you a pre-configured architecture out of the box.

Why do we need OpenRAG?

We need it because blindly feeding data to AI is inefficient and inaccurate.

• Instead of reading the whole 3-hour transcript, RAG searches the database, finds the exact two paragraphs from minute 45 where the camera is discussed, and feeds only those specific details to the AI. This keeps token costs incredibly low and responses lightning-fast.

• You need a system that gives you complete freedom to swap out underlying AI models or connect totally new external databases (like a database for YouTube Shorts) without writing complex backend code.

How OpenRAG Works

For a complete and proper RAG system to work, it requires three main components. OpenRAG achieves this with three powerful tools:

1. Docling (Intelligent Data Entry)

Suppose you are processing a highly technical tutorial video.

The data isn’t just spoken words; it’s a mix of auto-generated transcripts, on-screen text (OCR), and chapter metadata. Traditional parsers dump all this raw text into a file, destroying the timeline structure.

Docling is the smart parser. It identifies these different components and extracts them properly, keeping timestamps aligned with the text. If this isn’t done right, your system fills with junk data, and the AI quotes a timestamp that points to the wrong part of the video.

2. OpenSearch (Fast Searching)

Once Docling processes the video transcripts and metadata, the data goes directly to OpenSearch.

This is your memory bank. It stores video data chunks as vector representations (mathematical embeddings of text).

When a viewer asks, “When do they talk about the battery life?”, OpenSearch performs similarity searches to retrieve the exact transcript chunks that mathematically match that concept, even if the speaker said power efficiency instead of battery life.

3. Langflow (The Main Wiring)

Think of Langflow as the execution engine.

It connects your AI models, your OpenSearch database, and the YouTube app interface together.

It provides a Visual Studio UI where you can make custom changes directly in the workflow. When you add your transcript database here, you give it a unique, descriptive name.

This is crucial so the AI agent knows to pull from the video content.

Challenges with OpenRAG Systems

• If Docling fails to parse a poorly auto-captioned video (where words are mumbled or overlapping), OpenSearch retrieves garbage text, and the LLM confidently hallucinates an incorrect answer.

• Vector databases can be computationally heavy. Efficient indexing is required so viewers aren’t left staring at a loading spinner.

• Adding an orchestration layer (Langflow) and a retrieval step adds latency before the LLM even begins generating the first word of the response.

If you are managing an OpenRAG-based YouTube AI companion, track these:

• Retrieval Latency: How many milliseconds does it take for OpenSearch to find the relevant 30-second chunk of the transcript?

• Time to First Token (TTFT): How long does the user wait from clicking “Ask” to seeing the very first word generated by the AI?

• Timestamp Accuracy: Did the retrieval engine actually fetch the correct segment? If the AI provides a “Jump to 12:04” link, users will instantly downvote the answer if the timestamp is wrong.

• Token Efficiency: How many tokens are you sending in the augmented prompt vs. how many were necessary? This directly impacts the feature’s computing cost at YouTube scale.

Crack AI PM Interview | 500+ Success Stories | 4.9/5 Rated Course (having real AI PM Interview Questions from Google, OpenAI, Anthropic, etc.) -
(35+ Videos) & (Extra 25+ Real Case studies as well).

For New Year, we are giving EXTRA 60% OFF on our AI PM Flagship Course for very limited Time | ( 35+ Videos ) & ( Extra 25+ Real Case studies as well )
Coupon Code — NYE26 , Course Link — Click Here

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. For more, check out my AI Product Management Course, PM Interview Mastery Course, Cracking Strategy, and other Resources

Spotify is a leading global audio streaming platform.

It provides users with access to millions of songs and podcasts. The platform connects creators with listeners worldwide.

It operates on a freemium business model. Users can choose a free ad-supported tier or a paid premium subscription for uninterrupted listening.

What is the ultimate Goal of Spotify?

The primary business goal of Spotify is to maximise user engagement and retention while growing its subscriber base.

The company wants to become the ultimate audio ecosystem. They aim to keep users on the platform for as long as possible.

Higher engagement directly leads to better ad revenue from free users.

It also leads to higher retention rates for premium subscribers. This ensures long-term business profitability.

So what should be the North Star Metric?

A North Star metric is a single metric that best captures the core value a product delivers to its customers.

The North Star metric for Spotify is Time Spent Listening.

Increased listening time means users are discovering relevant content and finding value in the platform.

This metric perfectly aligns user satisfaction with business growth. A user spending hours on the platform is highly unlikely to cancel their subscription.

First Principle Breakdown of North Star Metric

Time Spent Listening can be expressed as a multiplication of three key terms.

Time Spent Listening = Daily Active Users x Sessions per User x Average Session Duration

• Daily Active Users represent the breadth of the user base.

• Sessions per User represents the frequency of engagement.

• Average Session Duration represents the depth of engagement.

Improving any of these three terms will mathematically increase the overall Time Spent Listening.

How will the AI strategy impact the North Star Metric?

AI is the core engine driving these three levers today.

AI algorithms analyse listening habits to recommend highly personalised content. Better recommendations make users open the app more frequently. This directly increases the Sessions per User.

Users do not skip tracks when the algorithm plays exactly what they want to hear. This extends the Average Session Duration.

AI also helps reactivate dormant users through personalised notifications. This reactivation increases Daily Active Users.

All these AI-driven improvements multiply together to exponentially increase the overall Time Spent Listening.

AI Strategic Initiatives

Spotify is actively executing an aggressive AI strategy to transition from a passive streaming app into an interactive platform. They are rolling out several key initiatives.

First is the AI DJ

This feature uses a synthesised voice and generative AI to curate a personalised radio experience.

It talks to the user and explains why specific songs were chosen. This creates a deeply engaging experience that increases session duration.

Second is Prompted Playlists

Users can type simple text prompts to generate custom playlists.

This feature transforms passive listeners into active participants. It directly boosts session frequency.

Third is internal engineering velocity

Spotify uses an internal AI tool called Honk.

This tool helps developers write code and fix bugs directly from mobile devices. Faster software development means faster feature releases for users.

Fourth is AI music derivatives.

The platform is developing frameworks to allow creators to monetize AI enabled covers and remixes of their original music.

This expands the content library and attracts more users.

Way Forward AI Strategy

The future AI strategy for Spotify will focus on deep cross-format integration and hyper-contextual awareness.

The platform will predict what a user wants to hear based on their real-time environment or daily calendar.

The AI will become a proactive companion rather than a reactive tool. We will likely see AI negotiating licensing deals or automatically creating dynamic audiobooks.

The strategy will shift towards building a proprietary data moat. This data moat will ensure the AI understands user psychology better than any competitor.

If you like this article, you will absolutely love our AI Product Management Course ( having real AI PM Interview Questions from Google, OpenAI, Anthropic, Amazon, Nvidia, Booking, etc.) - ( 35+ Videos ) & ( Extra 25+ Real Case studies as well ) | 4.9 Rated out of 5

For New Year, we are giving EXTRA 60% OFF on our AI PM Flagship Course for very limited Time | ( 35+ Videos ) & ( Extra 25+ Real Case studies as well )
Coupon Code — NYE26 , Course Link — Click Here

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. For more, check out my AI Product Management Course, PM Interview Mastery Course, Cracking Strategy, and other Resources

For New Year, we are giving EXTRA 60% OFF on our AI PM Flagship Course for very limited Time
Coupon Code — NYE26 , Course Link — Click Here

Now back to the article

Imagine you are a Senior Product Manager at Amazon.

You are building a new GenAI feature, an interactive shopping assistant, right on the product details page.

A customer is looking at a complex, high-end DSLR camera.

To make the AI truly helpful, you load the camera’s entire 50-page technical manual, hundreds of customer reviews, and your rigid system instructions into the LLM’s context window.

The user types: Is this camera weather-sealed?

Spinning loading wheel. —> 6 seconds later —> Yes.

Then the user asks: What’s the return policy on this?

Spinning loading wheel —> 8 seconds later —> You have 30 days.

You realise you have a massive problem.

Also, your compute costs are destroying the feature’s unit economics.

Why? Because for every single question the user asks, the LLM is re-reading and re-processing that massive 50-page manual from scratch.

Today, we are doing a First Principle Breakdown of the infrastructure solution to this exact problem: Prompt Caching

What Prompt Caching is NOT

Let’s clear up a common misconception. When you tell an engineer you want to cache the responses, they might think of traditional output caching (like caching a standard SQL database query).

Output caching means storing the final generated response.

If User A asks What is the capital of France? and User B asks the same thing, you just serve the cached answer.

But in our scenario, users are asking different dynamic questions about the same static product manual. Output caching won’t help us here.

Prompt caching tackles the input bottleneck. It caches the prompt itself.

The First Principles of Prompt Caching

To understand why this saves your latency and cost, we need to look under the hood at how Transformers process text.

When you send your massive prompt to an LLM, before it can generate a single token of its answer, it goes through the prefill phase.

For every single token in your 50-page manual, the model computes Key-Value (KV) pairs across dozens of transformer layers.

Think of these KV pairs as the model’s internal mathematical understanding of your prompt—how every word relates to every other word.

Computing these KV pairs for thousands of tokens requires millions of operations. It is computationally expensive and painfully slow.

Prompt caching simply stores these precomputed KV pairs.

When your Amazon shopper asks their second question, the system recognises the product manual, retrieves the cached mathematical understanding, and only processes the few tokens of the new question.

The Prefix Matching Rule: Structuring Your Prompt

For this to work, the LLM relies on Prefix Matching.

The cache system matches your prompt token-by-token from the absolute beginning. The exact moment it encounters a token that differs from what is cached, caching stops, and expensive normal processing takes over.

This means your prompt structure directly dictates your unit economics.

If you are building this Amazon assistant, you must structure your prompt to put all the static content first:

1. System Instructions (You are a helpful Amazon shopping assistant.)

2. Few-Shot Examples (How to format the output)

3. The 50-Page Product Manual (The static context)

4. The User’s Question (The dynamic content: What’s the return policy?)

If you make the mistake of putting the user’s dynamic question at the top of the prompt, the cache will fail immediately on the very first differing token.

The LLM will have to recalculate the KV pairs for the entire 50-page manual again. Always put the dynamic components at the very end.

Key Takeaways while Execution

When you sit down with your engineering team to implement this, keep these constraints in mind:

• Minimum K Tokens: Prompt caching isn’t for simple queries. You typically need at least K tokens to initiate caching. Below that threshold, the overhead of managing the cache exceeds the compute savings.

• Time-to-Live (TTL): Caches do not last forever. Providers usually clear them after 5 to 10 minutes to keep data fresh and manage memory (though some architectures allow up to 24 hours).

• Implicit vs. Explicit API Calls: Some model providers handle this prefix matching automatically. Others require your engineers to explicitly mark which parts of your prompt should be cached in your API calls.

By leveraging prompt caching, we can turn a slow, expensive AI feature into a highly responsive, cost-effective product that your customers actually want to use.

If you like this article, you will absolutely love our AI Product Management Course ( having real AI PM Interview Questions from Google, OpenAI, Anthropic, Amazon, Nvidia, Booking etc) - ( 35+ Videos ) & ( Extra 25+ Real Case studies as well )

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. For more, check out my AI Product Management Course, PM Interview Mastery Course, Cracking Strategy, and other Resources

See this question recently asked in a PM Interview:

Develop a strategy for OpenAI’s fine-tuning capabilities?

We will see how to answer this question like the Top 1%.

First Principles Breakdown

First, let’s break down using First Principle Thinking and ask some clarifying questions.

If you look at the concept of fine-tuning on a broad level, we need to ask three fundamental questions:

• What is it?

• What is it required for?

• And are there any constraints?

What is it?

At its core, fine-tuning is taking a massive, pre-trained foundation model—like GPT-4o—and training it further on a much smaller, highly curated dataset of your own.

You are essentially providing hundreds or thousands of ‘prompt-completion’ pairs to adjust the model’s internal behaviour.

Why is it required?

This is where candidates mess up.

A lot of people confuse fine-tuning with RAG (Retrieval-Augmented Generation). RAG is for giving the model new facts; it is not training.

But fine-tuning is for teaching the model new behaviour.

In the case of RAG, you always need to attach the document while calling the LLM, which will increase the token cost and inference latency.

Base models are generalists. Fine-tuning bridges the gap between general intelligence and domain-specific expertise.

I hope you are able to get this.

Does it have any constraints?

Fine-tuning is computationally expensive and requires high-quality data.

Clarifying Questions

I hope you are now able to understand the fundamentals of fine-tuning. It’s time to ask some clarifying questions, as the prompt is broad.

1. What is the Objective of building this? Are we trying to defend against open-source models? Are we trying to increase Enterprise Adoption? Or are we just improving our own model performance?
   For this case, let’s assume the interviewer says the primary goal is to Increase Enterprise Adoption, as OpenAI wants to create a moat. This is how you need to ask clarifying questions to narrow your scope.

2. When we talk about fine-tuning, what exactly is on the table? Are we talking about supervised fine-tuning (SFT) only, or does it also include Reinforcement Learning from Human Feedback (RLHF)?
   Let’s assume the interviewer wants us to look at the Full Stack.

3. The final question we can ask is about the modality. Are we sticking strictly to Text, or is Multimodal fine-tuning included?
   We know multimodal is the future, so let’s assume the scope is Multimodal.

Now we have a good idea about the exact boundaries of the strategy we are going to build.

Basically, OpenAI needs to think about building a solution for Enterprises, where an Enterprise can fine-tune the model to get their company’s specific intelligence.

High-Level Strategy

Let’s think about the high-level strategy as to why OpenAI even needs to push fine-tuning as a service. Does it really make sense for enterprises?

A lot of candidates jump directly to the solution, and they don’t talk about the high-level strategy.

You might ask, Why can’t enterprises just use RAG with a General Model? Why do they need a fine-tuned model?

Because RAG is excellent for retrieving facts, but it will not change the fundamental behaviour or tone of the model. Plus, with RAG, you need to spend a lot of tokens every single time you pass context.

So definitely, there is a strong need for fine-tuning.

The second thing is the moat. When enterprises bake their proprietary data and brand voice into a custom model, they create high friction to leave.

This massively increases the Switching Cost. Rebuilding that exact customised behaviour on a competitor’s platform is costly and slow. So OpenAI would want to latch onto this opportunity.

The third thing is that by enabling fine-tuning for Vision and Audio, OpenAI moves from being just a general tool to a specialised industry expert. Think Medical, Legal, Retail—this is verticalized Intelligence.

Till now, we have understood the problem statement and thought about the high-level strategy.

Pain Points for the Customer Segment

Now let’s think about the user segment—in this case, the Enterprises—and what their current pain points are with adopting fine-tuning. There are broadly three problem statements:

1. Data Quality and the Cold Start problem. Organisations have plenty of data, but it is incredibly noisy, unstructured, or unlabelled. They don’t know where to start.

2. Security and Leakage. There is a massive fear at the enterprise level that their highly proprietary data will leak into OpenAI’s general training pool. This creates a lot of friction.

3. Evaluation Complexity. It is incredibly hard to quantify if a fine-tuned model is actually better for their specific use case, or if it is just different.

The Solution

On a very high level, these are the pain points of an enterprise, correct? Now, let’s think about the solution that we need to build as an OpenAI Product Manager.

But before that, find out the most valuable for Money and the advanced Course on AI Product Management and Cracking AI PM Interviews. See the curriculum of this course, having more than 35 Videos and 25 Case Studies. Now you don’t need to spend thousands of dollars; we are running a special discount as well, so do check it out from the link in the description box.

So we can introduce a comprehensive solution: OpenAI Expert Studio.

This would be an end-to-end, secure workspace dedicated entirely to Enterprise Fine-Tuning.

1. The Data Refiner. This solves the Data Quality and Cold Start issue. It’s an LLM-assisted preparation tool that allows enterprises to upload raw, noisy logs. The platform automatically extracts, cleans, and formats this into high-quality Golden Samples that are instantly ready for training.

2. Second, The Private Space. To solve the security fear, this provides a Zero-Data Retention training and hosting environment. This guarantees, right at the infrastructure level, that an enterprise’s custom weights and training data are completely isolated from OpenAI’s general base models.

3. Third, The Eval & Diff Dashboard. This solves evaluation complexity. It acts as a native deployment sandbox where we can run automated regression tests. It provides a visual, side-by-side comparison—a “Diff”—between the base model and the fine-tuned model so enterprises can mathematically prove performance gains before deploying.

Metrics

Now, let’s quickly jump into metrics. What are some of the key metrics you will track to measure the success of this strategy?

1. Number of Custom Models Generating ‘X’ Inferences Per Month. Why? Because simply creating a model isn’t enough. We need to measure both adoption and quality. If a custom model is generating a high volume of inferences, it means it is actively providing value in production.

2. Then, Time-to-First-Model, or TTFM. This measures how effectively our “Data Refiner” tool is working. If we reduce the friction of data cleaning, enterprises should be able to spin up their first test model much faster.

3. Finally, a very important metric is the Enterprise Repeat or Retention Rate. Why is this important? Because when you launch a new capability, there is always a novelty effect where companies will try it once. But a truly successful enterprise product retains users who come back to iterate, retrain, and refine their models over time.

If you like this article, you will absolutely love our AI Product Management Course ( having real AI PM Interview Questions from Google, OpenAI, Anthropic, Amazon, Nvidia, Booking etc) - ( 35+ Videos ) & ( Extra 25+ Real Case studies as well )

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. For more, check out my AI Product Management Course, PM Interview Mastery Course, Cracking Strategy, and other Resources