Podcast: Learning Product Leadership

I’ve just been on Ross Webb’s new Product Coach podcast talking about learning product leadership. You can listen to it on the widget below or over on on Podcast.co. A transcript is available after the break.

We cover a fair amount, including:

• why I think 9 out of 10 recruiters haven’t a clue
• should you hire product managers with market specialism?
• frustrations for new product managers
• does following a process drive product success?
• the skills and abilities of a product leader
• getting the non-tech parts of the organisation to buy into product
• failing versus learning
• time management: personal, project and roadmap
• a quick way to organise your personal priorities
• why you need lots of tools at your disposal
• the tension between product manager and scrum master / delivery manager
• characteristics of a great product leader
• me saying “yeah, yeah, absolutely” a lot

If you fancy a chat about any of the topics we discussed, please feel free to get in touch with me.

Transcript #

[Ross Webb] Welcome to the Product Coach Podcast Series for product leaders. Today we’re extremely lucky to have with us Jock Busuttil, and Jock is an author of a great book on product management which I really enjoyed called, “The Practitioner’s Guide to Product Management,” as well as a highly in demand speaker, and he also runs his own business called Product People. Jock, welcome to the podcast.

[Jock Busuttil] Hello.

[Ross Webb] Thanks so much for joining us, and I guess one of the questions people must be having right now after listening to this intro is, how do you find the time to do everything you do?

[Jock Busuttil] Well it’s kind of, it sounds like a lot of things. In reality, you kind of time box things. So, when you’re doing a speaking engagement, it’s something that’s gonna take up a bit of time to do the preparation, write the talk, usually something that’s kind of relatively top of the mind, so I try and do something fresh each time. But then the actual giving the talk is usually quite a quick affair. It’s kind of out for the day, give the talk, and then come straight back again. So that’s not too much of a problem.

And in terms of the other things, I mean, running Product People, I mean, there’s probably a lot more I could be doing, but certainly just keeping the admin to minimum, to sort of keep it ticking along it’s relatively straight forward. I use lots of, kind of online tools, like FreeAgent and so on, to kind of make life a bit easier for me. But also, the amount of day to day stuff that you need to do to keep a business running actually can be quite minimum if you keep on top of it and do your bits, little and often. And as for the other stuff, it’s essentially filling the time where available to help people out and sometimes that’s going to be for a few months at the time, sometimes it’s for an afternoon, and anywhere in between. So, you know, it’s just a kind of, you slot in things as you have time available. It’s not too much of a problem.

[Ross Webb] We’d love to get your view of that. Talking to a lot of recruiters, they’ll go, “we see a lot of job posts on LinkedIn “and you’ll see things like, “‘Looking for ” ‘product manager in FinTech,'” you know. What do you think about, you know, product managers who have got the great broad ability and have delivered good products in,

[Jock Busuttil] Yeah, yeah, yeah.

[Ross Webb] I don’t know, it could be anything else, HR software, and now they’re looking at moving over. What do you think?

[Jock Busuttil] I’ve got a fairly strong view on this only because I’ve kind of been on both sides of the table, both as a person being recruited and person recruiting, and it always slightly annoys me because when people are saying that you need to have, you know, you need to be a tenure experience product manager and be expert in FinTech or HR software or whatever, ’cause half the time, they’re asking for specialism in an area that didn’t necessarily lend itself to, you know, there just simply hasn’t been product manage in there for long enough to get the kind of levels of experience necessarily these companies are asking for. So, on the one hand, as a recruiter, you are kind of very much limiting yourself down to a very, very small niche pool of product managers who combine both the product managing experience you’re looking for and the main knowledge.

Whereas, what I would say is a far more useful thing is, product managers by definition are agnostic because even between two products in the same market sector, the dynamics of those products, the business model for those products, the situation each company is at, the maturity of the product, all these different things, all these things are different. And as a result, you kind of look at these two products almost as being completely different and you’re gonna go into a new job in that particular area and learn all this stuff. You’re going to learn about the market dynamics and the context, and what’s working, what’s not working, and, you know, what your competitors are doing and all that kind of stuff, and you’re going to immerse yourself in all this knowledge as part of the first couple of weeks to a month of working in that particular company.

And, you know, with maybe some notable exceptions, I think if you’re going into a really kind of high-engineering, you know, like semiconductors or something like that, where fundamentally you probably need to be a doctor, you know, to actually kind of understand the kind of problems you’re trying to solve, let alone kind of product-manage it, you know, or genomics, or even things like that. With those very technical, notable exceptions, things like HR software or CRM software or FinTech software, fundamentally, if you’re able to understand the problems your users are having and can articulate those, then you can start to solve them.

I don’t think there is a huge amount of mystery around understanding market dynamics or understanding what stage a company’s at and what they need to do, because you know what? There’s only a few kind of archetypes, really, for types of business, whether it’s a marketplace model and whether it’s a compliant app or whether it’s, you know, services-driven or whatever else. And so, as a result of that, it just really doesn’t matter if you’re new to that particular market. You’ll learn it, you’ll get up to speed. Any decent product manager is going to get up to speed on things really quickly.

And so, it always kind of annoys me when recruiters are, you know, putting this down as kind of a must-have experience in a particular area, ’cause all you’re doing is you’re just turning away really, really good candidates who might bring a really helpful perspective from a different market that might actually be a solution to fixing the problems in that particular company. And so it’s just a loss, really, for the recruiters and the recruiting company to turn away such good candidates just because they’re making a criteria too strict.

[RW] Do you think that’s changing in the industry a bit?

[JB] I don’t know. I still think about 80, 90% of recruiters have no idea what product managers do. It’s a really depressing statistic, but seriously, about one in 10 I speak to actually has a clue. And I don’t mean to be down on recruiters, but the number of times you get approached on LinkedIn or something, it’s like, “Hey, here’s a great role for you “because I did a random keyword search “and I think you’d be fantastic at,” looks at notes, “PHP development,” and go, “Well, okay, yeah, sure.” I did that in like 1999, okay, so you’re only a millennium out, but yeah, sure, I’d be, I’m sure I’d be perfect at it. Why not?

[RW] Give me another thousand years and I’ll get back to you.

