So, What Exactly is Software Product Management?

15 min readJun 7, 2018

[Note: This is a follow-up to an earlier article that proposed the Venn diagram described in this article]

I’ve been in software product management for over 20 years. When I started, I had to explain what I did to my family and friends. They were curious as they’d never heard of the job before.

I explained it this way:

“I don’t develop, market or sell the product, but I am responsible for ensuring what we build is the right product and how we market and sell it is done as well as possible.”

“ OK, so you’re the boss then?” many would ask.

“ Well kind of, but not really.” I would respond.

Most conversations ended there and it didn’t really warrant further explanation. In that first role, my coworkers all understood the Product Management role, and when I moved to California to work in a startup, the understanding there was pretty similar.

i.e. a cross-functional leader who was responsible for product success.

But over the last 20 years, things have gotten more complex, and as software products have extended throughout every industry, the definition, makeup, organization and skillset required for Product Management has gotten more and more confusing. And of course the advent of Agile and Scrum (in particular) have only muddied the waters, adding confusion to an already complex situation.

This article aims to bring some clarity to technology Product Management. I will discuss the following:

Metaphors for Product Management
A Definition of Product Management
Key Product Management responsibilities
Types of Product Managers
Differentiated Product Management roles
Organizing Product Management teams
Key skills required for Product Management roles

1. Metaphors for Product Management

Over the years I’ve heard a lot of metaphors used to explain Product Management:

Hub of the wheel
Voice of the customer
Cross-functional leader
CEO of the product
and (sadly) Gap filler or Glue

They all have some truth to them — though I particularly despise “gap filler or glue” — but they also all fail to accurately describe Product Management in simple terms.

But if we take these phrases and interpret the intent of those who use them, we can reach a clearer definition.

“Hub of the wheel” also connotes cross-functional leadership and organizational .
“Voice of the customer” implies an understanding of customer and market dynamics and the ability to communicate it internally and externally.
“Cross-functional leader” is pretty clear.
“CEO of the product” brings in leadership, and business objectives. i.e. strategy, revenue, profitability etc.
And we won’t mention gap filler or glue.

2. Defining Product Management

Looking at all those highlighted terms, we have a cross-functional leader with a product and market focus, aiming to meet business objectives. Or a bit more formally, we can say that:

Product Management is cross-functional business and technology management focused on creating and delivering products that meet or exceed their business goals and objectives.

Those last few words — “ business goals and objectives” are key. Far too often people consider product management mainly as a technical role and many people in those “technical” product management roles have no understanding or even visibility into the business goals their products must meet.

Taking the key components out of that definition, we can define the following key areas of focus:

Focus on achieving Business (and Product) Objectives
Understanding Market Needs (to drive Product Capabilities and align with Business Goals)
Driving cross-functional Organizational Alignment (to support Business/Product Objectives)
(and of course) Managing the delivery of necessary Product Capabilities (to meet Market Needs)

Product Management must blend and balance these four areas of focus. As a diagram it looks like this:

i.e. Product Management operates at the intersection of all those areas, balancing each one or emphasizing some over others depending on the product, stage in the product lifecycle, goals and objectives.

3. Key Responsibilities of Product Management

Another challenge many companies have is in defining the responsibilities of Product Management. Most people sort of, kind of, usually (roughly) understand it, but it’s not clearly articulated in most companies that I’ve seen. Often, Product Management responsibilities are listed in grids or diagrams with literally DOZENS of individual tasks such as:

Market Research, Competitive Analysis, Value Propositions, Defining Requirements, Working with Development, Roadmaps, Evangelism, Issue Resolution, Pricing, Messaging etc. etc. etc.

And often these are split or organized in various ways such as:

Inbound vs.Outbound,
Business vs. Technical,
Strategic vs. Tactical etc.

A better way to define Product Management’s responsibilities is to consider the lifecycle of Products and then map the MAJOR activities that align with those stages

Thus, in a nutshell, Product Management is responsible for the following:

Business planning and management
Product and portfolio strategy and roadmaps
Product research and definition
Product release planning and oversight of product development
Product launch planning and coordination
Post-launch oversight and optimization
Product end-of-life

Note that each one of these areas of responsibility requires significant time, knowledge and focus. For example Product Research and Definition is often an ongoing process that, for a large or complex product, can be a full-time job.

