Passing in the rain - AI as a PM career accelerator
“You cannot overtake fifteen cars when it’s sunny weather, but you can when it is raining.”
Senna wasn't talking about luck. He was talking about what happens when conditions get difficult enough that machinery stops mattering and everything becomes about the driver.
In a dry race, the fastest car wins. Full stop. Superior engineering, superior funding, superior infrastructure. The gaps between competitors are baked in before anyone turns a wheel. When the track is wet, those advantages compress - the driver who reads the conditions fastest, who commits when others hesitate, who stays sharp when the car feels alive underneath them, that driver can go from fifteenth to first in ways that were impossible an hour earlier.
The conditions for product managers right now are wet. Torrential, in fact. And most people are treating that like bad news.
What just changed
For most of the last decade, the constraint on good product work was engineering capacity. You could identify the right problem, write the sharpest brief, align every stakeholder in the building, and still wait six months to find out if you were right. Feasibility was a genuine wall.
AI has dissolved that wall. A prototype that would have taken a team two weeks to scaffold now exists in an afternoon. The cost of building software has collapsed to something close to zero.
For PMs who were coasting on process, these are the conditions in which you crash. For PMs who are sharp, who understand what they're building and why, who can direct AI to produce the right thing because they understand the tradeoffs underneath the prompt, these are the conditions in which you ovetake. The machinery gap just closed. It's all driver now.
Start building. Not at work. On your own time.
The goal is reps, not polish. Nobody is grading you. Solve a niche problem for yourself, your friends, your family. Pick up the pet project you've been putting off for years because you "don't know how to code." The entry cost has fallen away.
Use Claude Code or Cursor rather than no-code tools. The goal matters here: produce code an engineer could ship with minimal changes. No-code tools are fine for disposable experiments. You're not training for disposable. You're training to close the gap between your thinking and what ends up in production, and that requires understanding what production actually looks like.
The excuse that you don't have time has never been thinner, if you’re not able to use the latest AI tools at work, you’ll be quickly replaced when you can unless you already know what you’re doing with them.
Sharpen your technical foundations
In a wet race, every input counts. Knowing the track means knowing where to push and where the car will bite you. The same is true here; you don't need to read code. You need to make good decisions about it.
Data modelling. Know the difference between relational and non-relational databases. Know what a schema is and why getting it wrong early compounds into something expensive. Bad data models are bad foundations; everything built on top is a liability.
APIs. Know how systems communicate, what authentication patterns exist, what a webhook is. This is the plumbing of every product you will ever build. You don't need to lay the pipes. You do need to know where they run.
System layers. Frontend, backend, database as distinct concerns. When business logic ends up in the wrong layer it becomes invisible, untestable, and impossible to reuse. Knowing where things should live means you can spot when they don't.
Data pipelines. Where data comes from, how it transforms, where it lives. This separates PMs who can have a real conversation about analytics from the ones who present whatever report lands in their inbox.
Security basics. PII handling, encryption, role-based access, how authentication tokens work. You don't need to implement these. You need to know when they're missing and ask for them clearly enough that someone takes it seriously.
Scalability thinking. Stateless versus stateful, async versus synchronous, what technical debt actually compounds into. The decisions that seem cheap in month one tend to become the most expensive conversations in year two.
What to ask your company for
Push for read access to the codebase. Not to write code. To understand what exists, how it's structured, what assumptions are baked in. A PM with codebase access is a fundamentally different animal from one who has to wait for an engineer to answer every technical question.
Ask for AI coding tools. The argument isn't that you'll replace engineers. It's that your specifications will sharpen, your edge cases will get tighter, and your time-to-prototype will collapse to something that lets you validate ideas before they become commitments.
If the answer is no, build on your own time anyway. The market will not wait for your company's approval process.
The window is open
Senna didn't wait for better conditions. He read the ones he had and found lines through them that nobody else could see.
The feasibility argument is gone. The "engineering won't build it" argument is gone. What remains is judgement: what to build, for whom, in what order, and why. The PMs who understand the tradeoffs underneath the prompt will pull ahead. The ones using AI to clean up their meeting notes will wonder why the gap keeps growing.
Build something this weekend. Something small, something imperfect, something that teaches you how the pieces fit together. Then build something else.