Product Management: An Insider Guide

• Why Product Management isn’t about products
• How to avoid analysis paralysis: balancing discovery and delivery
• Solution pollution and how to avoid it
• The importance of challenging EVERYTHING
• The art of negotiation
• Why you should say NO a lot
• Why you need to prioritise ruthlessly
• Why the truth is more important than being right

“I’ve been working as a Product Manager for many years now, mostly in the Public Sector, so I do a lot of work with UK central government, helping them with digital transformation and also to build their own Product Capability.

Something that I’ve noticed over the years is that when non-Product people talk about Product roles and responsibilities, they generally focus on things like Backlogs, Roadmaps, Prioritisation and User Stories.

Indeed, when I first started working in product and was trying to understand more about the role and the skills required, that was largely the focus of the information that was out there. However, my years of experience in the job and time spent discussing the role with other experienced Product Managers has taught me that there is a lot more to it than that.

So here I’m going to walk you through the things that Product Managers REALLY spend most of their time doing…

It’s the invisible but absolutely essential side of Product Management…

This is the biggest realisation of my career so far: Product Management isn’t about products.

It’s about people.

Yes, it’s essential to have the skills to produce Backlogs, Roadmaps, User Stories and Prioritise effectively. But Product Management is all about people. 

Your team are people.

Your stakeholders are people.

Your users are all people.

It’s fundamentally a People Management role.

Not People Management in the traditional line management sense. But People Management to explore and realise potential through real leadership and excellent communication skills: bringing people together and uniting them around a shared purpose. 

It’s about building trusted relationships with your stakeholders and your team, and maintaining those relationships even when things get difficult, because trust me, they do get difficult.

It’s about being able to reassure people and calm them down when everything is on fire.

It’s all the qualities that people often refer to as soft skills. Which, let’s be honest, are really the hard skills. 

The way the responsibilities of a product manager are described sometimes make it sound like they work in a silo, making decisions on their own. But the best product managers collaborate with everyone on their team, across all disciplines to ensure that they are building the right thing, at the right time, in the right way.

Martin Ericsson summed it up perfectly when he said

“We only build products that people love if we do it as a team”. 

The core purpose of any product is to satisfy some human need.

As Product Managers, we naturally want to build the best products for our users. We want to delight them. We want them to want to use the products that we deliver.

So we also want to continually learn from them and discover what problems they have and what they need so that we can ensure that our products really work for them.

But the thing about user needs is: the more you look the more you find. It’s really, really easy to fall into the trap of analysis paralysis. This is where the fear of not having enough information to build the right thing holds you back and prevents you from building anything at all.

As a Product Manager, it’s important to know what the least is that you can do to discover and when to stop discovering. You need to be able to recognise when you have done enough to inform the solution. It’s about assessing the impact associated with getting it wrong and sometimes taking calculated and well-informed risks in order to deliver.

Our job is to work out which needs to focus on.

The ongoing trade-off between discovery and delivery is a balancing act that I have to perform every single day. Because we’re here to deliver a product and in the real world we constantly face the challenges of constraints such as budget, timelines and legal and technical limitations.

I am aware though that not all people in the team have the same emphasis on delivery. So sometimes the Product Managers job is to ensure that the team also understand this balancing act.

For example, on one project, a team member had an idea for an amazing feedback collection mechanism for our product. I didn’t prioritise it because we were only going to be going live initially with a very small set of users and building this idea would have meant not having time to complete the functionality that was essential for the release and I knew that we could still collect the feedback without having to build anything.

Needless to say, they were very disappointed and said to me ‘you product people and delivery managers are all the same, you only care about delivery’. Well, I was almost speechless, which isn’t something that happens me very often. Not at the challenge but because this person thought that in their role they didn’t need to care about delivery.

I have strong views on this. At the end of the day, everyone working on the development of products that are intended for release to real users should all care about delivery because we only deliver real value when we deliver a working product to our users. 

Without that, everything else becomes irrelevant.

If anyone working on product development thinks that they shouldn’t have to care about delivery -  that it’s someone else’s problem - then I would encourage you to think a bit more about that. 

When you are in that Discovery phase of trying to understand what users really need, it’s really important to avoid ‘Solution Pollution’.

Dan Olsen used this phrase on a course that I attended a few years ago and it really stuck with me.

When there’s a problem to be solved, human instinct is to jump straight to a solution. Especially for people like designers and developers whose job it is to provide solutions.

