What is a Technical Product Manager, Anyway? "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 28 May 2014 True Agile, Product Culture, Product Manager Jobs, product manager role, Technical Product Manager, Mind the Product Mind the Product Ltd 1452 Product Management 5.808
· 7 minute read

What is a Technical Product Manager, Anyway?

Technical Product ManagerWhat does it really mean to be a “Technical” Product Manager?  And how is it different from just a Product Manager?  In this post, I share the difference between these titles plus key Do’s and Don’t’s to help you succeed as a Technical Product Manager.

You might have noticed many variations on the Product Manager job title.  Some companies have Strategic Product Managers, while others have Product Manager titles linked to specific industry verticals, for example, eCommerce Product Managers and Energy Product Managers.  Among software companies, you’ll often see the titles Product Manager, Product Development Manager, and Technical Product Manager.  But what’s the difference, anyway?

In reality, the term Technical Product Manager describes a person, not a role.  Specifically, it describes a Product Manager who has a technical background and works on a technology product.  It does not describe a Product Manager who needs to actually perform technical tasks, such as software architecting and coding.  The same goes for a Product Development Manager.  They are not actually developing the product—they are performing a Product Management role in close coordination with a Software Development Team.

In short, for a company to get the most value from the role, Product Managers must focus on product management, not development.  But some Product Managers need to understand the company’s technology at a deep level and interface with the Development Team in order to successfully lead the strategy for the product.  Companies may choose to call these people “Technical Product Managers” in order to attract the right candidate.

In my view, technical skills are one of the Four Pillars of Product Leadership.  A technology-savvy Product Manager has huge advantages, such as:

  • Improved communication (and trust) from your development team.
  • Ability to understand tech trends, see how they impact your roadmap, and how they drive innovation.
  • Improved communication with your customers, for example when speaking with CIOs and CTOs.
  • Ability to understand technical challenges and make educated trade-offs with your team.

However, all too often, Technical Product Managers focus those valuable skills on trying to create the technical solution for their product, rather than solving the business and user needs of their target customer.

From that perspective, let’s look at key Do’s and Don’t’s for Technical Product Managers.

Technical Product Manager Do’s:

1.  Do focus on the business side of the role.

Regardless of the industry or vertical, the whole idea behind Product Management is to drive the vision and execution of a product.  It’s our responsibility to bring to market products that users want,  that solve a business need, and that generate profit for the company.  I’m always fascinated to see technologists launching their new company with a product that is a very clever technical implementation, but it doesn’t solve any real customer need.  Needless to say, these companies rarely do well in the market.

The focus of a Product Manager (technical or not) should be to understand what the users need and work with all the necessary departments to bring the product to life.  In that sense, the Technical Product Manager is a business role with some focus on technology as opposed to a technologist role with no responsibility for the product’s market success.

2.  Do use your technical skills to improve prioritization and planning.

If you have a clear understanding of how your product is built, then you are able to assess the risk of certain features or get a more accurate gut feeling about the duration of stories or tasks.  Since you are able to communicate with the Development Team in much more detail, you can understand the implications of certain decisions and make trade-offs in terms of complexity, depth or even timelines.

By demonstrating technical leadership, you’ll be able to quickly gain the trust of your development team and they will be more likely to stand behind you on tough decisions that require risky changes, prioritizing bugs, or even negotiating the dreaded “technical debt.”

3.  Do leverage your technical skills to close the communication gap between engineering and the rest of the world.

People with technical backgrounds usually forget that hardly anyone else understands (or cares) about the technical details.  This is a perfect opportunity for the Technical Product Manager to use her skills to translate between Engineering and other departments, including Sales, Product Marketing, and the customer.

Also, Technical Product Managers are often hired to drive products that are targeted at a very technical audience, such as APIs, development tools, IT software, etc.  In these cases, the product features, product positioning, and messaging has to resonate with a very technical audience.  This is another perfect opportunity to leverage your technical skills to communicate with your audience, get feedback (in their language), and help close a deal by speaking with the customer’s technical staff.

Technical Product Manager Don’t’s

1.  Don’t design/solution the product yourself.

This is a key source of confusion within the Technical Product Manager role.  Many Product Managers that come from engineering have a hard time leaving their comfort zone and realizing that their value is now in a different area.  They focus on defining the technical solution for a particular feature instead of defining the expected user outcome or business value.  They spend more time talking to their architects and looking over the developers’ shoulders, than talking to customers and Sales.

