Managing product managers

Managing product managers

In this virtual round table for product leaders and C-level roles, let’s talk about measuring product manager performance, providing opportunities for career growth and the challenges of managing teams of product managers and product owners.

In this article #

Join Jock Busuttil, a freelance head of product who has headed up product teams from startups through to UK government, as he discusses what you need to know about cultivating high performing product managers.

In this discussion Jock covers:

  • what motivates product managers
  • how to build a career path for product managers
  • what your product teams need to become high performing

Video, slides and transcript after the break!





[MARY] Hi guys! Nice to see you all. Thank you very much, to everybody, for joining in again, I know we’ve got a couple of faces have been on a few times. And so I’m not going to talk for long. Just going to hand over to Jock, he’ll do an introduction and then get cracking with Managing Product Managers. Over to you, Jock.

[JOCK] Okay, hello, everyone. So I was going to say before I kind of jump into the introductions in the slides. Obviously, this is a round table. And if you have any questions, you know, don’t be shy about putting them into the chat. We’ll pick up with them, we’re gonna have three kind of separate roundtable discussions on three topics related to managing product managers. So feel free, if any questions kind of come up as you’re coming along, then just pop them in the chat. We’ll pick them up as we go along in each of the discussion breaks.

Perfect. Alright, so first things first, let me get my screen shared, and then we can get going.

Thank you very much for coming along today. I appreciate some of you’re here in the UK, some are over in the US. It’s very nice to see you all. Thank you very much for coming.

About Jock Busuttil

Why am I here? And why am I talking to you about managing product managers. So I’m the founder of a company called Product People Limited. So I’ve been working with lots of different companies on a freelance basis for about eight years now. I tend to work with teams to coach them, to train them up. But I also work as a hands on head of product or product manager as needed.

And so because of that, I’ve had a chance to work with lots of different organisations, including some quite large ones. So a few years ago, I was the head of product for UK government, which was at GDS, the Government Digital Service. And that meant really looking after the entire product community. So there is about maybe 40-50 product people within just that particular office, at GDS itself, but I reckon I was finding about 200-300 product people from all of the, you know, different departments across government, and getting them to all kind of start working more as a community, which is gonna be one of the things I’ll have a chance to talk about a bit later.

But I’ve also been head of product for the Ministry of Justice. And generally speaking, whenever I work with one of the startups or other companies that I tend to go into, I’m going in as their interim head of product to help them get started, build their team, and build their product management. So I’ve managed lots of teams in relatively quick succession over the last eight years. So hopefully that qualifies me to share a bit of what I’ve learned from that, some of the things that work and don’t work. And yeah, that will hopefully give us a bit more insight into the kind of things that hopefully will make more sense and maybe some tips that will apply to you in your organisations.

If you’re interested. I’ve also written a book, it’s The Practitioners Guide to Product Management, and it’s available generally.

We can do better

Okay, so without further ado, let’s get into the actual topics. So the first thing I think, I want us to take away as product leaders, is this message: we actually can do better than we’re doing at the moment. And the reason for that is there was a survey done quite recently, it was a Product Management Trends and Benchmarks report from this year, it was organised by the Product Management Festival, and it surveyed 2000 product managers across 30 countries of all different seniorities. So everything from Chief Product Officer down to the most junior product managers.

And they asked, amongst other things, a couple of questions that were quite pertinent. So the first one was, “What do product managers think their manager can do to lead them better?” And as you can see, there’s things like provide me with growth opportunities at the top of that list, improve the way they give feedback, provide more training opportunities. So there’s clearly some issues that are coming up quite a lot across the product managers surveyed.

The next finding was, “Why do product managers leave their jobs?” So where product managers have actually left their jobs, this was the main reason they gave they gave for doing so. And again, we’re seeing no opportunities to grow coming up as the main ones, poor management performance, in other words, you know, their managers not treating them as well as they would have liked; bad team culture being another one.

So clearly there’s some some issues here. And there’s some things that we can do as product leaders to improve things.

What we’ll cover in the 3 round table discussions

So as a result, what we’re gonna do is we’re gonna have three round tables, the first one is going to be a recap for some people, but maybe if some people are less familiar with the role, we’re going to just spend a little bit of time thinking about the actual role of product manager, and really get under the skin of that.

We’re going to think about creating growth opportunities, so really answering that main point that came out in both, what people are asking from their managers, and also the reasons why they were leaving, when they did.

And then the last one we’re going to look at is setting your team up for success. So these are things that you can do to actively change your culture, change your environment, and really create a high performing team.

So! Hopefully, that’s all good with you people. Let’s start off with the first one. So understanding the role better.

Understanding the product manager role

So as product leaders, we can become better managers by understanding the role and the motivations of a product manager better than we do at the moment. Now, obviously, some of us here on the call are themselves, you know, head of product, have come up as product managers and made their way up to leadership positions themselves. So clearly, you will have a pretty good idea of what it means to be a product manager.

But not every person who’s put in charge of product people necessarily comes from a product management background. So it’s quite a good idea to just recap, or refresh our memories on what’s important to our teams.

So some of you should know this chap. He’s a guy called Martin Eriksson, amongst working for 20 years in various companies, having founded startups, and, and so on, so forth. He’s also the co-founder of minder product, which is one of the largest product management conferences in the world.

So he defines product management in terms of this Venn diagram you see there. So he says, “I’ve always defined product management as the intersection between business, technology, and user experience.” And the product manager is sitting there at that intersection.

Human outcomes, not outputs

The second thing about product managers to think about is that they’re focusing on outcomes, human outcomes, in other words, helping people to solve a problem or achieve a goal much more than they are about delivering things. So people often say, somewhat confusingly, that product management is 80% people and only 20% product. Because actually, the main focus of product managers is working with people, either on their team, their users, their customers, the stakeholders, their managers, other people in the organisation.

So product management is actually a very people-oriented role. And so when we’re seeing what motivates them, when we’re seeing what they’re focused on, they’re really focused on outcomes. And this kind of illustrates the difference.

Instead of asking people to build a thing, namely, build a fuel gauge measuring in litres. A very specific thing, you might see this in a requirement, if that’s kind of the way you do things. What we’re actually trying to do is to solve the problem of drivers running out of fuel. This particular example is dear to my heart. So I used to have a motorbike that would periodically run out of fuel in the middle of the road, and then a little yellow light would come on just afterwards, to tell me I’d run out of fuel.

So for me, solving the problem of making sure drivers don’t run out of fuel is quite important. But that’s actually what I’m trying to achieve. I didn’t need necessarily a particularly whizzy fuel gauge. I just needed to know before I ran out of fuel and got stranded, that that was going to happen.