[JB] Exactly. I mean, I don’t wanna characterize every recruiter as being the kind that chucks spaghetti at the wall to see what sticks, you know. But there’s a lot of recruiters out there who are simply playing the numbers game because that’s the way the incentive’s set up. If you chuck enough CVs at a company, eventually they’ll hire one of them. Whether it’s a good hire or a bad hire is a different matter entirely, and they’ll get a commission.

There are, admittedly, other recruiters who are a bit more ethical and maybe a bit more concerned about whether they’re actually doing a decent job for both the hiring company and the person they’re recruiting, and they do a much better job of actually understanding whether that person would be a good fit. For them, I say, you carry on doing what you’re doing, because obviously they’re the people who get referred and recommended within product managers and by-product managers, so it’s one of those things.

But yeah, I’d say the vast majority of recruiters just don’t really get it still and, as a result, it’s really difficult for them to kind of get the right candidates, and that’s why they’re not advising these companies to say, look, just don’t bother putting these criteria about FinTech or market domain experience because it’s just not necessary.

[RW] That’s a great answer. I come across it all the time myself, so, thanks for sharing that.

[JB] That’s all right.

[RW] You know, you do spend a lot of time coaching people and a lot of, let’s say in the Agile environment, having an Agile coach, Scrum coach is a fairly accepted thing in digital product. Do you think product coaches are getting more and more accepted? How do you see that changing over the last couple of years?

[JB] Well, it’s kind of difficult to tell. I see a regional demand for product coaches simply because I see the kind of work I’m being asked to do. But then again I’m skewed because people don’t come in and ask me for help if everything’s fine, you know? They only come in when there’s a relatively junior team, perhaps with no senior product experience in an organization because they’re just establishing themselves.

So, maybe, maybe if there is, if there is a trend towards more companies establishing product teams, multidisciplinary product teams, you know, with product managers as well as Agile people as well as developers and user research and so on and so on and so on, and designers, and so on and so forth, if there’s more companies establishing those kind of teams within an organization, then there is probably increasing demand for coaching at the moment simply because they don’t necessarily have the skills in-house to be able to help coach or manage these aspiring product managers.

‘Cause if they’re kind of starting from ground up, you know, they might’ve got a bit of training here, they might’ve read a couple of books, but essentially, what usually tends to happen is somebody’s told, “You’re now the product manager, “go and figure it out.” You know, and that’s changing, it’s not necessarily the case across the board, but it certainly is still happening to such an extent.

So, you know, one of the questions I tend to ask when giving a talk in the beginning is, “Hands up, who are product managers,” and you got some people sort of putting their hands up and down because they’re not quite sure whether they are or not yet. You get some people will sit there and ask you of a follow up question. Say, well, know you, “how many of you knew “what a product manager was before you “were made one?” And again, like, you only see a few hands going up because quite a lot of people are smiling and saying, “yeah, I just got made product manager “on Tuesday and I have no idea “what I’m doing,” you know.

And it’s kind of funny that people aren’t put off by that. But at the same time, it’s still happening a little bit too often and so, people kind or take initiative. You know, the good product managers are the ones that go out and figure it out for themselves and go and listen to podcasts like this or read books like mine or whatever. And there’s plenty and plenty of good stuff out there that people can read which will help them figure out what it is this thing called product management and what on Earth they should be doing on the day to day basis.

[RW] That’s a great answer and that really leads me to my next question is, what do you think is most frustrating them, for people new to product. I mean, you mentioned where you might get thrown, or get, Tuesday you’re the product manager. Oh by the way, on Wednesday we’re gonna send you on a two day Agile course in it. You’ll essentially come back just with a glossary terms, but anyway, that’s it.

[JB] Yeah.

[RW] Yeah. What a frustrating thing for those people, yeah.

[JB] Ah, crikey. So, on the one hand, ah, it’s, you get pulled in lots of different directions and particularly at the beginning when you don’t really know which side is up and you are still trying to kind of find your feet. On the one hand, you’re probably get put in some kind of Agile course and if you do, like, a certified Scrum product owner’s course or something like that, then you’ll go through and you’ll learn about how to do Scrum and you’ll learn about the product owner’s role within that.

And that’s fine as a starting point, but then the problem is that, particularly the company that’s, you know, sent that person on the training, they’re now under the impression that this person is a product manager and completely after two days worth of training. And this is the problem because in terms of being a product owner there are some specific things that you do, you fulfill, as a product owner as well, but this is just a small part of what it means to be a product manager and I think that there’s very few people necessarily who are able to articulate that to somebody joining as the first product manager if they’re not necessarily experienced in that themselves.

They don’t realize that product management isn’t actually about managing product. It’s about managing people. And as a result, I think probably the most frustrating thing is this, there’s nobody, you know, quite a lot of these people starting out their roles in product management and there’s nobody there to help them to figure out what it is they’re actually supposed to be doing and being mislead possibly into thinking it’s just being a product owner in the Scrum sense and I think that can be quite frustrating because then somebody comes along a little later and says, “well, you’re “only doing this. “When was the last time you went out “and spoke to people who are your customers “who used it?” And things like that. How do you do user research? Oh, you don’t do that.

Or, you know, because the Scrum guy doesn’t talk about user research because that stuff happens outside of Scrum, you know. Or the intangible things, like how do you convince the stakeholders to let you get on and do the right thing for your product. What is the right thing for you product? I think it’s all these unknowns at the beginning that’s probably the most frustrating thing because, particularly, I think product managers almost get looked up to being people who are supposed to handle the answers and sure they don’t have them to begin with. They need to figure things out and they will make mistakes and they’ll need to learn from those things, but that’s part of the learning process.

[RW] In coming to product, do you think people say coming from project or BA or tech tend to be more successful?

[JB] Difficult to say. I honestly don’t have any firm idea. I would say, it’s a tricky one. I think particularly people coming from the very process oriented disciplines, whether it’s project management or other things where there’s a very kind of well defined way of doing things. I think there’s a danger. Not always the case, but there’s a danger that they might fall into the falacy of believing that the process is the thing that creates product success when in fact, it’s not. It’s ensuring you have as much feedback and learning as you can get as you’re going along and making sure that you have as many opportunities to learn about your users and what works, what doesn’t work as you’re going through the process of developing a product.

All the process in the world will not make a good product work. You can iterate in Scrum as many times are you want but it won’t necessarily make the end result any better unless you’re actually understanding the needs of the users and how best your product should be designed and be built to address those needs. The process itself is nothing that’s going to bring any success.

