A PM’s Guide to AI

People ask me constantly what’s actually changing about product management right now. Most answers you’ll find are either hype or panic, a tool list or a warning. Mine is neither.

I’ve spent the last couple of years using AI inside real products, real client work, real deadlines, and my broad view, since I get asked, is that none of this scares me. Change is scary, I understand that, especially big change. But we’ve faced this kind of shift before, since the printing press, and it always brings pains alongside the upsides. Personally, I think PMs starting out today are fortunate.

My first ritual as a PM was writing meeting notes by hand, then turning them into outputs. That essence hasn’t changed. Everything sitting underneath it has. So this isn’t a playbook, and it isn’t a tool list either. It’s four things that shift taught me, the ones I’d hand to any PM trying to figure out where they actually stand in all of this.

Turning multiple stakeholders’ goals and user pains into a research output, then various PRDs, then into multiple tickets used to take most of my day. That was the job: not building, but translating, taking one thought and reshaping it, over and over, for whoever needed to act on it next.

Now I mostly just give the AI my requirements and constraints, and the dry part, writing it up and putting it where it needs to go, happens on its own. I say documentation is free now, and I mean it.

But free time is not the win. What you do with it is. Once documentation stopped costing me the energy it used to, I could take on more projects without feeling stretched thinner.

The really interesting part is where that energy went instead. Relationships with stakeholders. Understanding what’s actually wrong with the product, not just what we assumed was wrong. Holding the whole macro picture in my head instead of just my corner of it. That’s the skillset the job was always asking for. I just didn’t have the room to practice it properly before.

But free doesn’t mean automatic. You can’t automate what you don’t know how to do manually. If I hadn’t spent years writing PRDs by hand, I wouldn’t know what a good one contains, and I’d have no way to tell whether the AI’s version was actually right. That’s the part nobody gets to skip: understanding the pain well enough to know what you’re really getting out of the shortcut.

Whenever I’m building out context for an AI, I think of it as training an apprentice. A very enthusiastic apprentice, willing to work a lot, but one that needs to be taught how to work, where to look, what skills to use, and what the real-world context of that project actually is.

So the first rule I give any AI I work with is: ask questions, never make assumptions.

That teaching happens in layers. Every project I work on gets its own context, not because I’m precious about organization, but because I split my AI into a macro level, product management tools, project management, the stuff that’s true across everything I do, and then a separate context for each specific product I’m working on.

An apprentice like that picks up the basic skills fast: writing well, organizing information, keeping things structured. What it won’t have on its own is the content. That part I always have to bring myself.

Can you actually train the assumption-making out of a system? Not totally. Most of the planning, I’d say eighty percent of it, is still breaking down assumptions before they turn into answers.

Even when using AI, there’s still a first step: understanding the problem and what you’re actually going to use AI to solve. A quote I’ve been saying a lot the last few months is that it’s pointless to run faster if you’re not running in the right direction. Beyond pointless. Counterproductive.

Execution is much faster now. But sitting down with a person, understanding the problem, breaking it down, defining the requirements, has gained a new light because of that. Execution you can do with experts, with developers, or even yourself, if you’re prototyping and trying to fail fast. It’s doable. The real question is whether you’re doing the right thing at all.

You always have to make a judgment about the product you’re building. That’s where the human comes in. We work with finance and blockchain products, and an important aspect of blockchain is that it’s fully transparent, anyone who can read that code will be able to read it, and it’s immutable. Once it’s deployed, if there’s a bug, you’re going to have to handle it. So the human-in-the-loop concept comes very much into light: at what point will we trust the AI, and where does the human need to come in, and how?

There are features simple enough that we just throw the AI at it and review the output. As long as it’s working, fine. But there are features that, if they involve money or smart contracts, we’re much more careful. We put a human there to review, making sure everything is okay. Even that is probably more efficient than building it from scratch. A lot of the code is boilerplate, repeatable, and the AI can do that. The human goes to the critical point and spends their energy, time, and brainpower on the critical matters.

If I had to sum it up in one sentence: always be learning, always be critical of what you’re learning. It falls back to an old quote, though eighty percent of quotes are probably fake anyway. More important than reading is being critical about what you’re reading. I think that’s the go/no-go factor with AI: critical thinking.

The thing that’s unique to humankind is our imagination. AI empowers that a lot, because what you imagine can now be brought to reality quickly. So: always be learning, but always keep your imagination and a critical mindset on what you’re learning and how you apply it to your life.

*I’ve spoken about this and more of my takes on AI in the first episode of The Intelligence Series. Check it out here!