The last three years have been a wild ride, watching PMs adopt and sometimes abuse new tools (especially fancy schmancy AI tools) to make their lives easier. As someone who’s managed my fair share of product folks, I’ve seen it quite a lot. Whether you’re running Product Ops, a market-facing team, a core engineering group, or something in between, here’s what I’ve learned - I’m loosely going to nickname three types of PMs in the “AI” age that I’ve seen. There may be others, but for today we’ll talk about these:
the Outsourcer: Those who blindly trust AI to do their jobs for them (like the one who phones in their customer or market research, or “auto-writes” stories based on a standard template. You know...the one who thinks they’re a “10x PM”)
the Apprentice: Those who use AI as a learning tool and a way to improve their craft (like the one who uses vision or multi-modal models to prototype designs because there may not be enough designer capacity in the company to help them immediately)
the Orchestrator: Those who understand that AI is a tool, not a replacement, and use it to amplify their own strengths and fill in the gaps. (like the one who uses a model to help write a six-pager or PRD, but then has other models review the work, perhaps goes back and forth with them)
I want to offer two ways we can avoid being an Outsourcer and become an Apprentice or Orchestrator (depending on whats needed in the moment). Before we dive in, let’s be clear: PM certifications or Extension Degrees aren’t helpful for this. They might help you land a job because HR departments and Hiring Mangers still look for this, but they don’t guarantee you’ll be a good PM. They’re more like building construction codes – they set a minimum standard, but they don’t teach you great tradecraft. So, let’s skip the theory and focus on real-world examples.
Write Better Stories
If you’re a PM, write better stories damn it. More human. More relatable.
Whether you’re an engineer, a project lead, or a PM yourself, you’ve likely come across the “As a User, I would like to get the ability to do X when I enter this part of the tool. See requirements and acceptance criteria below.” stories. They suck. PMs hate writing them. Engineers hate reading them. And the future PM and Engineer who needs to reference them 10 months from now will hate looking for them to cover their ass. And if that person in the future is you, you’ll doubly hate it if you’re on the losing end of a dispute.
Stories are meant to be just that...they’re stories. We should write them in a narrative form that actually provides context. They’ve also been much harder to write in human form because it requires quite a bit more time than most PMs are willing to spend. It’s also not something that can be templated for quick and easy writeups that our 10x PM friend likely wants.
That same sentence above could easily be written as “One of our Solutions Engineers, Jamie, uses our platform to do a lot of things on a daily basis. They recently helped Brenda at “Brenda’s Paninis” get all her gourmet sandwiches made in top quality in under 10 minutes on average. But sometimes, when the lunch rush is at its peak and customers are getting hangry, those 10 minutes really matter. Jamie really needs to be able help trigger a customer SMS notification to let Brenda’s customer’s know their panini is almost ready. They need to be able to send that SMS fast so no sandwich goes cold. Let’s try to support all the Jamies out there. It may not always be paninis, but you and I both likely want our next ramen or burger made that much faster. They don’t need all the bells and whistles, but clearly they need to make sure those SMS notifications get sent reliably, or at least in this case, Brenda just might lose it. Additional details below: (technical details)”
Does this feel like it adds fluff? No doubt. But will an Eng Lead actually enjoy reading this requirement? Absolutely. Will that Eng Lead reviewing your ticket message you a 😂 emoji or a Denzel Washington My Man GIF* after reading that story?
Maybe...probably not if they’re GenZ though. They’ll use 💀 for some nihilistic reason I don’t fully understand.
The revised story I wrote was a little funny and it also talked about what the end-user actually had as an outcome from that product so the engineers know a bit more about what’s going on. A small tidbit outcome like this across 300 user stories can slowly build customer intimacy on the engineering team that no Customer Feedback meeting or All Staff Presentation could compete with. So it’s just a simple plea from myself. If you’re a PM, write better stories damn it. More human. More relatable. It’s never been easier to do so and you’re likely smart enough to get a (company approved) LLM to help you with this.
Here’s how an Apprentice and Orchestrator might approach this:
Apprentice: Uses an LLM to rewrite the standard “As a User...” story into a more narrative form. The story would stop being generic and gets a strong connection to the user’s actual needs for anyone reading that story.
Orchestrator: Leverages the company’s internal AI tool to integrate with Salesforce, pulling data on how much $ in existing sales contracts could benefit from the SMS notification feature. They may even go as far as calculating contract renewal risk in dollar terms if this feature doesn’t get built out, presenting a compelling business case to leadership. This kind of math used to take forever, but now, you can just have an LLM do most of the work and then review it at the end.
Just make the life of your nearby team members better. Your Product Marketer can be closer to the product and the Engineers. Your Engineer can be closer to the Customer.
Why is it taking so long to ship?
It has never been easier better understand code for a PM who doesn’t code, but wants to be just a little bit more technical. Largely, you might want to know the contents of a repo that runs the product or feature you’re responsible for since...it’s what you’re responsible for.
I mean, it could be because you’ve heard “gah, we’re still seeing race conditions when we merge and run the updated code.” from your engineer for the 10th time now. Then you’re pulling your hair for why that’s a problem and not another reason your product is ready to sell to F1 teams. But likely, you’re just annoyed you’ll have to tell your boss or your 5 most important customers that they’ll still have to wait before the new thing can get shipped for them to use.
You can use Cline or some other open source tool with a little bit of upfront setup to better understand the code. Below, I just downloaded the Ollama repo from Github and asked Cline (connected to the Gemini API, but you can also use local models too!) to explain something inside the repository to me. It’s a simple example, but the sky is the limit for how you can make this work for you. Mostly, though, you might want to use this to help you learn more technical concepts inside your codebase at your own pace.
Why go through all this? Well...you might have an engineering team who would rather focus on fixing an issue than to have to hop on a meeting to explain something to “Senior Leadership” taking time away from solving the problem. This helps you be a better first line of defense for your team. (NOTE: The lesson here isn’t to gatekeep important, perhaps consequential, discussions from your engineers. It’s to give them an option to opt-out should they trust you enough to handle things on their behalf)
Here’s how an Apprentice and Orchestrator might approach this:
Apprentice: Uses Cline to explore the codebase, hoping to understand the basic concepts so they can participate more effectively in technical discussions. They document their findings and share them with the team, hoping to spark some knowledge-sharing. This newfound (and still limited) knowledge helps them have more productive conversations with both senior leadership and the engineering team.
Orchestrator: An Orchestrator might go a little beyond this. While contributing to external-facing codebases is generally a bad idea for a non-engineer, there are plenty of places where internal tooling can be improved. An Orchestrator might identify a need for a better internal tool or an open-source one and then use AI to accelerate the development process, working closely with engineers to bring their vision to life. My colleague, Chris Holmes, is a perfect example of this. He even published a tool to download GeoParquet data from cloud sources via QGIS, built using Cursor and Claude. He published his journey of making it happen that you should take a look at.
Look, obviously AI isn’t going to solve all our problems. The real challenge for us as product managers is to use these tools to do things that actually make a difference. It doesn’t even have to be done at scale. Just make the life of your nearby team members better. Your Product Marketer can be closer to the product and the engineers. Your engineer can be closer to the customer (without actually having to talk to them, unless they really want to). Challenge the way things have always been done. Create products that are not just innovative, but also ethical, responsible, and human-centered. And maybe, just maybe, in the process, we can become better leaders, better teammates, and better people.