But it is really, vitally important to first focus on the problem or opportunity space, dedicate time to really understand and explore the problem that you are trying to solve and the people that you are trying to solve it for.

A Product Manager’s job is to keep everyone in that problem space and prevent anyone from jumping to solutions until we truly understand the problem and have defined measurable outcomes to be achieved by solving it.

Otherwise, you run the risk of not solving the problem in the right way.

As a Product Manager it’s crucial to be inquisitive. Ask lots of questions and never accept that things are the way they are because they have always been like that.

You can’t drive change by doing things the way they have always been done. 

As a Product Manager, my role is to challenge everything from scope to approach. But here’s the key: only where necessary. 

Challenge for the sake of challenge is just being difficult.  

So quite often, when I meet clients for the first time, I introduce myself as the person who will be asking lots of annoying questions!  

Some people shy away from challenge, they assume it has to be a confrontational or negative thing.  I have learned that it doesn’t have to be and if done properly, can be extremely effective. 

There are non-confrontational ways to challenge things and people: just digging around in a subtle way or asking a few questions usually does the trick. 

It’s not all about challenging others though, it’s really important to be open to being challenged as well and creating a culture where the customer, your stakeholders and your team feel that they can challenge you because quite often that’s how the best ideas are formulated. 

It’s a team effort. 

Another huge part of my job is negotiation. But I never used to think of myself as a ‘negotiator” until I read an article that challenged what I think of as negotiation.

It made me realise that I, like most people negotiate every single day without even realising I am doing it.  

A team estimating user stories together are negotiating with each other when they are trying to agree what the estimate should be. Agreeing what’s in scope and what’s out of scope is negotiating. It made me realise that the extent to which we all negotiate every day and it is a crucial skill for any Product Manager. 

I seem to spend most of my days either trying to convince people to do something or more frequently, trying to convince them why they shouldn’t do something. Which leads me on nicely to my next point…

Through my work, I do a lot of coaching and mentoring, so quite often I work with people who are new to their Product Management role. To begin with, they believe that their role is to constantly identify new features to be added to products, which usually just results in feature bloat. In other words, a product so overloaded with bells and whistles that it doesn’t deliver its core function.

On top of that, it can lead to missed delivery deadlines, a blown budget, unhappy stakeholders and a lot of uncomfortable questions.

Similarly, a lot of people who are new to the role believe that the best way to manage stakeholders and to keep them happy is by always saying yes to them. They tell them they’ll add their request to the backlog, knowing it will never be delivered.

This is not stakeholder management. To be honest, it’s just a cop out and it stores up future problems, potentially resulting in a really bad relationship with your stakeholders.

Being a Product Manager means making really tough decisions and saying no is often the hardest part. It takes practice and it’s important to realise that the role is actually about identifying what does not need to be done. Let’s face it, anyone can identify features to add to a product, it takes real skill to identify what’s not needed right now or even at all. 

The best Product Managers, are great at saying ‘no’. They say it unashamedly and they clearly articulate the reasons why they are saying no in terms that their stakeholders and team will understand.

Everyone knows that product managers have to prioritise, it’s a big part of the job.

But what a lot of people don’t know is the speed at which decisions have to be made.

If you have a team sitting waiting on you to make a decision so that they can get back to work, you can’t take your time about it because that time has a cost associated with it, as well as a frustrated and unhappy team. 

You also must be able to make prioritisation decisions impartially and ruthlessly. You have to put your own personal feelings aside and look at things objectively. You can’t fall in love with your own solutions.

I have encountered many people who want to be a Product Manager because they mistakenly believe that it will allow them to execute their creative vision, but it doesn’t.

You have to remember that you are not your user because if you forget that, it can lead to ignoring evidence and ultimately building the wrong thing.

Which takes me neatly to my final point…

Whether we’re aware of it or not, we all have our own internal bias which is used in unconscious decision making.

I would recommend trying to identify what yours are, so that you are aware of them and you can check them when you are making decisions. 

For example, confirmation bias is a type of unconscious bias where people essentially search for the evidence to back up their opinions, not dispute them. It’s easy to tell yourself that you are making decisions that are based on data and evidence, but it’s always worth stopping and asking yourself if perhaps you are only seeking or acknowledging evidence that supports the outcome that you wanted all along.

As a Product Manager, it’s important to value the truth more than being right and to make sure that your decisions are based on evidence or else once again, you run the risk of building the wrong thing.

To find out more about Product Management at Kainos or to work with Charlene and the team, get in touch.