David Brown

Welcome to episode 74 of Coding Over Cocktails. My name is David Brown. I'm the founder and CEO of Toro Cloud and I'll be your host for today's episode of Coding Over Cocktails. Our guest for today is an internationally recognized expert on product management and agile. He is the author of Agile for Everybody and product management in practice. He has helped build and scale product management practices at companies ranging from early stage start ups to fortune 500 enterprises. He's also the co-founder and partner at South Compass, a consultancy that has helped organizations like Spotify, Clorox Google and Procter and Gamble. Put customer Centricity into practice. He's also a musician, recording engineer and the author of a book about singer songwriter Elliott Smith. Joining us today for a round of cocktails is Matt LeMay. Hi, Matt. Great to have you on the show.

Matt Lemay

Thanks for having me. Happy to be here.

David Brown

Good. Well, I guess the obvious question is what is a product manager

Matt Lemay

if you figure it out? Now, please tell me that's, you know, I think one of the things that makes product management so interesting. And so infuriating is that if you ask 50 people, I'd say 10 of whose job it is to answer that question, All 50 people will have a slightly different answer. So, um you know, my favorite, my favorite definition of the, the responsibility of product management comes from Melissa Parry's book escaping the build trap where she says that a product manager facilitates a value exchange between the business and its customers. Um So that might be a value exchange in terms of software for revenue or software for attention, which then gets monetized via advertising. So it's very, very hard to define what a product manager is and does because if you ask 10 product managers, what they do all day, you'll get 10 very different answers. So it

David Brown

is it different from a product owner? Like what are some of the similarities differences or?

Matt Lemay

Yeah, this, this one's really tough, right? Because there is an academic answer to that question, but it's not always true. The academic answer to that question is that a product owner is a specific defined role on a Scrum team. Whereas a product manager is a set of possibilities that kind of exists outside of that type of development framework where this gets tricky is that there are some organizations I've worked with who define it the exact opposite way. I actually stood in front of a room full of executives and gave that academic answer. And one executive stood up and said, um excuse me, why on earth would we define the person who manages the product team as the product owner? And the person who owns the outcomes of the product is the product manager that makes zero sense. And I had no good answer to that other than, but the Google said it was the other way and most people do it the other way. So my, my necessarily unsatisfying answer to that entire set of questions around. What's the difference between a product owner and a product manager, program manager and a product manager, a delivery manager is, is you kind of have to ask locally, you have to ask the particular organization that is hiring for or defining those roles because they are gonna have their own, their own definition of their own way of doing things.

David Brown

OK. Well, can you tell me what are the prerequisites ski prerequisite skills for product manager?

Matt Lemay

Sure. So in, in my book, I have a skill model called called core, which is communication, organization, research and execution. I I don't necessarily think of those as prerequisite skills because one of the defining characteristics of product management is given how ambiguous and let's say dynamically defined it is you're always gonna need to be learning new things. So I say the, the sort of pre the preconditions I look for when I'm hiring or advising folks who wanna transition into product management is just a tendency to, to be curious and to connect. Um There's an exercise I run with a lot of companies when they're looking for internal product management candidates where they map out how information informally travels in the organization. So, you know, you have your formal org chart, but usually there are some people who, who are just connectors by nature who might be copywriters or engineers or designers. But when you ask somebody, how do you know what's going on in the organization? They say, so and so talk to me and talk to so and so those people whose natural inclination is to look beyond the formal boundaries of their role and do what makes sense in order to maintain a flow of information within the organization. Those are usually the people who take the product management really well, because again, given the ambiguity around the roles, definition and how important that ultimate responsibility is of facilitating that value exchange. If you know a lot of folks who work in products say that that's not my job is never a good thing to hear from a product manager because if it needs to get done, it needs to get done. So people who will naturally take a curiosity in the work of others who will have those conversations who are looking to connect and synthesize and build bridges across different functions and different disciplines tend to be the people who take most naturally and most easily to a product management role in my experience.

David Brown

