As much as this question sounds overly simplistic, it’s actually a pretty good place to start this blog for the simple fact that Product Management is a notoriously amorphous role that looks totally different at different organisations and as a result, there’s about as many definitions of what Product Management looks like as there are actual Product Managers in the world. The answer will be different depending on who you ask.

When people ask me what I do I usually just say “I work in Tech” and hope they ask no further questions, mainly so that I can avoid having to say “I’m a Product Manager”, have them look at me blankly (understandably), and then end up in the situation where I have to navigate through this minefield of subjective definitions. For the inquisitive types though who do ask further questions, my definition is usually something like:

I figure out what digital products need to be as valuable to the user and business as possible, and then figure out how to build that.

A gross oversimplification admittedly, but about as much detail as I’m willing to subject an unsuspecting victim to who doesn’t realise what a rabbit hole of a question they’ve just innocently asked.

If you’re reading this blog I can safely assume you have a genuine interest in this stuff, so I can indulge my inner nerd and go a lot deeper.

Product vs Project Mindset

The role of Product Manager/Owner is becoming more and more in demand, and part of the reason for this is the realisation that a product mindset ultimately drives stronger net results than a project mindset. Traditionally, software projects were delivered by Project Managers, who's main concern was the iron triangle of constraints - scope, timeline and budget. A business wanted to build a thing, and they needed someone to oversee the building of that thing. The success of this individual was ultimately measured by how closely the project was delivered against those three metrics.

However, people started to realise that a successful project does not necessarily mean a successful output (ie product). For an illustrative example let’s go with Nokia, who successfully delivered project after project churning out new phones frequently, with someone dilligently making sure this happened on time, on budget and on deadline, yet the business still declined catastrophically to the point where nobody (not even your nan) has a Nokia anymore. This is because the end user/customer does not care about whether or not the project was a success, they get no value from that, what they get value from is the end product.

If the product doesn’t satisfy what the market wants/needs, it doesn’t matter how effectively you delivered it. You’ll still fail.

As such, a shift from Project Managers focusing on scope, timeline and budget to Product Managers/Owners focusing on building a valuable end product occurred. In the words of Don McGreal and Ralph Jocham in the book 'The Professional Product Owner':

The objective is not to deliver projects, but to deliver value through products - products that ultimately lead to higher revenue and lower costs for your organisation. Products that are so great that your customer base will grow and existing customers will stick around. – Don McGreal and Ralph Jocham, 'The Professional Product Owner'

To put it simply, Product Management is all about outcomes, not output.

Product Roles

For the sake of both of our sanities, I’m not even going to attempt to break down the full gamut of Product Management roles (basically take any technical or business-y word and place it in from of the words “Product Manager” and you’ll have a genuine role that exists somewhere, ie ‘Data Product Manager’, ‘Growth Product Manager’, ‘Technical Product Manager’).

For our purposes, let’s stick to the main two; Product Owners and Product Managers. These are two distinct, separate roles, but the exact responsibilities of each tend to vary wildly in each organisation. Some (usually larger) organisations employ both Product Owners and Product Managers, some only employ one or the other but have a good enough understanding of each role to only ask for what's typically expected of the title they hired, while others employ one but expect them to pick up some of the responsibilities of the other role as well, blurring the lines between the two.

Technically, the usual separation between the two is as follows:

  • Product Owner - the PO is the person responsible for managing and prioritising the product backlog, they must ensure that each user story in the backlog is clear and comprehensive and that the backlog is ordered in a way that delivers maximum value with regards to the goals and mission of the product. They tend to be more "tactical" or "operational", in that they're heavily involved in the day-to-day activities and overall delivery; communicating heavily with the development team and designers, attending stand ups, writing tickets, ensuring the development team have all the information needed to work on them and unblocking them when they don't, and generally owning the output.
  • Product Manager - the PM on the other hand is usually a more "strategic" role, focussing less on the day-to-day and more on the overarching product vision and strategy. They identify and monitor key metrics to assess the product's success, gather and analyse user feedback, and plan the product roadmap.

My philosophy on Product Management

I’ve talked so far about how hard it is to define what Product Management is since it’s such a wildly variable role. I’ve also talked about what Product Management isn’t.

But what does good Product Management look like to me? Well, this is what I strive for as a Product Manager:

  • The captain navigating through a sea of ill-structured problems
    • I've split the Product Management section of this blog into a series of topics that I believe are core, foundational elements of the practice. The issue is that each one of these topics is an ill-structured problem; novel and nebulous with no clearly defined path to a solution or agreed upon “correct” answer. This is what makes Product Management such a difficult, but also deeply rewarding, role. If you don’t like dealing with ambiguity to find solutions to complex problems, then definitely pick a different career.
  • The steward of a reciprocal value exchange between the business and the user.
    • This is a beautiful idea from Melissa Perri’s book ‘Escaping the Build Trap’. Users want something that solves a problem they have, and businesses want to build and monetise that solution. As a Product Manager, I want to facilitate and maximise that value exchange for both parties.
  • Getting the best out of the people around you.
    • No one individual can be a great Product Manager, Software Engineer, UX/UI Designer, QA, Data Analyst, Sales person and Marketeer. Each one of those is a distinct career that takes years to become competent at, and I have neither the lifespan or the hours in the working day to be able to do all of those things effectively, but all of them are needed to build, scale and sell quality products. That means I’m going to have to rely on others, and since I’m directly responsible for building the best product possible, I need to know how to help everyone around me do their best possible work. I believe that’s an intrinsic but often overlooked part of this role that I take very seriously. How I go about that is a blog post for another day.
  • A person with lots of responsibility but very little authority.
    • Product Management is a very responsible job, but you’re usually doing it from within a cross-functional team where you’re nobodies direct line manager. Thankfully, that’s exactly how I like it and I believe it’s a part of the process that leads to better products. Again, a blog post of it’s own for future me to write.

The required skills of a Product Manager

Given the nebulous nature of the role and how much the responsibilities vary from organisation to organisation, defining the skills needed to be a good Product Manager can be surprisingly challenging.

Matt Lemay provides a great overview in his book ‘Product Management in Practice’ where he uses the acronym CORE:

  • Communication - with your team, internal and external stakeholders, and to make sure they’re all communicating with each other too
  • Organisation - organise the product team (and wider business) for sustainable success
  • Research - the users, the market, the technology, regulatory requirements etc
  • Execution - actually getting features built and shipped.

While I agree wholeheartedly with this, I’d posit a couple of others:

  • Tolerance for uncertainty - pretty much everything in Product Management is uncertain; the market, the competitive landscape, the technology you’re building on/with, the responsibilities of the role itself and what you should actually do with your time each day, the company you work at, how what you’re building will be received in the market. Everything. Being able to accept this uncertainty and move forward as confidently as possible in the face of it is a required skill (at work, and in life).
  • Leadership - you cannot do this job alone, you need a team. I strongly believe there’s a direct correlation between the leadership skills of a PM and the quality of the products they’re able to build.

This list will undoubtedly change and grow over the course of my career as I do, but for now, these are the most important skills as I see them. Hopefully it’ll grow in a way that allows me to make a neater acronym, because frankly I’ve broken Matt Lemay’s with my additions. Sorry mate.

Tip: From here you can navigate to the detailed subtopics to learn more about Product Management. You'll find them in the left-hand sidebar on desktop, or by tapping the 'Change topic' button on mobile.