Matthieu Ramognino hosts DataNomad, a French podcast about freelance data work. On the show, he said PMs keep asking him the same question. “I’d like to become an AI PM. Do you have any advice?” Data engineers ask him how to become AI engineers.
My answer started with permission, and how I skipped asking for it. Ideas reached me through the newsletters I read. I tried them on the project already on my desk. Then I told the team what worked and what failed. Nobody had put AI in my job title, and nobody stopped me either. The title came later, after the experiments.
That’s the bottom line of this post. You become an AI-native PM on the job you already have. And the AI PM job itself is mostly product work: discovery, adoption, and evaluation. You test one idea on your current project. You design an agent the way you’d onboard a new hire. You turn a meeting transcript into a Jira ticket before the next call starts. The model work is the smaller part, and data scientists and engineers handle it well.
If you speak French, the full episode is on Spotify. It runs twenty minutes. This is the English version, rebuilt from the transcript, with a source behind every claim. You need nothing new to follow along. Any chat assistant covers the first habit: Claude, ChatGPT, or Gemini. Claude Code covers the step after it.
The whole path fits in one picture.
My path. The discovery habits that carried into AI work, and how to find your own thread.
Three moves. Here’s what got me into AI work before the title. Experiments at work, proof of depth, one topic at a time.
Agent design. You’ll see the five calls I make on an agent, starting with whether it should exist.
Leadership. How I reset “100x productivity” expectations, and which metric I refuse to track.
Your week. Less time on specs, more time with users, and one new chore to plan for.
First steps. Feel behind? Watch people’s screens, then climb three levels with your meeting transcripts.
By the end, you’ll have a sequence you can start on your current project. You’ll have a four-part template for agent design. You’ll have a metric swap for leadership, and a habit for your next meeting. You stop waiting for someone to rename your role, and you start doing the work it describes.
It started for me with a prototype in someone else’s hands.
The path that led me to AI work
After engineering school at Arts et Métiers, I spent about six years at EY. I was a PM consultant. The missions I liked were the ones where discovery was real work. We built interactive prototypes. We went on site. We watched end users work with the platform. Watching beat asking them what they wanted. Those years taught me to trust what people do over what they say. Teresa Torres wrote the full method for that habit in Continuous Discovery Habits.
No-code tools made it faster. Bubble and Webflow let me put a working product in front of users within days. In 2021, I combined the two into my own offer and went freelance. The first mission took some luck. Pernod Ricard’s innovation team needed a product live in three months. I gave people mockups they could click and use, then watched where they got stuck. We shipped an MVP we were a bit ashamed of, and that was on purpose. It surfaced needs nobody had said out loud. Reid Hoffman’s line covers it: “If you’re not embarrassed by the first version of your product, you’ve launched too late.”
That mission led to SeLoger’s experience platform, and later to AI platform and agent work. My AI work before LLMs was classic machine learning, like fraud detection. The step from innovation to AI was shorter than it looks. In innovation, you accept that most experiments get dropped. In my experience, about 10% are worth continuing. The other 90% are how you find them. Ronny Kohavi ran experimentation at Microsoft. He sees a similar ratio: “the winner ratio is about 10% to 20% of all test ideas.” AI work runs on that same ratio, so a team that can’t live with a high miss rate struggles with it.
The no-code years left me one more habit. A new tool appeared every month, and the winners kept changing. What lasted were the principles: layout, state, components, the hand-off to users. The principles moved from one tool to the next, and the buttons stayed behind. AI tools behave the same way, across Claude, Cursor, ChatGPT, Gemini and Claude Code. Give context and constrain the task. Check the output, then put it in front of a real user. Your bridge into AI will follow a different thread from mine, and it’s worth naming.
Key learnings
Watch people use the thing. Next discovery session, hand over a clickable prototype. Stay quiet for five minutes.
Ship the version that embarrasses you a little. Pick the one flow users can try now, and cut the rest of the scope.
Plan for most experiments to fail. Before you start one, write down what you’d learn if it fails.
Name your own bridge. Write one sentence on what in your past work makes AI your next step.
Those habits only mattered once I put them to work on AI. Three moves did that.
Three moves before the AI title
Matthieu’s question was about the jump into an AI role. My answer was three moves, made on the work I already had.
Experiment on the job you have
I never asked permission to bring AI into my missions. Ideas reached me through the newsletters I read. I tested them on the work in front of me. Then I shared what I learned with the team. That work sat outside my job description. It still became my story for the next client: what I tested, what worked, what didn’t. That story carries more weight than a certificate with no failures in it.
Ethan Mollick explains why this works from the inside. In Making AI Work, he argues that experienced people find the uses best. “People with a strong understanding of their job can easily assess when an AI is useful for their work through trial and error, in the way that outsiders (and even AI-savvy junior workers) cannot.” Your domain is your edge, so the experiment belongs in your domain. Leadership won’t stop you from sharing what you learned. Everyone wants that conversation now.
Companies now check for this at the door. Zapier assesses every hire against an AI fluency rubric. I went through it in the hiring post. Its line for a PM who falls short is worth reading in full. “Uses AI for simple tasks like summarizing, writing, or looking up information, but output reads like obvious AI slop. Cannot point to clear evidence that work is faster or higher quality. The work they do before AI and after AI looks largely the same.” Zapier sells automation. Read that as the demanding end of the market. The direction still holds: your before-and-after has to look different.
Prove depth with real projects
Matthieu raised the other side. Plenty of people on LinkedIn call themselves AI experts. From the outside, it’s hard to tell real depth from someone who prompts ChatGPT. I wanted depth I could show. So I compared programs, online and in person, short and long. I picked the one-year Sorbonne Data Analytics diploma. It ran in the evenings, next to my PM job.
The title says analytics. I read the curriculum first, and it leaned toward data science. The teachers came from industry and brought their own projects. One arrived with an AWS project and showed us how they built it at work. Then we built it ourselves. A year turned out to be the right length to absorb the concepts. It also gave me a shared language with data scientists and engineers. Technical conversations got easier.
I should be honest about how I went in. In the learn-to-code post, I admitted my mindset going in. “Give the minimum, collect the diploma, move on.” What stayed with me were the projects. The diploma was the vehicle, and the repos are the proof. Diego Granados is an AI PM at Google. His guide to becoming an AI PM says it from the hiring side. “Listing”AI/ML knowledge” on your resume won’t get you there. Showing what you’ve shipped will.” So put your experiments on GitHub. A peer or a recruiter can then see what you solved.
Go deep on one topic a week
AI moves too fast to follow everything. When I started The AI Thinker, I set one rule. One topic a week, carried to the end. The pick was arbitrary on purpose. Choosing what to skip was the hard part. I skipped n8n and OpenClaw while they were rising. I went deep on Claude Cowork, skills in Claude Code, and prototyping in Cursor. Each topic got a week of experiments. Then I wrote up what I tested and learned.
Those weeks produced posts like your first Claude Code skill and an AI helper with Cowork. Full honesty: lately, I haven’t kept to one topic every week. The rule still helps each time I return to it. Depth gives you opinions you can defend. A client or a hiring manager hears the difference. A tour of ten tools gives you ten first impressions.
Key learnings
Start on the project you already have. Pick a recurring task and try an AI tool on it.
Share the misses with the wins. Bring one failed experiment to your next team meeting, with what it taught you.
Show projects over certificates. Put one experiment in a public GitHub repo, with a README that names the problem.
Pick one topic and finish it. Write down the two tools you’ll skip, so the choice is deliberate.
Those moves got me onto agent projects. Here’s what the work looks like once you’re there.
Design agents the way you onboard a hire
I work on LLM and agent systems now. With an agent, you take a messy problem and give it to a system that reasons and acts through tools. The PM part still comes first, and it shapes every call that follows. Customer support is my example here, because it’s the case people talk about most. The same calls apply to sales operations, a finance close, or internal IT tickets.
Say no before you say agent
Start with the problem: understand it, observe it, analyze it. Then decide whether AI is the right answer at all. Sometimes my answer is no, and that project stays a regular project. A script, a checklist, or a better process does the job. An agent would waste the budget. Anthropic’s engineers make the same point in Building effective agents. “This might mean not building agentic systems at all.” Thiago Avelino gives a one-line test: “does the model need to decide what comes next, or do you already know?” If you already know, write the workflow.
Onboard the agent like a new hire
When an agent does belong, the design looks like bringing someone new into the company.
First comes the context, meaning what the agent knows. You explain the product and its past problems, as you’d brief a new colleague. It needs enough to make decisions and plan its own steps. Second come the instructions, the agent’s job description. Engineers call it the system prompt: what the agent must do, and how. Third come the tools, its connections to systems in the company. In support, that’s the complaint-management tool, Confluence, and maybe Jira. Fourth come the actions, spelled out: it may create a Jira ticket and assign a team.
Anthropic’s own docs use the same picture in their prompting guide. “Think of Claude as a brilliant but new employee who lacks context on your norms and workflows.” Their golden rule is a test. “Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they’d be confused, Claude will be too.” OpenAI’s practical guide to agents adds a shortcut. Write the agent’s routines from the procedures, scripts, and policies you already have. The agent interviews post mapped the same parts from the users’ side, and it holds.
Start adoption on the most tedious step
Here’s the paradox of agent projects. The hardest part is rarely the technical one. I work with data scientists and data engineers who know that stack well. The hard part is change. Users often tell me their work is too unique to reproduce. They see nothing AI could do for them. So I skip the argument and take the step they hate most off their plate.
Matthieu quoted an earlier guest here. AI projects are 10% AI, 20% data, and 70% transformation. That echoes BCG’s 10-20-70 rule, a rule of thumb for effort. BCG’s version puts “10% of a company’s efforts” on algorithms and 20% on technology and data. The remaining 70% goes “on people and processes.” In my agent projects, that 70% is where the hard part lives.
I look for the step that takes the most time and feels the most tedious. In support, that’s often the PDF summary for the customer. It says what went wrong and how it got fixed. I meet the team and offer to help with that one step through an agent. It works a bit like a Trojan horse. People are usually glad to lose that step, and the next asks come from them.
Once they see the agent work, the questions start. Could it find the right team to contact first? Could it suggest a fix based on past cases? Could it spot the bug before the customer even complains? Adoption grows upstream from the first step people were glad to lose. Each new ask is one they made, so nobody has to sell it to them.
Turn memory into business questions
PMs and engineers decide many technical points together. Memory is a good example. Short-term memory keeps what was said inside one conversation. Long-term memory keeps things across sessions, like how the agent should behave next time. LangChain’s docs draw the same line. I never ask users which type of memory they want. I ask business questions, then translate the answers with the engineering team.
Some answers are obvious. Nobody wants a goldfish that forgets which ticket you were discussing a few messages ago. Feedback a user gives at the end should land in long-term memory. Other answers come from deciding with imperfect information. Then you watch the monitoring once the agent is live. I found plenty of engineering writing on memory and almost nothing from product people. What an agent remembers about a customer, and for how long, is a product decision.
Spend more on evals than on the agent
One principle I keep coming back to: invest more in evaluation and monitoring than in the agent. The agent can go stale fast. A new model ships or a new framework appears. The build you were proud of looks old. The tests outlast all of it, and they become the specification that stays. Whatever model you run next, you still check it against the same tests.
The order matters, though. Hamel Husain and Shreya Shankar teach evals to product teams. They start by reading real outputs. Their evals FAQ is direct. “Write evaluators for errors you discover, not errors you imagine.” Each failure found in production becomes a new test. I wrote in the agent-factory post that an agent with no eval is a faster way to be wrong. That still holds, and it’s the call I’d protect first when a deadline gets tight.
Five calls is my list. Other teams add more. Diego Granados counts designing what happens when the agent gets something wrong. Anthropic counts the cost and latency budget, since agents trade both for better results. Treat the five as a starting set, and add the calls your domain needs.
Key learnings
Ask whether it needs an agent. Write the steps out. If you can list them all in advance, build a workflow.
Onboard it like a hire. Write one page per part: context, instructions, tools, actions.
Start with the step people hate. Ask the team which step they’d pay to stop doing, and automate that one first.
Translate memory into business questions. Ask “should it remember this customer the next time they write?” Skip “long-term memory” with users.
Read outputs before you write evals. Review 20 to 50 real outputs, then write a test for each failure you find.
All of this ends up in front of leadership. That conversation changed a lot in a few years.
Talk to leadership without promising magic
When I worked on fraud detection, AI felt opaque to everyone outside the team. You had to convince leadership that machine learning was useful at all. Today, the people funding the work use ChatGPT themselves. They’ve felt what it can do. They listen much faster now, and they expect much more. Many expect AI to bring double the productivity overnight, or a hundred times more. That rarely happens. The processes still run through people, and AI won’t fix an organizational problem.
Felt speed can fool everyone, including the people doing the work. In early 2025, METR ran a randomized trial with experienced open-source developers. “When developers are allowed to use AI tools, they take 19% longer to complete issues.” They still misjudged it. “Even after experiencing the slowdown, they still believed AI had sped them up by 20%.” METR has since said those early-2025 results no longer reflect current tools. The lesson that lasts is the gap between what people feel and what you measure.
A professor at my engineering school said something I still remember. Put an information system on a badly defined process, and you get more chaos. AI makes that worse. Michael Hammer made the same case in Harvard Business Review in 1990, long before LLMs. “It is time to stop paving the cow paths. Instead of embedding outdated processes in silicon and software, we should obliterate them and start over.” Leadership is right about the potential, though. So my work with them starts with the process and the target, before any agent.
Then we pick the metrics, and every metric carries an incentive. Track lines of code written by AI, and you’ll get plenty of them. That says nothing about the value users got. Thiago Avelino is blunt about it. In his words, “% of code generated by AI” is a vanity metric (Vanity Metrics in Engineering). Track what users get instead: delivery, quality, and where the saved time goes. I learned this the hard way. In the adoption post, I admitted I was measuring activity instead of impact.
Then there’s the room itself: the people already excited, and the people holding back. Same rollout, different coaching. Ethan Mollick has a kinder read on the second group. Many “may have received a scary talk about how improper AI use might be punished, and they don’t want to take any risks.” Make it safe to say how you use AI, and some of your skeptics turn out to be quiet users. Mollick’s numbers fit: official chatbots reach about 20% of workers, yet over 40% admit using AI at work.
Key learnings
Ask for the process before the agent. Before any AI project starts, ask for the current process on one page.
Answer “100x” with a measured number. Agree with leadership on one baseline you’ll measure before and after.
Swap the vanity metric. Replace “% of code written by AI” with cycle time or defects that reach users.
Coach both ends of the room. Share how you use AI first, then ask the quiet ones what they’ve tried.
Leadership sees the outcomes. Inside my own week, the change was bigger than I expected.
What AI changed in my week
This one makes my colleagues smile: AI made my job bigger. More is expected of me than before. Marty Cagan has coached product teams for decades, and he says the same at SVPG. “The PM role becomes more essential but also more difficult with generative AI-powered products, not less.” My week used to be specs, Jira tickets, and refinement prep. Product strategy got what time was left. Now I can take an idea all the way to the end. I no longer wait for someone to pick my item from their backlog.
Say I have a product idea. I prototype it. I query the data with SQL that AI writes for me, to get the insights. Then I show the prototype and what users said. No slides for a committee. Do we go, or not? An idea used to wait three months for a budget committee. Now it can get its answer in one or two weeks. Agents work the same way. With users, I prototype the agent they need in Claude or Claude Code. That replaces the spec-writing session.
The wider data is more cautious than the hype. Figma, which sells a prototyping tool, argues that prototypes are the new PRDs. Lenny Rachitsky’s survey of 1,750 tech workers is more measured. Writing PRDs is still where PMs get the most value from AI today, at 21.5%. Prototyping is the use PMs most want to add next, up 24.6 points. The shift is underway, and most teams are early in it.
The biggest change is where the hours go.
I used to spend about 80% of my time on execution. Specs, meeting notes. With good automation, that 80% can go to vision, strategy, and users. Talking to users is still the best part of the job. AI can’t do it for me. That time is the one I protect. Everything else on the list is negotiable.
Little by little, my job shifted in another way. I became the manager of the AI systems I build. They’re never perfect and always need to evolve. So I spend much of my time giving them feedback. Each time an AI tool does work for me, I check that it’s correct. Much of that lives in Claude Code skills. The workspace post shows how I organize them. I also coach other PMs through workshops and demos, so they can use the same tools. It’s close to an internal trainer role, and it sits next to delivery.
Key learnings
Replace the committee deck with a prototype. For your next proposal, bring something users can click, plus what they said.
Write your own SQL with AI. Ask the AI for the query. Check the result against a number you already trust.
Move the hours to users. Book your user conversations before anything else goes into the calendar.
Budget time to manage your AI systems. Each time you correct an output, fix the instructions so the mistake doesn’t return.
If all this feels far from your own week, that’s normal. Here’s where I’d start again.
Start with screens and meetings
Don’t worry if you haven’t started with AI yet. Everyone is behind by default. The field moved so fast that the moment you pay attention, you’re early. Start whenever you’re ready. Two first moves make it easier, and neither needs a new tool.
The easiest way in is to watch people work. My main channel is How I AI, Claire Vo’s show. Guests share their screen and show how they use these tools. I’ve watched more than 50 hours of it. Many times, I wondered what use it would ever be to me. Some guests seemed too methodical. Some did things I’d have called unnecessary. Then, a few weeks later, it clicked, and what they did made complete sense. It was my top pick in the AI product education post, and it still is.
The second move is one concrete task. PMs spend much of the week in meetings, and so does almost everyone else. That’s where you gather the information everything else runs on. A good first use of AI is making sure each meeting delivers its full value. I climb three levels.
Level 1 is a recap. I copy the detailed transcript of a meeting into a chat. Then I ask ChatGPT, Gemini, or Claude for a recap, so nothing gets lost. A prompt to start from:
Here is the transcript of a meeting. Write a recap in three parts:
the decisions we made, the actions with one owner each, and the open questions.
Quote the transcript wherever a decision or an owner is unclear.Once that works, save it as a reusable assistant. The Gems post shows the one I built for meeting notes.
Level 2 turns the recap into actions. Run it in Claude Code, connected to your tools through MCP. Those connectors let it act in apps like Jira and Slack. It can create the Jira ticket and post the recap in Slack. The meeting stops ending as a recap nobody reads. You review what it’s about to send, and it does the clicking.
Level 3 pulls the thread. This one saves me the most time. I take the recap and its list of actions. Then I do each action in the same thread, to the end. One question I always ask at the end: “What next?” It usually gives me ideas. Little by little, a meeting turns into finished work. Daniel Blum is a PM at Melio. His How I AI episode shows where this leads. His morning brief reviews yesterday’s transcripts and pulls out “any action items that were decided.”
One warning before you climb. Each level has to leave you better informed. Researchers at BetterUp Labs and Stanford have a name for what happens otherwise: workslop. It’s “AI generated work content that masquerades as good work, but lacks the substance to meaningfully advance a given task.” Read the recap before you forward it. Decide the actions yourself, then let the AI carry them out.
Key learnings
Start late without guilt. Pick a tool you already have access to, and use it on a real task.
Watch screens before you read takes. Pick one How I AI episode close to your work. Copy one workflow from it.
Paste your next transcript into a chat. Ask for decisions, owners, and open questions.
Finish the work in the thread. End each meeting thread with “what next?” and keep going until something ships.
Read before you forward. Check every recap and every action before it leaves your hands.
Climb those three levels, and the rest of this post starts to connect.
Start before the title
Matthieu’s question was how to become an AI PM. Here’s the whole answer, as a checklist.
Your path. Find the thread from your past work that makes AI your next step.
Three moves. Experiment on your current job, prove depth with projects, and go deep on one topic at a time.
Agent design. Say no first, onboard it like a hire, and start on the most tedious step. Ask business questions about memory, and invest in evals.
Leadership. Fix the process before the agent, and measure outcomes over AI-written code.
Your week. Trade committee decks for prototypes, and spec time for user time.
First steps. Watch real screens, then climb the meeting ladder.
The line I’d give any PM who asks Matthieu’s question is short. Don’t wait for the title: run one AI experiment on the project you already have, show the team what failed as well as what worked, and pick one tool to go deep on. The work comes first, and the title tends to follow it. That’s how it went for me, through experiments on each mission. Whatever your thread is, the first experiment fits in the project you’re already on.
If you speak French, the full conversation is on Spotify. And the subscriber chat is open if a question stays with you after reading. I’m there.
The part worth stealing is the boring part, and it's the actual skill: put a manipulable thing in front of someone and watch their hands, instead of asking them to imagine what they'd want. That works whether the thing is a Webflow mock or an agent that faceplants on step three.
"AI-native" still reads like a passport stamp to me — something you have rather than something you do. You half admit it yourself, with the bit about keeping a classic seat while AI shows up on every roadmap anyway. That's the honest version of the post, and I'd have led with it.