These areas of responsibility fully cover what Product Management works on at any given time. There is *some* linearity there, but it’s not simply a linear process. e.g. For a given product, there will be MANY releases of that product so steps 3–6 will be done many times. Steps 1 and 2 are part of an ongoing process. i.e. ensuring strategy is correct, roadmaps reflect that strategy accordingly, and the plans are well researched. And step 7only happens once for any product.

An aligning factor in all Product Management activities should be Business Objectives.

For any major activities or decisions, Product Management should always consider whether the activities or decisions support or help drive towards those objectives. e.g. if not, then why are those activities being performed or why was that decision made?

Each of these steps can be described in significant additional detail, but I won’t get into them specifically at this post. There are chapters of books (and in fact entire books) written about strategy/roadmaps, product research, product launch etc.

[NOTE: I may write more about each of these in more detail if I get enough encouragement from you. :-)]

Suffice it to say that if a task DOESN’T fall into one of those 6 areas, it’s almost certainly NOT a Product Management responsibility and Product Managers should question why they are being asked to do that task.

4. Different types of Product Managers

Aside from responsibilities, defining Product Management ROLES still seems to be a challenge in many companies. I acknowledge that not all product management jobs are alike. Aside from different levels in the organizational hierarchy (i.e. individual contributor, manager, executive etc.) there are different levels of focus on business vs. technology vs. market/customer in different companies and even in different roles in the same company.

There are many ways to slice the roles and focus, which is truly part of the challenge companies face in defining Product Management roles. McKinsey published an article on the role of product managers in a digital world, and provided the following diagram[1].

This is a good initial breakdown. i.e. it does distinguish between more technically focused vs. more business focused roles. I don’t necessarily agree with all of it — e.g. the Focus for the Generalist is almost never simply “User delight” — but it’s a start. It is a step forward from how a lot of the ongoing dialog on the Web describes the role of the Product Manager.

5. Understanding Differentiated Product Management Roles

The challenge is to think about Product Management and NOT about Product Managers. i.e. think about the overall function and not a singular Product Management role. Why? Because just like any department there will be different roles with different areas of focus (different foci?).

For example, in a sales department there are typically multiple sales roles:

outside sales reps who typically handle larger accounts or larger deals
inside reps who focus on smaller deals or smaller companies
business development reps who focus on prospecting or qualifying and developing leads etc.

The “one person does it all” role in sales is only evident in the smallest of companies. Analogous role differentiation exists in virtually all departments — e.g. Marketing, Engineering, Finance etc. Yet we don’t often see this kind of role differentiation within Product Management teams.

Companies start with a “one per does it all” product manager. They hire someone who they think is a “rockstar”. And then as the company grows, they want more rockstars. But, just like they’ll never have a sales team full of rockstars, they’ll never have a Product Management organization that looks that way either.

The key is to realize that there are ways to differentiate roles and thus focus and expertise WITHIN a Product Management team.

Areas of focus by department

If we look at a company and how the different departments in a company are positioned on the following axes, and then understand the problems they may face, we can understand how define needed Product Management roles.

Departments such as Engineering and Support are very technical and very product focused. Conversely, Senior Management and Marketing are much more business and market focused. Sales, PreSales and Alliances are generally product focused, but vary in their orientation between Technical and Business.

This is not a perfect diagram as there can be significant variances across companies and company types. e.g. An Alliances team in some companies may be VERY technical working on OEMs or other product integration opportunities. The best way to interpret this diagram is to look at the relative positions of different functions. e.g. Engineering is more technical than Support which more technical than Presales. Marketing is more market-oriented than Sales. Sr. Management is more business focused than all other groups etc.

Having said that, your company and results may vary, but for the purposes of this exercise, it’s a reasonable representation.

The “do it all” Product Manager

Now looking at that diagram, one could plop the Product Manager dead-center to try to make her fully cross functional. i.e. the perfect balance of Product/Market, Technical/Business. e.g.

The challenge with the singleton “do it all” Product Manager is that she is inevitably stretched thin and must focus in some areas at the expense of others. All too often she is pulled towards the Technical/Product quadrant focusing her efforts on working with Engineering and Support etc., much to the detriment of the Sales/Marketing/Management side of the company.