So, if you’re coming from a background where actually everything you’ve been taught from til now has been, the process will keep you safe, the process will give you control, the process will give you a good result, then it’s a very difficult thing to sort of deprogram that a bit and say, well, actually no. The process is the servant of the team. If the process needs to change because it needs to change and it will work better for it, the process should change. It’s not, the process exists to provide repeatability and consistency, but if the thing you’re working on is continually changing and inconsistent, you’re not ready for that consistency and repeatability yet.

So, the process needs to adapt to whatever it is you’re trying to do. So, I think getting that flexibility mindset into people who come from the very process heavy background can be tricky, but at the same time, there’s many, many, many people who make that jump across and just go, “oh fantastic. “I’ve now got the freedom to apply process effectively “in the places where it needs to be “and to have the freedom and flexibility “to change it where we need to, “as long as it’s done in a way “that helps the team to deliver “what they’re delivering.” So, I think there’s pros and cons. But like I said, there’s a danger of falling into that falacy that process is a the path to success.

[RW] One of the questions I like to ask just to test that is, you know, when I’m brought in, I’ll ask the question really quickly to see how flexible people are, how well they can deal with ambiguity, is to ask a question like, “okay, “how do you guys feel about “why we do two week spreads, “how do you feel about that? “What if we move it to one or three?” Just throw that out and it’s really interesting to see kind of the,

[JB] Yeah, yeah.

[RW] how people either dig in and it’s, “well, that’s “how we’ve always done it,” or, “we …

[JB] Yeah, yeah, yeah.

[RW] “… shouldn’t change it now because,” you know. We’ve set up the ceremonies. We called a meeting.

[JB] Oh exactly, yeah. The ceremonies now drive the team rather than everything else

[RW] Yup.

[JB] and if that paints us into a corner, then so be it. I went to work at one place which will remain nameless where I think I spent the first month just trying to get people to allow you to move some furniture around. All I wanted was to get my team to sit together and honestly, it was like, don’t touch my stuff. It was like having an office full of the character from Big Bang Theory, Sheldon. It was like, “oh my goodness, mate, “don’t touch my stuff, “that’s my spot.”

And so like, in all honesty, one morning I came in about sort of six in the morning, before anyone else was there. I nabbed kind of a charlie from the maintenance guys and then literally shifted the room around myself and then, you know, came in later, and everyone’s, “uh, who’s moved my stuff?” And I’m like, “no idea, it was like “that when I came in,” and then got on with my job.

[RW] Ah, I love that, that’s great. Because you don’t know there’s an open plan environments, or hot desking.

[JB] Yeah. I’ve worked in a couple of environments that are super into hot desking. We don’t have places. We don’t sit there. I was like, okay, and we also don’t collaborate with the people we need to talk to every single day.

[RW] Yeah.

[JB] I mean, hot desking is fine if genuinely people are not in the office every day and there’s a need to shift people around, but to be honest, when you’re working amongst this with a new team, you’re probably gonna have a team of about eight people who are gonna be sitting together and the team probably won’t change for at least a couple of months.

[RW] Yeah.

[JB] So, a couple of people might come and go or might not be in one day or another, but that doesn’t really hot desking, you know.

[RW] Yeah.

[JB] And with the greatest love and respect for many wonderful developers I’ve worked with, some of them just have so much crap on their desk, there’s no way they’re gonna clear every day. Which is fine, but you know, so, there’s a little bit about that, but in reality, it’s far more important to think about the people loving the furniture and the lay outs. I mean, if you can get the people next to each other, you’ve got a mixture of disciplines whose ideas can spark off each other and people are able to share different perspectives and genuinely have an interest in what each other are doing rather than having all of your developers piled off in a corner somewhere with headphones on and they never speak to any other disciplines and so on, except when they’re forced to.

You know, that, the multidiscipline, the kind of collaborative approach is what we’re trying to get to, because realistically, you can’t make a product without each of those disciplines and skills coming into play and having those people talking to each other and saying, this is kind of tricky, this makes it all, or what happens if we try this, why don’t you and I go and sit down together and we’ll scribble some ideas down and then maybe we’ll bring some prototypes back to show the rest of the team. You know, that the kind of fluidity of working and I want those little, mini, sort of mini sort of heads in pairing to happen or that kind of thing.

I think essentially the way to kill a product, that is to force people to have all hands meetings every week, which don’t achieve anything, because three quarters of the people are sitting there asleep and the rest of them are just not interested anyway and could be thinking what I could be doing more usefully with the time. So, be focusing again on the people. Focusing on what’s gonna get them to spark off each other I think is far more important than necessarily who’s got more size of desk.

[RW] Ah, I couldn’t agree with you more, but you know, you’re talking about people. I always talk, you know ’cause there’s so many terms, product manager, head of product, product whatever.

[JB] Yeah, yeah, yeah.

[RW] I like to talk about product leadership because I think all those roles are leadership roles depending how you define leadership and I think, you know, that makes me really want to ask you, how do you see product leadership or a good leader and what are the, I guess, what are the skills and what are the abilities that a good leader should have in product?

[JB] Oh, very hard. It’s a very hard thing to kind of put your finger on. Or at least I find it very hard to put my finger on. Think about what I’m actually saying.

[RW] Sure, sure.

[JB] I mean, to be honest, I think even a brand new product manager needs to show some element of leadership, so it’s not even something that you want to even ascribe to senior roles or head of product roles or that kind of thing. Leadership starts as soon as you’re working in a team of people and when essentially the product manager on that team is saying, “this is “the goal, this is the product vision, “this is the problem we’re fundamentally “trying to solve and this is why it’s important “and this is why it matters.”

That’s kind of the beginning of leadership, because what you’re really trying to do is get a number of people of different background in your team of different abilities, of different disciplines to all come together and agree on a particular goal or outcome for this product or a particular problem you’re trying to solve, and to come together in a way that they can work together to build something that will ultimately solve that problem to a greater, hopefully, or lessor extent.

And getting any group of people just to agree to do something together can be very, very difficult and so you need that leadership to be able to not just tell them what to do, because that’s not gonna work, but instead to think about showing them why it’s important and showing the people for whom it matters, mainly the users and customers whose lives will be affected in some way by use of this product. And that, I think, is kind of the beginnings of leadership, to exhibit that kind of leadership.