So really, the message here is product managers are focusing on what people are trying to achieve the human outcomes, rather than building features or releases, which is the output.

User needs first

The next area that kind of motivates a product manager is kind of their internal motivation and definition of success. So this is very much about putting the needs of users first. So users being the people actually using the product in real life. And business needs come second. It’s not to say the business needs are disregarded, but it’s to say that in the general weighting, user needs have a higher priority over business needs.

Because fundamentally, you can only make a product successful if it solves a problem for users, or allows them to achieve a goal. But if you do those things, and you’re able to get a product that does those things out into the market, then what you should see are all the other things that the business needs, namely revenue, profit, market share. However, if you only focus on revenue or if you only get product managers to focus on revenue and market share first, and not on user needs, then mediocre products will always result.

Continuous learning

So a product manager is really there to guide the team, who are going to be delivering that product, from a position of uncertainty and risk to a position of knowledge and understanding. And the way they do this is through a process of continuous learning.

Now, when we’re talking about uncertainty and risk, what we’re really saying, is there stuff we don’t know, there’s a lot of uncertainties. Even in projects where there’s things that are relatively well understood in terms of the components we’re putting together, the particular combination of things we’re putting together may pose challenges, the particular needs of that user segment we’re targeting might be quite interesting and challenging.

So there’s always a degree of uncertainty, particularly in software development, but but generally in any technology sphere. And so as a result, we’re always continually trying to break down this uncertainty and risk into smaller, easier questions to answer. And doing this as rapidly and frequently as possible. And we do this through a process of experimentation with the team to figure out what works, what doesn’t work.

Now, quite often, people try and ship a product too early along this curve, where actually they’ve had to make some guesses because they haven’t actually had the chance to figure out the answer to those questions. And that’s where we start to get problems with achieving product-market fit a product that, you know, doesn’t matter how much we push it in terms of advertising, or promotion, just doesn’t connect with our users. And that’s probably because we haven’t really understood the problem or the needs well enough yet.

Tracking user research interactions

So you might think, okay, that’s fine. But you know, who actually does this in real life? Well, you know, what, here’s an organisation you might not expect. This is HMRC. So the Revenue and Customs – HM Revenue and Customs. So one of the government, large government departments in the UK. And what they have on the wall to keep track of their user – how often they’ve interacted with the users is this very simple chart.

What they’ve got is the number of participants on the left, that they’ve tested the product with. And these are going to be iterations of the product, not necessarily the finished thing. There’s going to be number of days since the last time they ran a usability test, which is just one of the user research options they’ve got available to them. And here’s the critical one: 95% of a team observed a user session in the last six weeks.

So what we’re saying is that everyone on the delivery team, the developers, the designers, the user researchers, the content people, the product manager, the project manager, or the Scrum Master, or whoever, all of the people on that team, go out and participate in user research together. And that way, the whole team gains a shared understanding of the user needs, rather than the product manager being the proxy or the gatekeeper to the users and feeding back to the team what the users are saying.

So it’s really, really important to see how this process of continual learning applies not just to the product manager, but actually to the whole team’s ethos.

A generalist working with a team of specialists

So a product manager is a generalist working with a team of specialists, they’ve got a little bit of a foot in each area, like we saw the beginning with a Venn diagram, a little bit of user experience and customer-facing stuff, a little bit of business, a little bit of technology.

But what they’re not, is a replacement for absent specialists. So the people on their delivery team. So a product manager, you know, just because they’re able to do wireframes doesn’t make them user interface designer, they’re a generalist. Being able to do a usability test that doesn’t make a product manager or user researcher, being able to write code doesn’t make you a software engineer.

However, what an understanding of those different areas in a general level allows them to do is to have sensible conversations with each of those specialists to understand what is the best way to solve the problem for the users, but also to make sure the whole team is understanding and moving in the same direction towards the same product vision.

Round table 1: What do you find challenging about managing product managers?

Okay, so that’s a quick recap of what the role of the product manager is. Let’s start off with our first round table. So in this in this one, what I’d like us to discuss is what you find challenging about managing product managers? What are the main areas of difficulty you find when managing product managers?

[CALLER] I think one of the things that can be difficult is when you have a larger team, right, and they all have different strengths and weaknesses and trying to create an effective process of interfacing with the other organisations and members that they’re supposed to work with. And creating a baseline that is effective for that diverse team that that could be a very, very challenging aspect.

[JOCK] Absolutely. Do you find that the product team is working in a different way to the rest of the organisation?

Consistency or uniformity?

[CALLER] And not so much than the rest of the organisation but maybe work in slightly different ways from one another, right? So trying to create a standardisation, if you will, in being able to how the product team as an organisation works with the rest of the organisations, when they’re all working a little bit differently, that creates a difficult, you know, difficulty with cohesion.

[JOCK] What’s the driver between – what’s the driver for that cohesion? Like, why is the cohesion important in the first place to your organisation?

[CALLER] Repeatable process, right, we want to be able to end the overall software development lifecycle process, we want it to be repeatable, we want it to be, you know, capable of creating the same types of outputs time and time again. And so it’s helpful to allow different people with different skill sets and capabilities to level up in areas that they’re deficient in. So you can create that repeatable process.

[JOCK] Okay. So just just as a way of giving another kind of perspective, or an example of this. So I mentioned I was the head of product at the Ministry of Justice. And when I was there, I had 12 separate product teams working on different services, public services related to the Ministry of Justice. So things like you know, making a court booking or paying court fees, or doing this, that, the other. So lots of different teams solving, you know, various different problems across lots of areas.

And what we had was no specific mandate for consistency. So in other words, or rather what I’d say is that we had this kind of idea of consistency, but not uniformity. So in other words, people were all still trying to do the same things. And yes, they were using broadly the same practices. But they also recognised the fact that different teams solving different problems needed to work in a different way sometimes.

Different approaches for different problems

So even just to take a very simple example, you know, the difference between Scrum and Kanban. Scrum is great when things are a bit more certain. And you need kind of a frequency of learning of maybe every sprint, which could be you know, one or two weeks or maybe longer. And so it’s only at the end of each sprint, you get a chance to do the retrospective to do the review of what you’ve achieved, and figure out what changes you’re going to make for the next sprint.

So you’ve got a kind of a learning and feedback frequency of maybe one to two weeks. With Kanban, the frequency is the time it takes to get from one side of the board to the other, which could be within hours. And so in situations where you’ve got greater uncertainty about the problem, you might want to have a feedback loop that is much shorter to deal with that additional uncertainty. And so in those situations, maybe using Kanban over Scrum made more sense.