Yeah. And I guess, you know, that sort of communication and facilitating skills, kind of soft skills if you like, I, I'm, I'm also wondering what sort of hard skills like you need. For example, if you're gonna be a product management manager for a software product, there's obviously a certain amount of technical expertise required to understand what the product does. So do you need to bring with you vast amounts of domain knowledge on that space of what that product does for it to be a good product manager?

Matt Lemay

My short answer is no, but I think it depends a lot on the product, right? If you're working on a highly technical. So to give you an example from my own experience, um my first product management role was managing an API and I did not know what API stood for when I got that job. Um I,

David Brown

I would say that's not a vast amount.

Matt Lemay

No, I am inclined to agree with that. Um But, you know, it's funny because I kind of fixed my way in with the technical knowledge I had, which was very outdated technical knowledge. It was very like I was a web developer in the late nineties. Like, I mean, I built my first website in Pearl back in the day. So that's, you know, giving you a sense of where I'm coming from here. Um But once I actually got into the role, I found that in some ways, my technical knowledge was a hindrance more than a help because I was leaning back on the things I knew rather than asking about the things I didn't know. I've seen really effective product management from people who don't have a technical background. If they're really curious about technology, if they're willing to go to their engineering team and say, hey, can you explain to me how this works? Can you help me understand this learning in context is always the most valuable way to learn because you're learning about the actual systems that your software is built in rather than doing what I did and going off and trying to read a bunch of books and showing up like greetings, fellow developers. I hope that that no sequel is good today, which they were just, what are you doing? Just don't, you don't try. Um So again, I think a lot of it just comes down to curiosity. I will say, I think if you believe that you are a non technical person and that you cannot learn and cannot engage with technical concepts, that's gonna be a big problem. Product managers were like, well, I'm not technical, I don't understand anything that's an incurious approach, right? That is not a connective approach that is not gonna work for you. Um But I've seen product managers who have very little technical knowledge, but a lot of technical curiosity who actually make the developers on their team stronger because those developers are then learning how to explain those concepts to non technical folks, which is really valuable. Um I remember when I was trying to learn about no sequel about sort of non relational object oriented databases. And I was sitting down with a, a data engineer and I was like, um and eventually he was like, you know, you can kind of think of a relational database as a Excel spreadsheet and a no SQL database has a word document. So like you can put structure in there if you want, but there's not one structure. And I was like, my God, it just clicked for me. Thank you. That's amazing. Um So I think those conversations between technical and non technical folks are really important conversations and product managers need to fearlessly facilitate those conversations.

David Brown

Can you find, do you find sometimes it's um resentment amongst developers and those technical people that they have more knowledge than you do?

Matt Lemay

Only if I try to, only if I lead with my knowledge. In other words, like when I was trying to be like, look, I know stuff too there. Absolutely was resentment because I, I don't know as much as they do. It's not my job to know as much as they do. It would be weird if I knew as much as they did um As soon as I was just like, I'm really curious, like, tell me more. This is really cool and exciting. They like that because everyone likes having an interest taken in their work. I think a lot of people assume that other people don't care about the work. They do. I remember a, a data scientist on my team being like, I thought you just thought we were a bunch of nerds and I was like, no, I thought you were like the cool kids. I thought you were at like the cool kids table. They were like, we don't, we didn't think we were the cool kids. So I think if you can just take a genuine interest in the work that somebody does, that's a much more collaborative stance as opposed to trying to have a competition based on knowledge which you will generally lose and alienate people trying to suggest that, you know, as much as, or more than they do at their actual job.

David Brown

Hm. We, we've talked about some of those soft skills like communication, building bridges, curiosity, what, what recommendations or suggestions would you have for a product manager to deal with company politics and dealing with senior stakeholders?

Matt Lemay