As I said, it’s not something you get. You don’t have necessarily in your authority. You’re almost certainly not the direct line manager for all your different groups of people on your team and you’re certainly not gonna get great results if you’re just putting your foot down and telling them what to do every day. Instead, I think it’s about, almost this concept of serving leadership. I forget who coined the name, but it’s something that goes, you know, way, way, way back to, even kind of, sort of military kind of origins, possibly.

Again, forgive me. I don’t have the references off the top of my head, but this idea of where the best way to lead is to serve the needs of your team. In other words, putting them in the position, those people on your team as experts, in the position where they can do their job to the best of their ability and essentially working to give them guidance to remind them what it is they’re aiming for and to point them in the right direction, but absolutely not to dictate the route by which they get there.

In other words, you’re telling them the objective, not the route to get there. And if you can put yourself in that position where you can gain the respect of people by understanding of each other in the very beginning, understanding what it is that they’re doing, what’s special and unique about their individual roles and specialism and expertise, and getting the best out of each of those people, then saying this is what we’re trying to get to and this is why it matters, then hopefully you can get to a position where actually you almost have to do no leadership at all.

The team will lead itself with you just gently course correcting here and there where needed and maybe broadly focusing on the bigger question such as how do we ensure that the senior management team will aboard, is supportive of us and will allow us to continue working on this. Or how can we start looking at the next big problem to solve for our users. You know, that’s maybe a better way to think about product leadership, which is kind of almost get your team into a state where they lead themselves so that you can focus on some of the bigger questions or the more strategic questions.

[RW] That’s a great way of looking at it. It does make me think of one thing. So, sometimes a lot of the people that buy into product are in, let’s say, in the tech leadership in the company and not necessarily in, at the CEO level or maybe, let’s say you’ve got operations and I believe product goes over marketing, product, sales, tech, HR, everything. How do we get people who aren’t in tech to buy into product as well from a leadership level?

[JB] Oh, another tricky question. I think it really depends. I think it’s partly about understanding about dynamics in the company. So, what I often suggest to product managers, they do something, almost like a stakeholder map or an empathy map, and so, you almost profile the main influencers or the main people who have authority and that do have some kind of direct influence over your product and kind of understand what are their needs and desires. Try to understand where they’re coming from. Try and understand what they’re worried about. You know, things that they would express concern about. Things that they would maybe be worried about but wouldn’t tell anyone about. You know, try to almost read their minds a bit of all the various different characters and stakeholders that you’ll have within your company.

And the purpose for doing that is really just to understand better almost why they will say certain things or why they will be in favor of one thing or another. So for example, if you know that one of the sales team leaders is under a really big pressure to kind of hit their targets and they know that they can sell a lot more of this more established, mature product over perhaps your newer, more sort of less tested or less tried and tested, maybe, product, they’ll probably go back into their comfort zone because fundamentally they’re being targeted on hitting the numbers and they’ll hit the numbers in the way that most confidence do so.

So if they think we could take a risk and spend more time trying to sell this new product, this new untested product in the market, or we just need to hit our numbers, let’s focus more on spending our time on something that’s tried and tested, but we have a reasonable idea how our closure rates going to be and how we’re going to sell this thing, and you know, it’s understandable to say, yeah sure, they’re gonna take that route if that’s the pressure they’re under and that’s what being asked of them.

So, then your question as a product manager is to say, well how can I get them into a position where they’re equally as confident if not more so to sell this new thing than the tried and tested thing, and if you can get that right, then you should hopefully be able to get by. you should be able to demonstrate to those sales leaders, look, you can sell this, you’ll get better results and you’ll get better margins, which means you’ll hit your targets more easily, which means you’ll actually be doing less work for better results.

That is like one example of where you might kind of try and work really hard to bring someone round to selling your product in combination with, or instead of, other things that are maybe less useful to focus on. But really, the fundamental principle is kind of understand what’s driving these people, what it is that they really need. And if you can bring them around and turn them into positive influences and supporters of your product, then great. If you can’t and they just never going to, for idealogical reasons or whatever, just never get on board with what you’re doing, then essentially, figure out ways in which you can minimize their influence, so that essentially you’re not going to be, you know,–

[RW] Well, yeah, exactly. It’s obstructed in a way. You’re just reinforcing that way in which you can allow your team to get on with what they’re doing. And not everyone will be brought around. And so, I think that’s that kind of a tricky thing to figure out and learn and I think it gets more and more of a challenge for product managers, particularly as maybe their product becomes more successful, more intrinsic to the company’s bottom line. Or maybe if they become more senior within your organization, maybe become responsible for a larger number of products across different portfolios. You know, being able to think about and navigate that, I think, is a really different thing and that’s very much, I think, one of those leadership topics that comes up over and over again, which is how do I influence my senior management team or board.

– Sure, there’s a lot to unpack there.

[RW] Yeah, yeah, yeah.

– Sure, you know, maybe you went from the leadership thing just for a little bit. Failure.

– Okay.

[RW] A lot of people say they want to let their team fail and they’re gonna let their team fail for a bit and whatever. What’s your thinking on that.

[JB] Failure’s not the important bit. Learning is much, much, much, much more important. If you fail and don’t learn anything from why it failed, then all you’ve done is fail. Even if you’re successful, you won’t necessarily be 100% successful and you can still learn stuff about how to make it better next time. So, I don’t think failure, which I think with concept of fail fast, you know, whole kind of lead start up idea that was popularized, I think people focused on the wrong word, which was failure, and instead should be thinking about the learning that comes with those particular experiments.

So in other words, what you’re really saying is you’re setting up a particular test or experiment and that experiment is there because you want to learn something about the outcome and if that test succeeds, then you learn something hopefully, and if that test doesn’t succeed, you should also learn something, which may be to discount a particular option or to just say, maybe we should refine our approach in a different way.

Or maybe, you’re even deliberately testing for failure. So, we think this shouldn’t work. Let’s check if we’re right. So, this concept of failure is kind of not the important thing. It’s just like almost a binary number. A one or a zero that comes out of a particular test. It either worked or it didn’t. That’s almost not the point. It’s what do you learn from the outcome that then informs what to do with your product.

