Product Management Challenges for LLM Creators

Product managers & designers working with AI face a unique challenge: designing a delightful product experience that cannot fully be predicted. Traditionally, product development followed a linear path. A PM defines the problem, a designer draws the solution, and the software teams code the product. The outcome was largely predictable, and the user experience was consistent. However, with AI, the rules have changed. Non-deterministic ML models introduce uncertainty & chaotic behavior. The same question asked four times produces different outputs. Asking the same question in different ways - even just an extra space in the question - elicits different results. How does one design a product experience in the fog of AI? The answer lies in embracing the unpredictable nature of AI and adapting your design approach. Here are a few strategies to consider: 1. Fast feedback loops : Great machine learning products elicit user feedback passively. Just click on the first result of a Google search and come back to the second one. That’s a great signal for Google to know that the first result is not optimal - without tying a word. 2. Evaluation : before products launch, it’s critical to run the machine learning systems through a battery of tests to understand in the most likely use cases, how the LLM will respond. 3. Over-measurement : It’s unclear what will matter in product experiences today, so measuring as much as possible in the user experience, whether it’s session times, conversation topic analysis, sentiment scores, or other numbers. 4. Couple with deterministic systems : Some startups are using large language models to suggest ideas that are evaluated with deterministic or classic machine learning systems. This design pattern can quash some of the chaotic and non-deterministic nature of LLMs. 5. Smaller models : smaller models that are tuned or optimized for use cases will produce narrower output, controlling the experience. The goal is not to eliminate unpredictability altogether but to design a product that can adapt and learn alongside its users. Just as much as the technology has changed products, our design processes must evolve as well.

I saw a job posting for an AI PM at Figma yesterday, and it highlights why "vibe-launching" LLM products is not enough to become an AI PM. Anyone can build an LLM-Wrapper over the weekend, but it's not enough to be an AI PM at companies like Figma, Google, Microsoft, Anthropic, and so on... The reality is, this role was never just about prompting; it’s about owning the Machine Learning lifecycle. I see a lot of aspiring AI PMs focus purely on the "creative" side of GenAI, but if you look closely at these job descriptions, they are asking for three very specific, very technical skills that define the role in 2026: 1. Beyond the "Black Box" (LLMs & ML Fundamentals) Figma asks to "prioritize model improvements." You can't do that if you don't understand what's happening under the hood. For example: 🤖 LLMs (RAG vs. Fine-Tuning): If your chatbot fails, is it a Retrieval (RAG) issue (showed the wrong doc) or a Fine-Tuning issue (wrong tone)? If you don't know the difference, you can spend too much time 'fixing' the wrong thing. 📊 Traditional ML: Think about a Netflix Recommendation System. If it recommends movies you hate, it’s likely a data issue—maybe the model only trained on your weekend habits. You need to understand how Data Collection and Training work so you can spot these bias issues before they ruin the user experience. 2. Owning the "Definition of Good" (Evals & Metrics) In traditional software, a bug is a bug. In AI, "quality" is subjective—and that is terrifying for a roadmap. That’s why you see requirements for "experience with evaluation and iteration." 🥇 LLMs (Golden Datasets): You have to move beyond "it feels good". You need to learn how to build Golden Datasets—essentially a set of ground-truth examples that you define as the perfect answers. When engineering updates the model, you run it against this dataset. If the score drops, you don't launch. 🎯 Traditional ML (Context): You need to understand why an 80% Precision score might be great for a music recommendation, but 90% could be a total disaster for a fraud detection model. 3. Scaling (Reliability & MLOps) Making a demo work for one person is easy. Scaling to 10,000 is hard. When companies ask for "scaling experience," they are talking about the unsexy stuff: Latency, Cost, and Reliability. You need to get familiar with the MLOps landscape—tools like LangSmith or Arize for tracing errors, or Datadog for monitoring latency. ---- The biggest hurdle isn't Python. It's moving from Deterministic code (If A, then B) to Probabilistic outcomes (If A, then probably B). It changes how you think about roadmaps and how you manage user expectations when you can't guarantee a specific output 100% of the time. 👋 If you’re trying to move into an AI PM role, what's the biggest challenge you are facing? --- 💎 I’ve been an AI PM for 6+ years. If you want to dive deeper into AI Product Management, check my comment below for resources!

