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?
To answer this question, I originally wrote this article as a guest post in Mind the Product after participating in one of their forum discussions.
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.
[tweetherder]The term Technical Product Manager describes a person, not a role.[/tweetherder]
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:
- 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.
- 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.
The Bottom Line
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.
10 Comments
-
Great post – it really highlights the need to know what we are applying the word ‘Technical’ to. Does it apply to Product? If so, then we’ve got a ‘Technical Product’ Manager. If it applies to a ‘Product Manager’, then we know that the individual is technical (and more likely to get caught in the list of ‘Don’t’s’).
A good product manager gets deep into the product and understands how it creates value for customers. With a technical product, the succesful PM will make themself into a TPM!
-
Nice Article! It doe a great job of defining that the PM is focused on WHAT a product, say an API, should accomplish and that the technical team envisions HOW to deliver it.
-
Hi Daniel,
I was asked in a Senior PM interview to narrate an example where I questioned the Engineering team on the architecture that they used and how well it will support my long term vision of the product.Is a PM’s job limited to just asking the right questions or understanding the tech stack to find flaws and correcting them?
Should a PM understand the design and HOW of a product. Is it a requirement for a PM to be adept at this?-
Hi Amarnath,
A Product Manager should focus on the WHY (why we are doing something) and the WHAT (what needs to be built), but not on the HOW. It is the role of engineering to determine the HOW based on their collaborations with the PM. As long as you define clear acceptance criteria, then that should be enough.Naturally, the more you know, the better conversations you can have with Engineering. For PMs that come from a technical background, it’s easy to want to jump into the details and dictate how the solution should be built. That always backfires because engineers feel you are dictating how they should do their job.
To me, this interview question could be an opportunity to probe deeper and understand what problem are they trying to solve. I’m sure there’s more background to the questions and it can be an opportunity for you to shine by clarifying the role of the PM vs Engineering and how you can contribute in that scenario.
If they truly expect a PM to evaluate and correct the architecture, then I question whether they are really looking for a PM or they’d like somebody that can be a PM, and an architect, and a Project Manager, etc. That is a red flag to me.
What do you think?
-Daniel
-
-
Great article. I appreciate the breakdown. It helps me figure out what my focus needs to be if I land the Technical Product Manager role I am seeking.
-
Nice article !
-
Hey,
Great article. Totaly agree.
My 50 cents abot technical PM is that sometimes your technical exp can make you get a less creative decisions since you are aware of the complexabilty and you close your eyes for better solutions.
Thanks, insightful.
-
Thank you for comment Asaf. It is true, sometimes not knowing the technical implications can lead to a better solution since your creativity is not constrained with “how to do it”.
-
-
This is absolutely insightful! Just yesterday, as I’m looking for a new role, i had a telephone interview with the recruiting manager and he was definitely looking for a technical product manager in the technology sense as opposed to the vertical sense. I totally agree with your analysis because having been in product management for 20 years, I’ve always had these two type of products managers in my teams. I’ve seen extremes, where engineers are wheeled in as product managers. In terms of terminology, I always tell potential recruiters or my management line that I’m a “fundamental” product manager as opposed to the other categories. So I see myself as the MD of my product/s; focusing on vision, raising funds, engaging virtual teams to deliver a strong and sustained P&L and a Balance Sheet and to eventually retire and replace the product….good piece, this is!
-
Borie, thank your for your comment. I like your way of distinguishing the “fundamental” PM. I think that’s a good way of putting it. The role is PM, and from there, we all have different areas based on experience or company need. You can prefix PM with terms like “Technical”, “Integrations”, “Hardware”, “Commerce”, “Cloud”, “Mobile”, you name it, but at the end of the day, the role is fundamentally Product Manager.
-