And I think if you think about it more on those terms and basically increasing the frequency with which you can run those kind of experiments with a predefined set of what might come out of this and what we could learn from this, as long as you’re going and you’re learning something useful and valuable that can inform what direction your product’s gonna take and as long as you do that as often as possible, then you’ll be fine.

And then it’s less about failing because you’ll be doing that, so you’ll be trying out 50 different things during the day and you’ll be picking the ones that work and discard the ones that don’t. I mean, talk to any developer, if they’re trying to crack a really particular difficult bit of code, they’ll try out several different things. They’re not gonna, let’s say, broadcast the fact that they’ve tried out seven things and only on the eighth find it actually worked, because you bought the batch is the eighth time it worked, yeah.

[RW] Yeah.

[JB] And sitting with teams. We’re sitting with teams trying out products. I mean, you’re not aiming to fail really big.

[RW] Yeah.

[JB] Because no one wants to make an absolutely pig’s ear of something and broadcast how, look, look how well we failed. No, no, what you’re doing is you’re doing lots of little things and you’re trying them out. You have several things a day even. So, that by the time you actually get to the thing put out there as like your proper real release, whether you do a weekly release, a daily release, a monthly release or whatever.

By the time you get to that point, you hopefully tried out so many different permutations that you’ve got to the point that you know, you’ve got confidence that that thing’s gonna work because you’ve basically knocked all the problems out before you got there. And it’s not to say that the thing you then release will itself be bug free and completely 100% perfect. It won’t be, but you will have gotten rid of most of the obvious stuff before it gets out into the market and that’s really what we’re trying to do. So, all it is is really the more experiments, the more tests, the more things you can try out to either increase your learning or to check whether what you think is the case is actually the case, the better. And that’s all we’re really talking about. Learning from those different experiments.

[RW] Maybe we should stop talking about failure and just focus more onto learning.

[JB] Yeah, yeah, absolutely. It’s that failing is just an outcome. You know, you could call it one and zero or one or zero and it wouldn’t really make a difference. It’s just an outcome. What is important is what you learn from that particular outcome and what it is that it would do to inform your product’s direction.

[RW] Ah, that’s really helpful. So, and that leads me onto the next thing that none of us have got enough of, which is time and a lot of the time in Agile, people are concerned about product always being focused on delivery and deadlines and the business insists on delivery and they’re like, we Scrum, we Agile, you know. What are your thoughts around that.

[JB] I think there’s three different areas and I’ll try and remember them so I don’t like to forget off–

[RW] Sure we’ve talked about–

[JB] It’s like kind of your personal time management, okay. And as a self confessed procrastinator, this is something you just need to sort out and find ways of managing your time. I almost won’t bother going into that in much more detail because partly I’m gonna talk about in in our chapter in the book, but also because people know how to make themselves effective and there’s lots of different techniques for doing that and not everything will necessarily work for all people because everyone’s different. So, your personal time management is kind of one area. You need to divide your time up and focus on what is most urgent and what is most important right now.

So actually yeah, throw away tool, two by two grid. More important to the right. Less important to the left. More urgent to the top. Less important to the bottom. And then plot out all of the things that are on your plate at the moment on that grid and then focus on the top right grid, which should hopefully be most important and most urgent and work downwards from there. That’s an easy way to clear your head if you’re just rushed off your feet, okay.

So, that’s probably all I want to say on that personal time management stuff because there’s plenty more out there that people have written that’s far more interesting in their forum than anything I’ve got to say on the topic.

The other two aspects, I guess, of time management, or so, the big one is kind of product delivery, which is when will this thing be ready, when will setting a fixed, firm deadline. We will release this product on the 27th of November, blah. You know, whatever it might be.

So, first of all, I think big bang launches are a terrible idea because it places almost too much pressure and it almost saves up or it has a tendency to push people away from that thing we’re talking about, doing lots of learning and little and often, if everyone just basically, let’s get it all done and we’ll learn about things when we do the launch, then all you’re really doing is you’re setting yourself up for a really big failure because you haven’t actually shaken out all of these problems before you got into that point. So, I’m not a big fan of big bang approaches. Big bang launches.

The second thing is what is the reason for that particular date and time, okay. Most of the time, I’d say it’s gonna be because somebody on the board or somebody senior has promised that date and essentially, if you don’t deliver on that date, it will make them look bad and that will have repercussions. If there’s nothing really much more to say about that date other than somebody is set in stone for no other reason than because they felt like it that day, then it’s a bit of a non-date. It’s artificial.

You need to kind of figure out a way to get away from that because the product will be ready when you know it’s ready, because you’re seeing it pass lots of tests and you’re seeing it meets the needs really well of the users you’re expecting to be able to use it to solve a particular problem. That’s when you know you’re product’s ready and that’s when you know you should be putting in front of people. So, these artificial deadlines need to go away.

Now, whether or not that happens, by your influence or whether you can convince your board that it’s a bad idea or whether you can maybe somehow gain control through actually over-communicating about your progress. To say well you know what, at the beginning, we don’t know when we’ll be finished because we haven’t started yet. Halfway through, we have a better idea. Three quarters of the way through you have a really good idea. And as we get close to the end, we’ll be able to narrow it down to an exact date, but until that point, our understanding of the problem, how difficult it’s going to be for us to solve is only going to increase as we go through this project and it’s only as we go through that process that we can get to a point of knowing when we’re going to be able to finish.

And so as a result, we will set the date when we are confident enough to say we’re gonna hit the date, okay. But setting a date in the very beginning before you’ve even done anything, when you know nothing about the problem or how you’re gonna solve it is pretty crazy, yeah. So, that you know, I’d say the date will emerge as you go through a particular project.

Now, there’s a bit of balance to that because obviously you can’t have a team that’s trying to solve every problem in the world and it’s kind of, the project scope is almost broadening and broadening and broadening and so there never will be an end date because the project scope is changing all the time. If, however, the scope of the product is kept in check, you know exactly which specific niche group of users you’re catering to to begin with and your objective is to get to something that solves at least one decent problem in its entirety for that small group of users, then you’re keeping focused, you’ll get to that point much more quickly, and then you can do further iterations to address more problems for more users. So, a focused approach and then the date will emerge.