The biggest problem with LLM-based apps? It’s not the model. It’s not the framework. It’s not even the prompt. It’s everything around them. We’re not just calling an API. We’re integrating a stochastic system into a world that expects deterministic behavior. 𝗟𝗟𝗠𝘀 𝗮𝗿𝗲 𝗻𝗼𝘁 𝗱𝗲𝘁𝗲𝗿𝗺𝗶𝗻𝗶𝘀𝘁𝗶𝗰 𝗰𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁𝘀 Same prompt ≠ same output. They predict tokens, not answers. You don’t pass parameters—you design prompts. That makes it hard to predict outputs, validate correctness, or reproduce behavior. 𝗣𝗿𝗼𝗺𝗽𝘁𝗶𝗻𝗴 𝗶𝘀𝗻’𝘁 𝗽𝗿𝗼𝗴𝗿𝗮𝗺𝗺𝗶𝗻𝗴 No function signatures. No modular reuse. Tiny prompt changes can break results. Long prompts increase latency. And prompts don’t always work the same across workflows or chains. 𝗥𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 𝗮𝗱𝗱𝘀 𝗺𝗼𝗿𝗲 𝘂𝗻𝗰𝗲𝗿𝘁𝗮𝗶𝗻𝘁𝘆 In RAG, you’re combining semantic search, reranking, and formatting. Each step adds noise. You’re generating over possibly irrelevant context. Now the system is doubly stochastic: retrieval + generation. 𝗧𝗲𝘀𝘁𝗶𝗻𝗴 𝗟𝗟𝗠𝘀 𝗶𝘀𝗻’𝘁 𝘀𝘁𝗿𝗮𝗶𝗴𝗵𝘁𝗳𝗼𝗿𝘄𝗮𝗿𝗱 There’s no .assertEqual(). Heuristic metrics are flawed. Human evals are expensive and inconsistent. Even stable outputs might still be wrong. 𝗦𝗰𝗮𝗹𝗶𝗻𝗴 𝗺𝗮𝗸𝗲𝘀 𝗶𝘁 𝗲𝘃𝗲𝗻 𝗵𝗮𝗿𝗱𝗲𝗿 LLMs are slow, expensive, and limited by token windows. You need chunking, caching, windowing, reranking, fallback logic. You’re not calling a model—you’re orchestrating a distributed system. 𝗗𝗲𝗯𝘂𝗴𝗴𝗶𝗻𝗴 𝗶𝘀 𝗮 𝗯𝗹𝗮𝗰𝗸 𝗯𝗼𝘅 No stack traces. No explanations. Logs give you input/output, not reasons. Prompt tweaks can cause side effects far from where you made the change. 𝗘𝘅𝗽𝗲𝗰𝘁𝗮𝘁𝗶𝗼𝗻𝘀 ≠ 𝗿𝗲𝗮𝗹𝗶𝘁𝘆 People expect memory, perfect instructions, stable outputs, and truth. LLMs forget, hallucinate, and drift based on sampling. Without scaffolding, they feel brittle and inconsistent. 𝗜𝗳 𝘆𝗼𝘂'𝗿𝗲 𝗹𝗼𝗼𝗸𝗶𝗻𝗴 𝗳𝗼𝗿 𝘃𝗶𝗯𝗲𝘀, 𝗹𝗲𝘁 𝗺𝗲 𝘁𝗲𝗹𝗹 𝘆𝗼𝘂 𝗶𝘁'𝘀 𝗼𝗻𝗹𝘆 𝗽𝗮𝗶𝗻 LLMs are probabilistic pattern matchers—not deterministic components. Building with them means thinking in systems, not functions. It means controlling chaos, not eliminating it. If your LLM system feels fragile, you’re not alone. You’re just facing reality. And it’s solvable—if you design for it. ♻️ Repost to share these insights. ➕ Follow Shivani Virdi for more.

Nobody tells you these things about deploying LLMs in production. I learned them the hard way, across Airtel, PwC. Here are 5 things I wish I'd known earlier: 1. Latency will surprise you more than accuracy. Your model can be brilliant and still fail in production because it takes 4 seconds to respond. At Airtel's call volumes, even 800ms matters. Optimise inference from day one not as an afterthought. 2. Prompt drift is a real problem. The prompt that works perfectly in staging quietly degrades in production as real user inputs arrive. Build prompt versioning and regression testing into your workflow like you would for any other piece of code. 3. Your vector DB choice will come back to haunt you. FAISS, Pinecone, Weaviate they all have different tradeoffs at scale. I've seen retrieval pipelines that worked beautifully at 10K documents completely fall apart at 10M. Test at production volumes early. 4. Hallucination is a product problem, not just a model problem. You can't fully eliminate it. So you design around it with guardrails, confidence thresholds, and fallback flows. The teams that win treat hallucination as a UX challenge, not just a research one. 5. Monitoring LLMs is nothing like monitoring traditional ML. There's no single metric that tells you your LLM is performing well. You need a mix latency, retrieval quality, user feedback signals, and regular human eval. Build your observability stack before you go live, not after. The gap between a working LLM demo and a production-grade LLM system is enormous. Most teams underestimate it. The ones who've shipped it don't. What would you add to this list? #LLMs #GenerativeAI #MLEngineering #AIIndia #DataScience

