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.
You can now define with precision. And before you orchestrate any action, you can get meaningful validation of whether your definition even makes sense. With AI, you can prototype fast enough to get 50% of the way to confidence before committing engineering time. The workflow shifts: define, prototype, validate, then orchestrate. The loop is shorter. The mistakes are cheaper.
The underlying mandate hasn't changed though. Care. Care about whether the thing you're building actually helps the person who has to use it. Everything else is downstream of that. Process without care produces hollow products.
If you want the longer argument for why AI changed what this job looks like in practice, I wrote about it here. This page is where the principles live. That post is where they got tested.
Always start with the problem, not the solution. Before any discussion of what to build, be able to answer: what pain exists today, who experiences it, how often, and what happens if we do nothing?
The failure mode I watch for: jumping to a solution because it's exciting, then working backwards to construct a problem that justifies it. It happens more than anyone admits.
"Launch X" is not a goal. "Reduce analyst triage time by 40%" is a goal. The question after shipping is always: did behaviour change? Did the pain go away?
Outputs are easy to measure and easy to game. Outcomes are harder to measure and much harder to fake. Use outcomes.
Strategic context, clear outcomes, guardrails. Then trust the team to figure out the how. Micromanaging the solution is a failure of trust and usually produces worse results.
The best engineers I've worked with don't want to be told what to build. They want to understand what problem they're solving and why it matters. Give them that and get out of the way.
Now/Next/Later. The further out, the more likely things change. That's not a failure of planning. It's honesty about uncertainty. A roadmap with specific dates twelve months out is a confidence trick, not a plan.
Ship early, learn, adjust. Every release should deliver standalone value. Big bets rarely survive first contact with users intact.
With AI: prototypes are now cheap enough that iteration starts before engineering begins. Get something in front of a real user before committing the roadmap. You can get 50% there with a prototype. That's 50% you didn't have yesterday.
Taking time to understand a problem properly is not slow. It's the thing that prevents you from building the wrong thing confidently and expensively. Slower in the short term. Faster in the long term.
These principles weren't formed in a vacuum. A lot of my thinking on product was shaped reading through the work of Rian van der Merwe, whose writing on what product management actually is (and isn't) cut through a lot of noise I'd absorbed earlier in my career. We overlap at Cloudflare, and his clarity of thought on the craft has been genuinely useful. If you work in product and haven't come across his writing, you should. What's here is my version, personalised through years of practice, but the foundations owe him a lot.