If you’ve got this kind of broad scope creep going on, a date will never emerge, whether you want it to or not. So, with that kind of aspect, and kind of tied into that, because some times there are legitimate hard deadlines, okay. Sometimes if you work in a particular industry, there’s a trade show that you just have to have a product there to exhibit up, otherwise you’ve got to wait til next year, sometimes you need to do something to make sure that you have something to show and if you can’t fix, if you can’t move the deadline, then the scope has to change.

The ambition you have for your product has to be sort of pulled in a bit, reigned in a little bit. But broadly speaking, those really hard fixed deadlines that are either regulatory or sort of events you cannot miss are relatively few and far between. And so as a result, you shouldn’t really be arbitrarily kind of putting in place a deadline until you’ve got a reasonably confident sense that you’re actually going to hit it, which only comes later on on the project. So, that’s that kind of thing.

Tied into all of that is the road map and kind of the sort of longer term planning. So, what happens after this project, what happens, what do we do next? Again, I don’t like this idea of Q1, Q2, Q3, Q4 kind of roadmaps because you just don’t know when things are going to drop and you don’t know how easy or difficult a thing’s gonna be. You need to have the flexibility to be able to change things around if something comes up, because you’ve learned something or because something’s changed.

So, I like to think instead of now, next and later as the three different categories for a road map and this is something that, again, I think people like Janna Bastow and Simon Cast from both Mind The Product and ProdPad, they’re the people who’ve kind of really switched me on to this. And this idea that you’ve got lots of certainty about what you’re working on right now, the one to two things your team’s working on right now, you’ve got probably a pretty good idea of what you’re gonna work on next, and again, it’s going to be one or two things that you know your team will probably tackle next. It may change, but they’re reasonably certain and then pretty much everything else is gonna be in a later column because you’ll get to it when you get to it and that column’s gonna change a lot.

And to be honest, that’s how you should start your road map because you’ve got certainty that we’re working on right now. You can have reasonable certainty that we want to work on next and much less certainty about everything else. Everything about time and shuttling of deadlines.

[RW] That’s brilliant because, I mean, a lot of the time with people, let’s say, who are very experienced with project management or being in business and they want specific things, they struggle a little bit with ambiguity.

[JB] Mmh.

[RW] If you tell them that we’ve finished this sprint on the 17th of September or this feature on the 17th of September, on the 18th of September, they’re gonna expect to be sending it.

[JB] Yeah, yeah, yeah.

[RW] It can be tough to communicate it to them effectively and yeah.

[JB] So, I was going to say the flip side to this is the fact that other bits of the organization do need to plan around you and I think this is the bit where people get confused. I think, essentially doing release planning at an appropriate time is absolutely fine providing people know how certain or confident you are about those dates. So for example, if you’re doing a kind of thing where actually you do need to be planning two or three years in advance, then that’s fine as long as everyone has got the flexibility within their planning process. Say well, what happens if we’re six months early or six months later than expected? How do we build flexibility into our planning?

However, if you’re looking at say, we’re going to release in six month’s time, yes you do need to kind of get the marketing team briefed. You do need to potentially to get the sales team briefed if you have one. You need to think about maybe getting some PR, particularly if it’s a really big release for your company or whatever else. But the point being is that you need to be able to start planning ahead for those things really at a point when you’re confident that this set of things is going to happen around those times.

Now maybe you’re lucky enough that this set of things you need to do for a maybe more involved launch is as it were relative. So basically, it doesn’t matter when you start doing this set of things, as long as you set them off when you’re ready to do so, you’ll hit your date. They’ll happen in sequence as long as you start two weeks before you’re actually going to launch. And in those situations, you can do kind a reasonable end to planning.

Say, what is going to be the set of things we need to do and who do we need to talk to, when, and do it in relative terms rather than absolute terms. But, you know, at the same time is it, particularly if it’s a first product or a very, not ground breaking product, but something that’s just a lot, have a lot of unknowns associated with it, so you don’t really know how long it’s gonna take and whether it’s gonna work in the first place. I think at that point, gradual release.

Just saying it’ll be ready when it’s ready, when it’s stable enough to put in front of real users, but hopefully should be as soon as we can. Take the time testing and learning from small sets of users. If we can at least gain confidence to the point whereby we’ve got a reasonable idea that yes, we think it will be finished by June, then you can actually do a bit of planning on that, but I think it’s all based on how much you really understand about the problem and your progress along the path to finding a solution. If it’s all uncertain, then how on Earth can you plan realistically. It is quite a tricky one.

[RW] Yeah.

[JB] And I think if you can impress that level of uncertainty on the rest of the organization, then maybe they can kind of help with that a little bit and adjust their plans accordingly.

[RW] Yeah, I think a lot of that goes back to the leadership, as well, trying to communicate to your stakeholders, especially on leadership teams. Keeping them up to speed. A lot of the times, people new to product tend to be, I’m gonna spend all my time just presenting. That’s like, well okay, forget the presenting. You’re gonna spend all your time talking.

[JB] Yeah, yeah, yeah.

[RW] So, that’s what you’ve got to do. That’s just, if you want to get on your side, you’ve got to communicate to them.

[JB] Yeah, yeah, yeah. Absolutely, it’s very much about communication. It’s almost overkill communicating.

[RW] Yeah. I worked with someone once who kept instructing, you’ve got to communicate to people once. Tell them what it is you’re doing. Tell them what you’ve done. Tell them what you just did. And then go back and I’ve seen that with people that I’ve coached where, you know, sometimes I get them to just send Google Forums saying, how was the presentation, kind of asking them, what did I just present to you, because you’re trying to get them to kind of say, what did you think that I just told you? And based on that, because it’s usually quite different to what you’d think,

[JB] Yeah, yeah, yeah, absolutely.

[RW] Building that up, it’s–

[JB] Yeah. Yeah, what did you, we talked about three things. A, do you remember any of the three things and B, did you understand what those three things even meant, you know.

[RW] What do you think the three things were?

[JB] Yeah, yeah, yeah and then there’s the willful stuff which is what people go, “well, I heard you say “we’ll be releasing next month.” Head of sales. No, I didn’t say that.

[RW] Nope.

[JB] That’s what I took away from it. No, no. I really didn’t say it.

[RW] Sure.

[RW] Well, you’re in the office.

[JB] Yeah, I know and I spoke to someone who does the cleaning and they said that you’re definitely going to release next month.