Sure. So when I, when I did the first edition of product management and practice, I, I asked the question to a lot of product managers, which is the same question I asked when I was researching the second edition, which is what's one story from your work that you wish somebody could have told you on day one so that you could avoid making the most painful mistakes you've made in your product career. For the first edition. Almost all of the answers were about executive stakeholder management, which was really interesting because that's not what I anticipated. I thought it was gonna be more about like product development frameworks and agile. But the big theme was like, every time I've tried to do like a big wow presentation and impress senior stakeholders, it's backfired on me. Um You know, I think there's this idea, there's kind of this fantasy that your job is to sort of influence and shape the decision making of senior stakeholders, like sort of trick them into making the decisions that you want them to make. And that doesn't work. I think that no, it doesn't and it, it tends to backfire in part because sometimes you will, in order to get someone to do what you want, you usually have to be selective in the information you present, right? I've worked with a lot of product managers who are really excited because they presented cherry picked data one option. They argued for the one thing they wanted to do and executive setting. Yes, that sounds great. And then the thing didn't work, the executives turn around and say, well, wait a second, you told me this was the right thing to do. You said the data suggested this was the right path. What happened. And the pro is like, well, you know, there was some other stuff I didn't necessarily tell you and that's a bad look, that's just not good that, that obliterates trust. So I think that the thing I've been been thinking about and my own thinking about this has been changing a fair amount of late. But I think, you know, your job is to inform senior stakeholders. So they make the best possible decisions, not to influence them to making the decision that you want them to make. Because in a lot of cases, they know things you don't know, that's just the reality of organizations, right? They might know that a big acquisition is about to happen or they might know that the CEO is about to leave, they might know something which affects corporate strategy in a way that you simply don't know. So your job is to present all the options that exist to make them aware of the tradeoffs of each of those options, which they likely do not understand unless you make them aware of them because they're not close enough to the work being done. And then to trust that there's some reason behind it, even if it's not a reason you like. And if you can accept that, then your life will be much easier than if you spend most of your career raging against the fact that executives did not make the decision, you wanted them to make.

David Brown

Yeah, it's because you're gonna get good at dealing with rejection, right? So, like you said, they may have other reasons, you may, may be unaware of for the, the purpose of their decision. They don't necessarily enlighten you on the, the reasons for their decision. but they, and they can often senior management can be brutally blunt and direct to the point. Right? And so as a product manager, you have to be dealing with that kind of feedback.

Matt Lemay

Absolutely. And that's, that's why I always tell product managers to present multiple options and to be clear about the tradeoffs of each one because then, you know, there, there is no, there is no, yes, there is no, no, there is no rejection, there is no acceptance, there's just choices and um that's I find just a healthier framework and also makes it easier to adjust course because if you then learn that the choice that was chosen isn't working the way you had hoped, people are aware of other options and can start to be like, well, what about that other thing you presented? Maybe like maybe we're launching this product to the wrong market or maybe, um you know, this wasn't as good an idea as we thought it was. And this other thing, it's always good for there to be a move. You always want to just present, present multiple options and multiple moves so that there's a move to make, you don't get stuck.

David Brown

Now, we haven't talked about the users of the product yet. So I, I'm guessing they have a say as well. And I'd like to know where they come into the picture at what stage and, and how you build a customer feedback loop. Um You know, in, in today's day and age with digital transformation, The whole point is to listen to the customer and be close to the customer, allow people close to the customer and make decisions and inform the direction of the company. So what's your perspective on incorporating the end user feedback into product development as a product manager?

Matt Lemay

Sure, I mean, so the, the the short answer in my perspective is a recommendation of the book Continuous Discovery Habits by Teresa Teresa Torres, which is such a wonderful book which really gets into like all the details of how to do discovery as a team. Um I think Theresa Torres has done so much for the product community, but my favorite thing she's done is she defines continuous discovery as the team learning directly from customers at least once a week. Um And I love that because it's so practical. It's, it's not like a mindset, kind of like it's the way you think about it. She's like, are you talking to your customers once a week? And it's wild to me on linkedin whenever she posts this, they'll get like 50 comments of people being like, well, we can't do that for these reasons. It's like, you, you can do that, like, once, like, learning from customers once a week is not an absurdly onerous suggestion. I'm like, that's pretty straightforward. Um, so open ended. There are so many different ways to do it. Um, you know, I think,

