Richard Rodger runs Voxgig, a company that provides developer relations (DevRel) tools and services. He kindly invited me back on to his Fireside podcast to chat about the similarities and common challenges in product management and DevRel.
We cover topics including:
» Learning product management by soundbite and from stories that gloss over the messy context has given a generation of product managers a superficial understanding of their craft.
» Why we’re finding it hard to communicate the value of our work to our bosses, and how we can do this more effectively by talking about not just what our team has done, but also what we chose not to do.
» How others in our organisation can insert their own narrative when we don’t communicate effectively (or at all).
» Remembering that people across the company usually don’t have ill intent towards you personally, they’re just set up to be antagonistic by the organisational structure, vague strategy and misaligned incentives.
» Stakeholders are messy, complex people (just like us). Don’t dehumanise them — listen and talk to them to understand where they’re coming from.
Show notes #
“You’re only as good as your last delivery”. This phrase may apply best to ambitious UberEats drivers, but when it comes to providing non-food based services, it also neatly fits in the DevRel (developer relations) and product management world. We’re joined once again by Jock Busuttil, for an update on his work at Product People, and to gain his thoughts on the wider product managing space.
The level of crossover between DevRel and product management means that we not only share our victories, but also our struggles, and Jock speaks to one of the most common problems he’s seen: people struggling and sometimes entirely failing to communicate their worth to those at the top.
Another issue – adaptability. Context is absolutely everything, and a solution that might have worked flawlessly for one client might be devastating to another. Knowing when to make adjustments and put the “rulebook” aside is a key skill, and one that the new influx of applicants to product management roles would do well to remember.
It was great to catch up with Jock in this episode, and hear what he’s been up to. We hope you enjoy it!
Transcript #
[Richard Rodger]
Welcome back to the fire side of the Voxgig podcast. It’s great to have you back talking about product management again.
Um, I have to say your t-shirt, which by the way, if you’re just listening to this reads Weyland-Yutani Corporation – building a better world or sorry, building better worlds. Yeah. That’s it.
Uh, you, you win the t-shirts today, I have say.
[Jock Busuttil]
Thank you very much. It’s lovely to see you again. Um, it’s been a while and thank you very much for having me on again. Obviously I didn’t put you off last time.
[Richard]
Well, you tried very hard, but, uh, you know, I kept kicking, but you wouldn’t go. Are you, are you, uh, are you building better worlds through product management? I hope so.
[Jock]
Um, I mean, it’s that kind of campsite mentality, you know, leave things in a better state than when you left them, you know?
[Richard]
Yeah. Yeah. Um, not something that software developers often do.
Oh, let’s refactor everything. Oh, everything stops for a month. We’ll refactor and, um, now it’s totally broken. We have to go back to the old version, uh, which I’ve done and I’ve seen happen more times than I care to admit. Okay.
So, um, yes, this is a podcast about developer relations, but we have to work with lots of different people and product management is a very important part of our lives because we’re supposed to be giving you feedback and all that sort of stuff. So I invite you on, um, just to get an, I guess, an update on where product management is now, um, how it’s progressing. And I guess we were talking about this a little bit before we started recording from the outside product management looks very mature and extremely well-organized.
Um, you guys seem to know your shit. You kind of know what you’re doing. Um, I remember doing some technical due diligence for VC a couple of years ago and product management people at this particular startup, uh, that was for series eight.
So things had moved along a bit. Um, they had analysed every feature literally on a value proposition level. Uh, that was pretty, it was pretty intense, right?
I’ve never seen anything like that elsewhere, but I mean, they were hardcore detailed analysis of the product. Um, I was like, Oh my god, I need to up my game here. Um, but yeah, I mean, everything looks rosy from the outside.
Um, but yeah. How, how is it in the trenches?
[Jock]
Well, it’s, it’s kind of, it’s so funny you say that because, um, we’re kind of having a little bit of a, uh, a crisis, um, probably overstating it slightly, but kind of, uh, it’s, it’s a kind of a com several things have happened all together at the same time. Um, and in some ways we’re a little bit victim of our own success. Um, uh, so yeah, so it’s kind of, let me put this in context.
So, um, we are, we’ve the, the job market for product management at the moment is an absolute bloodbath, right? And it’s partly, you know, you know, very, very superficially. It’s like, if you’re going to start off with layoffs in an organization, they always go for middle management and like product management is the archetypal middle management role where we’re a connector where we’re kind of a mediator between lots of different parts of the organization.
But I think the other reason why product management tends to get it in the neck at the moment is, um, organized. We’re still, and it’s funny you say that we seem to have our shit together because, um, we seem to not to be able to convey what value or not. We’re not as good as we could be at conveying what value we bring to the organization.
It’s kind of a bit intangible and it’s one of those things where, um, I think it’s on both sides. I think it’s partly the organizations, you know, and you know, senior management and whoever hires us don’t necessarily understand product management as much as we do, which is understandable. But equally, I think we’re not as good as we could have been, um, at articulating where we bring value.
Yeah. Um, and so those combination of factors have kind of meant that we’re, we’re a little bit of a victim of our own success. Um, product management has kind of gained popularity and you’re right.
There’s like dozens of books on product management and loads of people talking about product management, but as a result of that, um, you’ve had this influx of people who have learned product management kind of by soundbite. So they’ve learned it from, um, the books, which of course will say, and everything worked out perfectly. And, you know, it tends to gloss over the messy details.
Um, they’ve learned it from, you know, the influencers, the people writing stuff online who have kind of taken bits out of context and kind of say, this worked really well for us. It’s, you know, copied best practice from this organization, you know, that notoriously it’s like kind of everyone’s sites, the Spotify model of like squads and that kind of cross disciplinary thing is the archetype. Spotify didn’t even use it themselves.
[Richard]
I love the way all those things you dig into it. It’s like, no, this is the way we wished we could have done it.
[Jock]
Yeah, exactly. So it kind of gets glossed. It kind of gets glossed over.
It gets zhuzhed up. Yeah. For, for the, to tell a good story.
And as long, I think what’s been lost a little bit is that kind of saying, okay, that worked in that particular context, when this is applied in a different context and we apply similar principles, not necessarily the methods, you know, verbatim, but maybe also can we apply a bit more thinking to how it needs to change, how it needs to adapt, what’s different between their organization and ours? Are they being a hundred percent truthful about, you know, how they did things and how it worked in practice and what, what are our problems? I think the, the interesting thing has been people have forgotten that context matters so much.
And the nature of product management is, it’s a very different beast. You do it very differently, depending on your context. You do product management very differently.
If you’re in a startup versus an established, well-funded, you know, multinational, you do it very differently. If you are a kind of at different stages of maturity of the product, you know, you treat a brand new product, seeking product market fits very differently to one that’s very mature and probably due to be phased out, you know? So that kind of missing bit, what has been lost in translation, perhaps is a better way of putting it, is context.
And I think the, with all these new people, which is great, you know, we’re attracting all this new talent into product management, but they have this very wide, but shallow appreciation of product management. And as a result, they go, well, I’m just doing what the books told me to do. And it’s like, and it’s not working and I don’t understand why.
[Richard]
Right. Okay. Yeah.
Okay. So that’s a problem, isn’t it? Because you know, you, you, you ride out in bushy tails, you come in, you’re doing your product management, you, you’re getting your A grades.
You think you’re, yeah. You know, pat on the head.
[Jock]
You’ve done your certification.
[Richard]
Yeah. Yeah. All that kind of great stuff.
But actually you’re, you’re just not delivering any value.
[Jock]
Yeah. And the challenge, the challenge is that it’s kind of like the iceberg thing, right? You know, you’re seeing the tip of the iceberg, which is what people describe product management as, but actually the, the bits of the iceberg it’s hidden underneath the water is almost like all the people stuff, all of the tricky context-specific conversations that you have, the messy conflicts that come out of nowhere, that sideline you, that derail you.
And all of that stuff has to be managed and negotiated to get you and your team to the place where you can actually deliver that great product. But I don’t think that’s the bit that anyone’s necessary. Well, I don’t think it’s spoken about as much.
And I think because of that, people have come into product management, believing the hype and not necessarily understanding the complexity and the emotional intelligence needed just to be able to do it well.
[Richard]
Yeah. Now here’s the thing, right? I mean, you and me, yes, that value proposition is very clear, right?
Are these companies cutting back on product management just because of finances? You know, if they, if they had the money, would they, would they still have product management in place or has there been a more general loss of faith?
[Jock]
Oh, that’s a tricky one. So.
[Richard]
Oh, that’s a nasty question.
[Jock]
That’s fine. I mean, I think so we can speculate, right? Because I, I don’t know what’s, what, what’s really driving decisions.
You could say, just because lots of companies have been following each other’s lead that, sure, they over-hired when money was cheap and interest rates were low. And now they’re suffering a bit from that kind of hiring spree and they need to cut numbers down because people are expensive. Right.
So I get that as a kind of Maybe the fact that other organizations have been publicly saying, we’re, you know, cutting down on our product managers, you know, there’s the, there’s a, there’s a, there was an interview with, with Airbnb’s Brian Chesky. And many people took it as kind of like a harbinger of, you know, the death of product management because he said he was basically merging his product function or getting rid of his product function and make it more like product marketing, more like the go to market focus. And some people go, Oh, that’s the, that’s the end of product management.
And other people are going, well, actually I think that’s overstating it. Product management, you know, can have a focus on the go to market piece as well. And, you know, it, it’s not saying it just needs to be something different in his organization.
And that was fine, but anyway, it kicked off this massive, like debate and product management kind of got, got to be seen as a bit of a target for layoffs and understandably as well, because like we’re, we’re the ultimate middle managers, right? We are the connectors between different bits of the organization. And as we were saying before, it’s been difficult for us to necessarily articulate the value we have been bringing as well as we could have been doing.
So, you know, understandably, if you’ve got a lot of product managers who you’re not entirely sure as the, you know, you’re a CEO or whatever, and you’re not entirely sure how much value they’re bringing to your organization in revenue terms or tangible measures, then you go, well, of course, they’re going to be an easy target, right? So there’s a bit of that. Now, what I think is probably going to happen is it’s that age old thing.
If you don’t know what you’ve got until it’s gone, you know, and I think the less tangible value that product management brings to an organization done by the people who get it. And again, it’s kind of, I’m, I don’t want to do down the, the people who have kind of come in all bright eyed and bushy tailed, but with not a depth, not necessarily a depth of understanding or experience, because they have to get it right. They have to learn it somewhere.
So I’m not, I’m not, I’m not doing, I’m not doing it down, but you know, if you have a majority, shall we say, of people who don’t have that depth of understanding, then understandably, it’s kind of like they’re not showing their value. They haven’t learned yet that skill of saying, and by the way, this is why product management is really important because this is what we’re really doing for the organization. So what I think is going to happen is the companies have trimmed down their product management teams.
Things will calm down. They’ll realize bits aren’t gelling together as well as they weren’t. Things are more disjointed.
There isn’t as necessarily as much alignment between the various bits of the organization and indeed the vision and the strategy that they have set out and how that translates into how the products deliver against that. So there’s – we’ll start to see this kind of cohesion splintering a bit. And the reason for that will probably be because there isn’t that product manager asking the annoying why questions and saying, well, shouldn’t we be doing this rather than this?
Because that helps the company get to where it’s trying to get to more, more effectively.
[Richard]
Oh yeah. A hundred percent. I mean, we see when it comes to developer oriented products, we would be helping people do developer relations, but a lot of the time there is no product management.
We’re just dealing with the technical side and you can definitely see that it’s, I mean, we almost have to take the product management on in a sense. It’s interesting that you talk about demonstrating value because that’s a thing in developer relations as well. And I was recently talking to Matt Ravel, who set up the DevRelCon conference.
And he was saying that in the very first year of that conference, which is now nine or 10 years ago, there were three talks on metrics and measurements and demonstrating value. And that has probably been the minimum number of talks about that topic since then, every single year. On a practical note, and I’m interested in your take on this, I mean, we’ve come under pressure to demonstrate value to our clients.
And I suppose I was lucky enough to be working in plain old software consulting previously. And one of the things that has worked really well for us is just having a regular weekly cadence of providing information and updates on what you’re doing in an intentional way. So you start from baseline of actually the leadership doesn’t really understand what we’re doing.
So we need to prove ourselves every week. You’re only as good as your last week of delivery. And we’ve had to up our game significantly on that side of things.
But it doesn’t require hard metrics per se. It just requires authenticity around wanting to continue to deliver value and showing that you’re willing to do it. Do you feel that, I mean, I’ve seen this a little bit in developer relations.
Do you feel that as it exploded, as lots of people entered it, there was perhaps a loss of focus on communicating value upwards? Sort of an assumption that if I come in and I do my 9-6 or whatever, I go home on a Friday and I don’t actually need to prove that I was working?
[Jock]
So yes, it’s a short answer. The slightly longer answer is in many of the coaching sessions I have with product managers, I’m not saying it’s like the general catch-all fix is you need to communicate better, but often in the absence of timely and relevant communication, particularly with your bosses, particularly with the senior leadership team, whoever are the people that need to be hearing this stuff because they’re not directly connected with it, being able to engage with them in the right way with the right level of detail to show we are doing stuff. Here’s what we’ve learned.
Here’s what we’ve done. Here’s what we’ve delivered. But I think almost the more important bit, I think this maybe touches on why we find it so difficult, both DevRel and product managers, find it difficult to communicate the value is because the value comes from in what we’ve helped the organization or the team to avoid doing.
And it’s difficult to measure that because how do you measure something that hasn’t happened? And it’s like saying, so to be able to communicate, look, we looked at five things potentially that we could do, and we dismissed three of them straight off the bat because they’re not aligned with our strategy or they’re not going to work for us right now with what we’ve got on, or if we just wait a little bit longer, something easier will come along that will unlock this kind of thing. The point being is we have spent time evaluating and choosing not to do these things because they are going to be a red herring or a waste of time and money.
There is value in that decision not to do those things, and yet we don’t talk about that as much as we should do.
[Richard]
Oh, yeah. And it’s super interesting for leadership, right? Because you can say, I thought that was a really nice feature or idea.
[Jock]
Exactly. And in terms of kind of measuring that to an extent, it’s almost like when you’re exploring something or learning about something, it’s showing how much you have chosen or the decisions you have taken to avoid doing something just as much as the things you’ve chosen to do that are valuable to the organization. To give you a really good example, so somebody I interviewed once told me this fantastic thing about the dangers of not commenting in the code.
Here’s a bunch of stuff I tried. It didn’t work because of this thing, this thing. It’s that encoding that kind of knowledge, contextual knowledge about here’s the 15 things I tried to get this code to work, but it didn’t.
This is why I’ve settled on this particular way of doing things. It may look suboptimal at face value, but what you’re not seeing is the context of it’s actually the best one because it’s the only one that works in the context. When things change or when CPU power becomes 10 times greater and for less cost, sure, we could probably brute force it this other way, but for the time being, this is the right way of working.
Describing that in the code comments as a way of sharing that knowledge from one generation, if you like, to the next is something that tends to get lost.
[Richard]
Oh, man, wow. That would be so, that’s such a great idea. Yeah, I could have done that many times and I’m so guilty of just erasing the past.
[Jock]
It’s that kind of communication of here are the roads we did not take. Here are the paths we did not choose. I’m not saying that’s the one golden bullet that will solve all of the problems of product management at the moment, but certainly we need to get better about communicating all of the things that we’re doing and where that holds value rather than just maybe talking about what we think are the things that hold value, like we shipped some code or we delivered a particular release of the product or we conducted these experiments or whatever else. I think there’s maybe a little bit of a shift in how we communicate, but certainly I think most product managers, most teams, particularly the ones that think they’re autonomous and therefore don’t need to (they’re wrong), need to be really good at pushing up the organisation, that narrative about what they’ve been working on, why it’s valuable, how it helps them to move forward and therefore how it helps the organisation to move forward.
[Richard]
Yeah, yeah. That’s applicable to DevRel as well, by the way, thank you. I’m going to steal that.
[Jock]
By all means.
In a way it sounds similar to something else which I always try to do, but the discipline has failed me many times over the years, is maintaining something called a decision journal.
[Jock]
Yeah, yeah.
[Richard]
So this is an idea that you need to write down the decisions that you’re taking and why you took them.
[Jock]
Yeah, yeah.
[Richard]
As a general activity, as a discipline to help you make better decisions in the future. Yeah, that is a really practical idea.
[Jock]
Yeah, yeah. That decision log is something I’ve recommended and used many times because teams change, people move around. I think it’s called that tacit knowledge, the unspoken stuff.
[Richard]
It disappears.
[Jock]
It disappears. And then you end up with these teams going round in circles and not reinventing the wheel necessarily, but retreading the same path and spinning their wheels on something we’ve done before.
[Richard]
Exactly. And that’s why you have that old sort of Chesterton’s fence, you know, place the fence there. Better leave it there, otherwise, who knows, right?
[Jock]
I heard a great example of that, just to digress very slightly, of like there was a comparable piece of software, it’s like sort of a warehouse management kind of automation stuff, like physical warehouse, like people and boxes and stuff. And in the corner, there’s always been this box in the corner with like ARW equals zero in red letters.
Right, and it’s just always been carried across from refactoring to refactoring.
[Richard]
Don’t you love back office B2B software?
[Jock]
And somebody asked a question going, but what on earth does ARW equals one even mean? And a bit of archival and historical stuff, apparently in the second world war, when there was an air raid warning, when there was an air raid warning, there was a sign which said how many air raid warnings there were, and the number was put up in this big sign. And that sign got kind of converted into digital forward.
It just got carried across all the way through the iterations, through the years, and nobody never really figured out why it’d be there in the first place. So there you go.
[Richard]
That’s marvellous. Yeah.
[Jock]
Always zero, but air raid warnings.
[Richard]
Yeah. And very important to know how many.
[Jock]
I’m sure.
[Richard]
Okay, so let’s change gears slightly, because another thing that you’ve been exploring recently is, I don’t know, just to quote the IT crowd, is it relationship management? But I think it’s another crossover point between sort of DevRel, and a product manager, which is this cross-functional role and dealing with lots of different personalities in an organization. And you talk about an iceberg, right?
But what’s under the water is often mostly about people. And in both our cases, we’re expected to do a job with literally no actual allocated resources and no actual power, just by sheer force of persuasion. So I mean, is that a skill that takes time to develop?
Is that something that people who’ve come into both roles, if they’re just trying to follow checklists and books or whatever, are missing?
[Jock]
So this is a really interesting one.
[Richard]
Yeah. I mean, we can get philosophical.
[Jock]
Yeah, yeah. Here’s the thing. So I’ve long maintained that you can learn the techniques and the methodologies and the frameworks and whatever else.
You can learn the technical stuff. I’m talking about product management here, because obviously what I know more about. But you can learn that stuff, right?
And learning it from books, learning it from blogs, whatever, fine, cool. And sure, there’s the element of, yeah, you need to make sure you’re applying the principles and you’re taking into account the difference in context between the person that’s suggesting this framework or methodology and how you apply it in your organization. So taking all of that kind of context adaptation as read.
What you can’t learn as easily, I don’t think, are the softer skills, okay? And I probably shouldn’t say soft skills, because they’re not soft skills, they’re actually quite difficult.
[Richard]
They’re extremely hard.
[Jock]
They’re extremely, extremely hard, yeah.
[Richard]
Extremely hard, yeah.
[Jock]
So maybe a better way of putting it is the emotional intelligence piece, okay? And I think people forget that product management, despite the name, is actually about people. It’s about the people you work with.
It’s about the people that help you learn and understand things. Product management is by definition that generalist role. We try to work with specialists in lots and lots of different disciplines as needed to make the thing happen.
We can’t do it by ourselves. And I appreciate that the role of product management sometimes gets a bit overloaded. We do a little bit of user research and a little bit of design or a little bit of wireframing, if that.
But we’re not any of those things. We’re not user researchers. We haven’t done a behavioural psychology degree, usually.
We haven’t got a career’s worth of experience in each of these specialisms to be able to justify us doing them. We’re maybe a stopgap until someone with that specialism comes along. So we need other people to do this stuff.
But equally, we also need to understand what matters to the various groups of people around an organization. And often, because that seems to be the way we design and build organization structures, often these differing groups of people, whether it’s sales or marketing or development or this, that, the other, or legal compliance, whoever, we’re almost set up antagonistically. They’re almost set up with individual departmental goals and incentives to do those things that aren’t necessarily aligned.
And so you’re going into a situation where you’ve got a bunch of people saying, why should I help you when it is not in my interest? And the way the organization is set up, my own personal, you know, bonus structure, incentive structure, whatever, is that it is actually not in my interest to help you out. So that, you know, I mean, that’s probably maybe a bad case.
I appreciate that’s not the way it works in every organization.
[Richard]
Well, I don’t know, all human societies seem to end up that way.
[Jock]
If you end up in that departmental siloed kind of stereotypical organization structure, then, yeah, that kind of ends up being the way it is. So given you’re ending up in this situation, how do you get everyone to get along and how do you get them to all pull in the same direction? And there are some things that we can influence for sure.
We very rarely have direct authority like, you know, you were describing there as well. And interestingly, even the people who’ve got up to CPO level, so in the C-suite, they’re saying, I thought I’d have, be able to tell people what to do. Nope, still have to get my respective peers at C-level to work with me to do these things.
So it’s never going to change no matter how senior you get. And so it all boils down to our ability to show that we understand what all these other groups of people need, want, are worried about, are being pushed to deliver. Identifying that those things are probably not aligned.
And that might be because they’ve been set up to be misaligned because of poorly chosen incentives, or it might be because there’s an absent strategy guiding that alignment or providing that pull to get everyone moving in the same direction. But the reality is we have to find a way to get stuff to happen in those organizations. And it’s often like we automatically dehumanize people.
We talk about them as stakeholders. They’re not stakeholders, they’re people, and they’re just trying to do their job. And usually, most times, they’re not trying to screw each other up.
Yeah, they’re all just trying to do the job that they’ve been asked to do as best as they can. And the conflict arises from that, not out of necessarily any ill intent. OK, so often we see that kind of conflict emerging because we’re just not seeing people as other human beings.
We’re not listening and understanding what matters to them. We’re not realizing that actually nobody gives a toss about our discovery project. They’re just bothered about hitting their numbers.
And remembering that what’s important to us isn’t necessarily what’s important to other parts of the organization. And then figuring out, well, OK, how can I demonstrate that what I’m doing actually benefits them as well? How can I show that, fine, it may take a bit longer, it may cost a little bit more money, but what we’re then figuring out and learning to do unlocks a much better way of working in all of these different areas.
And we should do a better job of communicating how that’s going to help you and where we are with things. But equally, if you can give us a bit of trust as well, that we are actually working in your interests, even if it’s not obvious from face value that we’re doing that, then hopefully we can start to encourage more of that trust and therefore kind of be able to step through some of these challenges or conflicts that we find ourselves up against. But, you know, it’s got to work on that.
[Richard]
Why have we chosen these roles? Because it’s so difficult doing that, right? Because, I mean, if you, I’ve worked as just a plain old developer and that’s OK.
You get your task out of JIRA, you do your task and you try to hit your estimates and you can just be difficult and awkward with anybody else. Right. If you work at IT, accounting, even if you’re in sales, right, laser focus.
And I love that expression, coin operated, right?
[Jock]
Yeah.
[Richard]
That’s just it, right? I think marketing has more of a challenge that way as well, right? Because they have to try to assimilate.
Why on earth have we chosen this almost impossible task, you know, where you can’t narrow your domain, you have to go cross-functional? To do what you’ve just said, you know, I have to get inside the mind of the head of IT, that’s really tough. I mean, how do you approach that?
[Jock]
I mean, you’re right, it is hard and it’s also hard because, well, let’s face it, not everyone is a massive extrovert. And if, you know. Again, to generalise wildly, product management is one of those professions that tends to attract slightly more people nudging towards the introverted side more often, you know, it tends to be people who are in it not for themselves, but for the greater good, to be a bit cliched about it.
And these kind of conversations are perceived, the apprehension of the conflict can be, you know, very off-putting. But at the end of things, being able to sort of step back and say, well, OK, this person is upset about something or is angry about something or is very adamant they need something, can we understand why? Can we listen to them?
Can we allow them to express where that strength of feeling is coming from, even if it’s uncomfortable? Because the first thing is, one, we’re listening to them and that may be the first time that anyone’s actually done that. And the second thing is that what we may uncover is what’s really underneath that particular sense that we’re getting.
And again, I keep coming back to this context, this idea of context.
[Richard]
I was going to say, it’s yeah, it’s what you said at the start, right?
[Jock]
Yeah.
[Richard]
What’s the context?
[Jock]
Exactly. And it’s understanding, well, they’re behaving like that for a combination of complex reasons, one of which is what are the contextual factors? What’s what’s the what are the things that are pushing them in that particular direction?
Equally, you know, other things that might be completely relevant to the context, but completely outside of our control. It might be having a really crappy day at home with the family or whatever, you know, the kids might have been driving them nuts or something particularly frustrating happened or a family member is unwell or whatever it could be. There’s all this kind of stuff that’s buzzing around.
And so somebody might just have a bee in their bonnet about something. And even though that’s the thing they’re annoyed about, it might be something else that’s actually driving that. And that’s not actually the important thing.
But the only way you can get through that is by letting them talk to you about that and let them tell you what they’re concerned about and what they’re upset about and what matters to them. And it’s not saying, well, OK. If this is actually the underlying reason why, you know, this you believe this is important, why we absolutely have to have this button coloured blue, then can we understand – can we explore some other ways of maybe achieving the desired effect. Yeah, in that, that will actually work better for you in the long term, but actually align better with what we’re trying to do as well. Bearing in mind, we’re all trying to work towards this kind of broader goal or strategic outcome.
But there’s an element of that, there’s an element of just like not hiding behind jargon. Right. So nobody cares about the wonderful frameworks or methodologies that we’re employing in product management or, to be honest, any other specialism.
Yeah. It’s like, tell me what I need to know in my own language. Yeah.
And I think we forget about that a bit when we’re talking to people. It’s people don’t care necessarily how we do things, just whether or not we’ve achieved the thing they’re looking for.
[Richard]
Yeah. Yeah.
[Jock]
And that’s that’s a kicker, right? Because we do what we do because we love what we do. And, you know, not everyone is as excited about what we do as other people.
[Richard]
It’s funny because, I mean, that’s and I’d share that excitement about getting a group of people that are at odds with each other to ultimately collaborate and do something effective. That’s a great puzzle. But it does sound like product management is not something where you can you can say to yourself, I am doing product management, I am following the rules.
Well. Yeah, this obsession with context is …
I do recognize a parallel in software consulting, and this again, this goes back to these soft skills or things that are very hard to learn from books over the years.
Like the death of any software project, especially in a client relationship is feature fights. So I don’t know, I don’t know. I don’t know. Maybe there’s a proper technical term for something, but this is where the towards the end of the project, instead of collaborating, it just becomes a fight over one side trying to get as many features as possible and the other side trying to deliver as little as possible. I think huge arguments about what’s in scope, what isn’t, timelines, all that sort of thing. So every – there’s no collaboration anymore, right?
It’s all just completely adversarial. Yeah. And obviously there’s money on the line, but that’s it.
But once that happens, you’ve lost, you know, and it’s it’s kind of the end because everybody will end up completely unhappy. And this context of the wider goals and what we’re actually trying to achieve gets completely lost.
[Jock]
So, you know, if you’re thinking about a particular situation, you know, a particular example of that. How was that initial contract or engagement set up, you know?
Was it very transactional in terms of “we want you to build an X, Y, Z, which has the following features”, or was it “we have this problem, can you help us solve it?” And it’s really hard, particularly in kind of agency work, you know, contracted work and so on. If somebody comes to you with a fully formed idea of what they want, there’s not really much scope for negotiation.
It’s like it becomes very binary. Did you deliver the thing we asked for or not? Barring the fact that what we asked for might not necessarily be particularly clearly defined or at least might be ambiguous in some ways. Right. And I’ve been in that situation as well.
And so you end up arguing about your interpretation of what the thing was in the first place rather than whether anybody has actually achieved the thing you’re trying to do with that thing.
[Richard]
Right.
[Jock]
Everyone’s forgotten the reason why you need the thing in the first place. Does it do the job? Does it do the job well?
Does it matter then whether that tiny feature you asked for in specification one dash three dash five, you know, has been has been delivered to spec or not, or does that thing do what you’re trying to do? And the problem is, I think, when you have a relationship that’s built up on I want a specific thing and the conversation is not about here’s my problem, here’s what I’m trying to achieve.
That’s when I think you end up in that, you know, adversarial, he said, she said, blah, blah, blah, blah.
[Richard]
Yeah. And so many people have been poisoned or had such bad experiences. Building software products, it often goes that way.
I try so very hard never to give estimates because that’s that’s sort of the path of madness, right? Because. Yeah, but it kind of comes, it kind of comes back to this relationship thing, because that building trust in a relationship requires constant work.
[Jock]
Yeah. And as you say, you’re only as good as the last thing you’ve done. You can very easily burn trust.
But, you know, in some ways it’s, it’s, I think there’s, there’s a, there’s a couple of things about trust that, that I’ve come across from, from chatting with people. The first thing is that you don’t necessarily earn the huge bit of trust straight away. You have to earn little bits of trust to do a slightly bigger thing.
And as long as you keep doing what you said you would do and telling people that you did what you said you were going to do – that’s the communication bit we’re talking about before – you can’t kind of accumulate trust. You can’t build up the trust to the point where you’re given that leeway to do the bigger thing.
Right? And the moment you stop communicating or the moment you start doing something different to what you said you were going to do, you lose the trust. And that, and the communicating part is really important because if you don’t say what you’re going to do, then people will interpret what they want you to do themselves.
And then funnily enough, when you do something different, it doesn’t match up with what they thought you were going to do because they’ve just inserted their own interpretation. And so it all comes down to that thing of we can’t read each other’s minds. And so the best we can do is to talk to each other, to listen to each other, to try and peek inside the brain a bit of the other person.
And the more we do that, hopefully we can work through those misunderstandings or those different mental models, or just those simple, we’re all using the same words, but we mean completely different things. Yeah. And just trying to unpick that by talking to each other is really important.
But if we don’t talk at all, people will just fill the void with whatever they think is going on and insert whatever narrative they think is going on. And funnily enough, that creates all sorts of problems we then have to dig ourselves out of again.
[Richard]
What’s the best way for me, as somebody entering product management, to learn this stuff, because I don’t know if you’re like me, I learned this, the school of hard knocks, but if we’re going to have, I suppose, more maturity in our professions, is there a structure or is there some way that this type of knowledge, which is learning by doing, you can’t learn it in a book, I know you do coaching, and this must be part of it, right?
But I don’t know, I mean, and I think we’ll kind of finish up on this one because we have been waffling on, it’s about to keep going forever. But yeah, I mean, let me just pose the question, right? Because you do coaching, right?
So what’s, if you have a sort of fresh off the boat product manager, how do they learn this stuff?
[Jock]
So I would always recommend finding any excuse to talk to as many people around your organization as you can. I kind of made the joke years ago that kind of, when you start at a company, you get the org chart, you cross your own name off, and that’s the list of people you’ve got to talk to. Yeah.
It’s kind of like that because you don’t necessarily need to be besties with absolutely everyone. And in fact, there will people, there’ll always be people that you don’t necessarily get along with as human beings, yet you still have to find ways to work with them. You still need to find a way to collaborate, even if there isn’t consensus.
So step one, I think is try and build something resembling a functional working relationship with as many people as you can around the organization. Absolutely focus on the people who are going to be more crucial to your success or failure in your particular product area, but get to know them. Build up as much rapport as you can as human beings, not just as coworkers.
I’m not saying you need to like, you know, be sharing, you know, photos of your kids with each other. But the point being is you should know enough to know, you know, what other stuff could be going on in their lives that could affect them. Um, but also I think there’s that other piece, which is, goes back to that thing about, you know, treating people as human beings and not applying labels.
The moment you start talking about ‘sales’ or ‘marketing’ or, you know, or ‘stakeholders’, ‘god, the stakeholders are really annoying me’. It’s like, you’re just treating them as, you know, objects rather than human beings, and there’s people behind that. And, um, the moment almost we catch ourselves doing that, even if we’re venting to our friends, you know, after work or whatever else, the moment we catch yourself doing that, we’re going, I’m not treating this person like a human being anymore.
I need to rein that in. And I need to figure out how can I get back to the point where I’m seeing them as a real human being again. And particularly when you’re, there’s hybrid working and you know, we’re on the end of video calls and stuff like that.
It’s even harder when you’re not there in person, but we need to try and cultivate that human connection, that human understanding and not assume. The narrative in our heads that we’re making up as you go along, not assume that people have ill intent. It just could be that they’re set up in a way through no fault of their own that happens to be not in line with what we’re trying to achieve. So don’t blame them personally for that. Find work with them to work around it.
[Richard]
Yeah. I wish someone would have given me that advice.
[Jock]
Oh man. Tell me, you know, me both. I mean, this is the thing that kind of been reflecting on recently, I mean, particularly as a result of all the coaching, it’s, it’s what keeps coming up.
It’s not the technical stuff. It’s always the people stuff. Um, so it’s an area I’m really interested in because I’ve always found that stuff particularly difficult.
Like, like you said, you know, I wish somebody had written that on that at the beginning. But equally, I don’t think it’s something that lends itself necessarily well to a book because it’s like, without the context, you can’t just say this, do that and do the other thing because it won’t work.
It’s like, think about it in this way. Figure out what’s going on in your own head, figure what’s going on in other people’s heads as best you can, think about the things in the context that maybe modify or change the situation, and then maybe figure out from that, what the best course of action is going to be.
And so that’s the thing I’m researching at the moment. And with any luck, I might turn to some kind of bit of advice or book on the topic, but I’m still figuring out whether it can be done.
[Richard]
Um, yeah, tacit knowledge is so difficult to, it’s so difficult to transfer. Um, I, I, I often like to think of it as like, you know, uh, I don’t know – medieval blacksmithing, right. Which you learn by apprenticeship.
You know, why, why, why does, why does the sword need to be stuck in the water for two minutes after being left in the charcoal bed? I don’t know. Now we know it’s all about the carbon content of the steel, but back in those days it was, well, it looks about right, you know, um, I feel, yeah, we’re, we’re like medieval blacksmithing.
That’s where we are. That’s what we do.
[Jock]
But having, I think to that point, having a good role model is super important.
[Richard]
Right.
[Jock]
Yeah. You know, if you learn from a crappy blacksmith, you only have a crappy apprentice, they’ll learn how to do it badly.
[Richard]
Problem is, and no disrespect to people who make their living, um, in public. Good role models are often not particularly noisy, you know, that’s finding them is tricky.
[Jock]
Yeah. There’s a lot of noise. Um, a lot of kind of echo chamber-y kind of people taking stuff out of context, people blasting out opinions that again, that very superficial broad, but not very deep, uh, appreciation of the thing.
But equally, it’s also really hard. You can’t give the context, the complete context every single time you explain something. So there’s an element of, you have to assume a degree of experience on the part of the individual.
But equally, it means that you need to tailor that advice you’re giving to the experience of the person. You can’t assume they know everything yet. You know, you can tell a seasoned, you know, product manager of 20 odd years’ experience, yeah, you know, the shorthand because you’ve been through all that yourself. So I can just skip straight to the thing.
For somebody just starting out, they don’t have any of that reference, that frame of reference. So you do need to start with a basic and say, look, you can’t assume this or you can’t assume that what you’ve read isn’t necessarily the case.
[Richard]
Yeah. Yeah. It’s quite fun.
All the same. I don’t, I got it. I get it.
When you, when you can do that, when you can bring that context together and you can get difficult people to all go in the same direction and, you know, you start off with clients that are antagonistic and they’ve been burnt so many times and then you can build trust and get them to actually collaborate. Three months in, they’re finally collaborating. Yeah.
[Jock]
It’s great.
[Richard]
It’s fabulous. It’s fabulous. That’s, that’s, that’s why we get up in the morning.
Yeah. Jock, thank you so much. It’s always a pleasure.
Uh, absolutely. Uh, always good to talk. It’s good to know that, uh, it’s good to know that others are suffering as well.
[Jock]
Oh god, yeah.
[Richard]
It’s a, it’s a bit of, it’s a bit of a miserable time, but you know, these things are cyclical. I was, I, I was, I, I was looking for a job in the dot-com bust.
Um, yeah, it, it all, it always changed. It always changed.
[Jock]
It will, it will work itself out. Yeah. I think like, possibly like you, I managed to, um, I think I weathered the dot-com, uh, bubble bursting at one organization that shrank by like 80, 90% overnight.
Um, but then also managed to get myself fired, uh, around about 2008 when the financial crisis, that was impeccable, impeccable timing on my part. Um, um, but then it led me into another role, which led me to another thing, which actually set me on a really good path. So, you know what, these things work their way out.
These things will pass. As you say, it’s all cyclical. People will, you know, product management and DevRel will find its place again.
And we’ll move on from that. But again, it’s about remembering we have kind of been here before. There are still lessons that we can carry with us from previous iterations around the loop.
Um, but yeah, we’ll figure it out. We’ll figure it out.
[Richard]
Okey-dokey. Thank you so much. It’s been an absolute pleasure.
Likewise. Best of luck. And, um, yeah, keep, uh, keep, you know, I feel like you’re the puppet master, you know, pulling the strings.
[Jock]
Maybe that’s a bit creepy, but hey.
[Richard]
Yeah. Yeah. A little bit.
Yeah. Master of puppets. It’s going to be playing in the background in the podcast.
All right. Jock, take care.