So that’s partly the reason why whenever we’re talking about Scrum masters, we actually say delivery managers because they weren’t necessarily always doing Scrum. But what it also meant is that we had 12 teams are actually doing quite a mixture of different things, even down to using different tools for tracking how they’re going along. Because actually, we weren’t so bothered about the way in which they achieved things, as long as they’re kind of adopting some basic, agile principles, and you know, continuous learning and user needs and that kind of thing.

But it was only the end result, the outcome we’re bothered about, which is did we actually solve the problem for the people. So in those situations, whilst I fully see the rationale, and understand the benefits of consistency of process, actually, sometimes it’s quite good to have variation in process, particularly for teams are solving quite different problems. Obviously, not not applicable to everyone not not possible for everyone. But just as a counter example, it’s kind of useful to see that that can be done.

[CALLER] That’s a really good point, finding that good balance between pure process, pure strict process and, and flexibility is where teams become most effective and creating really great output.

Copying best practices from each other

[JOCK] Absolutely, I wonder where things was just is because the teams are working together and sort of stealing best practices from each other. What would happen is actually they would gravitate towards a consistent process, because everyone see each other going, Oh, that’s a really useful way of doing that. That’s much easier the way we’re doing it, we’ll copy it. And so what happened was over time, you actually got consistency, and indeed, a degree of uniformity, just because everyone is gravitating towards the best way of working. You see, I mean, so, so interesting, you end up with a desired results of that kind of similar process across the teams without really having to try and enforce it.

Any other challenges that people have around managing product managers they’d like to share?

Keeping people engaged and motivated

[CALLER] Yeah, I’ve got one perspective. I’m working on teams on a probably a smaller scale than than what you’ve described. And it’s the challenge of keeping people engaged and their personal development and progression because logically to them, the next step up is my job. Which I’ll be – I’m more than happy for them to kind of step into my shoes and then I can kind of develop as well but it’s kind of when it’s a role that’s pretty consistent and kind of that is, that is the role and the kind of development opportunities aren’t quite so obvious is how to keep them kind of engaged and motivated about, you know, just managing the product. If that makes sense.

[JOCK] Absolutely. So what I’ll do is actually, we’re going to deal with that in the next sort of main topic coming up. So I’ll park that just for a second, because we’re going to be actually talking about it in much more detail momentarily. Does anyone else have any other questions? Or should we move on?

No? Okay, well …

Don’t inhibit personal growth

[CALLER] I don’t if we’re going to highlight in the next section, but to to Jamie’s point there, I just as anecdotally, I always encourage people to find growth, where growth is available, whether it’s within the company that I’m at now, if it’s replacing me, or if it’s finding opportunity elsewhere, I’m always open about and always rarely make references, or people that want to find growth opportunity elsewhere. Because that’s, that’s what we should mostly be about is about growth of the people that we work with, as opposed to trying to pigeonhole everyone to stay in here. As much as we want great people at our company. We shouldn’t inhibit personal growth of those individuals.

[CALLER] I’ll certainly agree with that. I just feel like sometimes I’m the kind of a nursery for other other product teams.

[JOCK] Yeah, it does feel that way sometimes. Okay, so let me reshare my screen, and we’ll move on to the next bit.

Creating opportunities for product managers to grow

Perfect. Right, so how do we create those opportunities for people to grow?

So just to recap what we saw the beginning, when people were saying they left the job, but the main reason they said was because there were no opportunities for them to grow within the organisation. And you know, that’s a particular problem, particularly if we spent as we were just talking about a moment ago, a lot of time and effort training up people and bringing them into the role of product management to begin with.

And what else do product managers want from us as their managers? Well, again, lots of people want growth opportunities, and lots of them want the opportunity to do some training as well. So everyone is clearly interested in moving themselves up, you won’t, you generally tend to not to get complacent product managers. Kind of inherent in the characteristics of the of the role, there’s kind of a fairly self starting mindset. So what can we do to help them with that?

A product manager career path

I want to share with you the typical kind of career path that I see in organisations. Now, clearly, it’s difficult to implement a career path when you’re a relatively small organisation. And there’s simply not enough people within your organisation to have multiple levels to work through. But we’ll show this as kind of an example. And maybe this will help us to talk about – give us something to talk about in a moment.

And what I’d like to kind of start off with is, you can see the axes on the chart at the moment. What you should be able to see is left to right, left is more product focused, right is more people focused. But as we know, product managers should be a blend of both. And then top to bottom is kind of seniority or level of experience. And you’ll see there’s this kind of dotted line, and I’ll explain that in a minute.

And then what we do is, as we go up the path, we’re gonna be starts off managing a single or a simple product, and then all the way up to the top, we’ve got very complex, more products, or indeed, all of the portfolio.

Associate Product Manager

So let’s add in some of the people. Now, the first role is kind of the anomaly, because the Associate Product Manager is the entry level role. So it’s almost getting your foot in the door. And it’s trying to overcome this problem that many people have with product management, which is, you can’t really do a university degree now. And appreciate there are now courses you can do and so on. But even things like MBAs and that kind of thing don’t really give you the hands-on experience, you need to be a product manager in real life.

So Associate Product Manager is a role that typically I have used to bring people into the profession, but to hold their hand a bit. So they’re buddied up with a real – with a with a product manager who’s actually responsible for the product, they maybe over time gain some responsibility for maybe aspects of the product or particular features. But really, their job here is to learn how to do the roll through doing, with somebody there who’s more experienced and can guide them along the way.

And this was particularly useful in the civil service, in the UK government because product management was a completely new discipline to them when we started bringing it in and as a result, we had this problem of lots of bright graduates, but no way within the civil service to actually, you know, train people and bring them in.

Product Manager

So when we created the Academy, we were training up people to become Associate Product Managers, so they could learn on the job, and then become product managers, where they now have responsibility for their own product.

And to begin with, you know, it’s relatively simple, straightforward, maybe a single product, that would be plenty for them to be getting to grips with. As you can see, they’re beginning to be more people focused. So we’re already shifting a little bit. And in some cases, these product managers, despite being relatively junior, still have a responsibility to buddy up maybe with Associate Product Managers.

Senior Product Manager

Then next level up, a Senior Product Manager beginning to be more people focused, again, maybe responsible for either more complex or more sensitive politically or otherwise, products, or maybe a couple of ranges of products within the small portfolio.

VP / Lead Product Manager

Then when we get to kind of VP or Lead Product Manager, this is kind of like almost like a group area. So one particular business line, this person might have responsibility for that. But also, they have a much greater responsibility to look after the Product Managers and the Associate Product Managers beneath them. Okay, so very much in the middle between being product focused and on the strategy side, but also people focused in terms of needs of their team.