David Brown

and, you know, that the product manager specifically should be speaking to customers once per week.

Matt Lemay

I think the whole team should be. I mean, the research is most effective when it's a team sport, it's, you know, I think product development world, there's this kind of myth that I feel is, is less strong than it was several years ago that developers don't wanna learn from customers. They don't care about why they're doing what they're doing, they don't care about, they just want to like sit with their headphones on and write code all day. That doesn't describe 99.9% of the developers I've met like developers are people and get excited when they're solving a problem for other people and when they're learning from people and they're like,, this is so cool. I help make someone's day better. Like, so, you know, I think the answer is almost always to just get decision makers and users closer together. Um My, my business partner and I did some work with a AC PG company in California a couple of years ago where we, I don't want to say, we ambushed them. Exactly. But we surprised them. We asked them, you know, what's a company that you heard is doing interesting things around customer service? So we said,, Home Depot and we said, great, let's go there and they got so nervous. They were like, well, well, no, we're, we're gonna learn about digital transformation. We like, no, we're gonna go to Home Depot and talk to people. Um, at first they were so nervous. They were like, well, what don't we ask them? What do we do? What do we say? And like, you know, don't worry, we'll show you we'll, we'll help you out. And um it was really fun because we, we went with them and at first they were really nervous. They didn't know what to do, but like within a half hour they were having a blast. They were like talking to people about their weekend barbecue plans and they were talking to people about like what they're shopping for and why they like shopping at Home Depot. I think one of the funny things about hierarchical title oriented business as it does sort of distance us from our fundamental humanity, right? Like when you reduce somebody to a title and place them in a hierarchy, um we sort of develop artificial methods of, of relating to each other as opposed to just being like, greetings fellow human. How are you, what do you care about what's going on and part of what I like about user interviews and team centered user interviews is like, it reminds us that we're just people working on stuff with other, for other people and with other people. Um There's a, a like, you know, in, in my book, I say, live in your user reality, in your user reality. Like, they don't care about product development processes. They probably don't care that much about your product. They're just trying to live their life and like do what they wanna do. So I think, you know, the more directly you can make decision makers which ranges from like, you know, the people doing the work hands on making technical decisions to the executives making, you know, corporate strategy decisions, the more those decision makers can have direct interaction with users, the better their decisions are gonna be.

David Brown

Hm, that's a good segue to my next question you mentioned, you know, they're not product managers, they don't understand the, the, the principles of it and they don't necessarily even care about the product. It's just a, it's a might be just a tool to get their job done, you know, so they can move on to the next thing. Um Steve Jobs famously said it's not the customer's job to know what they want. So how do you move beyond that customer feedback loop, particularly in technology, which can be so innovative and think beyond customers feedback and incorporate thoughts which the customer couldn't even, wouldn't even occur to them.

Matt Lemay

