Difference between Product Manager and Technical Product Manager

Hi , I was offered Technical product manager (TPM) role at a company. I wanted to know the difference between this role and product manager role.
I understand product manager as someone who is market, customer and business focused. Who defines the why and what of the product. The technical aspect is handled by the tech team. Now then what does it leave on the table for a Technical product manager? Is this just another made up role for techies who are good at defining things? I am really annoyed with companies creating such pseudo roles. I think TPM is more of a grunt role of taking requirements from people and get it delivered by Tech team, more like a project manager.
Please share your thoughts.


Each company has a different definition and YMMV. But Amazon can be a good case study here. It has four roles:

  1. Product Manager, Tech. (PM-T)
  2. Product Manager (PM)
  3. Technical Program Manager (TPM, TPgM)
  4. Program Manager (PgM)

As you go down from #1 to #4, the work becomes more execution and less strategy. Though at very high levels, it should be strategy for all (except #1 is strategy for a product initiative and #4 is strategy for execution of a program or org related functions).

Generally speaking, the pay also goes down as you go from #1 to #4.

What you need to clarify with the HR/HM is if you are #1 or #3 in the list.


FWIW there’s also a fifth role at Amazon for PM-T ES (External Services).

To be specific about Amazon (based on my experience) a generalization is that almost 100% of the PMs at AWS are a PM-T or a PM-T ES (external services), while in retail it is a mix.

All PMTs are expected to understand the strategy of building complex technical products and to be able to “speak engineering” to understand system architectures, etc. PMT ES has the same expectations, with the addition of building a service that customers interact with via software, eg an API or a SDK.

At AWS at least, PMT and PMT-ES are highly comped and generally speaking very senior roles, rarely being hired at anything lower than a L6.


Same old story. It means different things to different companies. And the quality of the title maybe depends on who wrote it. To a junior HR person, anything that looks like code might be technical.

