Should I learn to code if I want to go into product management?

You need to be technically *literate*, not able to code professionally. The distinction matters: PMs who can hold a credible conversation with engineers are substantially more effective, but PMs who try to write production code or dictate implementation are a known anti-pattern. **What technical literacy actually means for a PM:** 1. **Understanding how systems fit together** — what a frontend, backend, database and API are, and how a request flows through them. This is what lets you understand why something 'simple' takes three weeks. 2. **Being able to reason about effort.** Not estimating, but understanding why adding a field to a form might be an hour or a month depending on what's behind it. 3. **Knowing the vocabulary well enough to follow a design discussion** and ask a useful question. 4. **Understanding technical debt and trade-offs** — why the team wants to spend a sprint on something invisible to users, and being able to defend that decision upward. 5. **Reading data yourself.** SQL is arguably the single highest-value technical skill for a PM. Being able to answer your own questions about product usage without queuing behind an analyst changes how fast you can work. **How to get there without learning to code professionally:** - Learn SQL properly. Weeks, not months, and it pays back immediately. - Build one small full-stack thing end to end, badly. Not to become a developer — to viscerally understand what's involved. This single experience changes how PMs talk to engineers more than any amount of reading. - Learn the basics of how the web works: requests, APIs, databases, deployment, what happens when you load a page. - Read your team's technical design documents and ask questions. - Sit in on architecture discussions and take notes on what you don't understand, then ask afterwards. **What's counterproductive**: spending a year becoming a mediocre developer when that time could go into customer research, data analysis, or writing clearly — which are the skills PM roles are actually short of. Also, using technical knowledge to argue about implementation. The line is: the PM owns *what* and *why*, engineers own *how*. Crossing it damages trust quickly and permanently. **Where it matters most**: developer tools, infrastructure, APIs and technical platforms, where a non-technical PM struggles genuinely. It matters least in consumer products with straightforward technology, where user insight dominates. The short version: enough to earn engineers' respect and understand their constraints, not enough to do their job. Most strong technical PMs are at roughly the level of a competent hobbyist, and that's sufficient.