After two decades in technology, one pattern becomes very clear: Building a working demo is easy. Building a system that behaves reliably in production is where the real engineering begins. The same applies to LLM applications. Anyone can connect an LLM to a prompt and get an impressive response. But once that app is used by real employees, real customers, real business teams, and real workflows, the expectations change completely. Now the system needs to handle unclear inputs. It needs to retrieve the right context. It needs to avoid hallucinations. It needs to protect sensitive data. It needs to control tool access. It needs to be monitored, tested, audited, and improved continuously. That is why guardrails and monitoring are not “nice-to-have” layers. They are part of the core architecture. A serious LLM application needs more than a powerful model. It needs: A clear use case. The right model selection. A trusted RAG layer. A disciplined prompt structure. Input validation. Output validation. Tool and API controls. Observability. Evaluation. Secure deployment. In my experience, the projects that fail usually do not fail because the model was incapable. They fail because the surrounding system was not designed with enough discipline. No ownership. No risk model. No evaluation loop. No monitoring baseline. No access control. No production thinking. Enterprise AI cannot be treated like a chatbot experiment. It has to be engineered like any other critical software system. The model is only one component. The architecture around it is what determines whether the application becomes trusted, scalable, and useful in the real world. That is the shift every technology leader needs to understand.

AI in real-world applications is often just a small black box; The infrastructure surrounding the AI black box is vast and complex. As a product builder, you will spend disproportionate amount of time dealing with architecture and engineering challenges. There is very little actual AI work in large scale AI applications. Leading a team of outstanding engineers who are building an LLM product used by multiple enterprise customers, here are some lessons learned: Architecture: Optimizing a complex architecture consisting of dozens of services where components are entangled, and boundaries are blurred is hard. Hire outstanding software engineers with solid CS fundamentals and train them on generative AI. The other way round has rarely works. UX Design: Even a perfect AI agent can look less than perfect due to a poorly designed UX. Not all use cases are created equal. Understand what the user journey will look like and what are the users trying to achieve. All applications do not need to look like ChatGPT. Cost Management: With a few cents per 1000 tokens, LLMs may seem deceptively cheap. A single user query may involve dozens of inference calls resulting in big cloud bills. Developing a solid understanding of LLM pricing and capabilities appropriate for your use case and the overall application architecture can help keep costs lower. Performance: Users are going to be impatient when using your LLM application. Choosing the right number and size of chunks, fine-tuned app architecture, combined with the appropriate model can help reduce inference latency. Semantic caching of responses and streaming endpoints can help create a 'perception' of low latency. Data Governance: Data is still the king. All the data problems from classic ML systems still hold. Not keeping the data secure and high quality can cause all sorts of problems. Ensure proper access and quality controls. Scrub PII well, and educate yourself on all applicable regulations. AI Governance: LLMs can hallucinate and prompts can be hijacked. This can be major challenge for an enterprise, especially in a regulated industry. Use guardrails are critical for any customer-facing applications. Prompt Engineering: Very frequently, you will find your LLMs providing answers that are incomplete, incorrect or downright offensive. Spend a lot of time on prompt engineering. Review prompts very often. This is one of the biggest ROI areas. User Feedback and Analytics: Users can tell you how they feel about the product through implicit (heatmaps and engagement) and explicit (upvotes, comments) feedback. Setup monitoring, logging, tracing and analytics right from the beginning. Building enterprise AI products is more product engineering and problem solving than it is AI. Hire for engineering and problem solving skills. This paper is a must-read for all AI/ML engineers building applications at scale. #technicaldebt #ai #ml