Now, here’s where we get an interesting split, because essentially, you can go in a couple of different directions at this point: you can either continue down the individual contributor line, so in other words becoming better at product management hands on; or you can go in a direction of being a – more of a people leader. So if you wanted to kind of stay as a VP, or a Lead Product Manager, and essentially just deal with more and more complex product products, that could be a growth pattern for that particular individual.

Head of Product Community

Head of Product Community is effectively putting the hands-on product management to one side, and actively thinking about managing the team of product people as almost like a product in itself and serving the needs of that community.

Chief Product Officer

And of course, you have the Chief Product Officer at the very top. So board level, responsible for the overall strategy across the entire portfolio of all of the products, in all different business lines. And marrying up not just the respective strategies with the corporate strategy, but also ensuring that the right people are in the right teams on the right – on the right product.

So really, what we can see here is that there is a career path for people to deal with more complex things or greater numbers of things as they go up the career ladder. But also, there’s very different options along becoming more specialists, or becoming more people focused, or maybe even going on to a board level appointment.

Communities of practice

So product people at all levels can learn from each other if you provide them the time and opportunity to do so. So in other words, what we’re doing is we’re going to find opportunities for growth through peer based learning. So in other words, we’re going to exploit the network effect of having lots of product managers in the same discipline.

And so this acts like a professional support network, but also it’s a good way of sharing expertise and sharing tips on how to tackle particular problems. And if you’re in a kind of organisation where there’s maybe only a couple of product people, then you know, that’s not to worry, because you can either join or start a local area meetup for product people. Or you could even start one up yourself, or sponsor an existing one, and then encourage the people in your team to participate.

The importance and the benefits of allowing this kind of community to get moving and to participate in is just – you can’t underestimate it – it is one of the most important ways for product managers to feel better about what they do for a living, become better at it and ultimately to share best practice and learn best practice from their peers.

And so Mind The Product is one of the largest organisations that kind of builds together a community of practice. The photo here is from the London conference, and there’s about 1500 product people of varying different levels in that audience, just there.

So, being part of a community and being able to just simply say, you know, I’m finding this really difficult, how do you do this in your organisation? Or how do you do this? And how do you solve this? Really, really valuable.

One-to-one coaching and mentoring

To couple this up with coaching and mentoring is also really important. So this is more one to one based stuff, typically with a senior product person. And it’s non directive, so it’s less about kind of telling them what to do. It’s more about saying, what are the challenges you’re having and how can I support you and help you to, you know, solve them or get around them?

Sometimes it’s prompting them to try a few different things, but often the answer is within the individual to their own problem, they just need someone to bounce the ideas off. And so having someone in their organisation to do that is fantastic. But if you don’t have a senior product person who really understands the role, and who themselves has been a product manager in the past, then maybe you can look to external coaches to come in with that experience, so that they have someone they can relate to.

Quite a lot of the coaching I do remotely is with individuals who are literally the only product manager in an organisation, and don’t really have a line manager who understands their role. And as a result, what we tend to do is I kind of become a surrogate kind of manager for them by providing that one to one coaching. But really, the purpose of coaching is to identify opportunities for growth, and to support the individual to achieve them.

Skills self-assessment

One of the things I like using when I’m doing coaching is I get the individual to do a skills self-assessment. So this is something that I put together originally for my team in government. But essentially, it’s a survey where we put together, ourselves as a team, what we believe to be the most important skills and characteristics of a good product manager. And then we went away and scored ourselves, honestly, on those traits.

So what we’ve got here is actually an anonymous example, there was no lady called Petra the product manager in my team. But to give an example of the kind of things we could see, we can see that compared to the grey area, which is the average for the whole team, Petra feels that she is not so great at the business case side of things, the product vision side of things. So maybe these are the areas that I’d work on with her in one to one coaching sessions.

But as you can see down the bottom left, she’s particularly good at metrics, maybe that’s her background, in data science. So this would be an opportunity to share her expertise, with the rest of the team. So what I typically do is, you know, prompt her to do a show and tell on that particular topic to really kind of help spread that experience and knowledge around the rest of the team.

So this is something that I do. Actually if you look up on my website, and it’s, I’ve actually got this available under Creative Commons. So you can grab the survey, you can grab the kind of the way of doing it. It’s very simple to put together yourself. And you can actually run this with your own team if you want to.

Allow time and budget for training

And also, last couple of things is – just remember to actually allocate time, budget, permission for training. I know I’ve worked in organisations, you know, as well as being in my own company. And I get the fact that when you know costs are cuts, one of the first thing that always goes is the training budget. If there’s anything you can do to kind of ringfence that, but also remember, there’s a lot more cheaper online options available these days.

So there’s there really isn’t any excuse for kind of just not having that budget available for people in your team to learn more about a specific skill in product management or even just refresh their ideas on what product management means to them.

Shadowing and secondments

And the last piece is, again, depending on how your organisation works, opportunities for product managers to gain experience of other disciplines, through shadowing, and maybe secondments, or maybe even learning from another product manager through shadowing and secondments either again, in your own organisation, or somewhere else.

So think about all these different options for providing opportunities for growth within your organisation.

Round table 2: What can we do to support growth for our product managers?

So let’s do our second round table. The second question I’m going to put to you is how can we support – what can we do to support growth for our product managers?

A stipend for training

[CALLER] So one of the things that we have implemented is, it’s actually company wide, is a stipend for professional development. Right. So the company is bought into the concept of professional development for the company, or for the employees. And so it’s an open site, then all you have to do is submit what it is that you want to get development on learning courses, certifications, etc. you submit that to your management, and then then you get the approval as long as it’s within your wheelhouse or adjacent to your wheelhouse, if you will, it’ll get approved but it is an annual stipend that every employee gets every year. And it’s really useful for someone that wants to attend, you know, product certification courses or wants to, you know, get an online learning course or wants to, you know, buy a library of, you know, design trap books or something of that nature.

Report back what you’ve learned

[JOCK] So, one thing I always got my teams to do when they’ve been on some training course or some certification or anything else, is they had to basically present back what they learned after each thing. So first of all, that kind of puts a bit of pressure on them to make sure that they actually pay attention and not coast it. But also, again, it’s getting the benefits of what they’ve learned and what they took away from that and sharing that with the rest of the team.

So yeah, I didn’t do it in a particularly kind of pressured way. But it was just a way of, you know, encouraging people to really think about what they took away from that course. And to be honest, quite often people, when they’re choosing the things, would be so enthused about it, when they got off, they’ve got to tell you about this! Anyway, you almost couldn’t stop them talking about it. But yeah, just just adding that extra little thing to kind of encourage that, that sharing.

