What is a Technical Product Manager, Anyway?

In brief:

What 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" 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:

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 keys Do's and Don'ts for Technical Product Managers.

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.

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."

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.

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:

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.

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.

I'm always amazed by the amount of discussion I see online about Agile and Product Management.  Though I do understand why--many Technical Product Managers 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 product 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 product manager.

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

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.