Few Lessons from Deploying and Using LLMs in Production Deploying LLMs can feel like hiring a hyperactive genius intern—they dazzle users while potentially draining your API budget. Here are some insights I’ve gathered: 1. “Cheap” is a Lie You Tell Yourself: Cloud costs per call may seem low, but the overall expense of an LLM-based system can skyrocket. Fixes: - Cache repetitive queries: Users ask the same thing at least 100x/day - Gatekeep: Use cheap classifiers (BERT) to filter “easy” requests. Let LLMs handle only the complex 10% and your current systems handle the remaining 90%. - Quantize your models: Shrink LLMs to run on cheaper hardware without massive accuracy drops - Asynchronously build your caches — Pre-generate common responses before they’re requested or gracefully fail the first time a query comes and cache for the next time. 2. Guard Against Model Hallucinations: Sometimes, models express answers with such confidence that distinguishing fact from fiction becomes challenging, even for human reviewers. Fixes: - Use RAG - Just a fancy way of saying to provide your model the knowledge it requires in the prompt itself by querying some database based on semantic matches with the query. - Guardrails: Validate outputs using regex or cross-encoders to establish a clear decision boundary between the query and the LLM’s response. 3. The best LLM is often a discriminative model: You don’t always need a full LLM. Consider knowledge distillation: use a large LLM to label your data and then train a smaller, discriminative model that performs similarly at a much lower cost. 4. It's not about the model, it is about the data on which it is trained: A smaller LLM might struggle with specialized domain data—that’s normal. Fine-tune your model on your specific data set by starting with parameter-efficient methods (like LoRA or Adapters) and using synthetic data generation to bootstrap training. 5. Prompts are the new Features: Prompts are the new features in your system. Version them, run A/B tests, and continuously refine using online experiments. Consider bandit algorithms to automatically promote the best-performing variants. What do you think? Have I missed anything? I’d love to hear your “I survived LLM prod” stories in the comments!

Most people still think of LLMs as “just a model.” But if you’ve ever shipped one in production, you know it’s not that simple. Behind every performant LLM system, there’s a stack of decisions, about pretraining, fine-tuning, inference, evaluation, and application-specific tradeoffs. This diagram captures it well: LLMs aren’t one-dimensional. They’re systems. And each dimension introduces new failure points or optimization levers. Let’s break it down: 🧠 Pre-Training Start with modality. → Text-only models like LLaMA, UL2, PaLM have predictable inductive biases. → Multimodal ones like GPT-4, Gemini, and LaVIN introduce more complex token fusion, grounding challenges, and cross-modal alignment issues. Understanding the data diet matters just as much as parameter count. 🛠 Fine-Tuning This is where most teams underestimate complexity: → PEFT strategies like LoRA and Prefix Tuning help with parameter efficiency, but can behave differently under distribution shift. → Alignment techniques- RLHF, DPO, RAFT, aren’t interchangeable. They encode different human preference priors. → Quantization and pruning decisions will directly impact latency, memory usage, and downstream behavior. ⚡️ Efficiency Inference optimization is still underexplored. Techniques like dynamic prompt caching, paged attention, speculative decoding, and batch streaming make the difference between real-time and unusable. The infra layer is where GenAI products often break. 📏 Evaluation One benchmark doesn’t cut it. You need a full matrix: → NLG (summarization, completion), NLU (classification, reasoning), → alignment tests (honesty, helpfulness, safety), → dataset quality, and → cost breakdowns across training + inference + memory. Evaluation isn’t just a model task, it’s a systems-level concern. 🧾 Inference & Prompting Multi-turn prompts, CoT, ToT, ICL, all behave differently under different sampling strategies and context lengths. Prompting isn’t trivial anymore. It’s an orchestration layer in itself. Whether you’re building for legal, education, robotics, or finance, the “general-purpose” tag doesn’t hold. Every domain has its own retrieval, grounding, and reasoning constraints. ------- Follow me (Aishwarya Srinivasan) for more AI insight and subscribe to my Substack to find more in-depth blogs and weekly updates in AI: https://lnkd.in/dpBNr6Jg