This causes problems on two fronts:

  1. The Development Team feels frustrated because the solution details are just handed down to them by the PM.  They don’t get a chance to architect and design the solution, which is a big part of their job, not yours.
  2. Most of the PM’s time is spent in the technical details, so there’s no time left for planning and understanding the customer.

In a nutshell, this approach doesn’t add value to developers, business owners, or the product itself.  Even Technical Product Managers need to be paired up with strong Technical Leads or Development Managers that can lead these tasks.  My motto is, “the fact that you can, doesn’t mean that you should.”

When writing features and stories, focus on the problem you are looking to solve and on the persona you are targeting.  The definition should include a flow diagram of what the solution should be (from a user perspective), including acceptance criteria.  It should not be a detailed explanation of the placement of every pixel, updates to the object model, or the required changes to the database tables.

2.  Don’t take on non-Product Management deliverables.

Many companies (especially those with a less mature Product process) think of the Technical Product Manager as an extension of the Development Team.  I’ve seen many job descriptions that list the regular responsibilities (roadmap, vision, feature definition, etc.), plus development responsibilities such as writing actual code, performing QA testing, writing documentation, etc.  To me, this just shows a big misunderstanding of the role’s value, and those situations should be avoided at all cost.

3.  Don’t get caught up in Agile, or whatever methodology you’re using.

I’m always amazed by the amount of discussion I see online about Agile and Product Management.  Though I do understand why–many Technical PMs come from development, so staying extremely involved in the day-to-day Agile flow feels very comfortable to them.

However, the reality is that Agile is a very small part of the Product Manager’s role.  Focusing too much on Agile can actually be a detriment when it’s taking time away from core PM responsibilities, such as interacting with customers and Sales and defining the roadmap.

To alleviate the workload, I’m a big proponent of having different people perform the Product Manager and Product Owner roles.  This approach is controversial, and it might only be possible in companies with a more mature Product process.  Regardless, I think there’s a lot of value in this separation to ensure that no aspect of the product development lifecycle or product management falls through the cracks, due to an overworked PM.

To get a better view of all the responsibilities of a Product Manager, I suggest looking into PM frameworks such as those from Pragmatic Marketing and SiriusDecisions.

In Summary

Different companies have different Product Management titles and responsibilities based on their type of product.  But regardless, the core job of a Product Manager is to provide the product’s vision, create the roadmap, and drive its execution.

Adding the word “Technical” to the title is useful in job postings to highlight the need for technical background.  But once in the job, the keys to success are the same as for every Product Manager—keeping customer focus, driving a vision, and ensuring the product meets the market needs.

This is a guest post written by Daniel Elizalde, author of Manager’s Build: best practices & inspiration for Product Managers & Leaders.

Comments 23

Interesting read, thanks so much for the clarification on the responsibilities of Tech PM role!

This is a good article! Thank you very much. I was hired recently as a ‘Technical Product Manager’ just because the role is part of the Engineering team. My core role was UX and project management working closely with Product owners and the dev team. It is a confusing setup and companies to understand the actual role of a Product Manager.

As a general rule of thumb, I stay away from companies that have “Technical Product Manager” roles. Sometimes it’s a euphemism for: we’ll pay you less, you’ll do the grunt work, and someone else will drive the product vision. No thanks. It’s usually the same companies who think engineers are a commodity, outsource to save a buck. And the Product Managers have to fill in the gaps and issues that outsourcing causes – that’s why they need to be technical. I know that my comment sounds antagonistic, but that’s what I’ve seen in some cases.

Great post! A role of a “Product Manager” is defined quite ambiguously even within the tech industry. There is the wide variation on the definition of product” in tech – app, website, API, platform capability. When I worked for an e-commerce company, folks confused it with inventory manager (i.e. someone who manages the products which are sold on the website).
You’ve outlined the key technical PM pitfall here: being informed about the technical design but not involved in the design itself is one of the biggest ones.

Thank you for clarifying this! In about four weeks I will start working as a technical product manager. I’ll also be product owner for our API. Feeling excited 🙂

hey Timon, i’m about to interview for a TPM role and wanted to know what your reflections are after taking the job… Still there? still happy as a TPM? what skills are required the most/least. will people who dabbled in code (who have some basic coding/engineering knowledge) survive or are very technical skills required day in / day out… let me know if you can talk alexalesio@gmail.com

