How an AI Product Manager is Different from a Regular Product Manager: A Day in My Life

My colleagues and friends have often asked me about my transition from a traditional Product Manager to an AI Product Manager. After walking this path myself, I wanted to show you—not tell you—what actually changed. Forget the theory about "probabilistic thinking" and "new stakeholders." Let me walk you through what my actual workday looks like now. ## My Monday Morning: Before vs. After ### The Old Way (Traditional PM) **8:30 AM** - Open Confluence. Stare at blank page. Start drafting a PRD from scratch. **10:00 AM** - Still writing. Trying to describe a UI flow in words. Hoping engineering will understand what I mean. **11:30 AM** - Schedule a meeting for Thursday to "align on requirements." **Thursday** - Meeting happens. Engineer says: "Can you show me what you mean?" I open Figma and awkwardly sketch something. **2 weeks later** - See first prototype. It's not what I imagined. Back to the drawing board. ### The New Way (AI PM) **8:30 AM** - Open Cursor. My PRDs live as markdown files, version-controlled like code. I describe the feature I'm thinking about in plain English: *"Create a PRD for a feature that lets users set spending alerts. They should be able to choose a threshold, select notification method (push/email/SMS), and see a preview of what the alert will look like."* Cursor drafts a structured PRD in 3 minutes. I refine it with follow-up prompts. **9:15 AM** - Instead of scheduling a meeting to explain my feature, I open v0. I paste my requirements and say: "Build a UI for this." 45 minutes later, I have a working, clickable prototype deployed to a live URL. **10:30 AM** - I share the prototype link in Slack. Stakeholders play with it on their phones. Feedback is concrete: "Move the threshold slider to the top" and "Add a test notification button"—not "I'm not sure I understand the flow." **11:00 AM** - I update the prototype based on feedback. Takes 10 minutes. **11:30 AM** - My Jira tickets? Auto-generated from the PRD using Cursor's MCP integrations. Status reports? Pulled directly from Jira data. I haven't manually written a ticket in months. **Afternoon** - Engineering starts building. But we're not starting from a spec—we're starting from a working demo they can inspect, click, and reference. ## The Tools That Changed Everything Here's my actual toolkit: ### Cursor - My Command Center That is because Cursor isn't just a code editor—it's become my entire PM operating system. Dennis Yang, Principal PM at Chime, put it perfectly: "Cursor is a much better product manager than I ever was." I use it for: - **PRD drafting** - Describe features in plain English, get structured docs - **Jira automation** - Generate tickets directly from PRDs - **Status reports** - Pull data from Jira and format automatically - **Stakeholder responses** - Draft replies to document comments My PRDs live as markdown files in a git repo. Version-controlled, diffable, and AI-assisted. ### v0 by Vercel - Instant Prototypes v0 takes plain English descriptions and generates working Next.js + Tailwind components. I describe what I want, and it builds a deployable UI in minutes. For eg., last week I needed to test three different onboarding flows. In the old world, that's a design request, a week of waiting, then a dev sprint to build clickable prototypes. With v0, I built all three in one afternoon. Shared the links. Got feedback. Killed two of them before engineering touched a line of code. ### Replit / Lovable / Bolt - Full-Stack Spikes When I need something with backend logic—API calls, database interactions, user authentication—these tools let me build functional MVPs without writing code. I recently prototyped an entire notification preferences system. Working database. Real API calls. Deployed to a live URL. Took 4 hours. That prototype became the spec. Engineering didn't interpret my words—they extended my working code. ## What Actually Changes Day-to-Day ### You Stop Writing, You Start Showing The old PM skill was translating ideas into words and hoping others understood. The new PM skill is translating ideas into working demos and iterating in real-time. This is a fundamental shift. You're not describing what you want—you're demonstrating it. ### Feedback Becomes Concrete When stakeholders interact with a prototype, their feedback changes completely: - Old: "I'm not sure about this flow" - New: "Move this button here, and add a confirmation step" You skip the interpretation layer entirely. ### You Discover Problems Before Engineering Does When I build prototypes, I hit the walls first. I discover edge cases, weird UX patterns, and technical constraints before writing the PRD. Last month, I prototyped a document summarization feature. Within 2 hours, I discovered the AI struggled with tables and produced inconsistent outputs for documents over 10,000 tokens. That insight shaped my entire spec—chunking strategies, fallback handling, error states. I would never have thought of those requirements from just thinking about it. ### The Validation Loop Shrinks Dramatically Old timeline: Idea → PRD (1 week) → Design (1 week) → Dev (2 weeks) → Feedback → Iterate New timeline: Idea → Prototype (2 hours) → Feedback (same day) → Refined PRD (1 hour) → Dev (1 week) Time saved: 2-3 weeks per feature on average. ## The Skills You Actually Need Now the question that will arise is: do you need to learn to code?? No. But you need to learn these: **1) Prompt Craft** The difference between a mediocre prompt and a great prompt is a 10x difference in output quality. This is a real skill—and unlike coding, you can get good at it in weeks, not years. **2) Tool Fluency** Spend time with Cursor, v0, Replit. Build throwaway projects. The goal isn't to become an engineer—it's to move from "I need to describe this" to "Let me show you this." **3) Iteration Speed** The new PM advantage is cycle time. Build → Show → Learn → Repeat. The faster you can run this loop, the better your products become. **4) Knowing When NOT to Use AI** AI-generated prototypes are for validation, not production. You build to learn, then hand off to engineering to build it right. This distinction matters. ## Why This Matters for You The numbers tell the story: - **77%** of organizations already use or plan to use AI tools in PM workflows - **6-9 hours per week** saved on documentation alone for PMs using AI tools - **2-3 weeks per feature** saved on validation cycles - PMs using AI prototyping tools report **40-60%** reduction in PRD writing time As the industry shifts, PMs split into two camps: those who describe, and those who demonstrate. The describers are competing with AI that can write PRDs. The demonstrators are using AI to build things nobody else can show. ## In a Nutshell The difference between an AI PM and a regular PM isn't about managing AI products—it's about how you work. Old workflow: Write PRD → Wait → Hope engineering understood → Iterate New workflow: Build prototype → Show stakeholders → Write PRD from what works → Ship And the best part? The tools to do this are free or cheap, require no coding, and you can learn them in a weekend. Your Monday morning can look completely different by next month. Excited to delve deeper? In next week's post, I will walk through my exact Cursor setup, the prompts I use daily, and how I structure my prototype-to-PRD workflow. Additional documents to read on this: - [Cursor for Product Managers](https://amankhan1.substack.com/p/cursor-for-product-managers) - Aman Khan - [Dennis Yang on Cursor](https://www.lennysnewsletter.com/p/cursor-is-a-much-better-product-manager) - Lenny's Newsletter - [AI Prototyping Guide](https://www.lennysnewsletter.com/p/a-guide-to-ai-prototyping-for-product) - Lenny's Newsletter - [v0 by Vercel](https://v0.dev/) - AI UI generation - [AI Prototyping Course](https://maven.com/tech-for-product/ai-prototyping-for-product-managers) - Maven Stay tuned!!