I recently spent time getting more hands-on with LLM & Agentic AI engineering through Ed Donner's training. Instead of stopping at examples, I built a mini multi-agent logistics delivery optimization framework. Building real AI systems quickly makes one thing clear: 𝙏𝙝𝙚 𝙝𝙖𝙧𝙙 𝙥𝙖𝙧𝙩 𝙞𝙨𝙣’𝙩 𝙩𝙝𝙚 𝙢𝙤𝙙𝙚𝙡 — 𝙞𝙩’𝙨 𝙩𝙝𝙚 𝙖𝙧𝙘𝙝𝙞𝙩𝙚𝙘𝙩𝙪𝙧𝙚 𝙙𝙚𝙘𝙞𝙨𝙞𝙤𝙣𝙨 𝙖𝙧𝙤𝙪𝙣𝙙 𝙞𝙩. A few practical lessons: 1. 𝗟𝗟𝗠 𝗺𝗼𝗱𝗲𝗹 𝘀𝗲𝗹𝗲𝗰𝘁𝗶𝗼𝗻 𝗶𝘀 𝗳𝗮𝗿 𝗺𝗼𝗿𝗲 𝗻𝘂𝗮𝗻𝗰𝗲𝗱 𝘁𝗵𝗮𝗻 𝗰𝗼𝘀𝘁 𝘃𝘀 𝗹𝗮𝘁𝗲𝗻𝗰𝘆. Trade-offs: • reasoning maturity for complex planning • context window & memory strategy • proprietary models vs smaller open models • infra costs (GPU/hosting) vs token-based API costs • tool-calling reliability & structured output adherence • benchmark performance vs real task behavior • model stability across releases In practice, it becomes a hybrid strategy: 𝘀𝗺𝗮𝗹𝗹𝗲𝗿/𝗰𝗵𝗲𝗮𝗽𝗲𝗿 𝗺𝗼𝗱𝗲𝗹𝘀 𝗳𝗼𝗿 𝗿𝗼𝘂𝘁𝗶𝗻𝗲 𝘁𝗮𝘀𝗸𝘀 + 𝗦𝗟𝗠 𝘄𝗶𝘁𝗵 𝗳𝗶𝗻𝗲-𝘁𝘂𝗻𝗶𝗻𝗴 𝗳𝗼𝗿 𝗱𝗼𝗺𝗮𝗶𝗻 𝗽𝗿𝗼𝗯𝗹𝗲𝗺𝘀 + 𝘀𝘁𝗿𝗼𝗻𝗴𝗲𝗿 𝗿𝗲𝗮𝘀𝗼𝗻𝗶𝗻𝗴 𝗺𝗼𝗱𝗲𝗹𝘀 𝗳𝗼𝗿 𝗰𝗼𝗺𝗽𝗹𝗲𝘅 𝗱𝗲𝗰𝗶𝘀𝗶𝗼𝗻𝘀. 𝟮. 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗺𝗮𝘁𝘁𝗲𝗿𝘀 𝗮𝘀 𝗺𝘂𝗰𝗵 𝗮𝘀 𝘁𝗵𝗲 𝗟𝗟𝗠: Many AI demos over-engineer the stack. In reality, simplicity, latency, security and reliability matter more than novelty. • Use orchestration frameworks only where coordination complexity exists • Combine prompts with structured outputs to reduce ambiguity • Watch serialization and tool-call overhead — they impact latency and UX • Reduce unnecessary LLM calls when deterministic code can solve the task Besides lowering token cost, this improves context efficiency, letting models focus on real reasoning. Sometimes best architecture decision is 𝙣𝙤𝙩 𝙞𝙣𝙩𝙧𝙤𝙙𝙪𝙘𝙞𝙣𝙜 𝙖𝙣𝙤𝙩𝙝𝙚𝙧 𝙡𝙖𝙮𝙚𝙧. 3. 𝗕𝗶𝗴𝗴𝗲𝗿 𝗺𝗼𝗱𝗲𝗹𝘀 ≠ 𝗯𝗲𝘁𝘁𝗲𝗿 𝗼𝘂𝘁𝗰𝗼𝗺𝗲𝘀 Smaller models with fine-tuning on domain data can perform more consistently than larger ones. Fine-tuning helps when: • tasks are repetitive but require precision • domain vocabulary is specialized • prompts become fragile But 𝗳𝗶𝗻𝗲-𝘁𝘂𝗻𝗶𝗻𝗴 𝗮𝗹𝘀𝗼 𝗶𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝗲𝘀 𝗹𝗶𝗳𝗲𝗰𝘆𝗰𝗹𝗲 𝗼𝘃𝗲𝗿𝗵𝗲𝗮𝗱. Base model upgrades trigger retesting and partial rewrites. 4. 𝗧𝗵𝗲 𝗿𝗲𝗮𝗹 𝗴𝗮𝗽: 𝗽𝗿𝗼𝘁𝗼𝘁𝘆𝗽𝗲 → 𝗽𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 Demos are easy. Production requires 𝙚𝙫𝙖𝙡𝙪𝙖𝙩𝙞𝙤𝙣 𝙛𝙧𝙖𝙢𝙚𝙬𝙤𝙧𝙠𝙨, 𝙤𝙗𝙨𝙚𝙧𝙫𝙖𝙗𝙞𝙡𝙞𝙩𝙮, 𝙨𝙚𝙘𝙪𝙧𝙞𝙩𝙮, 𝙥𝙚𝙧𝙛𝙤𝙧𝙢𝙖𝙣𝙘𝙚, 𝙘𝙤𝙨𝙩 𝙜𝙤𝙫𝙚𝙧𝙣𝙖𝙣𝙘𝙚 & 𝙜𝙪𝙖𝙧𝙙𝙧𝙖𝙞𝙡𝙨. That’s where most engineering effort goes. 𝟱. 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴 𝗳𝗼𝗿 𝗹𝗲𝗮𝗱𝗲𝗿𝘀 𝗿𝘂𝗻𝗻𝗶𝗻𝗴 𝗔𝗜 𝗽𝗿𝗼𝗴𝗿𝗮𝗺𝘀 Many AI conversations focus on SDLC productivity- Useful but the bigger opportunity is 𝙧𝙚𝙞𝙢𝙖𝙜𝙞𝙣𝙞𝙣𝙜 𝙡𝙚𝙜𝙖𝙘𝙮 𝙗𝙪𝙨 𝙥𝙧𝙤𝙘𝙚𝙨𝙨𝙚𝙨 𝙪𝙨𝙞𝙣𝙜 𝘼𝙜𝙚𝙣𝙩𝙞𝙘 AI. By simply automating existing steps, we risk making inefficient tasks efficient and missing the real transformation.

