If you missed my first two posts about the four flavors of product management, depicted by the PM Quadrants, feel free to check out the first post here and the second post.

If that’s TL;DR for you, a synopsis of both posts is below. If you’ve already read them, skip to here.

The PM Quadrants

Based on my experience working as a product manager, business analyst, project manager and consultant, I defined four ‘flavors’ of product manager, that are defined by their relative position on two axes — discovery to delivery on the X (horizontal) axis and technical to business on the Y (vertical) axis.

Here’s what the Quadrants look like.

Image for post
The four flavors of product manager, based on their relative position on the two axes. I make a really great pun about ‘axes’ in the original post.

The Skills of the PM Quadrants

In my second post, I went over the skills required for each of the PM quadrants, which is summarised in the image below. Loosely speaking, the Product Owner mirrors the skills and responsibilities of a Scrum Product Owner, the Product Marketing Manager sits at the intersection of Product, Sales and Marketing, the Strategic Product Manager looks at the big picture and the Technical Product Manager understands technology and can use their knowledge of it to solve business problems.

Image for post

Now that you’re up to speed, it’s time to crack on with the purpose of this post.

So how do I know if I’m actually a product manager?

I’m going to talk about peripheral skills. By that, I mean skills that belong to roles adjacent to the product manager or that support a different way of working and therefore sit outside of the PM quadrants. Based on how much of your role sits outside the quadrants, you can decipher if you really are a product manager or not.

In reality, not many of us can say that our role is a 100% textbook product manager because theory rarely fully accounts for the complex and variable nature of reality, but having an understanding of how close you are to this will help you baseline your current experience and develop your career in the direction of your choosing.

As I go through the associated roles I’ll mark up the requirements that should not sit with a product manager in bold.

The two most common roles to move into product management from are Project Manager and Business Analyst, and it is the requirements of these roles that most often end up in product management job descriptions, so I’ll go over these first.


Project managers have the responsibility of the planning, procurement and execution of a project, in any undertaking that has a defined scope, defined start and a defined finish; regardless of industry.

In a project manager’s world, the start and finish are pre-defined. In the world of product management, the scope is fluid, and there shouldn’t be a ‘finish’ date, as it’s a continuous process.

Essentially, a project is finite, and therefore so is the role of a project manager. When the defined scope is delivered, the project ends. That delivery might also include aftercare support or post-launch analysis, but there is always an end.

The four key skills of communication, stakeholder management, problem-solving and empathy are still crucial for a project manager, but when we look into their specific responsibilities, there are differences.

Image for post
The Project Manager takes a proactive role in ensuring the depicted steps happen, and takes an active role to keep the project on track.

This means that there are a handful of project management specific responsibilities that should not sit within the role of a product manager.

  • Resource planning — Determining who from the across the business will make up the project team, and what supplementary roles are required from external providers. A product manager’s team is pre-allocated.
  • Budget management — Even internally, people (often rather coldly referred to as ‘resources’) aren’t free. At the very least, there’s an opportunity cost of pulling them off other work (which may require that role being backfilled at a cost), and contractors or consultants through third parties are expensive. A product manager’s team should be pre-budgeted.
  • Scope management — A crucial part of the project manager’s role is ensuring that the scope of the project does not change ‘willy-nilly’. Any requests to change the scope must be documented, analysed, assessed and decided upon formally. As the scope is not fixed in an agile world, the product manager and team are free to debate and amend scope as new data or research indicates they should do so.


Similarly to the role of a project manager, a business analyst is aligned to a different way of working to a product manager. It is aligned to the waterfall methodology where requirements are gathered and agreed upfront. It requires Big Up-Front Design (BUFD) as all eventualities must be considered during the requirements gathering phase, mapped out and clear and prescriptive requirements written out. If you want a door on your house, you better make sure there are requirements detailing every aspect of it. If you don’t ask for the door to open, don’t expect to be able to get in or out of the house.

Therefore writing detailed, solutionised requirements is not something a product manager should be doing, and if you are, then you need to push back on this.



Even if you are a technical product manager, there is still a limit to how involved you should be with the technical aspects of the team.

Even if you are capable of writing code, you shouldn’t be. Firstly, you will muddy the water with the developers and secondly, your time can be better spent elsewhere, using your technical expertise to determine the right features to develop next.