[RW] Yeah, I’ve been in nowhere, but didn’t you say–

[JB] We’ve all been there. We’ve all been there.

[RW] Keeping along the whole communication thought that we’re busy chatting about, just Scrum masters and product owners, and I’m not trying to get too much into the whole Agile methodology, slash religion of,

[JB] Yeah, yeah, yeah.

[RW] the 100% the right way to do it, but I’d love to know your thoughts on Scrum masters in general and Scrum masters in relation to product owners and managers and how they can work really well. I always thought Scrum masters are a luxury, you know. And I’d love to know where you’ve seen them really work, where you’ve seen them not work, how product managers can help their Scrum masters and vice versa.

[JB] Well, it’s great. So, we, I think I said a little bit earlier that the role of Scrum product owner is just one bit of what a product manager does, so I think we don’t necessarily need to reiterate that.

[RW] Sure.

[JB] In terms of working within a particular Agile process, so, stepping back a little bit and just saying, first of all, as a product manager, methodology is like a tool kit, so how you choose to tackle a particular problem or what structure you put around a particular task, whether it’s developing a new product or learning about your users or whatever, is essentially picking and choosing from a tool kit of these different methodologies.

If your focus is primarily on discovering user needs and maybe prototyping potential solutions, then you access that particular took kit to things you might use to do that. If however you’re well within the middle of some development work and you’ve got a reasonably good idea of what you’re doing, you have a pretty good idea of how you can go about and do it, you just need to get through that work, you’re gonna pick a different set of methodologies to help you do that as efficiently as possible. So really what I’m saying is whether you do Scrum or Kanban or Lean Startup or some variant or something you really just made up yourself, it doesn’t really matter because the objective of those methodologies is to help do things more efficiently and depending on the kind of task you’re doing, will dictate which tools will be the best thing for the job.

If you’ve got something that looks a bit like a screw, you probably want to use a screwdriver, not a hammer. So, it’s about picking the most efficient methodology or tool for the job.

So, as a result, I think product managers need to be reasonably agnostic about particular methodologies. Sure, they might have done some Scrum training and certification, this, that and the other and that’s absolutely cool, but assuming that everything looks like a nail and therefore needs to be hit on the head with a hammer or a Scrum isn’t necessarily useful either, because there are some situations where Scrum isn’t right on, so we need to adapt Scrum or quite heavily change it. And that should be fine. That should be, again, back to that point of not letting the process drive you. You should be at liberty to adapt the processes as you need the methodologies as you require to help you solve a particular problem.

So, one example, just very quickly is, say for example, the difference between Kanban and Scrum. With Scrum, even if you’re doing one week iterations, the frequency with which you can learn is going to be when you finish a Scrum. So, if you Scrum every week or if you Scrum every two weeks, that’s how frequently you get an opportunity to learn and bring that feedback back into the organization, because that’s really the very point at which you are releasing something out there for consumption.

Contrast that maybe with Kanban where there’s no concept of a time box. There’s no kind of concept like of week or a day or whatever, is essentially dictating how long it takes an item to move from the left of the Kanban board through different steps to the right hand side of the Kanban board, okay. And so, that time it takes is effectively the frequency with which you can learn and if you can get something from one side of the board to the other in a day, then you can learn every day. If you can one thing from one side of the board to the other in an hour, then you can learn every hour potentially, yeah.

So, you might want to use something like Kanban with a frequency of opportunity to learn is more frequent on things where there’s greater uncertainty, yeah. So you might not know enough about the problem or anything about the technology going to use to solve that problem. You might use something like Kanban in that situation because it maximizes or increases your frequency. Whereas if you’ve got something that’s much better defined and better understood, aye, the certainty is a bit greater, you might use something like Scrum because you can just rack up a bunch of stuff in the back log, assign it to the team for that Scrum and then they can crack on for that sprint, rather, and then they crack on get going on fixing, going fully different items.

So, if you’re, depending on the job or depending on the situation you’re in, you might choose one methodology over another. So, there’s that, but then think about kind of all these other methodologies in all the different tool kits and ways of doing things and then you suddenly start to realize that it doesn’t really matter which methodology you necessarily were trained on to begin with. You should always think about what’s going to be the most appropriate thing to use in the situation.

So anyway, that’s a bit of a digression, but to get back to the thing you asked about what’s your relationship between a product manager and Scrum master, well, the reason I kind of did that digression is because in governments where I’ve done quite a lot of work in UK governments, they follow an approach where they don’t really have a Scrum master because they don’t necessarily always do Scrum, so they have a delivery manager and that delivery manager’s role is essentially to be a coach for the team in the process in the way of doing things, but more specifically, to be able to help them to adapt to the process as needed, to suit the needs of the team, the problem they’re trying to solve, the characteristics of that particular problem, the environment they’re in, even the skill sets in the team.

And so what that means is you’ve got someone who like, hopefully the product manager, is conversant in a few different disciplines and can adapt the tool kit to suit the needs of the team and the problem you’re trying to solve. So a really good delivery manager or a Scrum master is someone who can help the team to work as efficiently as possible, and so that’s either going to be by saying, “well, what can we as a team collectively “do better in our retrospectives,” or might be about doing, literally, moving desks around to put one person next to another because they’re going to be talking to each other much more often during the course of this sprint.

And then, you know, gaining efficiency that way. It might be that they gain efficiencies by making sure that they will have maybe somebody who’s expert in legal stuff available in a couple weeks’ time when we’re likely to need that person. Or it might be that they go and talk to someone who’s maybe being a bit obstructive or is not being forthcoming in whatever information the team needs to do something and that person needs to go and be diplomatic and unblock those obstacles.

So, there’s a lot of overlap in some respects between what the product manager is gonna be doing for the team as the delivery manager or Scrum master should be doing with the team. I guess the difference is gonna be that the delivery manager is much more focused on the needs of the team, whereas the product manager is much more focused on the needs of the users. That’s maybe,

[RW] Mmh.

[JB] that’s not to say the team isn’t focused on the needs of the user. They are obviously, but it’s that kind of a healthy tension. So, the product manager’s gonna be, “oh, but we should be doing this, “we should be doing this, “we should be doing this,” because you know, we want to solve all the problems and build the whole thing.

[RW] Sure.