Use it (or lose it)

The other thing I’d also do is I kind of do, I do report on who hasn’t spent their stipend for training. And just again, it’s a one to ones go go look, come on, you’re missing out here, you’re losing out on an opportunity to gain experience and knowledge. You know, use it!

What else do other people have on the call that they’ve used to help growth or promote growth for their product managers?

Balancing learning with fee-earning

[CALLER] So we kind of so I’ve only just recently stepped into the role of learning development lead.Yozu have gone from UX consulting to both front end helps us to learn button lead. And I think one of the things we’re pushing for, though, is we’ve got a progression framework, which I’m working on. So it gives you clear steps for progression.

But one of the kind of issues I’m having with that really is because we’re client facing, and to get people to kind of it’s a training budget is kind of is I guess it works in a slightly different way, in that if people aren’t working on client projects, and they’re not actively kind of earning money, essentially, you know, for us as a company. And now we’ll get we’re addressing this by having more of our own products as we go on. And we’re working more on that. So we’ve got that bit of leeway.

But I guess it’s kind of making it apparent to everybody how important it is to, for them to kind of take up the you know, so yeah, I know, you understand that if you’re working for client facing project, and you’re directly earning us money, essentially, but your training is just as important. It’s kind of trying to find that balance and how to, and don’t get that in their heads, I suppose that you know, you you’re this is budgeted for you, you know, take it.

[JOCK] Absolutely. One of the analogies is with certain professions, like lawyers or accountants is that they have a requirement as part of their practising certificate to do continual professional development. And they’ve got a certain number of hours of CPD that they’re obliged to get in every so often.

So on the one hand, you know, you don’t necessarily want to enforce it. But if people are struggling to find a balance between client and fee-earning work versus learning, then there are lots of examples from, you know, very fee-earning based professionals like lawyers, where they have to allocate that time. So they have to split their time between fee-earning and professional development, just to be able to keep practising as a lawyer. So you know, that’s potentially one thing that, you know, you could steal an example from, to kind of help find that balance within the organisation.

[CALLER] Thanks. Yeah, yeah. Cheers.

Bringing everyone up to same level of skills

[NEXT CALLER] One of the things we’ve got – I introduced a skills matrix and lots of what you’ve just kind of posted there, which we’ve had probably about 18 months or so. And the idea is, me as a manager, I don’t mentor in every area because even as a manager, I don’t know every area, it’s impossible. So we’ve got that, and we look at the strengths.

And we’ve also got a Gallup Strengths Finder, which we use when we introduce people into the business. So we see where their core strengths are. Sometimes some people are visionaries, some people, thinkers and people analytical. And so the aim initially was to bring up that baseline level of all the product managers across the board, so that at minimum they’re average, at least average or okay in every area.

What I have been noticing, though, and it’s something I’m not sure how to correct is, we have got particular strengths in every team member, they all come from different backgrounds. And what I feel is happening at the moment is because there’s going to get a baseline level some of our key strengths, I.e. people management, that analytical thinking, that I think we’re not using them as well, as much. So it’s trying to get that balance between making sure they use what they can bring without stifling it, you know what I mean?

Do you have the right skills on the team for the problem at hand?

[JOCK] Yeah, it’s tricky. I mean, as I said earlier, the role of Product Manager is quite a weird one because actually, regardless of what background you happen to come from, whether it’s technical or marketing or sales or development or user research or user experience design, you know, although you kind of have that skill set, you don’t often get to use it in anger. Because actually, it’s not your job any more to do that.

And in fact, one of the challenges I’ve always had with particularly people starting out product management is getting them out of their comfort zone and stopping them trying to revert back to whatever it was they were doing before. So in some ways, if they – maybe if they’re not using a particular skill set as much as they could be, that may not necessarily be problematic. The question almost I would be asking is, do they feel that they have the right skills for the problem they’re currently trying to solve with their team?

So in other words, whatever products we’re creating, whatever problem we’re trying to solve, for that particular market segment, do we have the right skills within our team, you know, and ignoring kind of job titles and so on? I kind of, you know, just because your job title isn’t something doesn’t mean you don’t have that skill, you know – so, but collectively within the delivery team, do we have the skill sets, we need to reasonably solve that problem?

And it’s perfectly reasonable to require different skill sets to drop in and out of that team as they go along. But I think that’s the more pertinent question, which is, do they feel equipped, either in themselves or with their team? To understand the problem, create a product that solves it and actively get out to market?

Growth opportunities outside of the company leading to churn

Yeah, okay. Yeah. Jamie, I’m waving to the side of screen. ‘Cause that’s where you’re on mine, who knows where you are on the screen! But you were saying earlier in the previous segment, that they had some questions around growth? Do you still have any questions that haven’t been answered by what we’ve talked about so far?

[CALLER] Not really, no, we’ve we’ve sort of taken that same approach that we try and look for opportunities where they are, even if it’s kind of learning about different parts of the business, or even transitioning into other roles and things like that, and just finding opportunities where they exist.

It’s just a regular challenge that we have in kind of different climates, depending on the person, there’s always something we’re having to kind of be mindful of. But yeah, I guess we’ve we’ve kind of taken very much that same approach. It’s just unfortunate that it caused a bit of churn in some cases for our team, but always in a positive way. I mean, everyone that’s gone on to do really good things. So it’s good. From my perspective, in that sense, not so much for recruitment.

[JOCK] Yeah, I understand. I mean, is, is there any scope as it were to, as it were increase, if not the, the seniority in terms of either number of products managed or people managed, is there more scope to increase the complexity and give greater responsibility to product managers moving up the career path?

[CALLER] I think for the ones that are more established, I think that’s naturally what’s tending to happen. Yeah, they’re kind of much more involved in the more complex decisions, or the more strategic decisions, get closer to things from a technical perspective, or they’re, they’re kind of aligned with the teams that are doing the naturally more complex work and that kind of thing. So yeah, that sort of naturally happens with the more established teams. But it’s the ones that are kind of in this sort of transition stage of kind of being very ambitious, and not quite ready and all that kind of thing. But, yeah.

[JOCK] Yes, it’s a tricky one. I mean, I’ve, you know, certainly, I think, I think as possibly one of the other people on the call today, who said that, you know, they, they encourage people to take the opportunities, even if there’s opportunities aren’t necessarily in your organisation. And yeah, I, you know, I would, I would second that. I appreciate, you know, it’s a, it’s a bit of a pain, when, as I said, you’ve got to now suddenly fill what was a very good experienced person’s shoes.

