Shreyas Doshi has the best definition of a PM I’ve come across: the PM is responsible for defining the product, and for orchestrating actions across the company to ensure its success.
I’ve held onto that for years. It’s clean. It captures both the thinking and the doing. It doesn’t let you hide in strategy and it doesn’t let you disappear into execution.
But I think AI has changed something fundamental about what both halves of that definition actually look like. Not in the incremental “you’re 20% faster now” way that most people mean when they say it.
The definition part used to have a ceiling
When you define a product, you’re making claims about what users need, how they’ll behave, and what the solution looks like. Most of those claims are guesses dressed up in research. The honest version of a PRD is a hypothesis document. You’re saying: I believe this is the problem, I believe this is the right solution, and I believe that if we build it, users will change their behaviour in this specific way.
The problem is that by the time you find out whether any of that is true, you’ve spent months and a team’s worth of effort. The feedback loop is slow. So you compensate by doing more upfront research, more stakeholder alignment, more process, hoping to buy down uncertainty before it becomes expensive.
AI compresses that loop significantly.
I can take a problem I’ve heard from five customers, generate a working prototype in a day, put it in front of real users, and get meaningful signal before a single engineer has written a line of production code. Not production-grade. Not scalable. But real enough to test whether the definition even makes sense.
That changes the confidence level you can walk into a roadmap conversation with. You’re not presenting a hypothesis anymore. You’re presenting a hypothesis that has already been partially stress-tested.
You can get 50% there before orchestrating anything
The orchestration half of PM (aligning engineering, design, marketing, sales, leadership) is expensive. It consumes time, goodwill, and attention. You want to do it when you have conviction, not when you’re still figuring out the shape of the problem.
The old workflow: define, orchestrate, build, learn. The loop was long and the learning came late.
The new workflow: define, prototype with AI, validate with users, refine, then orchestrate. You get to 50% confidence before you ask anyone to commit to anything.
That’s not a small thing. It means you can afford to be wrong at the definition stage, catch it early, and arrive at the orchestration conversation with something that’s been touched by reality, not just assembled from assumptions.
What this actually requires
This doesn’t work if you treat AI as a shortcut through the thinking. The prototype that validates a wrong hypothesis just validates it faster. The question “is this the right problem?” doesn’t get answered by a demo. It gets answered by talking to the people who have the problem.
What AI does is collapse the gap between “I think I understand this” and “I have something concrete to show and test.” That gap used to take weeks. It doesn’t have to anymore.
So the job hasn’t changed at its core. You still have to care deeply about the user’s actual experience. You still have to be honest about what you don’t know. You still have to make calls under uncertainty and live with them.
But the tools you have to inform those calls are fundamentally different now.
The thing about caring
None of this matters if you don’t actually care.
I’ve worked with PMs who were excellent at the process (requirements documents, stakeholder maps, roadmap ceremonies) and produced nothing useful because they were executing a job rather than solving a problem. The process was pristine. The product was hollow.
The core mandate, I think, is simpler than any framework: care about whether the thing you’re building actually helps the person who has to use it. Everything else is downstream of that.
AI doesn’t give you that. It amplifies it if you have it. It amplifies the absence of it if you don’t.
The principles I try to hold to, and how I got there, are on the Philosophy page. This post is about what changed. That page is about what stayed the same.