The product management role can be hard to understand and articulate. I think I can make it clear, but it requires changing your mindset about engineers (and everyone in a tech team).
The PM role is hard to understand for a number of reasons.
For one, there’s no obvious output. I once had an interviewer for a product role ask me what my work produced, and I genuinely couldn’t answer. I said “emails”.
For other jobs, it’s a lot easier. Designers design, researchers research, and engineers engine. But you can’t really ‘product manage’ something, so it’s ambiguous.
The role has some form of authority and responsibility, but it’s most tacit or implicit. PMs are sort-of in charge of the team, but not really.
The PM role also differs between companies. PMs can own the team decisions, support them, or execute on others’ decisions. Different-but-similar titles like product owner and project manager contribute to this confusion. I’m still not sure what an agile coach or scrum master does.
This ambiguity is bad.
It’s bad because it creates confusion about roles in a team. It’s hard to move fast when you don’t know what is yours to move.
Ambiguity makes moving between companies hard, and increases the time taken to settle. It’s hard to sell yourself to employers because it’s hard to describe what you do in a way that relates to their processes.
Ambiguity creates imposter syndrome, which is always tough. It can be hard to put forward your case for a promotion if you’re not crystal clear of your responsibilities, and don’t feel confident.
I believe that clarity is the most important thing for a product team to be successful. This confusion about the product role necessarily harms clarity.
There are several ways commonly used to describe the role, in an attempt to provide clarity.
I’ve heard people describe it as “telling the team what to build”, or “managing the teams time”, or “having meetings”. These are all partially true but don’t really add clarity.
The closest I’ve heard to a strong description is “PMs own the decisions that the team makes”. I like this because it covers the fact that PMs should give context and tools to the team to make the best decisions, without necessarily making the decisions themselves.
There’s an easier way to think about it.
As mentioned, the PM role doesn’t have a clear output. Here’s the thing: I don’t think anyone’s role should be defined by what they produce, but rather by how they solve problems. Bear with me here.
A product team is a set of problem-solvers, that happen to have technical abilities. This means they can make high-leverage solutions – which are scalable, fast and cheap (in terms of marginal cost).
Rather than thinking of designers as people that make things pretty and create UI visuals, you should think of them as people who solve problems and happen to be skilled at creating user interfaces and experiences.
Rather than thinking of engineers as people that write code, you should think of them as people who solve problems and happen to be skilled at creating technology. They can (and should) help solve problems without creating technology, where appropriate.
You probably don’t think of a plumber as someone that tightens screws and replaces pipes. You think of them as someone that fixes problems with your water supply.
Everyone in a technology organisation is a problem solver. Everyone in a team will have different skillsets, but they share the same problem that they solve.
The Product Manager’s role is to make sure the team is solving a problem that is important to the company.
Your designers, researchers, data scientists, engineers (and others) all have roles in the process of solving the problem that utilise their skill set.
The product manager’s role is to ensure that:
- The team is solving a real problem (e.g. to improve user activation rate to improve user growth)
- There is clarity and buy-in on that problem; from the team, and the wider company
- The team knows how to prove that they’re solving the problem (e.g. they’re measuring activation rate and user growth)
- The team understands the root causes of that problem (e.g. signup email open rate, email click-through rate, signup funnel conversion)
- The team is working on the biggest of those root causes
- The team is working on solutions that will actually solve the problem, are fast, scalable, and provable, and are in-line with the companies values or principles.
Framing it like this, it becomes much, much easier to understand the role of Product in improving the product. The PM role in software development is much more ambiguous (and much less important) than its role in solving problems.
A benefit of this way of thinking (as well as the role clarity) is that it forces you to think about any team in terms of impact.
Because of their technical skills, a team will normally ship technical features. If they don’t, it feels like great opportunity cost, and is frankly boring for them. Shipping stuff always feels like success, and it is normally the best way for them to do things.
Also, many teams naturally think about what code to write, because that’s what they’re used to doing. As the common saying goes: “once you have a hammer, everything becomes a nail”. Or “if you have a data science team, everything needs an AI”.
But, the team does not exist to ship code. If you ship code without solving a problem, you’re destroying value. You make things more confusing and difficult for other people to build on. It’s bloat.
This is why it’s so important to set a team up around missions and problems, rather than features. If the team’s mission to “improve this feature”, then they are incentivised to ship code rather than solve a problem, which is a bad thing.
Writing code can destroy value.
Some of the best product decisions I’ve seen have involved no code being written. Sometimes it means removing things, or not building things in the first place. This can feel wrong to the team because shipping is an external signal that you’re doing your job.
Think of it like training for a marathon. The amount that you train is a positive indicator that you’re headed towards your goal of doing well in the marathon. But if you train too incorrectly (no rest days, or when you’re injured, or the wrong type of training), then you can harm your overall goal. The same is true for shipping code when it’s not the right thing to do.
I have two examples from my time at Deliveroo that highlight the importance of problem-solving over coding.
In 2017, we had a site reliability problem. Food delivery is a business with hard peaks (mealtimes), and this hammered our database. Our new site reliability PM was making a plan for what her team should work on to fix it, focussing on (what I believe are) the usual suspects – autoscaling, schema efficiency and the like.
But the most effective work the PM did was not to build anything with her team. She identified queries from various services that were overwhelming the DB. If memory serves, every other tech team had at least one or two very expensive queries.
She presented every other PM with these queries, potential solutions, and a compelling pitch for why this was the most important work to move our metrics (if the site is down, your metrics are necessarily zero). This spurred everyone to action, and had a massive impact on her reliability goals. Fantastic PM (and engineering) work by that team, not a line of code written.
In another case, the team that handled live manual operations (getting riders to restaurants, and then to customers) was in a bit of trouble. They were using tools that weren’t fit for purpose, and they relied on myths and rumours to guess what to do.
My team was given the mission of fixing our live operational handling. If we were optimising for shipping features, we would have started building tools to let them do their job better. But I had a fantastic team of engineers and designers, who really wanted to solve the problem. They spent two weeks doing the live operations job themselves, and found something amazing.
People spent most of their time pressing a button marking each order as ‘ready’ to be picked up by a delivery rider. But our logistics AI already did that (it just didn’t update the UI), so people were wasting their time – we estimated this made up to 50% of manual live operations work.
By removing this button (education didn’t work – myths are strong), we managed to drastically reduce the burden on that team of agents. We wouldn’t have found that tiny thing with a huge impact if we’d focussed on shipping features.
The point to highlight here is that product teams solve problems, and that product manager should make sure that happens. It really is as simple as that.