Every time I have been hired as a Technical Product Manager, senior management has asked me the same question: how involved are you in the code? My answer has always been the same. I work closely with the development team at the level of algorithms, architecture and best practices, so they can think a technical problem through with me and weigh the options. I do not review code or merge pull requests. That question keeps coming up because “Technical Product Manager” is one of the most misread titles in tech, and the acronym makes it worse: TPM also means Technical Program Manager, and in some companies Technical Project Manager.
I have held two of those three titles, and under the same Technical Product Manager title I have done both a deeply technical job and one that was a product manager role in all but name. This post sets out what actually separates a technical product manager from a product manager, and how to tell which one a job post really means.
The short answer
A product manager owns what gets built and why. A technical product manager owns the same what and why, plus the technical trade-offs behind how it gets built. A TPM usually works on products where the hard decisions are technical: APIs, platforms, payments, data and AI systems. Neither role writes production code. The difference is how deep into engineering decisions the job expects you to go.
What a normal week looks like in each role
Job descriptions for the two roles read almost the same. The difference shows up in the calendar. Here is how the weeks compare, drawn from my own weeks in both kinds of role.
| Product Manager | Technical Product Manager | |
|---|---|---|
| Main question | Are we solving the right problem for the right users? | Same, plus: can we solve it this way, at this cost, without breaking something else? |
| Meetings | Customer calls, sales and marketing syncs, roadmap reviews | Architecture discussions, API reviews, backlog refinement with engineers, roadmap reviews |
| Writes | Problem statements, user stories, launch and positioning notes | User stories plus technical requirements, acceptance criteria, API and integration notes |
| Gets asked | “Why are we building this?” | “Why are we building this?” and “Which approach should we take?” |
| Measures | Activation, retention, conversion, revenue | The same, plus reliability, success rates, latency and technical debt |
| Typical products | Consumer apps, B2B tools, marketplaces | Platforms, APIs, payments, data pipelines, AI and ML features |
I have lived in both columns under the same title. Leading a payment gateway migration across a family of telecom products put most of my week in the right-hand column: how the new gateway handled saved cards, auto top-ups and 3D Secure, and how to split traffic between the old gateway and the new one without losing a payment. Later, running a portfolio of WordPress plugins at a plugin company, the same title came with a week in the left-hand column: user feedback, data-driven UX revamps, user stories, prioritization and retention. That was a product manager job in everything but name.
That swing is the point. The title does not fix the week. The product does.
Where the roles overlap, and where they clash
Most of the job is shared. Both own the backlog, both prioritize, both manage stakeholders, both define success before a feature ships, and both carry the outcome. A TPM who skips discovery because they are busy with architecture is not a better PM; they are an incomplete one.
The tension sits in one question: how much should a TPM weigh in on engineering decisions? Too little, and the technical depth is wasted. Too much, and you take ownership away from the engineers and quietly become the bottleneck.
When the technical background helped: during the payment gateway migration, the riskiest parts were not on any feature list. Saved cards, auto top-ups and 3D Secure authentication each behaved differently on the new gateway, and each one could quietly cost customers or revenue. Understanding how they worked meant I could plan the migration around them with the engineers: which saved cards could move and which customers would need to re-enter theirs, and why traffic had to move gradually rather than all at once. That gradual split is exactly where 3D Secure friction started causing drop-off, and we dealt with it before the full rollout, not after.
When it got in the way: at the plugin company, the less technical of my two roles, I was discussing a plugin problem with the developers and got deep into which approach was better, which algorithm to use and how the UI should work. Halfway through, one of the developers asked me, “Do you want to join the development team?” I said, “Pardon?” He asked again. Then I understood. I knew a solution, and I had been handing it to them instead of letting them find it.
The rule I now follow: bring the technical knowledge as questions and constraints, not as solutions. “What happens to saved cards if we switch gateways?” helps the team. “We should do it this way” usually does not. Even when I know the answer, I let the team discover it, as long as getting there does not cost much. When staying quiet would cost real time, money or customers, I speak up.
Skills each role really needs
Both roles:
- Running discovery: interviews, assumption tests and reading behavioral data before committing engineering time
- Prioritizing with a framework you can defend, such as RICE or MoSCoW
- Saying no to a senior stakeholder and keeping the relationship
More important for a product manager:
- Market and competitor analysis, positioning and pricing input
- Working closely with sales, marketing and customer success on launches
More important for a technical product manager:
- Reading an architecture diagram and asking where it will fail
- Understanding APIs well enough to write integration requirements and judge a breaking change
- Weighing technical debt against new features in the same roadmap
- Planning migrations and rollouts: phases, traffic splits, fallbacks and rollback plans
- Knowing what AI and ML components can and cannot reliably do
I have written more about this balance of depth and breadth in the T-shaped Technical Product Manager.
How companies use the titles differently
If job posts have confused you, it is not you. The same three letters mean different jobs in different companies.
- Startups often use “Technical Product Manager” for a PM who can also act as a bridge to a small engineering team, sometimes with delivery and project duties mixed in. Read the responsibilities, not the title.
- SaaS companies tend to use TPM for platform, API, integrations, data or infrastructure areas, while PMs own user-facing features and growth.
- Large tech firms often use TPM to mean Technical Program Manager: a role that coordinates delivery across many teams, owns timelines and dependencies, and does not own the product decisions. That is a different career, closer to project management than product management.
- Some companies still use TPM for Technical Project Manager, which owns delivery of a defined scope. I held this title for three years before moving into product, and the jobs are very different: a project manager is measured on delivering the plan, a product manager on whether the plan was the right one.
How to decode a job post: if it talks about timelines, dependencies, cross-team coordination and delivery risk, it is a program or project role. If it talks about users, discovery, roadmap ownership and outcomes, alongside APIs, platforms or data, it is a technical product manager role.
Which one fits you?
Answer these honestly:
- When a feature is proposed, is your first instinct to ask who needs it, or how it would work? The first points to PM, the second to TPM, and both together to TPM.
- Would you rather spend an afternoon on customer calls or in an architecture review?
- Do you enjoy translating between engineers and business people, or would you rather go deep with one side?
- Are you drawn to products whose users are other developers or systems, such as APIs, platforms and payments?
- Would you miss shaping how a system is built if you only decided what gets built?
If you are a developer weighing the move, start with how to move from developer to product manager, where TPM is often the first step. If question 5 was a strong yes, read the Solution Architect path too: it keeps you closer to how things are built. And for why the TPM role exists at all, see the TPM as the bridge between development and business.
Is technical product manager a good career?
Yes, and it is becoming more valuable. As AI makes building faster, more products are platforms, data pipelines and AI features, where product decisions and technical trade-offs cannot be separated. A product person who can judge both is harder to replace. The risk is the opposite one: a TPM who drifts into being a technical lead or a delivery manager stops doing the product job, so keep owning the outcome.
What I would tell my earlier self
When I moved from development into technical project management, most people assumed it was a reward for being a good developer with years of experience. That was only part of it. Alongside writing code, I had been taking ownership of outcomes, building the team, and managing the work around the code, not just the code itself.
My director gave me one piece of advice at the time: stay away from the code. I knew which code was where, which branch it lived on and what to do with it. That was exactly why I had to step back, and guide the team to the fix instead of making quick fixes or taking the complex tasks myself. It was good advice. It took a developer asking whether I wanted to join his team, years later, for me to fully hear it.
So this is what I would tell my earlier self about choosing between the two roles: your technical skill gets you considered for either one. What makes you good at it is everything else. Choose by the problems you want to spend your week on, not by the title. The title will mean something different at your next company anyway.
Tahir Shahzad is a Technical Product Manager and fractional product consultant who moved from web and ML engineering through technical project management into product, across payments, analytics, AI and SaaS products. If your team needs someone who can work both sides, see technical product management or get in touch.
Tahir Shahzad
Tahir Shahzad is a Product Manager, Product Owner, and technology consultant with over a decade of experience helping startups and organizations build products people actually use. If you are working on a product problem worth solving, reach him at tahirshahzad.com/contact/