[JB] The delivery manager and Scrum master are saying, “well, sure, “but pick two of those 15 things you “want to do because that’s realistically “what we’re gonna be able to do “in the time available,” yeah. And so it is that kind of healthy tension between all the possibilities and what’s actually possible in the time available, you know, to kind of get a really nice team partnership. I think between the combination of the product manager and the delivery manager or Scrum master, if you get a really good partnership going on where they’re both serving the needs of the team, but they’re kind of focused on maybe different areas.

The product manager’s focused more on the stakeholders and the outside world and the Scrum master is more focused on the needs of the team and the inside world, then you’ve got a really healthy, a really solid team that will hopefully allow that group of developers, designers, user research and so on to really motor, because all of the obstacles are being cleared out of the way by this combination as pairing of the product manager and the delivery manager.

[RW] That’s really nice. I like that kind of positive tension of, you know, we’ve got 20 things to do, pick five.

[JB] Yeah, yeah, absolutely.

[RW] Bring up five devs or whatever it is.

[JB] I mean, yeah, there’s a lot this stuff. I mean, it takes a lot of digging to find it. Many, many, many examples of this really healthy working relationship dotted around through various blogs, additional blogs, on the various governments, UK government’s websites. It’s that they take a little bit of tracking down but I think if you go to blogs.gov.uk, you get a list of all of the blogs and you can actually search by different kind of subject matter and so, if you look up delivery managers in there, you should be able to find a few interesting things, insights and stories there because it’s, it’s that I was really, I had my eyes opened when I went to work in the Ministry of Justice several years ago and just really, really liked that way of working and it was something I hadn’t really seen working into that kind of level of partnership before.

[RW] Oh wow.

[JB] It’s something I really would recommend everyone gets a chance to experience at least once, because if you can replicate that in your own organization, it’s fantastic, and as you said, it’s an absolute luxury if you’ve got a Scrum master or a delivery manager to be able to do that kind of thing.

[RW] Wow, thanks. I didn’t expect to find an inspiration from government, but I’ll definitely be checking that out. That’s great. So, just one last question while I’ve got you, Jock. I’ve really been appreciative of your time. Really enjoyed this and I’d like to know what do you think of the characteristics of a good or great product leader?

[JB] So, we’ve actually, we’ve talked about a few of them already. I think communication is really, really, really important. The ability to articulate one’s self, whether speaking kind of face to face or whether writing stuff down in an email or stuff on a slack board or whatever. I think that is probably gonna be one of the most key skills that a product manager needs to do, because essentially, they’re a conduit for information.

You’re always taking information from lots of different people and you’re feeding out information, packaging it up to different people based on what they need and I think that ties onto the second thing which is also really important, which is the sense of empathy. So, that sense of being able to truly understand the needs of different groups of people, which is tough, because let’s face it, you are not everyone, you are not representative of everyone, you are not the same as everyone.

So, anything you can do to really think about things from the perspective of the other person is gonna be massively beneficial and whether it’s something as simple as saying, I’m gonna have a chat with this person. I know they’re busy, so I’ll keep it brief, that’s immediately thinking about their needs. Thinking about the fact they’re time poor and that they just want the highlights, but you still need to get across some key information to them that’s going to be really valuable to them.

So, just by entering that conversation with that sense of the other person’s needs in your mind, you’re already being a much more effective communicator because you’re cutting through quickly to what is going to be the most important thing. And whether that’s with one of your stakeholders, with your boss, or whether they’re people on your team or whatever else, or whether you’re communicating more broadly to your market, potentially, you’ve got to think about what it is they need from you and how that should affect your communication and that all comes back to the sense of empathy which you’re going to be using day in, day out within your team, with your stakeholders, with your users. With everyone who kind of is affected by your product in one way or another.

And I think without those two things, it’s going to really difficult for you to be a good, effective product manager. It’s not to say they’re the only two things you need, but certainly if you can be more precise with your communication, be more confident with your communication and enjoy it, I think that’s really, really important.

[RW] Jock, I think a lot of that goes back to what we were talking about, leadership. I don’t think you can really be an effective leader if you haven’t got empathy,

[JB] Yeah.

[RW] otherwise, you’re just a tyrant, really.

[JB] Yeah, precisely. And you think about yourself, not everyone else.

[RW] Sure, and again, you know, not putting, not being able to put yourself in your users’ shoes, which is so, so important. Jock, it’s been really great talking to you today. I massively appreciated your time. Before we hang up, I’d love it if you could just let the listeners know where they can go to find out a little bit more about you.

[JB] Oh, well, probably the easiest way is to search for me on Google. If you type in Jock Busuttil, and the surname is B U S U double T I L. If you need to replay that a few times, don’t worry. I get that a lot. You’ll probably find me popping up on LinkedIn. You’ll probably find my company, Product People Limited. And you can certainly get in touch with me via either of those ways. I think I’m on Twitter as well as @jockbu and so on, but there’s lots of different ways to get in touch and lots of ways, you can read my blog on imanageproducts.com and there’s a lot of stuff on there which kind of goes over and above what I’ve covered in the book.

And yeah, say hello. I get quite a few people, actually, getting in touch, perhaps because they’ve read the book and so they just wanted to say. I just, I certainly not going to name the person but I just want to say because this made me laugh so much, I got a message from someone saying, “I just wanted to know that I read your book and I’m pleased to say it was one of the few business books I’ve read where I didn’t want to open a vein after the first four pages.” That ringing endorsement was exactly the level of feedback I want from my book. So yeah, read this book. It will hopefully not make you kill yourself.

[RW] Is that the best?

[JB] That’s one of the best ones I’ve had so far, yeah.

[RW] Beautiful, yeah, that’s brilliant.

[JB] I like that a lot, so, yeah. I think on that note, that’s probably a good place to stop.

[RW] Great, and for people who might not have caught the top, there’s “The Practitioner’s Guide to Product Management.” So, Jock, again, thanks so much for being with us today. I’ve really appreciated your time.

[JB] And thank you very much for having me, Ross. A real pleasure.

[RW] Thank you. You have just listened to The Product Coach Podcast with me, Ross Webb. Subscribe to our podcast on iTunes or Google Play. And if you have any questions, feel free to drop me an email to Ross at product dot coach. Looking forward to hearing from you and looking forward to having you with us next time on The Product Coach Podcast. Bye for now.