Making of a Product Manager with Matt LeMay

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 recognised 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 startups to Fortune 500 enterprises. 

He's also the co-founder and partner at Sudden Compass, a consultancy that has helped organisations 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. [laughter] That's, you know, I think one of the things that makes product management so interesting and so infuriating; it’s 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, my favourite definition of the responsibility of product management comes from Melissa Perri's book, Escaping the Build Trap, where she says that a product manager facilitates a value exchange between the business and its customers. So, that might be a value exchange in terms of software for revenue or software for attention which then gets monetised via advertising. So it's very, very hard to define what a product manager does because if you ask 10 product managers what they do all day, you'll get 10 very different answers. 

David Brown

Is it different from a product owner? Like what are some of the similarities, differences?

Matt LeMay

Yeah, 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 risk responsibilities that kind of exists outside of that type of development framework. 

Where this gets tricky is that there are some organisations I've worked with who defined that 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, “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 as the product manager? That makes zero sense!” 

And I have no good answer to that other than, “But Google said it was the other way and most people do it the other way.” So, my necessarily unsatisfying answer to that entire set of questions around what's the difference between a product owner and a product manager, a program manager and a product manager, [or] a delivery manager is, you kind of have to ask locally. You have to ask the particular organisation that is hiring for or defining those roles because they are going to have their own definitions in their own way of doing things.

David Brown

Okay, well, can you tell me what are the prerequisite skills for a product manager?

Matt LeMay

Sure. So, in my book, I have a scale model called CORE, which is communication, organisation, research and execution. 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, they're always going to need to be learning new things. So, I'd say that the sort of preconditions I look for when I'm hiring or advising folks who want to transition into product management is just a tendency to be curious and to connect. 

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 organisation. So, you know, you have your formal order chart but usually there are some people 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 organisation?” They say, “Well, 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 organisation, are usually the people who take product management really well. Because again, given the ambiguity around the role’s definition and how important that ultimate responsibility is facilitating that value exchange. 

If you know, a lot of folks who work on products say that “that's not my job” is never a good thing to hear from a product manager because 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 synthesise 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'm also wondering what sort of hard skills you need, for example, if you're going to 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 you to be a good product manager?

Matt LeMay

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

David Brown

Alright. [laughter] I would say that's not a vast amount of domain knowledge.

Matt LeMay

I am inclined to agree with that. But you know, it's funny because I kind of faked 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 90s, like I built my first website in Perl back in the day, so that's  giving you a sense of where I'm coming from here. 

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 didn't, going off and trying to read a bunch of books and showing up like, “Greetings, fellow developers. I hope that noSQL is good today. What are you doing?.” Just don't try.

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 going to be a big problem. Product managers who are 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 going to work for you. 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. 

I remember when I was trying to learn about noSQL, about sort of non-relational, object-oriented databases and I was sitting down with a data engineer, and eventually was like, “You know, you can kind of think of a relational database as an Excel spreadsheet and noSQL database as 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!” 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

Do you find sometimes there's some 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, “Look, I know stuff too,’ there absolutely was resentment because I don't know as much as they do, it's not my job to know as much as they do. I would be weird if I knew as much as they did. 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 their work. I do remember 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 like the cool kids table.” They were like, “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

We've talked about some of those soft skills, like communication, building bridges, curiosity, 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 in Practice, I asked a 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 going to be more about  product development frameworks and agile, but the big theme was like, “Every time I've tried to do a big wow presentation and impress senior stakeholders, it backfired on me.” 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.

David Brown

It doesn’t go down well?

Matt LeMay 

No, it doesn't and it tends to backfire in part because sometimes, 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. Executives said, “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 product manager was 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 obliterates trust. So, the thing I've been thinking about in 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 make 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 organisations, 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 trade-offs 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. 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 going to get good at dealing with rejection, right? So, like you said, they may have other reasons, you may be unaware of the purpose for their decision, they don't necessarily enlighten you on the reasons for their decision, and often senior management can be brutally blunt and direct at 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 why I always tell product managers to present multiple options and to be clear about the trade-offs of each one because then you know [that] there is no “yes,” there is no “no.” There is no rejection, there is no acceptance. There's just choices. That's, I find, just a healthier framework and also makes it easier to adjust of 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 start to be like, “Well what about that other thing you presented? Maybe we're launching this product to the wrong market,” or “Maybe this wasn't as good an idea as we thought it was.” It's always good for there to be a move. You always want to just  present multiple options and multiple moves so that there's a move to make [so] you don't get stuck.

David Brown

We haven't talked about the users of the product yet, so 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 how you build a customer feedback loop. You know, 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's feedback into product development as a product manager?

Matt LeMay

Sure. So the short answer in my perspective is a recommendation of the book, Continuous Discovery Habits by Teresa Torres, which is such a wonderful book, and really gets into all the details of how to do discovery as a team. I think Teresa Torres has done so much for the product community, but my favourite thing she's done is she defines continuous discovery as the team learning directly from customers at least once a week. 

And I love that because it's so practical. It’s not like a mindset-y 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 can do that once, like learning from customers once a week is not an absurdly onerous suggestion, like that's pretty straightforward. It’s so open-ended, there are so many different ways to do it. You know, I think product managers specifically should be speaking to customers once per week. I think the whole team should be. I mean research is most effective when it's a team sport. 

I think in the product development world, there's this kind of myth that I feel is less strong than it was several years ago, that developers don't want to learn from customers, they don't care about why they're doing what they're doing, they don't care about them. They just want to sit with their headphones on and write code all day. That doesn't describe 99.9% of the developers I've met. 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 helped make someone's day better!” 