But at the same time, you’re getting the opportunity to potentially bring in someone who’s going to be as good if not better, and, you know, give them an opportunity to similarly grow as an individual.

I’ve had situations where somebody who has gone off from my team elsewhere has like, come back again, much later and a much more senior position and really helped us out. And quite often, I’ve replaced myself in jobs with the people that I previously hired and had gone on to other things. So, but then again, that’s that’s kind of, you know, my way of working, which is generally to get in and out of somewhere as quickly as possible.

Internal recruitment

[CALLER] What I have found is that because we’ve got quite a quite a well established team and an established process for developing people like that, we tend to get people gravitate towards us from other parts of the business. So we’re not looking outside the company. We’ve got people that would have already got domain knowledge. Then they can come in and they can learn, you know, product management, right? So, and we struggled with our location in terms of, we’re in an area where we’re competing with Manchester, which is quite a difficult place to compete with recruitment talent. So that kind of process of bringing people on internally is worked quite well for us.

Spreading product management around the organisation

[JOCK] Great! And there’s also so much advantage in kind of, you can spread a bit of product management knowledge and experience kind of across other areas of the company, that’s only to the good. You know, to get people to get more people thinking in a bit more sort of, you know, customer or user focused way is only to the advantage. I’ve, I’ve kind of used, sort of dropping product managers into sort of shadowing arrangements sometimes to build up better relationships with a different department say, you know, whether it’s finance or sales or whatever else. Because actually, it’s useful for the product person to gain empathy, and understanding of the difficulties and challenges of that role, but also, it rubs off a bit on the the particular team they’re working with as well. And that’s only a good thing.

[CALLER] Just need a few more of those on the board.

[JOCK] Yeah, exactly. Exactly. Good. Shall we move on to the third topic?

Let’s look at then some things we can do to set up your team for success.

Setting your team up for success

Okay, so reminder why are we doing this. So poor manager performance: unfortunately, it’s us that are the problem said 17% of product managers, who left their job. And similarly ‘bad team culture’ said 15% of product managers who left their job.

Autonomy, mastery and purpose

So what are they saying they want from us? Well, autonomy, mastery and purpose. What they’re actually saying is 20% said, ‘don’t micromanage us so much, give us more autonomy to take our own decisions’. And this idea of autonomy, mastery, and purpose comes from a variety of different sources. But I think one of the ones that most people know is Daniel Pink’s book Drive. And he says that the key to motivating engaged people is to give them a working environment where they have autonomy, mastery, and purpose.

And what this means is autonomy, being able to take their own decisions, not being kind of forced to push everything up through tiers of hierarchy. Mastery is where they feel that they have the ability to get better and master their own particular discipline, be it product management, or anything else. And purpose is kind of the most, almost the trickiest one. Because it’s instilling in people, the thing that’s going to motivate them to get out of bed, the purpose for what they’re actually doing, and why it matters.

And when we think about kind of thinking about the very beginning, where we talked about human outcomes over outputs, the trick to instilling purpose in a team is to make sure they’re focused on those human outcomes, the things that matter to people, rather than the outputs, the things, the widgets, the features, the lines of code that they’re churning out.

It’s all about trust

So autonomy, mastery, and purpose are the foundations for a strong, high performing team. But fundamentally, it’s all about trust. Organisations almost fear, in many of the ones I’ve worked with, at least anyway, fear giving teams control over their own destiny, they don’t trust them enough to take their own decisions without supervision. Saying you trust your product teams and showing that your organisation trusts them, are different things.

So where you have, you know, a process that requires constant status reporting up the chain, has a requirement to escalate decision making beyond certain limits, or where metrics are puts upon the team without them having any input into them. Or indeed metrics that are kind of focused on outputs, again, or vanity metrics rather than human outcomes that are directly related to what the products trying to achieve. All of these things undermine that sense of trust, that you’re trying to establish within your teams.

And it’s, and it’s so easy to fall into this trap. You know, traditional project management metrics, like being on time on budget, on scope, are all measures of output. There’s no human factor in any of those things. What really matters is whether the product solves the problem effectively for the people it is intended for.

So through the team’s understanding of user needs, and hopefully their autonomy, they’ll be able to set their own sensible measures of success, what success, what good looks like for their particular product.

Psychological safety

20% of product managers also want their leaders to ensure that every team member feels safe and respected at work. And this is also known as psychological safety. Now I totally get that culture is not something you can flick – change with the flick of a switch. It’s something that often I’m brought in to try and help with. But it’s something that literally takes years to actually make stick and relies on top to bottom agreement that this is actually the direction the organisation needs to go.

But as leaders, we have a disproportionate effect on the behaviour of our teams. So we have to set the example and that means everyone you know, the CEO, the MD, whoever, downwards. We have to set a good example and ideally a good one. And it should also be a level playing field, what rules for psychological safety, which we’ll talk about in a second, what rules we have should be the same for everyone. It shouldn’t be, you know, one set of behaviours for leadership and one set of behaviours for everyone else.

So psychological safety, just in case, we’re not familiar with this. This is where we are talking about a culture of openness and mutual respect in an organisation. And this is where everyone in a team feels safe in front of their peers, to make mistakes without recrimination, take risks be vulnerable, not know all the answers, speak their mind openly, and be themselves – bring their whole selves to the organisation rather than wearing this kind of mask, of their business persona.

And it’s kind of it’s really important, because this all came from a study where we had situations where there was a junior nurse failing to query a surgeon’s mistake because she was afraid of doing so. And as a result, the surgeon’s mistake led to the death of patients.

So this kind of fear of piping up and being able to speak their own mind openly, is something that is really challenging when we’re trying to empower our teams, and make them really, really high performance.

Motivation and accountability

And it all comes from the work that Amy Edmondson did, who first coined the term psychological safety. So most organisations think the way to get people to do things and encourage them to do so, is around this scale of motivation and accountability, so in other words like carrot and stick, rewarding success and not rewarding or punishing failure.

And, you know, when you’ve got people who organisations that don’t really bother are kind of enforcing any reward or otherwise, for the things they do, you get this kind of apathy, because it does really matter what you do, and people don’t really kind of want to do anything. But when you go and kind of go too far the other direction, and everything is all about hitting targets, and your you know, performance related bonus is the be all and end all, that kind of thing, you actually drive people into this kind of anxiety zone.

Level of openness in the organisation

