A lot of PMMs I talk to are using AI to go faster. Messaging in minutes, a launch deck in an afternoon, a research summary before the meeting even starts. I do some of this too, and I’m not going to pretend speed is bad. But I think most of us are pointing AI at the wrong part of the job.
Marty Cagan wrote about this for product managers in Product Coaching and AI. His point is that if you’re using AI to speed up the old way of working, aggregating requests and feedback, generating roadmaps, writing PRDs, an agent or your engineer or designer could just as easily do that themselves. And then the line that stuck with me:
“Ironically, for many people, their use of AI is simply exposing the theater, rather than highlighting their potential contribution.”
Product marketing has the exact same problem. If my value is producing messaging docs and launch decks, AI makes that cheaper every month, and anyone on the team can now generate a decent first draft. Doing it faster doesn’t make me a better PMM, it just makes it easier to see how much of my work was output.
Cagan’s answer for PMs is to use AI as a coach. Give it real context about your company and your customers, then “look for critique and mistakes rather than affirmation.” For PMMs, to me that means loading AI with real market context and asking it to poke holes in my positioning. Running my GTM assumptions through it before I commit. Asking it what a skeptical buyer would say about the launch story. Using it to sharpen my instincts, not to skip having them.
I learned this hands on. I’ve been building AI agents for my own work and for my teams: ICP reviewers that read our copy the way a specific customer would, leads agents, GTM planning and more. None of them were quick to build. To make an ICP agent useful, I had to write down what a blogger or an agency actually cares about, what makes them trust us and what makes them walk away. A lot of that only lived in my head, and I’d never put it into words before. Building them made me understand our customers much better, and that was the real value.
And honestly, this is the part I care about most. Going slow first is what lets you go fast later. Once you understand the problem, you can build the right system around it, and then the speed is real. If you skip that step and jump straight to faster, you just get more of the same output, sooner. My agents can take on the repetitive work because I’ve already done the thinking about what good looks like. I also trained them to keep improving over time, and to ask for my input whenever a call needs taste.
That’s why this keeps coming back to judgment for me. I’ve written about editorial judgment and about who decides what’s ready when everyone can prototype. AI can do more of the making every month, but deciding what’s good and what’s worth saying is still on us. Which brings me to the question I promised last time: can AI learn taste and judgment? I’m writing that one now and will share it soon.
Until then, my take is simple. Go slow first, use AI to think harder before you use it to work faster, and build the systems once you know what they should do. Then you’ll be set to go a lot faster, and a lot more reliably.
Leave a Reply