From my perspective, it’s the difference between a more holistic PM, (maybe covering the ‘problem space’ of customers in general, perhaps P&L/budgeting, maybe high level requirements, maybe an individual contributor or has product owners and designers working for them, etc… and then a Technical PM. That person is maybe more engineering focused, perhaps an expert at defining APIs, or data schemas, or search technology focus. For example, what retail maybe used to call a “merchandiser” is someone who deals with products, gets them on shelves, maybe categorizes them. But today, that person might be an expert on taxonomy and faceted metadata, working closely with search technology and responsible for some complicated data flows. And that person could have a high demand skill role, possibly even getting paid more than a more general PM type.

So we end where we began and say - as with the hundreds, (thousands?), of similar posts on this topic… with the unsatisfying “it depends” answer.

You have to dig in a bit more to understand the scope of this particular role at this particular company. What it means to them. What the path towards the future might look like, etc.


Is TPM a junior level role? I have worked as a TPM for 2 years now. Is it fair to ask to jump to PM ? Please advise.


@PriyaVarma, It depends on the company and product. You should ask the company you’re interviewing with how they define the difference between TPM and PM.


Answers, (well, my perspective anyway), on your two questions:

  • Is TPM a junior level role?
    • As before, sorry… it depends. It may be a ‘tightly scoped’ role, but not necessarily junior. Some have called aspects of TPM work potentially ‘grunt’ work. But that’s not necessarily true. A SaaS product with core partners operating heavily with APIs might require a fairly senior level TPM to manage some of those flows. Crafting those solutions can be strategic, and tactical, and anything but “grunt.” I don’t know what specifically you’ve been doing, so it’s hard to say. What I can tell you is I’ve worked with, (and had direct reports), who were “Technical Product Managers” and the idea of it being ‘grunt’ work would never have crossed my mind at all. They were highly skilled and very well paid.
  • Is it fair to ask now to switch to PM?
    • Sure. Why not? That depends on if you have the skills to switch over. And what level is required at your place. It would be great if there was a PM or manager where you are with whom you could speak about this. In a perfect world, a non a-hole type who could maybe even be a good mentor. If there’s an opportunity to do so, you could even ask about taking on a side project at the company that was more PM general. Or shadow someone a bit in their role.
    • Readiness Levels:
      • Junior Crap Show: There are some PM roles out there where very junior folks with little experience get hired because the company just doesn’t know any better. This can offer amazing opportunities. Or be a disaster. For better or worse, there’s likely a straight on PM role you could get based on the experience you have, even if you’re not fully spooled up. But like so many PMs, you dive in big and learn as you go. Some people have thrived in this kind of environment, grown, and gone on to fine careers. Others have $$%%^ things up pretty badly.
      • Junior Real Deal: You’ve got a decent PM org and you can slide into a junior role and learn from quality more senior folks.

Remember, a more general PM role will also depend on the business. If the role has financial/P&L, etc. responsibility and you have zero finance background, maybe not the best place to start. If it’s more about product focus, and you’ve been doing that at a ‘lower’ level, maybe that’s a great place to start. Your scope will change. And your focus will change. You will - ideally - be living a lot more in the ‘problem’ space than just the ‘solution’ space, as you mention somewhat in your original post. You’ll have more stakeholders and be interacting, (again, ideally), directly with end customers, sales, marketing, whomever. So it’s a mind shift. You won’t just be “doing a thing,” but you’ll be trying to figure out - and deciding - what are the RIGHT things to do in furtherance of organizational vision, mission, goals/objectives.

Out of curiosity, please stop back here at some point and let us know what the outcome ends up being.


Thank you @MarcoSilva.
@DhirajMehta, Thanks for sharing your perspective. I am clear I want to work on the strategic and customer centric layer of the product . So TPM might not be a good fit for me? I have already done TPM work for 2 yrs in earlier org. Is this fair to ask now to switch to PM ?


@Priya, Did you ask the hiring manager? You’re going to get a ton of different answers here. None will be as accurate as that of the person you’ll be working for.


@Angie, Yes but hiring manager will be biased. Here I will get neutral opinions.


@PriyaVarma, Opinions is what you don’t want in this case. You’re asking something that varies so widely from company to company (and sometimes even from department to department within a company) - you want as close to the truth as you can get.

You’re right in that a hiring manager will be biased. They’ll be biased to finding the best candidate for the role. If you’re honest about your concerns, they’ll either assure you that the role is what you’re looking for or they’ll advise that its not. No decent hiring manager wants to hire someone only to have them quit 3 months later because they weren’t honest about the role - especially in this market.


Agreed with all of this.

@PriyaVarma, to show you how different the titles can be at different companies, I work for a public SaaS and am a TPM. TPMs here are more like Project Managers that help coordinate between PMs, engg and potential third parties. I have had pretty poor experiences with Project Managers in the past, so I feel like I lucked out and really like my role as a TPM. I’m technical, extremely well organized, and can handle myself well on calls. Hope I stay with my team long-term.


We use PM and TPM setup in our company. So, the role of PM is customer centric - gather requirements and feedback, share roadmap, explain that X will not be done. Also PM responsibility is to prepare direction what and why should be done (strategy). PM works closely to marketing, sales etc.

TPM is focused on execution - turning what & why into a working product with meaningful end-to-end experience. In some cases it really is about project management, but mostly it is about defining the product. Of course, depends on TPM and the team level and maturity. TPM works closely with engineering, QA, or doc.

In the end we (me and my fellow TPM) both define the roadmap and work as an mirror to each other - is this really a priority? do we want to invest that much in this? Are you sure this is not over-engineered solution? etc.


@MichaelYoffe, I’m also trying to understand the distinction, it kind of sounds like TPM at your org is similar to a PO? Is there any difference?


@Marty, In general the role is very similar. I have bigger impact on our roadmap, compared to my previous experience as a PO. probably the biggest difference is that I participate in technical decisions/designs as well.


It depends on the company.

Some companies consider use this to replace the agile Product Owner, others consider this to be a more distinguished roll because you cover tech and business well.

You need to ask this question directly to the recruiter and if they don’t know the hiring manager.


Like everyone says - different at every company. In my role, the reason I’m a TPM instead of a PM is because I have a strong technical background. The expectation is that I can better assess technical capabilities and technical debt needs, while of course prioritizing things effectively with this in mind.

When we say we want to use Kafka - I need to know what that is at more than a superficial level, how that impacts downstream product decisions, the technical risks of implementation, etc. Normally I wouldn’t have as much of a focus on product marketing and user interviews, but since we’re a Series A, I’m a full-stack PM (to borrow a SWE term).

Hope this single perspective helps.


@Damian, Thanks for sharing. I just don’t see how your role is different than say a Tech lead or Tech project manager? Not saying they don’t add value. But it’s more on the technical front.


@Priya, Think more or myself as a PM who understands why tech decisions are made and how they impact the future roadmap. A tech lead cares less about the roadmap (though still some) and more just about best implementation.


IMHO, a technical PM is building a product that is used by developers or other technical people. A TPM would be building Azure’s developer tools, or postman’s troubleshooting tools, or even an internal service that will simplify the in house developer process.

However, as other users have pointed out, it all depends on who writes the job description.