Now, there is another way of looking at this, when we start to introduce psychological safety is a different dimension to our organisation. So the level of openness we have in our organisations, then we get two things happening. And we clearly want to be in the top right in the in the learning zone where we have high motivation and accountability, and high levels of psychological safety. Because if we don’t have the motivation and accountability, even with psychological safety, it’s lovely for people to work in that environment, but there’s no real motivation for them to really kind of push on to the next level.

So what you want is a combination of high psychological safety, and high motivation and accountability. And so the way that Amy Edmondson described these two things is the motivation and accountability is like the gas pedal for accelerating an organisation. And psychological safety is like taking your foot off the brake to allow the organisation to move more freely.

Team social charter

Another thing that was quite useful from a community point of view was the team’s social charter. This was an example from GDS, Government Digital Service. And they put this up, because they wanted to show new starters all of the unwritten rules or the unwritten social rules that the team had. And this actually kind of went viral when they shared it.

It’s one of the things that the team writes for themselves. But it’s interesting because the exercise of doing this can bring up some interesting things if as leaders we’re kind of reacting with horror to the kind of things the team has said should be okay, we should be asking ourselves, well, why do we have a problem with this? Why? Why are we so horrified at this? Why don’t we want this thing to be okay?

So we should really think about this as a way to really understand what our teams, how our teams want to work, and how our teams wants to behave.

Do be careful. One caveat, I would say is be careful when there’s like a big elephant in the room type problem in your organisation. Maybe everyone is grumpy about kind of feeling overworked, underpaid, I don’t know whatever it could be. If you’ve got that kind of elephant in the room, don’t go and create a chirpy list of, it’s okay to do this and do that, because that’ll just annoy people. Instead, go and deal with the elephant in the room first. And then when that’s resolved, kind of think about doing this as well.

And here’s another example, actually from one of the NHS trusts, back in April, right in the middle of the beginning of the outbreak. This is a different kind of thing. But again, it’s like letting the team basically express what is acceptable behaviour for them within the organisation and kind of being given permission from leadership, either tacitly or explicitly to behave in these ways.

Setting the right example

You’ve probably seen in the news, you know, SpaceX has done another kind of relatively successful test, except they didn’t quite stick the landing, on the starship iteration recently. But jumping back to October, they had to scrub two separate rocket launches just 36 hours apart. So you can actually see both of the rockets, you know, one the distance and one in the foreground. And in response to this, Elon Musk jumps on a plane from Texas and goes across to the teams here.

Now, in some organisations, that would be, oh, god, we’re gonna get fired, because the boss, you know, the chief executive coming out to see what the hell’s going on, is usually a bad sign.

But in this case, Elon Musk is also the chief engineer at SpaceX. So what he was actually doing was coming along to Florida to, yes, motivate his team, but also to support his team to lend his technical expertise to help them solve the challenges of launching rockets on time, because it’s not easy. But I like this as an example of someone coming along, not to go shout at their team and put the fear of god into them, but instead to say, look, this is really important, you’re having problems? How can I help?

And that style of leadership is I think, very much the kind of example that we should be setting to our teams.

Round table 3: What can we do to set up our teams for success?

So very quickly, we’ll do our last little roundtable. What can we do to set up our teams for success? Does anyone want to jump in on that?

Shield the team from politics

[CALLER] I think you will highlighted a number of things, right? It’s got, you’ve got to ensure that the team is equipped and understands how to effectively execute on their job right, making sure that they have the air coverage from from you as a as the you know, the manager and their leader to be able to execute and not be hounded with with some of the politics that could be creeping around from other areas of the business. I think that’s that’s paramount.

[JOCK] Does anyone have any particular examples of how they’ve been able to help establish psychological safety in their organisations?

Bring teams together to connect at a personal level

[CALLER] So I have actually had a scenario where there was a lot of difficulty of the relationship between R&D and product. Because product management was a new function at the company, it was engineering driven before and there was a whole new initiative. And what I found, is – encouraging the teams to start having a regular group session, right, not where they’re so much worried about, you know, how do we execute on something, but more of how do we become more personable with one another, and trust one another, to be, you know, to work together. And that allowed the engineering team to become much more comfortable with the product management function, because they were more connected on a personal level with the product managers.

[JOCK] Perfect. Perfect. I’m conscious of time. And so what I’ll do is I’ll just finish off the presentation. And then if anyone wants to stick around and ask further questions, feel free to do so. But I just want to make sure that the people who do have a time constraint can can jump off.


We talked about understanding product managers better to understand how we can support them better. And that’s really to make sure we’ve got empathy with what they’re trying to achieve and what motivates them.

We talked about being clear on how product managers can progress if not necessarily in more senior roles than in greater challenge, perhaps, in what they’re doing. And we as leaders, as managers should be supporting them to do so.

And the third thing is it’s absolutely important to have a high performing team to make sure they’ve got a sense of autonomy, mastery and purpose. And within that is this idea of psychological safety, making sure there’s a culture of openness, not just within that team, but ideally, across your whole organisation.


Thank you very much for listening. I greatly appreciate all the fantastic comments and questions you’ve you’ve given. If there’s anything else you’d like to ask, now would be a great time, I don’t know, Mary, if there’s anything you or James want to round off with at the end?

[MARY] No. Just if there’s any questions for you really, and then we can wrap up, but no, thank you. That was really great.

[JOCK] Thank you very much. And if anyone does want to get in touch with me, the easiest way is to just drop me an email, you can see the web address up on there. Or alternatively, if you search for Jock Busuttil on LinkedIn, there’s not that many of us. So you should be able to find me pretty easily.

Where does this expectation of autonomy originate from?

[CALLER] So, Jock, I do have a couple of things. Autonomy. Every product person I brought into the organisation has this pie in the sky idea that they’re going to be able to just make decisions. I think that’s great, except the more complex and regulated the environment is, the less autonomy there is. So where is this – where is this originating? I mean, I understand I, you know, I’ve led product resources for a decade. But in my organisation, resources discovered very quickly that they weren’t going to be able to operate in a fully autonomous environment and make decisions and push product forward. And then, over time said, yeah, it was kind of ludicrous for me to come in thinking that so, I mean, we all come from different environments, and we’ve all worked in different industries is, is what I’m saying completely ludicrous, or does it resonate?

Supporting teams to avoid risky mistakes in highly regulated markets

[JOCK] Well, in my experience, I mean, there’s a common fear that, you know, when somebody new is coming into an organisation, you know, they’re relatively junior, because product managers aren’t necessarily particularly senior roles within organisations, at least to begin with. There’s often a fear that trusting them to make good decisions, particularly in highly regulated areas, is potentially opening up the organisation to risk. I guess the, the answer to that is, in the situations where that hasn’t gone wrong – when it hasn’t gone so well, what were the reasons for that? Was it a lack of experience or lack of support? Was it a lack of understanding of the regulatory constraints?

