How Technical Should PMs Be? (A Pragmatic Take)

“Should PMs learn to code?” is the wrong question.

The right question is: “What technical knowledge does a PM need to be effective?”

I’ve worked with PMs across the spectrum—from former engineers who could review PRs to liberal arts grads who’d never opened a terminal. The best PMs weren’t always the most technical. But they all understood enough to earn engineers’ respect and make sound technical trade-offs.

The Technical Knowledge Spectrum

Tier 1: You MUST know this

• How APIs work (REST, request/response, status codes)
• What a database is and basic concepts (tables, queries, indexes)
• Client vs. server (and what “backend” vs “frontend” means)
• How authentication works (sessions, tokens, OAuth basics)
• Basic performance concepts (caching, latency, throughput)
• What git is and how version control works

If you don’t know these, you’ll misunderstand engineers constantly and make terrible decisions.

Tier 2: You should know this

• Common architectural patterns (monolith vs microservices, sync vs async)
• How to read technical documentation
• Basic security concepts (XSS, SQL injection, HTTPS)
• What CI/CD is and why it matters
• Database scaling basics (replication, sharding concepts)
• How mobile apps differ from web apps

This knowledge lets you have informed conversations about technical trade-offs and feasibility.

Tier 3: Nice to have

• Reading code (you don’t need to write it)
• Basic SQL queries
• Command line comfort
• Understanding of specific tech stack (React, PostgreSQL, AWS)
• Familiarity with dev tools (debugger, network tab)

These make you more self-sufficient and earn extra credibility, but aren’t essential.

A Real Example

We were deciding whether to rebuild our notification system. Engineering said it would take “8 weeks.” Marketing wanted it “next sprint.”

A non-technical PM might have either:

1. Blindly trusted the 8-week estimate
2. Pushed back aggressively without understanding why

Instead, I asked questions:

Me: “What’s the current architecture?” Eng: “We’re hitting the database directly for every notification check. No queue, no caching.”

Me: “So every user refresh queries the database?” Eng: “Yep. And we’re at 200K users now. It’s getting slow.”

Me: “What if we did a temporary optimization—add basic caching—while we plan the full rebuild?” Eng: “That could work. Maybe 3 days of effort, buys us a few months.”

Outcome: We shipped the cache solution in week 1. It solved the immediate problem. The full rebuild happened later when we had more resources.

This conversation only worked because I knew enough to:

• Understand that database queries on every refresh was expensive
• Know that caching was a thing that could help
• Propose a reasonable middle ground

I didn’t need to know how to implement caching. I just needed to know it existed and roughly what it did.

How I Got Technical (Without Coding)

I didn’t start technical. Liberal arts degree, first job in marketing. But I was curious and intentional about learning.

What worked:

1. Shadowed engineers for a week - Just watched them work, asked questions about everything
2. Read post-mortems - When things broke, I asked to see the technical writeup
3. Attended architecture reviews - Even when I didn’t understand everything, patterns emerged
4. Asked “dumb” questions - “What does ‘API rate limiting’ mean?” led to 20-minute conversations that taught me tons
5. Built side projects - Made a simple website, broke it, fixed it. You learn more from breaking things than reading docs.

What didn’t work:

• Online coding courses (I’d never use it, so it didn’t stick)
• Technical books (too abstract without context)
• Trying to match engineers’ depth (unnecessary and exhausting)

The Credibility Test

Here’s how you know if you’re technical enough:

Good sign: Engineers explain trade-offs to you and accept when you choose the “wrong” technical option for business reasons

Bad sign: Engineers tell you something is “impossible” and you have no way to evaluate if that’s true

You don’t need to be able to build the product. But you need to be able to call BS when an engineer is sandbagging, and defend their estimates when stakeholders push back unfairly.

Bottom Line

Being “technical enough” means:

• You can follow technical conversations without glazing over
• You understand trade-offs (performance vs simplicity, speed vs quality)
• Engineers trust that you respect technical constraints
• You can bridge between “business wants X” and “technically we need Y”

You don’t need to code. But you do need to care enough to learn the fundamentals. Anything less, and you’re just a messenger between business and engineering—not a real product manager.