Everyone says the future of product management is AI-native. But what the hell does it mean to be an AI-native PM? After watching our instructors teach thousands of students at Maven and observing my own team's transformation, I think it comes down to two layers. 1. The technical layer If you want to build AI-first products, you need to know how they work.   • AI fundamentals. What an LLM actually is, the trade-offs of using something like RAG, when to use agents (one or multiple), and what evals are. You need to speak the language fluently enough to collaborate with engineers without a translator.   • Model intuition and selection. When to fine-tune, how cost and intelligence scales with model size.   • AI product sense. AI products have fundamentally different requirements. A mediocre AI experience is worse than no AI experience at all. You need to understand guardrails, failure modes, and how to design for non-determinism. 2. The productivity layer PMs should use AI as a second nature part of their day-to-day work. For existing PMs, this requires shifting their workflows entirely...   • Prototyping. Instead of PRDs, start by using tools like Cursor or Claude Code to ship and iterate on prototypes and feature demos.   • Research and insights. Use LLMs to synthesize data of all types (not just CSVs) into usable insights. Read the original data to ensure accuracy and deeply understand the context the LLM is presenting.   • Strategy and writing. You still do your own thinking, while leveraging AI to fill in the gaps. AI can produce excellent docs and decompose them into tasks given enough context and prompting, but it shouldn't make the final decisions.   • Personal software. Use tools like Claude to build small apps and tools that only you use, optimized entirely for your specific workflows and use cases. Taste and judgement still matter the same as they did before. PMs are still expected to be the CEO of their products. But they also need to be natively using AI in their work, and deeply understand the opportunities to build AI-driven products. P.S. BTW we’re partnering with Lenny Rachitsky to launch a new series of free lessons called “The AI-Native Product Manager”. Check it out: https://bit.ly/4s0mYYj   • The CTO of MySpace turned ML Product Lead at Google, Dmitry Shapiro, on how to best use Clawdbot as a PM   • The 1st Product Manager, v0 at Vercel, Ary Khandelwal, on how PMs can build and *deploy* code with no handoff   • Ex-Head of UXR, Spotify Business, Caitlin Sullivan, on when and how to construct synthetic data for product discovery   • The former CPO of LinkedIn, Tomer Cohen, on becoming a full stack builder with AI   • Former Director of Growth at Gitlab, Hila Qu 曲卉, on the The AI-powered VP of Growth playbook   • Former FDE Lead at Palantir and Citadel, Vinoo Ganesh, on building products like a forward deployed engineer   • Product Lead at Roblox, Peter Yang, on AI Powered Product Skills for Executive Leaders & GMs