In this episode Charles Humble talks to Matt LeMay, co-founder and partner at Sudden Compass about the job of product management. They explore what the job entails, common A/B testing pitfalls, conducting user research, dealing with senior stakeholders, and managing prioritisation.
Subscribe: Amazon Music | Apple Podcasts | Google Podcasts | Spotify
About the interviewee
Matt LeMay is an internationally recognized product leader, author, and consultant. He is the author of Agile for Everybody (O’Reilly Media, 2018) and Product Management in Practice (Second Edition O'Reilly Media, 2022), and has helped build and scale product management practices at companies ranging from early-stage startups to Fortune 500 enterprises. Matt is the creator of the One Page / One Hour Pledge, a commitment to minimise busywork and maximise collaboration that has been adopted by over 100 individuals and teams at Amazon, Walmart, CNN, BBVA, and more.
Matt is co-founder and partner at Sudden Compass, a consultancy that has helped organisations like Spotify, Clorox, Google, and Procter & Gamble put customer centricity into practice.Previously, Matt worked as Senior Product Manager at music startup Songza (acquired by Google), and Head of Consumer Product at Bitly. Matt is also a musician, recording engineer, and the author of a book about singer-songwriter Elliott Smith. He lives in London, England with his wife Joan.
Resources mentioned
Product Management in Practice by Matt LeMay
Escaping the Build Trap: How Effective Product Management Creates Real Value by Melissa Perri
What, exactly, is a Product Manager? Martin Eriksson
Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value by Teresa Torres
The Human Insights Missing from Big Data by Tricia Wang
Full transcript
Introductions
Charles Humble:
Hello and welcome to the seventh episode of "Hacking the Org”, the podcast from the WTF is Cloud Native team here at Container Solutions. With this podcast, we're aiming to bring together some of the most experienced software engineering leaders and to talk to them about their experiences covering topics such as building and leading high performing software engineering teams. I'm Charles Humble, Container Solutions Editor in Chief, and for this episode I'm joined by Matt LeMay.
Charles Humble:
Matt is an internationally recognized expert on product management and agile ways of working. He is the author of Agile for Everybody and Product Management in Practice, both published by O'Reilly and the second additional Product Management in Practice came out in May of this year. Matt has helped build and scale product management practices at companies ranging from early stage startups to Fortune 500 enterprises. He has co-founder and partner at Sudden Compass, a consultancy that has helped organisations including Spotify, Google, and Procter & Gamble put customer centricity into practice.
Charles Humble:
Previously Matt worked as a senior product manager at music Startup Songza, which was acquired by Google and was also Head of Consumer Product at Bitly. He is also a musician and a recording engineer and the author of a book about singer songwriter Elliot Smith. And I'd love to spend the entire episode talking music, but that will be a different show. Matt, welcome to Hacking the Org.
Matt LeMay:
Thank you so much, Charles. I'm happy to be here.
What would you say are the biggest changes to the practice of product management since the first edition came out?
Charles Humble:
So the first edition of the book came out in 2017 and you jokingly say in the forward that, well, nothing much has changed since then. Although I tend to think that the role itself has existed for really quite a long time, it's obviously a relatively recent thing in terms of trying to formalise it and come up with best practices and so on. It very much feels like we're sort of at the early stages of that. So with that in mind, what would you say are the biggest changes to the practice since the first edition came out?
Matt LeMay:
Yeah, that's a great question. I think when asked that question, I usually go to the interviews I did as a first step. For both the first and second editions of the book, I started by interviewing a lot of working product managers and asking them the same question, which is what's one story from your work that you wish somebody could have told you on day one that would've made your life easier and saved you a lot of pain and misery? When I did the first edition of the book, almost all the answers were about executive stakeholder management, where I wish somebody had told me that I shouldn't ambush executives with a brand new idea and a big fancy company meeting. And I wish I had understood that talking to executives was part of my job, not an impediment to doing my job.
Matt LeMay:
With the second edition, the most common answer I got was "I wish I hadn't spent so much time stressing out about how my company doesn't do product management "the right way"", which was really interesting and surprising to me. I think that since 2017 as product management has become more ubiquitous and has become more thought leadership and best practiceified, there's a sense among a lot of working product managers that we have to reclaim the uniqueness and the ambiguity of the work. That for all of the folks out there saying this is the right way to do things, and these are the companies who have it all figured out, you talk to somebody who works at one of those companies and they will tell you, Oh, we have nothing figured out. Nobody has anything figured out.
Matt LeMay:
So I think the biggest change in the practice of product management from 2017 to 2022 is that the more experienced folks are more understandably sceptical towards the very idea of one size fits all best practices and are really looking more at the context of their individual work, their individual teams, their individual organisations and saying, How do we spend less time stressing out because there is some theoretical blueprint to which we are not living up and more time just trying to deliver better solutions for our customers?
How did you get into the field yourself in the first place?
Charles Humble:
That's really interesting, I think. I'd love to come back and actually I'd like to talk about that shift around stakeholder management as well. But as you say, it is fascinating because it's not a one size fits all discipline. With that in mind, I'd actually like to talk to you a bit about your own journey into product management. So how did you get into the field yourself in the first place?
Matt LeMay:
Sure. So the short honest answer is by accident.
Charles Humble:
It's always is.
Matt LeMay:
It's funny to me now when I meet people who are like, Yeah, I wanted to be a product manager. I went to college, I studied business, or sometimes even I studied product management and now I'm going to become a product manager. Because when I started 12 years ago, there was no pathway to product management. I got my first job in tech through a personal connection, somebody who was familiar with my music writing and I had a good conversation with him and I talked about my history as a musician and he said, Oh, I think you'd actually be really good at a tech company because you can wrangle a lot of complexity. Because you can have a lot of folks who have specialised skills and figure out how to make things happen and you can sort of understand the gestalt of something and how the different parts add up to an experience.
Matt LeMay:
He kind of threw me at Bitly where my first title was API evangelist because I was technical enough to do sort of a developer relations role, but definitely not technical enough to be a developer at a company like Bitly. And I at some point did a Google search for job in tech, bad at code, decent salary, and the idea of product manager came up and I went to my boss and very confidently said, "I want to be a product manager." And he said, "Sure, I don't care." And so it was that I became a product manager and here 12 years later, I am talking about product management.
What is a product manager responsible for?
Charles Humble:
That's fantastic. Now we've said it's not a one size fits all discipline. So with that in mind, and obviously this will vary from organisation to organisation, but what is a product manager responsible for?
Matt LeMay:
My favourite high level answer to that comes from Melissa Perri's book "Escaping the Build Trap", which I highly recommend. And she says that a product manager's ultimate responsibility is to facilitate a value exchange between a business and its customers. And that value exchange can be an exchange of revenue for services or an exchange of usage for services. There's all kinds of different ways of thinking about that value exchange, and I like the notion of a value exchange because it also applies to public sector work and applies to things beyond sort of the traditional software as a service model when you think about a value exchange being a broader set of concepts than simply an exchange of money for software.
Matt LeMay:
I think in terms of the day to day work, it's connection. It's connection, it's getting people connected. The work of product management is connective work. When I work with individuals, I do a lot of online trainings for O'Reilly where I'm talking to product managers from different companies, different roles, different titles across the globe, and the first thing I usually ask them is, who are the five people or roles that is most important for you to connect within your organisation in order to achieve your team's goals? And what's wild to me is you see how different the answers are that some people say it's a designer and a developer and executives, the kind of traditional product trio plus executive stakeholder model.
Matt LeMay:
Some people say it's sales and it's marketing and it's compliance or it's other product managers in the organisation if you're working on bigger, more complicated software. Some people say it's customers, number one, we're doing all the customer research ourselves if we're a really small company. And it's one of my favourite moments in these online trainings to stand back, let everybody in the training answer who are the top five people you need to connect? And seeing how different these answers are saying, Well, how could anyone suggest this is the exact same role from company to company? How would your day look the same if you are connecting and aligning customers with founders versus compliance officers with product owners versus marketing with sales versus designers with developers, it's so different.
Matt LeMay:
And that's just the order of roles. When you get into individuals and personalities, it gets to be this kind of multidimensional fractal of complexity that is a little bit different everywhere, but has I think some similarities, which I'm happy to talk about as well. But it's a wild role where you are learning new things every day for better or worse.
What does the day to day work of a product manager look like?
Charles Humble:
And given the huge range of things that it encompasses, so everything from company vision and strategy work to competitive analysis to user research to project management, what does the day to day work of a product manager look like?
Matt LeMay:
That's the question that we all struggle with. I think one of the funny things about the day to day work of a product manager is that many of us are horrifically busy, but also feel horrifically insecure about whether or not we're doing anything of value. A developer is writing code, is building the actual product, the designer is putting a visual, taking ideas and making them manifest. Product management as connective work, involves a lot of talking to people, it involves a lot of things that don't have deliverables attached to them. I say that about so many mistakes I made, but one of the biggest mistakes I made early in my product management career was prioritising work that created tangible deliverables where I could say, Look, I made this roadmap, I made this product spec, I did something all by myself. Look at me, I'm doing real work.
Matt LeMay:
But I think one of the things that product managers eventually grow to understand is that your success or failure is articulated through your team, not through you. Your team is building software. That software is what directly feeds this value exchange. If you're spending all your time making complicated documentation that your team then has to read and understand each one of those hops, as it were, where somebody has to receive information, synthesise it, reproduce it, apply it to their work, usually comes at a cost to that value exchange if it's overworked. So I think one of the most challenging things about product management is that you are, if you're doing the job well, probably going to have a lot of times throughout the day where you say, "Am I doing anything of value whatsoever? Am I just a useless appendage of this product organisation or am I somebody who's actually driving value?"
Matt LeMay:
And the only way you can really measure that is by the performance. And by performance I mean the ability of your team at large to do its best and work effectively towards the goals that you have set at a team level, not at an individual level.
Charles Humble:
I think that's really fascinating. I think there are parallels in other sort of senior management roles where you get to a point where... I know on my own journey, so I started... well, I started in tech support then as a programmer. And for a long time when I was writing software, I measured my value in the software that I was writing. And then at some point, I stopped writing software and started getting other people to write software. And that transition was one that I found really hard because it's like, well, kind of what am I doing? I don't think it's necessarily unique to product management, but I do think it's a particularly interesting thing that sort of "what value am I adding" question I think is a really key one.
Can you give us a bit of a clarifying definition as to how you see the differences between the product manager and the product owner Scrum role?
Charles Humble:
Something that you should probably clear up and it's something we've been chatting a bit at Container Solutions and with my colleagues at Engineer Better as well, there seems to be a lot of confusion around the Scrum role, the product owner role versus product management as well as things like delivery manager, program manager and so on. Can you give us a bit of a clarifying definition as to how you see the differences between, at the very least, between the product manager and the product owner Scrum role?
Matt LeMay:
So I'm going to answer this by way of a joke that I told on Twitter. So a product manager, a product owner and a program manager walk into a bar, the bar's on fire and there's a fire extinguisher sitting right next to the entrance of the bar. The program manager says, Okay, the first thing we need to do is figure out role clarity here. Who's responsible for what as it pertains to putting out the fire? And the product manager says, Well, this isn't strategic work, this is tactical work. This is just picking up a fire extinguisher and putting out a fire. I do strategic visionary work, this isn't for me. Meanwhile, the fire is burning and the bar is starting to collapse around them.
Matt LeMay:
So they turn to the product owner and the product owner says, I need to consult the Scrum manual. I'm not sure what exactly my role is supposed to be on this, but I'll look it up and I'll figure it out. Meanwhile, the bar is burning, beams are starting to collapse, the kegs are starting to explode. Finally, the program manager says, Okay, let's go back to the office. We will put together a steering committee to figure out who's responsible for what as it pertains to the fire at the bar. Everyone nods and they walk out as the bar collapses in on itself.
Matt LeMay:
That's how I feel about that question. Which is to say, gosh, what a waste of time. We make up titles and then we spend time trying to figure out what the difference is between made up titles rather than what work we actually have to do. Somebody once told me, and I'm sure this is an apocryphal story about a team which consisted of a product owner, a delivery manager, and a product manager and no engineers, and that was the whole team. And I see so many companies do this where they hire product managers and they're like, This didn't work, we need program managers. And then they go, This didn't work, we need delivery managers. And they just keep hiring more people with ambiguously defined roles rather than saying, What are we actually trying to do here? What is the problem we are trying to solve?
Matt LeMay:
If you want to sound bite something, here's a good soundbite. Conversations about role clarity are usually problems of goal clarity. And I will say that time and time again because when I sit down with teams and they say, We need role clarity, we need to know decision rights. And I say, All right, what are the goals you're trying to achieve? They never have a good answer. Because if you know what you're trying to do, then you can figure out how to do it together. If you don't know what you're trying to do, all you can do is have these endless fiddly debates over what is my specific responsibility versus your specific responsibility because there's no goal, there's no team unity, there's no sense of we're going to work together to achieve something.
Matt LeMay:
So instead it becomes we're going to work together to figure out what each of our individual roles is, as if that matters, which it usually doesn't. So I go back and forth between how dogmatic I want to be about this. I will say if you are a company which has multiple ambiguously descriptive product roles, figure out what the purpose of each one is and put those people if they're on the same team in a room together and ask them what they are working together to achieve. Because otherwise you wind up the joke I told, which is how I see this work at a lot of companies.
What skills do you need as a product manager?
Charles Humble:
So maybe a better way to think about this then would be to think about the skills you need as a product manager. So in your book, you have your CORE model with the handy acronym. Can you talk a bit about those CORE skills?
Matt LeMay:
So this was sort of the second order question to that first question of who are the people you connect? Because the question then becomes, well if you're connecting all these different people, what are the skills you need to do that? Because in the traditional model, which comes from the Martin Erickson blog post, What is a product manager? The skills as it were, are presented as some version of design, technology, and business, which I had the pleasure of talking to Martin, who was one of my favourite people in the world about that model for the product fireside chat. And he said, "Yeah, it was just my attempt to capture where I saw things on the teams I was working with. It wasn't meant to be a definitive anything."
Matt LeMay:
And of course when you publish something that is meant to be an example or a description, people will then say, great, this is the definition, this must be the way it is everywhere because people like having solid, consistent definitions. But in my experience, the four roughly skills and these can all be defined differently... I'm doing the same thing where I'm like, here's a model, don't take it as definitive and people take it as definitive. And I'm like, that's fair because that's what people do with models. But CORE is Communication, Organisation, Research and Execution. The definitions of these have changed over time. The guiding principles for two of these have actually changed in the second edition of the book, which I think is important.
Matt LeMay:
I think it's important to be able to say, yeah, all of these things change and evolve over time. If I had to publish it again today, I'd probably do it a little differently. But the idea is that communication is the ability to bring clarity to your team, to prioritise clarity over comfort and have uncomfortable conversations. Organisation, which you could also frame as operations is the ability to organise your team for sustainable success to essentially make yourself obsolete.
Matt LeMay:
Research is the ability to live in your user's reality, to make sure that you don't get so bogged down in company centric ways of thinking that you lose sight of what you're doing in the first place. And execution is really the ability to prioritise your time and your team's time to do what needs to be done to help you achieve your goals. And I knew this model was a pretty good model when I used it in my online trainings and people were able to see the differences between these skills and have different answers when I ask them, which of them do you excel at and which of them do you need to learn? I feel like if your model is differentiated enough, that people will have different answers, it's usually a pretty good sign, but there's at least some degree of cohesiveness or cogency or whatever word indicates that it is a relatively decent thing we want to use in that model.
If you are looking for potential product managers internally within an organisation, what is it specifically that you look for?
Charles Humble:
So just to take that a little bit further, if you are looking for potential product managers internally within an organisation, what is it specifically that you look for? What are the kinds of people that you're looking out for?
Matt LeMay:
I look for the connectors. So almost every organisation has people who are informal information brokers. They're like the people you go to when you want to know what's really going on. The people who are curious, who aren't afraid to walk out of a silo and talk to someone else and say, Hey, what's going on over here? What's going on over there? The people who again, are willing to get out of the comfort zone of their own role and their own silo in order to deliver better outcomes for the business.
Matt LeMay:
I feel like every company has those people and those people come from all over the place. They can be working in customer support, they can be working in content design. Sometimes they're engineers. They can really be coming from anywhere. But to me those are the people who have already shown themselves willing to do the most difficult part of product management, which is to take that extra step to expand your sphere of knowledge to say, I don't know, to learn from people who have different skills from yours. If you're already inclined to do that kind of connective work, you're probably going to actually enjoy product management. So it's always a pleasure for me to work with organisations and find those people who aren't going to resist the work and say, That's not my job, you're not paying me to do that, but who are just going to lead with curiosity and take that connective approach to everything they do.
What are your recommendations in terms of doing end user discovery?
Charles Humble:
So the CORE model is Communication, Organisation, Research and Execution. And I'd like to dig in a little bit more to the research part of that. So specifically, what are your recommendations in terms of doing end user discovery, end user research?
Matt LeMay:
I highly recommend Teresa Torres's book Continuous Discovery Habits is the best answer to that question. I joke with people sometimes that I had to do a second edition of my book, so I could recommend that book. My favourite thing about Teresa Torres's definition of continuous discovery is it's the entire product team having a touchpoint with the customer at least once a week. It's so simple. It's so simple and straightforward. Entire product team touchpoint with the customer at least once a week. And if you go on LinkedIn, whenever Teresa Torres posts that, there's a torrent of dudes, and it's almost always dudes, responding being like, Well, we can't do that here for the following 37 reasons. And it's like in the amount of time it took you to post those 37 reasons, you could have done the thing that she's saying to do.
Matt LeMay:
Again, I was very lucky, my business partner at Sudden Compass, Tricia Wang is an incredible researcher and she patiently, thoughtfully taught me how to do research. And what I learned from her above all else is that you have to do bad research before you can do good research. Part of why I think she is such a great researcher is that she let me make mistakes and then through retrospective said, Okay, great. How did that feel? What kind of information did you get? She really helped me understand how to do research by letting me fail.
Matt LeMay:
And in a lot of organisations I work with, trained researchers are terrified of letting product teams do bad research. They on the one hand say, nobody values the research I do. And on the other hand say, but if we let the product teams do research themselves, then the world will blow up in a giant fireball and everything will be terrible forever. And I think the reality is, you can't have both of those things. If you really want to get folks caring about research, you need to involve them in research, not just hand over PowerPoint decks and say, Here's the research we did, it's really important. What do you mean you don't want to deeply engage with my hundred slide PowerPoint deck? Why does nobody hear value research?
Matt LeMay:
So it's very much a self-fulfilling prophecy. I hate to say this, I love researchers, I want to empower researchers, but I feel like a lot of researchers wind up disempowering themselves by way of fear. And I think we can work together to alleviate some of that fear and make research a superpower for entire organisations. Because at the end of the day, your customers decide whether or not your product is going to succeed, right? It's your customers who are ultimately determining whether or not your value exchange is a successful value exchange.
Matt LeMay:
So the idea of keeping them at arms length from a product team... When I wrote my book about Agile, I'm honestly sick to death of talking about Agile as I suspect many of us are, with early readers, the most contentious thing in what I thought was a fairly spicy book about Agile was the idea that product teams should all talk to users. A number of people said, no, no, no, no, the Scrum manual is very clear, only the product owner is the voice of the user. And I was like, that's the stupidest thing I've ever heard in my life. Why would you want to have a single point of failure for the most important part of a product team's work?
Matt LeMay:
This idea that the risks outweigh the benefits of having entire teams interact with and learn from users and customers has been disproven so many times, so many different ways. At this point. I'm, if you don't want to do it, just don't do it. But stop asking me to present a 79 point argument for why you should just talk to your bleeping customers. Because you know you should, you just don't want to. So leave me alone.
Charles Humble:
It's such a bizarre thing, this, because so much of... I'm going to use sort of small a, agile because I think agile, the practice has turned into an entirely different thing, but I mean really the entire point of Agile is you need to be close to the people that you're building the thing for. So you break down all of the silos and you have conversations and that's it. This stuff isn't rocket science. Funnily enough, I got into a sort of Twitter argument with someone, so it's very top of mind for me at the moment about this over the weekend. But I think fundamentally the problem we get into is, we focus on process and practice and ceremony. And the reason we do that is because dealing with human products feels weird and scary. And so it's so much easier to go rather than dealing with the actual human problem.
Charles Humble:
Let's just say, Oh, well, the scrum manual dictates X or Y, but the Scrum manual dictating X or Y does not solve any problem for anybody as far as I can tell, we just focus on the wrong things. And I think you can see a similar thing happening in the Cloud Native movement with the focus on, you're not Cloud Native if you're not building microservices or not Cloud Native if you're not using Kubernetes and none of these things matter even slightly. Being Cloud Native is about being able to deploy frequently to production, being able to respond quickly to change all of those sorts of things. It's agility in that sense. That's what it means. And that's generally cultural, not technology oriented, but I think as an industry we have a real tendency to focus in on, as I say, on process and ceremony rather than on the point of these things.
Matt LeMay:
I totally agree with that. And I'm also seeing the dark inverse of that, which is folks saying that if you are working in a certain process or ceremony, you're not really a product manager or you can't really call yourself, which is also I think as ascribing way too much power to the framework. I've seen a lot of product managers and product owners or whatever you want to call them who work in highly regimented, Agile, scaled Agile, whatever, who are still doing really good work. And I think that if we're going to look to work beyond the framework, that also means giving up the idea that the framework is so all powerful in a negative way that it precludes us from doing good work. I think we just have to say the framework is a means to an end. It's fungible, it's not the most deterministic thing in the world.
Matt LeMay:
And whether you're working in a formalised Agile framework or outside of one or whatever, you still need to focus on the fundamentals on what you're doing to facilitate that value exchange. And all of these conversations about what is really capital like Agile, what is really product management, what is really Cloud Native, these are all made up things. It's very silly to spend this much time... I gave a talk at a conference in 2019 where, so that's kind of debating what is and is not punk. There's no definitive authority on this and you can get into perfectly entertaining debates about it for hours on end, but that's not what our job is. And at the end of the day, we just have to let it go.
Matt LeMay:
When I work with organisations, I don't even say Agile now. If they're like, what are we trying to do? Let's just talk about what we're trying to accomplish and not use buzz words. Not talk about product mindset, which is a cursed concept that I also am sick of talking about.
How do you avoid merely optimising for things that are quantifiable?
Charles Humble:
So this may feel slightly tangential, but there is a connection in my mind and that's a trap that I have personally fallen into and I'm just wondering if it's common. So it's to do with optimising for things that are quantifiable. So I can measure this, I can design AB tests around it or multivariate tests around it so I'm optimising for that as distinct from thinking about the problem from an actual end user's perspective. And again, I think it comes down to it's easier to optimise for things I can measure, and so I will do that. Is that a common thing or is that just me?
Matt LeMay:
No, that is a very common problem and I see it a lot with usage metrics with, well, we want people to use this thing or the amount of times people engage with this button. There's a story in the book which is anonymized, but it's my story, which is about the world's most useless AB test. And I went through this with a designer where the designer and I disagree about I think the placement of a button. I anonymized it in part because I didn't remember it quite well enough to put my name on it but the point holds. And we did the AB test and the designers variant "one", and I brought it back to her and I was like, "You were right, we can make your change." And she was like, "I'm not going to waste any more time on this." And I was like, "What do you mean?" She was like, "It's like 10 users who use this part of the site. It doesn't matter. It'd be a waste of time to actually make any changes to this."
Matt LeMay:
And I was like, "Oh, but I could measure it," and it was statistically significant and I could feel like I'm doing real product management and I'm doing this really great important stuff. So I've fallen into that too. And I think it's very tempting, especially given the ambiguity around the role to want to feel like a scientist and put on your lab coat and say, "look, I've solved the problem." But if there was a scientific way to do this, then every company would be successful. We're in the realm of human ambiguity. We're in the realm of human behaviour and emotions and I've come to just appreciate qualitative research.
Matt LeMay:
Again, my business partner, Tricia Wang has a great TEDx talk about the human insights missing from big data. And that's part of why I wanted to work with Tricia. She wrote an article years ago called Why Big Data Needs Thick Data? Thick Data being her brilliant rebranding of qualitative data to make it conceptually appealing enough to compete with big data. But I think part of it is that numbers give us a sense of control. They give us a sense of certainty and control and the world is not a place of certainty and control and we fall in love with that illusion at our own peril.
How do you see the product managers role with regards to senior stakeholders?
Charles Humble:
Now, you said right at the beginning that one of the big changes between the first and the second edition of the book was that in the first edition of the book lots of people wanted to talk about stakeholder management and that was less true in the second. But I'm still really curious about how you see the product manager's role, is it to inform, is it to try and influence senior management?
Matt LeMay:
So I have cooled on the word influence. I don't like using the word influence anymore. And I'll tell you why. Because in practice what I saw was a lot of product managers saying, Here's the outcome I want, now my job is to influence senior stakeholders to do this thing. The problem is, senior stakeholders often have access to information that you don't. And I'm not saying that's a good thing. I'm not saying that, that's a just or beneficial thing, but it's the reality at an organisation that senior stakeholders might know about an acquisition the company's planning, they might know about a leadership change that's happening, they might know about things that you don't know about. And I often tell product managers that your job is not to make the decision or to get the decision you want, it's to create an environment where people have all the information they need to make good decisions.
Matt LeMay:
And I also think it's important because in the interest of influencing, I have often seen product managers cherry pick information and only present the information that they think supports the approach that they want to take, which is also massively risky to the business. And I went through this when I went through my transition to being a product leader where I was like, I'm going to empower my teams. And people would come to me and say, I have this great idea, and I'm like, Great, I trust you, go with it. Then something would go wrong six months later and they'd say, Oh yeah, well, we knew this might happen. And I'm like, Well then why didn't you tell me? And they're, Because I wanted you to do the thing. And I'm like, that's bad. When I say I trust you, that means I trust you to present all the information.
Matt LeMay:
This isn't a zero sum game, you don't win by getting me to do the thing that you think is the thing. This idea of influence I think can be really dangerous because it suggests that you know what the best outcome is. In a lot of cases, again, senior stakeholders have information you don't. And if you can present multiple options to them, if you can help them understand trade offs, if you can really make them aware of the things that they likely don't understand at their altitude of information, then I think you are likely to see better outcomes than if you go in thinking everything and trying to induce a certain outcome by way of influence.
How do you go about prioritising things?
Charles Humble:
Yeah, because as you say, as a product manager, unless you're sitting on the executive team, you don't necessarily have all the information that the execs have and however open and transparent you want to be as an executive, sometimes you can't share things, either perhaps for legal reasons or maybe just because you're concerned about setting up instability with an organisation before something is final and then perhaps it won't work out and that can create bad feeling and so on. Another area that I'm really interested in is, how you go about prioritising things. And that seemed to me to be a big shift between the first and second editions of the book. Is that fair? What was causing that change in terms of how you think about prioritisation?
Matt LeMay:
Yeah, when I wrote the first edition, my experience was much more startup focused and I said, the clearer and more actionable your goals are, the easier prioritisation will be. And I think this was largely based on the experience I had of working at Songza where our CEO's office was right next to my desk and every quarter when he'd write our quarterly OKRs, he'd have his door open and say, Come on in and let's try test prioritising against these OKRs and whatever makes sense, makes sense and we'll just do this. And it was great.
Matt LeMay:
It was brilliant because we could stress test the OKRs until they were specific and actionable enough that we could actually prioritise a backlog we had against those OKRs. It was brilliant. It was the happiest I've ever been doing it. When you work at a big organisation or even a startup that is not as focused with as open and clear a CEO, I couldn't come up with a better analogy than this, but I think this is a useful analogy. It's like if you've got this big layer cake, right? This layer cake of different goals and objectives and things where you've got the company level strategy and then product KPIs and it's like this big messy layer cake and some of the layers taste really good together, some of the layers taste really weird together and your job is just to figure out how to take a bite of that layer cake. And there is no right answer.
Matt LeMay:
This is part of why I see so many product managers freezing around this because they say, Well, we have these strategic initiatives that have their own goals and outcomes and then we have our company strategy and then we have my domain level KPIs and they're in conflict with each other. There's not a clear step forward. And the reality is, there's probably not going to be. Given the complexity of most large organisations, you are going to have different people pushing things slightly different directions. You are going to have things that are not entirely clear with each other. And part of your job as a product manager is to have a point of view about what's going to be most impactful.
Matt LeMay:
Take the best bite you can and have a point of view about why that matters. But closer to that top of the cake of the company level goals you can make it, the more likely it is to be successful, I think. If you can speak to like this and therefore we will achieve our goals for the entire business, that usually resonates pretty well. But I do this in workshops where if you look at, for example, Spotify, they have a very public goal of a million creators being able to live off of their work. Is that perfectly aligned with what every team at Spotify is doing? Probably not. But does that mean that Spotify should never launch any product and their product managers should just complain constantly about how their goals are intention with company's mission? Of course not.
Matt LeMay:
It's your job to navigate that tension. It's your job to figure out how to turn that tension into something productive. So the number one thing I wind up telling product managers now is like, there's not going to be a clear path forward. This is not going to be simple and straightforward. You're going to have to make some tough decisions, make some trade offs, and take the best bite you can, but you can't let the cake just sit there until it disintegrates, you got to do something. It's challenging and difficult, but it's the job we signed up for, for better or worse.
What would you say would be the number one resource for aspiring or new product managers?
Charles Humble:
Now, you mentioned a few resources already. So you mentioned the Teresa Torres book, Continuous Discovery Habits, which I think came out about a year ago, as well as Melissa Perri's The Build Trap, which is a real favourite of mine, which is a fantastic book and what I reference a lot and Tricia Wang's TED Talk and a couple of blog posts and things. So I will include links to all of those in the show notes. But for people who are listening to us who are maybe aspiring product managers or new product managers, what would you say would be the number one resource for product managers, maybe starting out interested in the field? What would you say would be the number one resource for them?
Matt LeMay:
I'd say the number one resource I always recommend to product managers is each other. Talk to product managers in your network. You will learn more from one conversation with a working product manager than you will from any book, including mine, I think. Because again, the ambiguity and the variability of the role means that everybody's individual experience is going to be so different and the stories and lessons and things that people are dealing with in the moment to moment, so interesting and so valuable. So I'd say yes to books and articles and talks and all those things. But above all else, go meet the product manager for coffee and talk to them and ask them what they're working on and what they're navigating. Because if it's live and in play, there's something to it.
Charles Humble:
Absolutely. That's fantastic advice I think. Matt, thank you so much for taking the time to join me this week for this episode of the Hacking the Org podcast, from the WTF is Cloud Native team here at Container Solutions.
Previous article