And in those situations, I would be looking to say, well, okay, what support can we give those individuals to help them avoid making the same kind of mistakes again in the future? Or indeed better, what can we do to prevent them making them in the first place by ensuring they have the right knowledge and experience at their fingertips, if not themselves, up to speed with it yet?

No autonomy = no product manager

But I think that, where there’s that tendency of saying, well, we can’t possibly let the team take the right decisions, because we can’t trust them to, I think, really, then at that point, you’re just saying, well, we are going to take decisions on behalf of the team. And so there’s really no role any more for the product manager, because they don’t have any control over their own destiny.

Give teams the chance to become the experts

I would say that, even in highly regulated areas, whether it’s healthcare, or whether it’s legal, governmental stuff, or whatever else, there’s always scope for the team to learn and become the experts in that domain area, and actually, to become more expert in that part of regulation than maybe anyone else in the organisation. But we have to give them the opportunity to do so.

And if we are worried of them making mistakes, then we need to figure out a way to allow them to make less risky mistakes, and to provide a safety net for them, to allow them to learn without fear of, you know, either having all of their decision making ability taken away from them, or without actually making a mistake that’s quite impactful and problematic for the organisation.

But I think without that autonomy, without that empowerment, there is no role for a product manager because their role is dependent on being able to make decisions on the destiny and the direction of their product, and how indeed, their team works together to to do that. It’s very difficult to motivate a team that’s in a position where they don’t have autonomy. And so I would say that if you’re if you’re struggling to find that, maybe the question to be thinking about is, how can you better support them to avoid the concerns that the organisation has, while still giving the team the ability to function as a product team?

Anti-pattern: disempowered product teams

[CALLER] Yeah, I guess I guess there’s just a difference in the line determining where product responsibilities begin and end. Because in a financial services environment, there’s continually changing regulations, there’s an entire compliance team, there’s significant review processes of everything that’s getting ready to be published. So, you know, choosing font, choosing placement, choosing pads, journeys, that stuff’s all really taken out of the hands of a, of a traditional, quote, unquote, product resource.

So, you know, looking at looking at funnels, looking at drop outs, making recommendations for changes, absolutely. But the final decisions aren’t, aren’t always in the hands of the product resource. So what I’ve always done is just, you know, allowed allowed the decisions to be made by the product team, and then go through a process of reviewing those making recommendations for changes. So they feel like they’re driving, and then you’re explaining the reason why the things aren’t necessarily happening the way they were designed.

The person on the team with the aptitude takes ownership

[JOCK] So maybe to give an example. So in one of the jobs I was in, before I started my own company, I was working at Experian. And I was working at a bit of Experian that had responsibility for maybe 50 or 60 different sets of data, some of which were very highly sensitive government data sets, and that kind of thing. And the person that was responsible for the overall direction and strategy, and basically being the expert on the changing regulatory environment for those data sets, was one of the more junior people on my team. And the reason for that was because he had the aptitude, the ability and the interest to manage those data sets better than anyone else in the organisation, that person has now become the head of data, he actually came back to Experian after leaving, in a much more senior role for data strategy.

But without that experience, without that trust in him in the first situation, he would have never had the opportunity to grow and develop and indeed, to be able to contribute to Experian in the way he did.

Product teams are good at dealing with uncertainty and change

So I would say that if you’re not giving your product managers and your product teams the opportunity to become the experts in those continually changing regulatory environments, because you know, one of the things that product teams are good with is dealing with uncertainty and change. The technical standards of dealing with are continually changing, the user needs to continue evolving and changing, the market competition is continually changing and evolving. And the regulatory environment is constantly evolving and changing, if you give them the opportunity to be responsible for keeping on top of that, you might be surprised with the results you get, providing, you know, you give them that support and reassurance and trust that, you know, they are able to take decisions, and you can help them steer away from potential decisions that might be problematic. But ultimately, the things that they are doing is, you know, driving their own decisions and taking them making their own path forward.

[CALLER] Yeah, in an organisation like Experian, you’re gonna have a lot more resources, then

[JOCK] Not necessarily, not necessarily: my team was four people.

[CALLER] Okay, well, we should we should continue the conversation because

[JOCK] There’s different approaches for sure.

[CALLER] There definitely are when you have very tight timelines to deliver, it’s difficult to bring someone into the organisation if they are not from the industry and give them an opportunity to get up to speed on all the relevant regulatory constraints. So I think again, it comes down to where you drawing the line of what’s considered products responsibility, because in some organisations, it might be, you know, a very, very small area is what falls under product. And it’s really more around, design, develop, delivery, whereas at other organisations that involves research and analysis. So

Put product teams in charge of their own destiny

[JOCK] As I said, it depends from varies from organisation to organisation. My approach is to make sure that teams are in charge of their own destiny. And that’s really full responsibility from top to bottom for the product and the way it gets out to market. So that’s everything from financial responsibility to making sure the regulatory stuff is right. But it’s only through trusting and empowering people that we actually get good performance from the teams I’ve worked with.

Closing remarks

Perfect. Any other questions before we finish? No? Well then, thanks very much again for all your questions and all your comments. If you want to get in touch please do more than happy to discuss, help out in a professional capacity or otherwise. So hopefully see you again soon.

Thank you very much.

[CALLER] Thanks, Jock.

[MARY] Thanks, guys.

[JOCK] Cheers, everyone. Bye!

Get articles when they’re published

My articles get published irregularly (erratically, some might say). Never miss an article again by getting them delivered direct to your inbox as soon as they go live.  

Read more from Jock

The Practitioner's Guide to Product Management book cover

The Practitioner's Guide To Product Management

by Jock Busuttil

“This is a great book for Product Managers or those considering a career in Product Management.”

— Lyndsay Denton

Jock Busuttil is a product management and leadership coach, product leader and author. He has spent over two decades working with technology companies to improve their product management practices, from startups to multinationals. In 2012 Jock founded Product People Limited, which provides product management consultancy, coaching and training. Its clients include BBC, University of Cambridge, Ometria, Prolific and the UK’s Ministry of Justice and Government Digital Service (GDS). Jock holds a master’s degree in Classics from the University of Cambridge. He is the author of the popular book The Practitioner’s Guide To Product Management, which was published in January 2015 by Grand Central Publishing in the US and Piatkus in the UK. He writes the blog I Manage Products and weekly product management newsletter PRODUCTHEAD. You can find him on Mastodon, X (formerly Twitter) and LinkedIn.

Leave a Reply

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