The confusion in the role market
If you read ten Technical Product Manager job posts on LinkedIn, you will find at least five of them describing what is, by any reasonable definition, a regular Product Manager role. The opposite is also true — plenty of "Senior Product Manager" listings that absolutely require a Technical PM but are not advertised that way.
This costs companies real money. The wrong hire takes 3 to 6 months to surface and another 3 to 6 months to replace. Worse, it costs the team trust: engineering teams who get burned by a non-technical PM stop reading PRDs; business teams who get burned by an over-engineering PM stop trusting product judgment.
The fix is being precise about which role you actually need.
The classic Product Manager
A classic Product Manager owns the why and the what. They are responsible for understanding users, prioritising the roadmap, communicating with stakeholders, and measuring outcomes. They are typically strong at:
- User research and customer interviews
- Market analysis and competitive positioning
- Roadmap prioritisation and stakeholder communication
- Defining outcomes and tracking metrics
- Partnership with marketing, sales, and customer success
What they delegate to engineering: the how. They write PRDs at the level of "users should be able to import a CSV of contacts," and the engineering team figures out the schema, the validation, and the API contract.
The Technical Product Manager
A Technical PM owns the why, the what, and meaningful parts of the how. They write PRDs at the level of "users should be able to import a CSV of contacts; the schema is X, the validation rules are Y, here is the suggested API contract, here are the edge cases we need to handle, and here is the test data."
They are typically strong at:
- Reading and writing code (well enough to debug a PR, not necessarily to ship features)
- API design and data modelling
- Reviewing technical specs and architecture decisions
- Tradeoff analysis between feature scope and engineering complexity
- Working with infra, dev tools, and platform teams
A good Technical PM is not a part-time engineer. They do not write production code. They write specs that engineers can build from on day one, and they unblock engineering decisions that would otherwise stall the team.
Five signals you need a Technical PM, not a regular PM
1. Your product is sold to engineers. Developer tools, infra products, APIs, observability platforms, security products. The buyer is technical; if your PM cannot speak to the buyer, your product will drift.
2. Your engineering team is small and senior. When the team is six senior engineers, the bottleneck is rarely "more features" — it is "fewer half-baked PRDs." A Technical PM can write specs at the level the team needs.
3. The product has deep architectural questions in the next six months. Schema redesigns, API breaking changes, multi-tenant rearchitecture. A regular PM will defer these to engineering and lose ownership of the roadmap.
4. AI or ML features are central. AI features have non-obvious cost, latency, and quality tradeoffs. A PM who cannot reason about prompt design, retrieval architecture, or eval pipelines will ship the wrong AI feature 3 times before they ship the right one.
5. You are pre-seed to seed and the founders are technical. Technical founders need a PM partner who can argue back about engineering tradeoffs. They will eat a non-technical PM alive — usually politely, sometimes not.
Three signals a regular PM is enough
1. Your buyers are non-technical. SMB CRM, marketing tools, B2C consumer products. The constraint is not engineering; it is understanding the buyer.
2. Your engineering team is large and has strong tech leads. When you have 30 engineers and 3 strong tech leads, they own the architecture. A regular PM can drive outcomes while leaving the how to engineering.
3. The product is in the "scale and optimise" phase. Once a product has clear product-market fit, the work shifts toward growth, retention, and pricing. These are PM problems, not Technical PM problems.
The hybrid model: when one person plays both
Early-stage SaaS often runs with one person doing both Technical PM and IC engineering work. This is fine for 6 to 18 months. After that, the engineering work crowds out the PM work, and the team starts shipping features that have no clear customer rationale.
If your "Technical PM" has been writing production code for more than a year, you do not have a Technical PM — you have an engineer. Either hire a real Technical PM and free your engineer to engineer, or hire a real engineer and free your PM to PM.
Hiring tips
When hiring a Technical PM, do not ask LeetCode questions. Ask:
- Walk me through a PRD you wrote that engineering loved. Why did they love it?
- Walk me through a PRD you wrote that engineering hated. Why did they hate it?
- Pick a feature your previous product shipped. Sketch the data model and API contract on a whiteboard.
- Tell me about a tradeoff you negotiated between scope and complexity. How did you decide?
The first two questions reveal whether they have actually written PRDs that worked. The third reveals whether they can think technically. The fourth reveals whether they can lead, not just describe.
Closing thought
The PM role is not one job — it is a family of jobs that share a name. Hiring well requires being honest about which member of the family you actually need. Get it right and your engineering velocity doubles; get it wrong and you spend a year in the wrong meetings.
If you are trying to figure out which one your team needs, book a free strategy call — I have hired and worked alongside both, and a 30-minute conversation usually clarifies it.