Business AND Technical Focus

To address the scalability of the singleton PM, the most common solution is to split the PM role into two specialties. i.e Product Manager (PM) and Technical Product Manager (TPM).

The two Product Managers form a small team and share the overall Product Management responsibilities.

The TPM works closely with the more technical teams in the company such as Engineering, Support and Presales. The TPM should have deep product knowledge and a technical inclination. The TPM often reports to the PM.

In this scenario, the PM is more business oriented, working more closely with Sales, Marketing and Sr. Management. While the TPM works with Engineering on the next release, the PM works with Marketing on planning the next launch. Or the PM may be “out of the office” conducting customer and market research for the roadmap and future releases while the TPM is in the trenches focusing on detailing out near-term requirements.

The differentiated roles help increase focus and scalability of the team and enable stronger cross-functional activities and relationships within the company.

Adding Product Marketing

Another role specialization is the addition of Product Marketing to the team.

Product Marketing is strategic marketing at the product or product-line level with a focus on prospects, buyers and influencers and optimizing the buying process

Adding a Product Marketing Manager (PMM) increases scalability, efficiency and focus allowing team members to “go deep” into their respective areas.

The PMM is part of the Product Management team, possibly a peer or possibly reporting to the Product Manager. The PMM focuses primarily on Sales, Marketing, external buyers, prospects and influencers looking to understand and optimize the evaluation and buying process. There may be an operational focus to the PMMs role, given that sales or marketing process optimization may be one way to impact positive change across those two organizations.

There are other possible specializations with roles such as Solutions Marketing and Technical Marketing (working along side Product Marketing) or Solutions Product Manager (an outbound technical role working to define industry focused solutions). The goal with specialized roles is alway to create a more scalable and effective organization to better address company needs.

6. Organizing Product Management Teams

Another challenge companies face is how to structure their Product organization. Given the cross-functional nature of product management, there have been endless discussions over the years related to where Product Management reports (Marketing, Engineering etc.). This usually starts when the first Product Manager is hired and the question is asked about where they should report. i.e. VP Engineering, VP Marketing, VP Sales, CTO, CEO? The answer depends on company culture, strength and focus of particular executives, perceived need and internal understanding of what Product Management is.

The decision — e.g. PM will report into Engineering — lays the foundation for the future in terms of Product Management focus. That Product Manager (who reports to Engineering) will inevitably be a “technical” Product Manager spending much of their time embedded with Development teams. It’s an inevitable outcome of that reporting structure, UNLESS there is a strong culture and push within the company to have a more outwardly, customer/market facing role.

When new PMs are hired, they simply report into the same executive (e.g. VP Engineering) and the Product Management organization will continue their existing (e.g. Technical) focus.

Now if a Product Marketing Manager (PMM) is hired, it’s unlikely that he will report into the VP Engineering. It’s highly likely he will end up reporting to the VP Marketing or possibly VP Sales. That will have the unintended effect of bifurcating the PM/PMM roles across different departments.

If the PM and PMM are in different departments, they will lose alignment and more than likely, the PMM will end up focusing more on tactical marketing activities vs. the strategic focus they should have.

Given that in the early stages there is likely no VP Product Management, the Product Management team (or initial Product Manager) should report into the CTO or CEO. If there is a Chief Product Officer, that is the best place to start.

Remember, in a startup, product success means company success. And product failure means company failure.

Don’t get caught up thinking that the first Product Manager can live anywhere and still be as effective as possible. That initial reporting structure decision will impact her, and will likely impact the company and future hires for a long time to come.

The following is a simple org chart for a small PM, TPM and PMM team reporting to the CTO.

The Product Manager and Product Marketing Manager are peers and the Technical Product Manager reports to the PM. This brings alignment between PM/TPM who need to be tightly coupled in their work. The peer relationship between PM and PMM allows the two to work together but stay aligned towards high-level business objectives.

As an aside, the VP Engineering (or the Engineering org directly) MAY also report to the CTO. This parallel reporting structure into one executive has significant benefits from an alignment perspective.

Growing the Product team

As the Product team grows, because of overall company growth or the addition of new products, the org structure can scale. Perhaps a VP Product or Chief Product Officer is hired to help scale overall management and remove some of the burden from the CTO. In that case an organization would look like:

