JB Product
← Back
Product StrategyTechnical PM

Technical PM: what it really means

Published on May 15, 2025·2 min read·Lire en français

You see "looking for a technical PM" everywhere in job listings. But what does it actually mean? Being able to talk JSON in a meeting? Writing SQL queries? Having studied computer science?

Short answer: no. Or at least, not just that.

What a technical background actually changes

1. Reading technical specs

A non-technical PM receives an estimate from the engineering team and has to trust it. A technical PM can ask the right questions:

  • "Does that 3-week estimate include integration testing?"
  • "Are we reusing the existing service or building a new one?"
  • "What's the risk if we skip the schema migration for now?"

This isn't about distrust — it's about depth of dialogue.

2. Defining scope

When you understand the architecture, you know what's expensive and what's cheap. A feature that looks simple on the UX side might require rebuilding the data layer. Conversely, something that looks complex might be just a config change.

This read on technical cost helps you prioritize honestly, not with poorly calibrated intuitions.

3. Credibility in the room

I'm not saying non-technical PMs lack credibility. But there's a difference between being respected and being heard. When you can sit through a design doc review and contribute on substance, your status shifts in engineers' eyes.

You go from "the PM who brings specs" to "someone who understands the constraints."

What it does NOT mean

Being a technical PM does not mean:

  • Rewriting specs in pseudo-code
  • Questioning every architecture decision
  • Positioning yourself as a backup tech lead
  • Coding in your spare time to "stay current"

The PM role remains defining the what and the why. The how stays in engineering's territory.

The real value

The real value of a technical PM is reducing translation costs. Every time a PM needs an intermediary to understand a technical constraint, there's information loss, delay, and risk of error.

A PM who can read code, understand an architecture diagram, or discuss technical tradeoffs reduces that cost — and speeds up the team.

This post is the first in a series on what it means to be a PM with an engineering background. Next posts will cover managing technical debt and collaborating with engineering leads.