I Made the Switch: Traditional PM to AI PM in 4 Months

I was a senior PM at a mid-size B2B SaaS company, managing a team of 8 engineers building workflow automation features. I had shipped 12 major features in 3 years, grown my product line's revenue by 35%, and felt like I had a solid handle on the job. Then my company started an AI initiative, and I realized I could not even follow the conversations in the planning meetings.

The gap was not just technical vocabulary. I did not understand why the ML team kept talking about "evals" instead of QA. I did not know why they could not give me a firm ship date. I did not understand why a feature that worked great in a demo fell apart with real customer data. It felt like being a first-year PM again, except everyone assumed I should already know this stuff because I had "senior" in my title.

I decided to make the transition deliberately rather than waiting for my company to figure it out for me. I gave myself 4 months. Here is what happened.

Month one was all learning. I took Andrew Ng's ML Specialization on Coursera, but I only completed the first two courses before realizing I was going too deep into the math. I switched to a more PM-focused approach: I read "Designing Machine Learning Systems" by Chip Huyen cover to cover and took notes on every chapter. That book was more useful than any course because it frames ML concepts in terms of system design, which maps to how PMs think.

Month two, I started building. I picked a real problem at my company: our customer support team was spending 6 hours per day categorizing incoming tickets. I prototyped a classification system using OpenAI's API, built a simple eval set of 200 real tickets, and measured accuracy by category. The prototype hit 78% accuracy overall but only 52% on billing disputes, which was the highest-volume category. I documented the entire project, including the failures, in a case study format.

I also started attending my company's ML team standups as an observer. I did not contribute for the first three weeks. I just listened, wrote down terms I did not understand, and looked them up afterward. By week four, I could follow 80% of the technical discussion without a glossary.

The turning point came when I presented my ticket classification project to our VP of Engineering. I did not pitch it as a finished product. I pitched it as an evaluation framework with a prototype attached. I showed the accuracy numbers by category, explained where the model failed and why, and proposed a phased rollout that started with the categories where accuracy exceeded 90%.

He asked me a question I was not expecting: "What happens when the model is wrong and the support agent does not catch it?" I had actually thought about this. I showed him my error analysis, which revealed that most misclassifications were between adjacent categories (e.g., "billing inquiry" vs. "billing dispute"), and I had designed the UX to show the model's confidence score so agents could prioritize their review.

That conversation led to a real project. Not my prototype, but a properly resourced initiative with two ML engineers. He asked me to PM it. Within two weeks, I was effectively doing the AI PM job, even though my title had not changed.

Three months into the internal AI project, I started interviewing externally. I had three things that most candidates did not. First, a documented case study with real numbers. I could walk through the ticket classification project from problem definition through evaluation results and explain every tradeoff I made. Second, I had experience working directly with ML engineers on a shipping product. I could talk about prompt engineering, eval set design, and model selection from firsthand experience, not from reading blog posts.

Third, and this surprised me, I had a clear framework for how I think about AI product quality. Interviewers kept asking variants of "how do you know if an AI feature is good enough to ship?" Most candidates apparently give vague answers about user testing. I could walk through my three-layer eval approach (component, system, user-facing), explain how I set quality bars, and give concrete examples of when I decided to ship vs. hold.

I received two offers in month four. One was a 15% pay increase over my existing role. The other was lateral on comp but at a company with a stronger AI team. I took the second one. Comp follows skill development, not the other way around.

I spent too long on foundational ML courses. If I did it again, I would start with Chip Huyen's book and move immediately to building a project. You learn more from one real eval set than from ten hours of lecture on gradient descent. The math matters for ML engineers. For PMs, the system design and evaluation mindset matters more.

I would also start networking with AI PMs earlier. I did not reach out to anyone until month three, and by then I was already interviewing. The best advice I got came from a 30-minute coffee chat with an AI PM at Notion who told me to focus my case study on the evaluation framework rather than the model performance. That single piece of advice changed how I presented my work and directly contributed to my offers.

Finally, I would have pushed harder to get involved in my company's AI work in month one instead of waiting until I felt "ready." Nobody feels ready. The ML engineers on my current team told me they preferred working with PMs who asked honest questions over PMs who pretended to understand everything. Showing up curious and engaged beats showing up polished and superficial every time.