For most of my twenty-five years the anxious question for a non-coding product person was whether they should learn to code. There were bootcamps. There were arguments on Twitter. The honest answer was usually a bit, enough to read a pull request and not embarrass yourself in a stand-up.
That question is now largely settled and the answer is no.
Not because coding stopped mattering, but because the marginal value of a product manager writing the code themselves has collapsed. I can describe the change I want with precision and get it built. The thing I bring is knowing which change, and why, and what it will do to the rest of the system.
But something replaced it, and almost nobody is saying this part.
You need to understand deployment.
Not perform it. Understand it. Where does this code go when it is merged. What triggers that. What happens if it fails halfway. Where are the environment variables and which environment is this one. What is the DNS actually pointing at. If it breaks at eleven at night, what is the sequence of things you check.
Here is why the swap happened. When AI writes the code, the code stops being the bottleneck and the seams become the bottleneck. Everything between "it works on my machine" and "a stranger can use it" is now the hard part, and that territory is full of things that do not fail loudly. The build succeeded but the environment variable was not set. The merge deployed but the sitemap got wiped, which happened to me repeatedly and drove me up the wall. The host auto-deploys but only for that branch. None of these are coding problems and all of them will stop your product working.
The good news, and it is genuinely good, is that this is far easier to learn than it used to be. Fifteen years ago understanding deployment meant a server, SSH, a web server config, and a folder of scripts written by someone who had left. Now a host listens for a merge to main and does the rest. The concepts are the same. The complexity is nowhere near what it was.
And you have a patient collaborator that will explain any of it as many times as you need, which is how I have learned most of what I know about the parts I had not touched before. There is no shame in asking it what a build step is.
What I would not do is skip it. Understanding stops at the point where you can no longer tell whether an explanation is true, and if your understanding stops at the merge button, you are trusting rather than knowing, and you will find out which on a Friday evening.
So: learn the path your code takes after you stop looking at it. That is the technical literacy the job now requires.
Next: where documentation should live.