It is not your responsibility to define the platform strategy or enterprise architecture. You may be an SME (Subject Matter Expert) and heavily consulted in the direction of it, but for similar reasons to the above, you need to remain focussed on your primary purpose of ensuring a clear roadmap and prioritised backlog.

  • Coding — it’s hard to explain this in any other way. A developer writes code; a product manager does not. Contrary to plenty of job descriptions out there, a product manager does not need a detailed working knowledge of PHP, React, JS, Ruby, Python, Swift or C++.
  • Enterprise architecture — A product manager shouldn’t be responsible or accountable for the site, app or ecosystem architecture. Much like the platform strategy, they should be consulted heavily if they are of a technical mind, and be asking questions to ensure it aligns to the customer and business needs.
  • Platform strategy — A senior developer, CTO or Architect should be responsible for this, and even a technically minded product manager would be a ‘C’ on the RACI matrix, using their somewhat technical and deep product knowledge to help align it with the business and product strategy. The building blocks of the platform underpin the product strategy, not the other way around.


A pure product manager doesn’t create wireframes or conduct user testing, either, as they will have biases and this is covered by a designer and/ or a UX researcher.

Again, I must emphasise that it is highly unlikely that you will be 100% pure, but strictly speaking, a Product Manager doesn’t do this, a designer does.

Scrum Master

The really lazy comparison of a Scrum Master is that they are the project manager of an agile scrum team. I don’t like this analogy, but it does give you a rough idea of their skillset. A scrum master is a servant leader that works at the behest of the team and not vice versa.

It is the role of the scrum master to unblock issues and facilitate sessions to ensure the team has what they need to succeed, including everything from JIRA access to a chair to sit on. What if I don’t have a scrum master, you ask? Well, then you should spread these responsibilities around the team. It shouldn’t all sit with the product manager.

Image for post
All for one and one for all might have been their motto, but the three musketeers (and D’Artagnan) still had their own specialisms. Image from Metro.

A product manager delivers through others, and owns very little. The value of their role is maximising the value of others through strategising, prioritising and consulting. Therefore the majority of the ‘doing’ responsibilities sit with other roles within the team.


There are also a few roles outside of the product and technology team whose responsibilities get dumped on the product manager. Let’s take a look at a few of them.


A marketing manager is responsible for managing the promotion and positioning of products that a company sells. Typically marketing managers are employed to attract more customers to buy from the company and to raise brand awareness through the creation of marketing campaigns (totaljobs.com).

In short, while a product manager focusses on the creation, evolution and optimisation of a product, the marketing manager focusses on how to promote and position the product for maximum impact.

Therefore SEO optimisation and running marketing campaigns both sit outside the PM quadrant. Go to market plans, however, are an expected responsibility of a product marketing manager, and is particularly prevalent in startups.


This might come as a shock, but guess who is responsible for selling the product… wait for it… the sales department! A product manager might have interactions with customers for the purposes of research and testing, but their role is to be unbiased and understand what the customer wants. Telling them about how amazing the product is all the time* doesn’t really fit that mantra, does it? So I’m adding ‘selling‘ to the list of no-nos.

*Massively oversimplifying the approach of a sales manager for effect. Don’t @ me if you work in sales…

Customer Service/ Support

A product manager should work with the customer service and support functions to ensure they are equipped with as much knowledge as possible about the product, the strategy and any upcoming changes. That does not mean they should be onboarding customers and resolving their queries themselves. Keeping these responsibilities separate avoids biases and distracting the product manager from their main purpose — maintaining and prioritising a backlog that tackles the product’s goals.

There are countless other roles and responsibilities that can slyly creep into the Product Manager’s remit but that’s plenty of rambling about what is and isn’t product management for now, so I’ll wrap this up.

What does it look like when mapped against the quadrants?

I’m glad you asked! Although the specific tasks of a product manager don’t always align perfectly with one of the four quadrants, I’ve mapped the responsibilities I’ve highlighted as outside of the product manager’s remit as outside of the quadrants and aligned, where possible, to the quadrant they are most similar to.

Image for post

An(other) 80/20 rule

I’m not talking about the Pareto principle here, in which 20% of your effort will yield 80% of your results. Instead, my view is that if up to 20% of your role involves tasks outside of the product management quadrants, it’s still fair enough to consider yourself a product manager.

If, however, your role is more weighted towards the skills outside the PM quadrants, then I’m afraid you’re not a product manager. I don’t say this because it matters what your title is or what you choose to do for a living, but because if you want to develop your career in product and move onwards and upwards, it’s important that you are aware of the relative alignment of your role to the industry and use it to develop your skills.

If your role is heavily weighted towards activities outside of the PM quadrants, you are not a product manager.

In my next post on this topic, I’ll cover using the PM quadrants to develop a career plan to be the type of product manager that you want to be, and the best version of that.

This article was originally posted on Chris’s blog @ https://chrismiles.co/how-to-tell-if-you-are-a-product-manager/


Leave a Reply

Your email address will not be published. Required fields are marked *