Sure. So that's one thing. There are the two kind of quotes that often get trotted out in this context. There's this Steve Jobs quote and,, the Henry Ford quote, I, the Henry Ford quote. A, he never said that B Henry Ford was like a horrible person who,, was famously anti Semitic and awful in lots of different ways. So,, yeah, don't, don't trot that one out. Um You know, Steve Jobs said a lot of things. He said that he also said that you should always understand the customer needs your solvent for before you think about the technology. And I think that, you know, the iphone is a really good example, right? Because I, when the iphone was introduced, if you would ask me, do you want an iphone? I would have said absolutely not like a $700 phone. Like that's crazy. I don't need a phone with a, how do you type on it? You know, I was like, I was like, it's like a blackberry without a keyboard. That's stupid. Nobody wants that. But if you had talked to me and observed my behavior, right? I was using a Motorola Razr phone back in the day. Um What was I doing on that Motorola Razr phone? I was scrolling down to the bottom of the menu and picking email. I'm going down and checking my email and I was going to the terrible internet browser and going to the internet and saying like,, can I see this website? So I know like, what the restaurant is that my friends are going to. So I think it is not a product, like you can't ask your user to do your job for you, right? Your users don't necessarily know like what product solution they want, nor is it their job to know what product solution want? But I feel like a good researcher would have looked and I'm sure that there were good researchers in Apple who did this research. Um Apple does a lot of good research. The idea that Apple doesn't do research, which is nobody's ever said that that's just been extrapolated out from some people from quotes like that. It's not true if you looked into how people were using feature phones. Um the case for a smartphone would I think emerged pretty organically if you think about a smartphone as a computer in your pocket, not a expensive phone or like an ipod, that's also a phone, which is how I thought about it. So, you know, I think that again, when I say live in your user reality, your product features minimally into your user's reality, almost certainly. But if you can understand the broader, you know, my business partner, Tricia Wong at Sudden Compass, she's an ethnographic researcher and she is so good at doing like high level exploratory discovery level research. And I've learned so much from working with her. Um There are so many times when we've gone in to learn things and we've zoomed out and found that the decisions we thought were important were actually not that important at all. But we were optimizing a thing which was fundamentally on the wrong track, right? That we were optimizing solutions to the wrong problem. Um So I think, you know, the user research, it's really easy to fall into that optimization trap. It's really easy to run a lot of A B tests and focus on what's quantifiable rather than doing that high level discovery work. But it's in that high level discovery work when you are immersing yourself in what matters to your customer that you often break out of, break out of some of those patterns and learn the things that genuinely surprise you.

David Brown

And if you were coming into a role as a new product manager, and you've been briefed by senior management as to the requirements of what they want to build and, and what they're looking for and the direction they want to take and you've spoken to your technical team and what they're working on and where they're currently at. When do you, when do you start talking to the customers?

Matt Lemay

I'd say right away. I mean, I think there's always, and it's funny because like every corner of product development is, is I think drawing closer to that understanding. I'm reading a really good book on my desk. Right now um by April Dunford called obviously Awesome about product positioning. And I, I let out an audible hell yes, when I was reading this because it says that basically like your users decide, but they don't, you know, decide, but what your differentiators are, you learn from your best customers, somebody made a choice to use your product and they understand your product probably better than you do because they understand the problem that your product is solving better than you do. So rather than you making a list and saying here are our differentiators because we do competitive analysis. If you go to your best customers and you're like, why did you pick us? You're gonna learn a lot really quickly about what actually matters to them. And I think there's a tendency, you know, there's a tendency to want to be a visionary and to be like, I came up with the answer, I figured it out and I think it can be disappointing for people when it's like you just got to talk to your users and like, learn again how to not be like the bold brave visionary, but just be a thoughtful facilitator. Learn how to, you know, ask open questions and not bringing your own assumptions. I think that's less exciting for people that's certainly less glamorous, but it works a lot better.

David Brown

Which, which is the important thing. You've also written a book on agile. In fact, you dedicated a section of the product management book on agile as well. So, are these two disciplines complementary?

Matt Lemay