My short summary: My technical skills did help, but managing dependencies was a pain for everybody involved. This started to get much better when we switched from component teams to cross functional teams. Fewer dependencies, fewer overhead, more throughout and not more TMP role needed 😎 I continued as PO for one of the newly formed teams and later moved on to different Scrum Master and agile coach roles. I very much enjoy this new work. Quick update from me on my current situation: I’ll be available to coach management + Scrum teams from new to great in Berlin, starting July 2017, for 6-12 months, 2-4 days / week (freelance). In summary, the TPM role was very exciting for me and I learned a lot. And it turned out as a stepping stone for supporting organisations in a different way 🙂 I wish you all the best for your TPM role, how ever exactly it may turn out!!!

Timon–thanks for getting back to me. I’m pushing forward and interviewing next week. Your freelance coaching role sounds exciting–best of luck with that! cheers, Alex

Product community need to clarify job roles and this article is a great start.
When you look for a job for Product Management of a software product, searching “Product Management” leads you to a wider and irrelevant position pool. The pool has PM jobs that are not about software. Technical Product Management role gathers all of us(recruiters and job seekers) in the right place. “Technical” is hidden keyword for “the product is software”.
Product Owner is not a position, it’s a role, as you mentioned. But again it helps all of us to meet effectively.

When I look for a Product Management job, I set alerts in career sites like “Product Owner” and “Technical Product Manager”. So I don’t get emails for a Product Manager role for a perfume.

When product managers get “technical” and start telling engineering how to build the product, they loose credibility with engineering and their ability to remain market focused.

Product Managers should be focused on creating a compelling offer for the market, defining customer requirements and how to build a compelling, competitive and profitability of the product line.

Product Managers role is to define the requirements clearly, prioritize and then interlock with engineering on how THEY will build a product that meets those requirements.

It does seem that too many job descriptions have product managers building the UI or doing testing and completely agree with you, that isn’t where a good product manager is focused.

Cool. Umm, how about telling all those people posting TPM reqs that when they say “Must be fluent in X/Y/Z language and protocol, and able to jump in to write code”, they are (cough) fundamentally misunderstanding the role of a product manager, whether or not the adjective “Technical” is prefixed on the title — and if they do hire someone who fits what they have written, they are almost surely not going to get a Product Manager but rather a coder who happens to sit in a “marketing” chair … and remains clueless about customers and market needs?

That’s a good point Tim. In my experience, I’ve seen a few reasons for that:
– These companies don’t fully understand the role of Product Management
– The job description was created by somebody in HR that just pasted some boiler-plate information from a standard engineering req
– The company has a small budget and trying to fill 2 roles with the same person.

All of these cases are not a good start for a Product Manager. But, if someone is really interested in the company, then it might be good to talk to somebody there and figure out what they need. It is possible that once you talk to the real hiring manager, the perception is different.

What do you think?

Thanks for reading,
Daniel

Ah, but then what would you call the Product Owner? Maybe you call them just that, but in most places it is a role and not a title.

And in many places, I am seeing the emergence of two roles. As you say, one is the PO and the other is the PM. But what is the title of the PO? Often it is Technical Product Manager.

If you have someone with the title Product Manager doing all of the more strategic (and critical) things you mention above, what would you call the person who is more embedded with the scrum team, acting as their liaison to the real world?

Thanks, Daniel!

Good question Bruce,

I’ve seen all sorts of approaches here. I’ve actually seen more and more companies using “Product Owner” as a title. On the other hand, many companies use PO just as a role and have more traditional titles like Business Analyst or even Program/Project manager. (I know, controversial, right?).

Also, I’ve seen that the “technical” aspect depends on the product being managed. For a very technical product, I’ve seen companies wanting a “technical product manager” to play the PO role. For other types of products, they actually prefer a less technical background even though they’ll be working directly with the development team.

And yet some other companies are using the PO role as a stepping stone for the PM role. They’d have a Sr PM to play the strategic part and a more Jr PM to play the PO role.

I’d like to hear comments from others as well. But in general, what I’ve seen is that there’s no consensus. For me, the most important distinction is that the Product Owner is a creation of Agile and it has a very narrow focus in relation to the overall responsibilities within Product Management. Breaking apart these two roles is just a result of capacity planning, delegation and division of labor, regardless of how it is called.

What do you think?

Thanks,
Daniel

Interesting post. I would be interested to learn more about your view in separating the Product Owner and Product Manager role. My understanding is that Product Owner is a Scrum position which replaces the traditional Product Owner, so the idea of having both seems to me incoherent?

Join the community

Sign up for free to share your thoughts

About the author