What a Technical Product Manager actually does (and doesn't)
March 14, 2026 · 6 min read · By Jean-Philippe Cormier
Every company seems to define 'Technical Product Manager' differently. Some treat it as a senior PM with a CS degree; others as a project manager with API knowledge. Both miss the point. After 16 years in the role, here is the definition I use.
What a TPM owns
- The 'why' and the 'what' of platform-level decisions
- Trade-offs between scope, time, cost, and technical debt
- Cross-team dependencies (APIs, data contracts, infra)
- Roadmap arbitration when two engineering teams want the same week
What a TPM doesn't own
- How code is written — that's engineering's job
- Pixel-perfect design decisions — that's design's job
- Sprint mechanics — that's the team's job
- Being the smartest person in the room — that's nobody's job
Where TPMs create leverage
A great TPM removes ambiguity faster than anyone else in the building. They turn a vague request from a stakeholder into a one-page spec engineers can estimate, then into a release plan that finance, marketing and support can prepare for. The output is alignment — not artifacts.
How to spot a great TPM
Their engineers trust them on technical trade-offs. Their designers feel heard. Their executives get the numbers they need without asking twice. And the roadmap actually ships — quarter after quarter.
Good TPMs are translators. Great TPMs are also editors — they cut what doesn't matter.