You know, I gotten no offense to anybody in particular, but I've gotten really exhausted by agile world. Um because it's made up, it's a made up thing. Like all these frameworks and methodologies are made up. The Agile Manifesto is 68 words written by 17 people 21 years ago. Um The amount of power and authority we delegate to made up things is so weird. It's so weird to me that people are like, well, you can't do that. That's not what the Scrum manual says. And I'm like, no, the manual made up like the thing that people made up and are constantly changing. We're gonna break the secret code of it like it's, you know, at the end of the day, the whole point of agile as I understand it is like, try stuff and see what works for you. And some of the signers of the ads manifesto Andy Hunt wrote a great article called The Failure of Agile where he was basically like, yeah, this was a really simple, like I believe the exact words he used were agile asks practitioners to think and frankly, that's a hard sell and I think that kind of sums it up, right that everyone especially enterprises are looking for like some magical silver bullet that's gonna make them innovative and make them, you know, work like a start up, which is also like, have you ever worked at a start up? Why, why people want to work like a start up is still mind blowing to me. It's like, look at that garbage fire over there that just laid off like 30% of their employees. We want to be more like that. Why do you want to be more like that? Find the best way to be what you are? Um So I, you know, my, my approach to AGL these days, there's a subsection of the book that was really fun to write called Seven Conversations About Agile. I never want to have again. Um It's, it's a lot of people wasting a lot of time talking about, easy to talk about proxies for the thing they actually need to talk about. In other words, it's easier and safer to fight. No pun intended safe, safer to talk about methodologies than to talk about actual human problems. Um It's easier to be like,, we're gonna do a transformation where we switch from one methodology to another to being like, what's the actual problem we have here? Like, what, what specifically are we trying to accomplish? And what specifically is stopping us from accomplishing it. And when I did advi consulting with companies, my first question to leaders was usually all right. If you know exactly where you need to go, why aren't you there yet? And had a hard time answering that question. And if they said it's because we're not at, I was like, nope, sorry, that's, that's not a real thing. Like, what are the specific reasons? And I feel like agile in general has just in a lot of ways become this, like hazy hazy smokescreen for talking about things that aren't the real thing. And I try to spend less of my time talking about that and more time talking about the real thing because I'm

David Brown

well, I think the product management and practice is, is the real thing and that's why people should be looking for that. So it's published by o'reilly. It is indeed. Yeah. And ava presumably available on amazon.com. where can our listeners follow you, Matt you have particular channels you like to um announce things.

Matt Lemay

Yeah, you can follow me on linkedin. You can find me on Twitter at Matt Lame. I am a, I am not a frequent tweeter but I tweet occasionally. Um you can subscribe to my newsletter at Matt lame.com and also just find, you know, I, I am not a content factory. I write, I think fairly slowly. So if you go to Matt lame.com, you can find some articles I've written in the past that I still think are quite good. Um And I always tell product managers like I love to hear from you if you have any questions, if there's anything you're not sure about. Um send me a message on linkedin. Send me an email ma of melanie.com and easy to find or send me a Twitter message. Um You know, the, the joy of this work for me is seeing how things work in the real world. So if anybody has any questions or any experiences to share, I'm always really happy to hear from you,

David Brown

Matt LeMay. Thank you very much for joining us today on Coding over Cocktails.

Matt Lemay

Thanks for having me.

David Brown

Bye. All right. That's a wrap. Great. Thank you so much. That was, my first solo, podcast.

Matt Lemay

Congratulations

David Brown

on the questions. Parts is what I normally do, but the intro and outro is normally somebody else. So, but,, yeah. No, cool. Thanks for that,, very easy guest,, to have a chat with. So I appreciate that. Of course. What, what, what time zone are you in? Where are you based? I'm in London., right. Ok. Is, this is too crazy hot over there at the moment?

Matt Lemay

No, not at the moment. We made it through that. Yeah. And you're, you're in Australia, right?

David Brown

Yeah. And that's,, we've kind of got,, the English weather you normally have in Australia and you've got the 40 degree days that we normally have.

Matt Lemay

I, you know, I moved here in the hopes of not having to experience 40 degree days. I'm not a hot weather person. So,, we'll take it back whenever you're ready to. We're ready again,

David Brown

we, we got to the, just the,, actually, I shouldn't say that today was a stunning day, but we have had months and months of rain and pretty ordinary weather. So, anyway, what are you gonna do? Climate change? What are you gonna do? Yeah. Enjoy the rest of your day. And by the way, we will, we'd normally turn these around in a couple of days., the whole editing process, we will then Aaron will then be in touch with you with all the links and also stuff and some little badges and whatnot that you can post if you choose to on your linkedin or Twitter channels. And, and we then we then repurpose it and pro promote it on multiple channels as well. It goes, goes up on obviously all podcast channels and streaming sites and all sort of stuff, but we do repurpose it as blogs and whatnot as well.

Matt Lemay

Perfect.

David Brown

Ok, great. Thanks very much.

Matt Lemay

Thanks so much. Take care. Bye.