So you know, I think the answer is almost always to just get decision makers and users closer together. My business partner and I did some work with a CPG company in California a couple of years ago where, I don't want to say we ambushed them exactly, but we surprised them. We asked them, “What's the company that you heard is doing interesting things around customer service?” [and they said], “Oh, Home Depot!” and we said, “Great! Let's go there!” and they got so nervous. “Well, no. We're going to learn about digital transformation.” “No, we're going to go to Home Depot and talk to people.”

First, they were so nervous about, “What do we ask them? What do we do? What do we say?” You know? “Don't worry, we'll show you. We'll help you out.” And it was really fun because 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, they were talking to people about what they're shopping for and why they like shopping at Home Depot. 

I think one of the funny things about hierarchical title-oriented businesses, it sort of distances us from our fundamental humanity, right? Like when you reduce somebody to a title and place them in a hierarchy, we sort of develop artificial methods 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-centred user interviews, [is] it reminds us that we're just people working on stuff for other people and with other people. 

You know, in my book, I say,  “Live in your users’ reality.” In your users’ reality, 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 do what they want to do. So I think, you know, the more directly you can make decision makers – which ranges from  the people doing the work hands-on, making technical decisions to the executives, making corporate strategy decisions –  the more those decision makers can have direct interaction with users, the better their decisions are going to be.

David Brown

That's a good segue to my next question. You mentioned, you know, [if] they're not product managers, they don't understand the principles of it and they don't necessarily even care about the product. It might be just a tool to get their job done so they can move on to the next thing. 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 wouldn’t even occur to the customer?

Matt LeMay

Sure, so there are the two kinds of quotes that often get trotted out in this context. There's this Steve Jobs quote and the Henry Ford quote. The Henry Ford quote, (a.) he never said that. (B.) Henry Ford was like horrible person who was famously anti-Semitic and awful in lots of different ways. 

David Brown

Right, glad I didn’t pick that one, then. [laughter]

Matt LeMay

Yeah, don't trot that one out. You know, Steve Jobs said a lot of things. He also said that you should always understand the customer needs you're solving before you think about the technology and I think that you know, the iPhone is a really good example, right? Because when the iPhone was introduced, If you had asked me, “Do you want an iPhone?” I would have said “Absolutely not.” Like a $700 phone? That's crazy. I don't need a phone with a how-do-you-type-on-it, you know? 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 behaviour, I was using a Motorola Razr phone back in the day. What was I doing on the Motorola Razr phone? I was rolling down to the bottom of the menu and picking email from 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 what restaurant my friends are going to?” 

So, I think you can't ask your user to do your job for you, right? Your users don't necessarily know what product solution they want, nor is it their job to know what product solution they 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. 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, the case for a smartphone would, I think, emerge pretty organically if you think about a smartphone as a computer in your pocket, not an expensive phone or like an iPod that's also a phone, which is how I thought about it. 

So, I think that again, when I say live in your users’ reality, your product features minimally into your users’ reality almost certainly. But if you can understand the broader… You know, my business partner Tricia Wang at Sudden Compass, she's an ethnographic researcher and she is so good at doing high-level, exploratory, discovery-level research. And I've learned so much from working with her. 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, that we were optimising a thing which was fundamentally on the wrong track, right? That we were optimising solutions to the wrong problem. 

So I think, you know, for 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 some of those patterns and learn the things that genuinely surprise you.

David Brown

And if you're 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 what they're looking for in 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 start talking to the customers?

Matt LeMay

I'd say right away. And it's funny because like every corner of product development is, I think, drawing closer to that understanding. I'm reading a really good book on my desk right now by April Dunford called Obviously Awesome about product positioning and I let out an audible “hell yes” when I was reading this because it says that basically, your users decide what 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 differentiators because we did 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 to people. It's certainly less glamorous, but it works a lot better, which is the important thing.

David Brown

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,  no offense to anybody in particular, but I've gotten really exhausted by agile world 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. 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, annual 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 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 where 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 startup. Which is also like, have you ever worked at a startup? Why people want to work? Like a startup 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? And the best way to be what you are? Um, so you know my, my Approach to agile these days, there's a subsection in 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 when I did adult consulting with companies. My first question to leaders was usually alright if you know exactly where you need to go, why aren't you there yet? And I had a hard time answering that question and they said it's because we're not acting. I was like nope, sorry, that's that's not a real thing. Like what are the specific reasons? And I feel like and in general has just been a lot of ways become this like hazy, hazy smoke screen for talking about things that aren't the real thing and I try to spend less of my time talking about that. I'm talking about the real thing because

David Brown

Well, I think "Product Management in Practice" is the real thing. So it's published by O'Reilly and presumably available on Amazon.com. Where can our listeners follow you, Matt? You have particular channels you like to announce things?

Matt LeMay

Yeah, you can follow me on LinkedIn, you can find me on Twitter  "@mattlemay" I am a I am not a frequent tweeter but I tweet occasionally. You can subscribe to my newsletter at Mattlemay.com. And I am not a content factory. I write fairly slowly, so if you go to Mattlemay.com, you can find some articles I've ripped in the past that I still think are quite good. And I always tell product managers that I love to hear from you if you have any questions. If there's anything you're not sure about, send me a message on LinkedIn. Send me an email, matt@mattlemay.com, [it's] easy to find. Or send me a Twitter message. You know, 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.