Here, Product Management and Product Marketing teams are peer organizations under the VP Product. There are two Product Managers, each with 1 or more Technical Product Managers under them. On the Product Marketing side, there are 2 Product Marketing Managers and in one case, a Solution Marketing Manager reporting into a PMM.

While not shown in the org chart, the individual PMs and PMMs are peers in that they have counterparts on either side who focus on the same product(s) and who are aligned with the same overall objectives related to product success, be they revenue targets, new customer acquisition, customer satisfaction etc.

This is a scalable model that can grow both horizontally and vertically as needed by the company. e.g. if the company were to add or acquire another product, those new people and responsibilities can be easily added without reorganizing the existing teams.

A Place for User Experience

User Experience (UX) teams (not to be confused with UI developers) are often a forgotten factor when thinking about Product Management. Formal UX roles are relatively new in many software companies with a huge surge in awareness and importance over the last 5–7 years. The field of UX focuses on understanding how the user experiences and interacts with a product and designing an experience that is optimal for the needs of users.

UX teams often work closely with both Product Management and Development teams, helping bridge the gap between high-level vision and concrete designs that meet specific requirements. From an organizational perspective, they are often placed within an Engineering organization, but they can equally be placed within a Products organization as another peer group alongside Product Management and Product Marketing. For example:

In this case, two UX Designers are part of the Product team, working cross-functionally with Product Management and Engineering. As the UX needs grow, a Director or other UX management position can be created to better structure the team.

7. Required Skills for Product Management

The last area that often challenges companies is understanding what kind of skill set is required for someone to be successful in product management. Given the breath of responsibilities (e.g. product strategy and roadmap, product research and planning etc.) and various areas of focus (e.g. Business, Organizational Alignment, Product Capabilities etc.) the skills required for success can be quite broad and challenging.

On some level, people working in Product Management need a mix of the following:

Business & Strategy — product success is the foundation for business success and so a clear understanding of business objectives and strategy and how to align that to your products to maximize results are critical. Analytical skills are also part of overall business skills included in this area.
Domain Knowledge — includes but is not limited to deep understanding of the market state and trends, competitors, customer problems and use cases.
Technology & Design — without being a technologist, technology product managers need to understand the software development process, software architecture, UI/UX concepts to the level that they can have the needed discussion with technical teams and make good decisions that benefit the business, customers and the product as a whole.
Systems & Processes — as cross functional managers, PMs need to be able to see how and where systems and processes that affect product success can be improved. Are Marketing/Sales working efficiently WRT the product plans/goals; are Services/Support in synch etc. The flow from concept to development to market should be as frictionless as possible. Product Management plays a key role in making this happen.
Leadership & Communication — Without a doubt, the most important aspects for Product Management are the abilities to lead and communicate effectively. Without these skills, they simply become tacticians often at the mercy of other larger teams (and let’s be honest, EVERY team in the company is larger than the PM team).

It’s virtually impossible for any individual to be strong in ALL of these areas. Yes, some might be, but they are very rare and special people. But that is why it’s so important to specialize roles and allow people to exploit their strengths and focus where needed. If we look at each of the PM, TPM and PMM roles through the lens of these 5 areas, the picture becomes much clearer.

To truly succeed, Product Managers need strength in a number of areas including Business & Strategy, Domain Knowledge and Leadership and Communication. They may be a bit weaker in the area of Technology and Design and Systems and Processes.

In contrast, TPMs are strongest in Technology and Design, followed by Leadership and Communication and weakest in the other 3 areas.

Product Marking Managers have a similar profile to Product Managers, but may not have much Technology focus. Their strongest areas should be Domain Knowledge and Leadership and Communication.

The 3 roles complement each other and bring combined strength across all 5 areas of focus.

In Conclusion

So there it is; a primer on what is Product Management, how to define it, staff it, structure it and the skills to look for when hiring for it.

Cross-functional roles are complex, and it’s no wonder there’s still confusion on this topic. I hope this article brings some clarity to the topic and of course, please leave comments or questions. I’d love to hear from you.

[1] https://www.mckinsey.com/industries/high-tech/our-insights/product-managers-for-the-digital-world

Originally published at https://www.linkedin.com on June 7, 2018.