The Matt LeMay Hypothesis: Great Product Managers Never Have to Say Yes or No

Matt LeMay is the author of Product Management in Practice (now in its second edition) and product leader and consultant who has worked with companies like Google, Spotify, Mailchimp, and Audible.

In this episode of the Product Science Podcast, we cover how constraints can be helpful in product, the effects of getting promoted without being ready, and why great product managers don’t need to say yes or no.

Subscribe for the full episode on Apple, Google Play, Spotify, Stitcher, YouTube and more. Love what you hear? Leave us a review, it means a lot.

Resource Links

Follow Matt LeMay on Twitter
Follow Matt LeMay on LinkedIn
Product Management in Practice, Second Edition
Follow Holly on Twitter
Follow Holly on LinkedIn

Questions We Explore in This Episode

How does Matt see the role of insecurity in how people act at work?

• At his first company, the team was highly technical but didn’t value non-technical team members as much.
• He himself dealt with insecurity that kept him from reaching out and communicating well with others. He later realized that at the same time that he was feeling that his coworkers were out of reach because they were so smart and skilled, the others thought he didn’t appreciate them because of the way he interacted with them.
• He overcame these challenges by building relationships with his team and learning from them.

How can constraints be helpful in product management?

• Constraints can provide focus and direction. Matt recommends creating one page in one hour.
• Forcing a PM to finish something and bring it to their team can be really powerful.
• The PM can frame it to the team as a simple unblocking exercise rather than a finished piece of work.
• This can also get the work reviewed and critiqued much earlier, leading to more collaborative and powerful work.

Why does Matt think that great product managers don’t have to say no?

• Matt tells a story of a product leader who turned a question from the CEO into a mandate to get the work done through the weekend. While the team delivered, most members of the team resigned afterward.
• A better approach is to think of trade-offs. This allows the decision-maker to still play their authoritative role while working with real constraints.
• Great product managers help team members navigate options and evaluate those options in the context of the shared goals, rather than having to say yes or no directly.

Quotes from Matt LeMay in This Episode

Early in my career, I really felt like I was missing something because I had read that product management was this visionary mini CEO role where you own the roadmap and you are this like powerful, all seeing, all-knowing entity, and I never felt that way at all. I felt like I was just spending a lot of time talking to people. I was recognizing that my work felt most effective when really advocating for other people's ideas, not my own. And when I was really helping my team lead the work, rather than throwing myself in front of the work and saying look at me, I'm the product manager. I came up with the ideas, I did the work.

I say sometimes that great product managers never have to say yes and never have to say no. They're just helping folks navigate options and evaluating those options against shared goals, which often means that if there are not shared goals, you'll uncover that through evaluating the options.

Product management is connective work, which means it's contextual work, which means that it changes day to day, moment to moment based on not just the company you're working for, but the team you're working with and the personalities on that team and the thing that's happening in their lives. It's so deeply contextual work, which means, again, you have to be open to trying new things and learning new ways of working and recognizing doing things by the book is not always gonna be the best way for your particular team at this particular moment.

The Product Science Podcast Season 5 is brought to you by Productboard

Check out their eBook: 10 Dysfunctions of Product Management

If your product team is struggling, it could be one of the 10 dysfunctions of product management. Learn more about each dysfunction and how a product management system can help you address and avoid them.

Get Your Copy

Transcription

[00:00:00] Holly Hester-Reilly:Hi, and welcome to the Product Science Podcast where we're helping startup founders and product leaders build high growth products, teams, and companies through real conversations with the people who have tried it and aren't afraid to share lessons learned from their failures along the way. I'm your host, Holly Hester Reilly and e O of H two R Product Science. This week on the Product Science Podcast, I'm excited to share a conversation with Matt LeMay. Matt is the author of Product Management and Practice now in its second edition, and a product leader and consultant who has worked with companies like Google, Spotify, MailChimp, and Audible. Welcome, Matt.

[00:00:39] Matt LeMay:Thanks so much for having me, Holly. It's great to be here.

[00:00:41] Holly Hester-Reilly:Yeah, it's great to have you here.

[00:00:42] Tell me your story. How did you get into product?

[00:00:45] Matt LeMay:The short answer is by accident, which I think is true for a lot of people. My background's kind of all over the place. I was a music journalist and then a musician, and then I was doing marketing at a music nonprofit and realized I wanted to move out of my mom's apartment and get a grownup job. Look at some jobs in advertising.

[00:01:04] I looked at some jobs in tech as an aimless young, creative person does. And basically wound up at a startup in New York as API evangelists, so doing developer relations cuz I knew enough technical stuff to be dangerous, but not enough to be good at writing code.

[00:01:22] Holly Hester-Reilly:Interesting. So before you go on, tell us a little bit about that. Like how did you get a role as an API evangelist being enough to be dangerous, but not enough to write code?

[00:01:31] Matt LeMay:Sure. So I had built websites for record labels, primarily when my band was still active in order to pay for gasoline to get from one city to another, et cetera. So I knew enough of the general ideas and concepts that I could be conversant in them, and I think that my experience as a musician had.

[00:01:50] Basically trained me up in cross-functional work, even though I wouldn't have described it as such. At the time, I knew how to work with bass players and drummers, and the artists and designers who do packaging and the record labels who have business concerns and deadlines to me. So I think I naturally fell into a connective role.

[00:02:09] I was very lucky to meet somebody who was familiar with my music writing and was able to see how the skills I had developed in music would potentially translate to a tech company environment. Yeah, I was lucky enough to have enough of that technical knowledge to get a foot in the door, and I very quickly fell into that more communicative, connective piece of the work.

[00:02:29] And at a certain point was invited to join that company full-time, and I did a Google search for, Job in tech, bad code. Okay. Salary, and the rest is history.

[00:02:40] Holly Hester-Reilly:That's funny, but that's great. Just the Google search part is funny. What was that first role in tech like for you?

[00:02:46] Matt LeMay:Gosh, it was tough. I think I had a lot to prove. I was joining a team, which was primarily technical folks where not everybody was sure the value of having less technical folks on the team. I remember the first product launch I was a part of, one of our senior leaders said We managed to ship this with no product managers.

[00:03:06] And I looked around like, oh, nevermind. So I think as with a lot of quote unquote engineering driven culture, there were some things that were really great and some things that felt like gatekeeping and felt like folks who did not have the set of skills that had been deemed the correct set of skills were not being included to the extent that they could have been.

[00:03:26] So I think it took me time to develop any kind of confidence in my own skills and any kind of sense that the work I was doing was valuable work, and that doing this facilitative connective work was really critical and really valuable. I think it was very much a not entirely atypical early 2010s New York startup journey of navigating an engineering driven culture and getting to a place of feeling more secure and confident.

[00:03:53] I'm comfortable with a set of skills that would've fallen more under the banner of soft skills.

[00:03:58] Holly Hester-Reilly:Yeah, I'm sure many of us have had those experiences of working with a highly technical team that doesn't necessarily value those soft skills and finding. Your own way and it is so valuable.

[00:04:10] Matt LeMay:Yeah, and it's interesting too because over time you start to realize that so much of what constitutes a company's culture is the insecurities and fears of people on that team, more so than necessarily their deeply held beliefs that are in any way immutable or intractable. So it was interesting as I got to know people better to see that it wasn't that these were.

[00:04:28] Bad people at all. It was that certain sets of assumptions and expectations and insecurities have unbaked into the way that people operate at as they do, and gotten calcified into that team culture. And as we got to know each other better and talked to each other more, as I learned more about how to work through my own insecurities and approach people with curiosity and openness, I think we were able to really get to know each other on a better level and come to appreciate the differences and skills and approaches we had rather than.

[00:04:58] Look at somebody with different skills and approaches as I had done as well, and said, oh no, if I don't have their skills, then I must not be doing a good job. So I'm gonna make a big stink about the skills that I do have, because that's the only way I know to feel secure in those skills, rather than being really open and curious about the areas where I might have some learning to do.

[00:05:17] Holly Hester-Reilly:Yeah. So how did you come to that? Learning yourself?

[00:05:20] Matt LeMay:The hard way is the short sort of that. I remember very specifically working with a team of incredibly smart data scientists and being just terrified of them cuz they just seemed like the smartest, coolest people. It was during exact same time that article ran that like data scientist was the sexiest job in the world and like these were people who were making like these really.

[00:05:39] Funny seeming inside jokes that I didn't even begin to understand. I just assumed that they thought I was stupid and I acted insecurely and defensively due to no fault of anybody's other than my own. I was like, oh, these people are so cool. They're so smart. They must think I don't know what I'm doing, so I'm just gonna leave them alone and I'm gonna let them do their thing and I'm just gonna make a lot of self-deprecating jokes.

[00:06:02] And it became clear to me at a certain point that I could no longer do my job effectively unless I understood their work a little bit better. So in a moment of deep physical terror, I emailed one of the data scientists on the team and said, Hey, really curious. Told 'em about the work you do. Maybe we could go for a coffee sometime.

[00:06:17] Okay, bye. And closed my computer and went for a walk. I just was so flush with embarrassment and got a really sweet email back. Oh yeah, that would be cool. And we went for coffee and it turned out that. His team thought that I didn't value the work that they did because I had been so evasive and insecure around them.

[00:06:34] So while I was in my corner saying, oh, they must think I don't know what I'm doing, they must think that I'm some weird idiot who doesn't understand math. They were in their corner thinking, oh, Matt must just think that we're a bunch of nerds and doesn't really care about the work we do. So once we actually got to talk to each other and I said, yeah, I need to understand more about your work just to be able to do my work.

[00:06:53] The folks on that team were so excited and so generous with their time and their knowledge to sit down with me and really explain, here's how this works. Here's how we make decisions here, how we decided to do this. I'm not that. Um, once that line of communication was open, once we had broken through our assumptions on both sides of that working relationship, we were able to get so much done and just to really enjoy working with each other and learning from each other.

[00:07:16] So when I work with product managers often advise them, like, just send those simple. I'm curious to learn more about the work you do emails, because they might seem so simple, but they are so incredibly powerful as a way to work across functions and silos to break down some of those assumptions that people might have and to really learn about the awesome, exciting things in play with the people you work with.

[00:07:39] Cuz there's awesome, exciting people doing awesome, exciting work at a lot of different companies.

[00:07:43] Holly Hester-Reilly:Yeah, that's a really powerful story and I think that it really speaks to the value of curiosity and relationship building.

[00:07:50] Matt LeMay:Absolutely, and curiosity is so important. It's one of those things that feels so simple and basic and straightforward, but it requires a lot of vulnerability To be curious, you have to, again, break through some of your own defense mechanisms and be willing to. Talk to people who know things that you don't know and understand things that you don't understand and ask questions that might seem naive or ignorant or poorly informed.

[00:08:15] But once you really open yourself up to that, it makes product work so much more enjoyable and so much more interesting.

[00:08:21] Holly Hester-Reilly:It does. I think it makes all work more enjoyable and interesting, but it is particularly valuable in product as well. I think that's such a strong message to send and something that resonates really deeply with me because in my first product manager job, when I first moved to a company that was a little bigger where I had similar feelings of, oh man, I can't believe I got this job.

[00:08:41] I still remember when I applied to it that they had written somewhere that they were looking for a rockstar product manager. And just getting that job made me feel like, oh man, now I have to be a rockstar. And the power of curiosity and just one of the things that I turned back on time and again, was just be curious about my coworkers and ask them questions.

[00:09:05] And it can be difficult sometimes when we're worried about how we look or how we come off to do that, but it's actually one of the best things we can do.

[00:09:13] Matt LeMay:Absolutely. I tell people often that 90% or so of the bad product management I see is driven by defensiveness, not incompetence. It's been really interesting to see how product managers who have a lot to learn but are open to learning. Will so quickly outperform product managers who think they know everything and will dig their heels in and refuse to learn new things or be open to new ways of working or to coaching or to extending themselves beyond their comfort zone.

[00:09:43] It's been really wild to see how much of the, the damage done by product managers to teams and to themselves is 100%. Self-inflicted damage based on pure defensiveness and this idea that if they ever admit that they have something to learn or an opportunity to grow, that they'll somehow be revealed as being complete charlatans who know nothing about the world of product management, which we can all feel that way sometimes, but I think once you engage enough with the product community, you realize that everybody feels that way sometimes.

[00:10:12] And that feeling that way, if anything, is exactly why. You need to be constantly curious and open to learning new things and why. If you try to pretend that you've learned everything there is to learn or know everything there is to know about product management, then you fundamentally misunderstand what product management is and how to do it well.

[00:10:32] Holly Hester-Reilly:Yeah. So do you have any interesting stories of times where you were working with somebody who did struggle to be open to new ways of working?

[00:10:39] Matt LeMay:Yeah, lots of them. It's interesting cause a lot of my work of late has been about applying really simple and basic constraints to time and format to get product managers. Working more quickly and more vulnerably. So I found myself in a lot of situations, for example, working with product managers who've been tasked with developing a product strategy.

[00:10:59] And this is often a very difficult ask because nobody really knows what a product strategy is. Nobody really knows what it's supposed to be. If you start frantically Googling it as I have done many times, you'll read 30 articles each claiming to be definitive. And some saying, well, product strategy must have these 37 things where it's not really a product strategy.

[00:11:17] Another saying, if your product strategy has more than five things, it's not really a product strategy. I've found myself in a lot of conversations with product managers who will say, oh, I've been asked to do a product strategy, so I've blocked out three months and I'm just gonna go disappear and like learn everything there is to learn.

[00:11:30] And I'll often say, let's just try drafting something within a half hour. What are the decisions your team is trying to make? What are some different paths you could pursue and. It's been really fascinating to me how often the simple application of absolute constraints around time and format. I have a whole spiel.

[00:11:50] I do about one page, one hour on a website, one page, one hour.com, where people can commit to those constraints as kind of default constraints. But I found that in a lot of cases, Getting product managers who are really afraid of doing things the right way, especially in a world where there really is no one right way.

[00:12:06] Just forcing them to finish something and bring it to their team is often the single most powerful intervention you can make. And it's really great to see. I worked with a product manager a while ago who somebody had come to her and said, Hey, I'm really curious what your team is working on. And she was starting to prepare a presentation, like a PowerPoint presentation, and I said, I've been doing this one page, one hour thing.

[00:12:28] Why don't you just try spending no more than one page and one hour putting together just like a brief summary of what your team's working on? And she said, I'm just really worried that this product manager is gonna think that I'm not taking this seriously, that this looks too messy or it's not clear.

[00:12:41] And I said, I understand that. I understand that's a fear, but why don't you start with this and explain that you spent one page and one hour on it. And if they need more information from you, you're happy to provide that. So she provided this to the other product manager and a couple weeks later that product manager came back to her and said, God, that document you gave me was so good.

[00:12:57] I wound up making one just like it for another team. And I was so happy in this moment because the other beautiful thing about constraints is that it also forces you to prioritize and so much of product management is prioritization. The program I was in at university had a one page maximum on all papers, and it was probably the hardest thing I've ever had to do to write.

[00:13:17] Effective term papers in one page, cuz you have to figure out what point you're making. You can't do the thing where you equivocate and ramble for 10 pages, but say it was 10 pages and it was a five page paper, so I'm probably gonna get an A on it. You really have to figure out what your point of view is.

[00:13:32] So again, I find that providing and applying and facilitating product managers through those simple constraints has the dual benefit of getting them out of that perfectionist mindset and also encouraging them to prioritize what they're actually trying to communicate. Um, who they're trying to communicate to and why.

[00:13:50] Holly Hester-Reilly:That's awesome. I think that those one page materials can be so powerful and I love that the person you were coaching to do that had such positive feedback and I think that it's really interesting to hear you talk about how that goes back. All the way to your college experience or your university experience.

[00:14:08] I'm guess I'm curious what kind of things you studied in college.

[00:14:12] Matt LeMay:I studied modern culture and media, and I wrote my senior thesis on Sex in the City. So I have very strong opinions about sex in the city, both through an academic lens and through my own personal opinions.

[00:14:23] Holly Hester-Reilly:Oh, interesting.

[00:14:24] Matt LeMay:Namely that Aiden is total garbage and never appreciated, Carrie for who she was, which I've gotten into some very heated debates with people about, and I am happy to have those heated debates with any listeners who want to reach out to me and talk about sex in the city.

[00:14:39] Holly Hester-Reilly:Awesome. I have to admit, I haven't seen enough of it myself to be able to. Say anything about Aiden I, I think that's a really interesting perspective that you have. Yeah. So it seems like that through line of the constraints has really been there for parts of your career. Do you have any other stories about experiences you yourself had where constraints were helpful?

[00:15:00] Matt LeMay:Yeah. One of my favorite experiences, I was working with a leadership team a couple years ago at a company, and they were about 70 slides into putting together a deck that was supposed to capture their vision for the company over the next year.

[00:15:11] Holly Hester-Reilly:Oof that first glance. Wow. Okay. Carry on.

[00:15:16] Matt LeMay:And I said, this is really cool. Do you mind if I spend an hour just reading it and trying to synthesize it down to a page?

[00:15:22] Cause you know, people are busy and I think it's always good, even if you're gonna use this. I tried never to get into battles of wills with executive leadership teams. Even if, just for my own sake to make sure that I'm understanding it, can I distill this down to a page? And they said, sure, knock yourself out.

[00:15:36] And I sent them the page and we got on a call and they ripped me apart. They were just like, that's not what we thought. How could you think that you're missing the point? You missed this one really important thing. You missed this other really important thing. And over the course of the conversation, it became very clear that the reason this was 70 pages long, so the five members of this leadership team had very different visions for the next year, but rather than reconciling their visions, they just added slides.

[00:16:00] So you basically have five different people's. Slightly conflicting and contradictory visions jammed into a 70 slide deck, and my one-pager was an attempt to synthesize this into something coherent and actionable, and everybody was unhappy with it. So the most interesting part to me though of all this is I'm sitting there and they're all yelling, this is bad.

[00:16:22] And I'm like, fine. That's great. We learned something. At the end, after laying into me for I'd say a solid 15 minutes, something, I go, but it's okay. We can use this. Don't worry. We're so sorry. It's fine. I'm like, but I don't care. I spent an hour on this. Like the whole point of this was to get us unblocked in thinking about how we move forward, and I'm not actually attached to this one pager at all.

[00:16:42] That's the whole reason I applied these constraints, and it was so interesting to me to see how that very commendable. Human empathetic wish to celebrate and elevate other people's work was working against our goals. In that moment. In that moment, after they had this very visceral reaction to that one pager.

[00:17:03] Their way of course, correcting was to try to salvage the one pager rather than trying to actually solve the issue among the group. And I think about that all the time. When I see product managers presenting these really long, rambling, meaningless documents and afterwards their team is on Slack, giving them kudos, saying The presentation was so great.

[00:17:25] Everyone smiled afterwards, and the slides looked really good. I'm like, yeah, but what was the purpose of this? Did we actually get anything across? Did we communicate trade offs? Do we make difficult decisions? Do we do the things that product teams really need to do? And I think that in a lot of cases there is an implicit incentive to do more work and to make things more finished and more polished and more impressive.

[00:17:45] And part of why I started this one page, one hour project was to shift that via an explicit incentive where you are committing to your team to keep things small and incomplete. So that, as I've found with my team, if I then show up with a polished 10 page presentation, there's actually a counter incentive there.

[00:18:03] My team will say to me, you made this whole thing about. One page and having things be incomplete and unpolished, why did you do this? So I found that in a lot of cases, unless you explicitly shift the incentive structure, there will always be an incentive to try to impress people with a long finished documents.

[00:18:24] So I'm really interested in how you can shift those incentive structures because in the absence of doing so, I think it's very hard to actually create a culture of constraints and collaboration.

[00:18:36] Holly Hester-Reilly:So how do you shift those incentive structures?

[00:18:38] Matt LeMay:Again, that's to me, I'm sure, I'd be curious to hear if anyone has better ideas than this, but literally signing a pledge to your team that says, I'm gonna spend no more than one page and one hour on anything, and then holding your team accountable to that.

[00:18:49] When I signed this pledge with my business partners in the States, I broke it immediately. I showed up with a five page detailed plan for a workshop and. They said, why are you doing this? I'm like, well, I really wanted to make sure we're on the same page. And they were like, yeah, but you said you would spend no more than one page.

[00:19:04] Or should we even be doing this? Like, why are you gonna make this commitment if you're not gonna follow it? And it turned out that, of course, there were a lot of assumptions baked into that five page plan. And if I had brought it to my team earlier, it would've been stronger. It would've better reflected a broader set of perspectives and would've saved.

[00:19:22] Me the time of making these five pages them, the time of reviewing these five pages, me the time of revising these five pages, et cetera. And that's the other thing is that I tell product managers sometimes that showing up to your team with a PowerPoint deck is like when your cat kills a mouse and leaves it in your shoe.

[00:19:36] Like they're convinced they've given you something really valuable, but all you have to do is essentially dispose of it and it's really not that great as a gift. So I think we also lose sight of the fact that when we. Deliver these over finished, over polished presentations and documents. Yes, we might feel accomplished in the moment, but we're also asking a lot of our colleagues to process and synthesize and provide feedback on those things.

[00:20:02] Holly Hester-Reilly:Yeah, you're definitely making me think about times when I've done that. So let's actually go back to your origin story. How did things evolve after that? A p i product manager job.

[00:20:13] Matt LeMay:Yeah, I wound up getting promoted at that company. Went to a director level position, then going to a different company and. In parallel with that, I started writing about product management because early in my career I really felt like I was missing something because I had read that product management was this visionary mini CEO role where you own the roadmap and you are this like powerful all seeing, all knowing.

[00:20:38] Entity, and I never felt that way at all. I felt like I was just spending a lot of time talking to people. I was recognizing that my work felt most effective when I was really advocating for other people's ideas, not my own. And when I was really helping my team lead the work, rather than throwing myself in front of the work and saying, look at me, I'm the product manager.

[00:20:56] I came up with the ideas, I did the work. And so I started writing about this and it resonated with people, and it resonated with people who I like working with. Like it seemed to resonate with other folks who were asking similar questions and dealing with similar kind of existential crises about whether or not they were doing product management, quote unquote, the right way.

[00:21:15] So I started writing more. I did a talk for gathering of newsroom product managers, where I talked about some of these things. Published it as a medium post. It got a lot more traction than I had anticipated, and I pitched a book to O'Reilly. I said, I wanna write a book about product management, but I want it to be.

[00:21:31] Really Voicey, really opinionated, really rooted in practical stories told by working product managers. I want this to be the book that tells you the reality of the work, not the idealized theory of the work, and they were hugely supportive of it. That book became Product Management and Practice, which is now its second edition.

[00:21:51] And. Since then, I've been doing a lot of coaching and consulting work, going into organizations, really trying to help do things like clarify team level goals, work with teams to again, apply these constraints to thread the needle and create iterative dialectical systems between strategy and tactics.

[00:22:10] Just a lot of really interesting things. I've been super, super lucky to work with some really amazing teams and some really amazing product managers and leaders. My worst fear is always that I will become disconnected from a practitioner's point of view. So I am super, super grateful and lucky to the practitioners I work with who keep me humble and grounded.

[00:22:30] Holly Hester-Reilly:Absolutely. I know that feeling as well, and I love every week, every day talking to people who are on the ground doing it and trying to help them, but also learning so much from them. They're helping me too. It's really valuable. I have to go back a little bit there. You dropped to something that I wanted to pull on the thread of, which is you in that first job, you got promoted to director.

[00:22:52] I think a lot of our listeners are always interested in how to get promotions, and so I'm curious if you could tell the story of how you got promoted.

[00:22:59] Matt LeMay:Sure work for a very volatile company where your boss keeps getting fired and eventually you will become the boss. That's one like very startupy way to do it.

[00:23:09] Holly Hester-Reilly:Right? Tell us more about that. What is the harm that you see?

[00:23:12] Matt LeMay:I think honestly I was promoted way beyond where I should have been pretty quickly, which is also something that I see a lot of folks struggle with, especially in startup environments. If you're there at the right time or you have a couple of wins under your belt, you're likely to get promoted with very little guidance, with very little training in how to manage people.

[00:23:32] And I've seen a lot of people burn out or clinging to some of the higher control approaches that help them be effective when they are individual product managers. I think for me, I got really defensive and really hung up on the idea that I wasn't empowered to do the things I needed to do. I got embattled, which was really toxic from my team.

[00:23:52] And one of the things I write about in the book is that I think a lot of product managers build cohesion with their team by trying to insulate their team from the business by saying, oh, the suits are making us do this. What a bunch of assholes, but we're gonna do it cuz we have to, but not my fault. And I fell into that pattern of like reflexively saying yes to senior leadership.

[00:24:10] Them go into my team, um, badmouthing senior leadership, which again works for a little while because senior leadership gets things delivered and your team doesn't hate you, but it becomes untenable very quickly and it does a lot of harm both to the team and to the company at large. So there's a story that a friend of mine told me once about a product leader working.

[00:24:32] At a famous company with a famous ceo, and that famous CEO says to them like, can you get this thing shipped by Tuesday? This is on a Friday afternoon. Product leader says, of course I can. Whatever you want. Um, goes back to their team and says, listen, cancel your plans. Tell your family you're not gonna see 'em this weekend.

[00:24:49] We're locking the doors. We're making this happen. I know it's not reasonable, but the CEO asked for, and we gotta get it done. Team worked through the weekend. At the end of this, some of their best engineers quit. People were having really hard times. People's families were mad at them. What do you think happened to that product leader?

[00:25:03] But the harm that did was real, both on a company scale and on a human scale. Asking people to not see their families for the weekend is bad. It's like I think about that story a lot because the CEO never said, you have to do this by Tuesday. The CEO asked a question and it was that product leader who turned that question into an order in order to enhance their own personal standing in the company.

[00:25:28] If they had gone to their team and said, oh, the CEO asked if we can get this done by Tuesday, the team probably would've said, of course not. And then that product leader would have to go back and say, Hey, listen. I talk to the team, here's what we think is realistic. Here are the trade-offs we can make, which is what a truly good product leader would do.

[00:25:43] But this story sticks with me because I recognize that I used to do that too. When company leadership will say, can you do this? Or what can you do? I would treat that as an order, bring the order to my team, blame the executives for it, and reap the benefits of like being perceived as a product manager who really gets things done while also.

[00:26:03] Reaching the benefits of my team, seeing me as somebody who tried their best to fight back, but was powerless against the unfathomable persuasiveness of senior leadership. I think one of the hardest truths of our industry is that the wrong people get promoted a lot. People get promoted for harmful behaviors and people do not get recognized for that.

[00:26:21] More facilitative and thoughtful style of leadership in a lot of cases. And. I think it's really important that we as a community acknowledge that and we take serious concerted efforts to address that.

[00:26:34] Holly Hester-Reilly:I've seen the same thing and it's always not at me and worried me. And for me it's been in coaching others that I try to help them avoid that. But I'm curious for you, what is action against that look like?

[00:26:45] Matt LeMay:Yeah, so one of the things I always advise product managers to do, It's just an an optionality, especially when you're dealing with senior leaders. Never get 'em into a yes, no argument. If you can present three options and help walk through trade offs, you are much less likely to get in that situation.

[00:27:01] Where can we do it by Tuesday? Yes or no? Say, all right, well if we deliver this by Tuesday, then we can't build this. Or if we deliver this by Wednesday, what are the actual trade-offs? Good product managers always thinking options. I'm always thinking trade-offs. I did a workshop with product managers, with the team I was consulting with a while ago where we did just some product manager role playing, where we had one person acting as the product manager and another acting as the executive, and the product manager pitched one idea.

[00:27:27] And the executive immediately starts saying, what about this? What about that? I don't like this. I don't like this. We tried the same thing where two different people role played and the product manager presented three options with trade-offs. And what was interesting was that the person playing executive could still maintain a position of authority without attacking anything.

[00:27:43] They could say, I like this part of this thing, but what about this? But you still got a chance to understand when I asked them to retrospect on this activity. The person who played the executive, the second one said they actually had to think through what their goals were. They had to think through what their perspective was when they were presented with multiple options.

[00:28:01] Whereas when they were just presented with one option and a yes no battle of wills, they didn't really have to think much at all. They could just fight for what they wanted and fight relatively thoughtlessly. So I think about that a lot and whenever I'm working with executives or coaching product managers who work with executives, I always try to get them to stay an optionality think in terms of trade offs and avoid a yes no battle of wells.

[00:28:25] I say sometimes that great product managers never have to say yes and never have to say no. They're just helping folks navigate options and evaluating those options against shared goals, which often means that if there are not shared goals, you'll uncover that through evaluating the options and you'll have to help facilitate the conversation around what are our shared goals, what does success actually look like to this team in this moment?

[00:28:46] But, You never really have to have those conversations if you are just constantly in a yes no battle of wills or jumping from yes no battle.

[00:28:55] Holly Hester-Reilly:That's very powerful. I think the thing in there that you said that kind of surprised me is the idea that, that a good product manager doesn't say no. So tell me a little more about that. I feel like it's very, Very apropo of what you just said. My brain starts to go through the things that don't. They say no in this situation and don't they say no in that situation.

[00:29:15] Hey, I'm doing the same thing.

[00:29:16] Matt LeMay:Yeah, and I think about this a lot through the lens of my own career, right? Because when I started, one of the first things I was told was that good product managers know how to say no. I took that to heart. I was like, oh, love someone. Say no to everybody. So I remember one very particular case where an executive came to me and was like, Hey, I know your team's working on this because you work on this other thing.

[00:29:33] And I was like, it is my job to get this person to leave me alone. Cause my team has already scoped something for this sprint. We don't change the work we're doing on a sprint mid-flight. And I was just like, listen, you wanted us to work in these agile sprints. You want us to scope stuff two weeks at a time?

[00:29:47] You have to respect that and leave us alone. And he's like, all right. A couple weeks later, it turned out that executive had been privy to some conversations that I was not aware of about some really important changes in our direction and where the company was going. And by saying, no, I have completely closed myself and my team off to those conversations.

[00:30:06] Often advise product managers to, if someone comes to 'em with an idea that seems like a bad idea, find out why they think it's a good idea. Be like, okay, cool. What excited you about this? I remember once telling my engineering team they wanted to refactor some of our code rather than fixing user facing bugs.

[00:30:21] And I was like, no, this isn't developer summer camp. We gotta fix user facing bugs. It turned out, I wound up asking one later, why did you want that? He was like, we just wanted to have a say. We just wanted to be involved in making decisions. Like we didn't even care that much about that, but it really sucked the way that you shut that down rather than helping us feel like we were a valuable part of the team.

[00:30:40] That's right. If I had just been open and curious and said, cool, why is this exciting to you? Like, here's what we've prioritized. Maybe the thing you wanna do, which aligns better with our priorities, which is more important to us. They probably would've gotten to a place and said, yeah, we should work on the user facing stuff, and I would be like, okay, awesome.

[00:30:56] I'm so glad we got a chance to come together as a team. I probably would've seen that they got interested and excited being more involved in prioritization conversations, but I never got to see that because I saw my job as to shoo them away if something seemed interruptive. If something seemed like a bad idea, I saw my job as to say no to that rather than to say maybe I don't know if this is a good idea or not.

[00:31:16] Our goals, our strategy should determine whether or not this is a good idea, not me. So let's look at that openly together and yeah, maybe this is a better thing for us to work on again, especially when you're working with. Executives and senior stakeholders, they might just know stuff that you don't know.

[00:31:30] They might know that there's an acquisition coming up that is top secret, but is going to greatly affect what your team should be working on. They might know that you're like, we're running outta money, and you gotta pivot to really focus on short term revenue. They probably know things you don't know, and it is always only a detriment to yourself and your team to not learn those things.

[00:31:50] Holly Hester-Reilly:Yes, very true, and I love that response in terms of if an executive comes to you or a team member comes to you, but what about when a customer comes to you?

[00:31:59] Matt LeMay:Yeah, you should. Ideally, you never have to say yes or no to a customer. Like one of the things I learned, I'm not a salesperson and I'm terrible at sales. Truly. I got disinvited from sales calls when I was exploring the possibility of being a sales vendor. Cause I usually be like, yeah, I mean, we can do that for you, but you'll probably just build your own solution.

[00:32:16] What are you doing? Stop right now. But I think the whole skill of talking to customers, and I know this is different, especially of the B2B environments and environments where like people need commitments to things. And that's again, where I think sales and engineering and product working together is so important.

[00:32:30] But when you're learning from customers, your job is to learn from them. And in a lot of cases that means honestly pretending you know less about the product than you do. I was very lucky to be trained up in user research by Tricia Wag, who's one of my business partners in the States, and is just a brilliant.

[00:32:45] Qualitative researcher and brilliant person overall, and she taught me to really play dumb a little bit to just go in and try to learn as much about the universe of a person and what matters to them. And I write about this in the book a little bit, but the techniques you use in managing stakeholders are very different from the techniques you're gonna use in learning from customers in a lot of cases.

[00:33:04] And it's very hard to make that switch mentally. I coached a product manager a while ago to do her first big qualitative research session, and I messaged her afterwards and I said, how'd you feel? And she was like, gosh, that was so hard. I totally get why product managers fight tooth and nail to not do this.

[00:33:19] And I was like, yeah, I get it. She was like, I felt. Like I was being stupid in front of my team. Cause I took my team to do this together and there were all these questions, which I knew the answer to, but I also knew that my job wasn't to answer the question, but to ask questions and to learn about what customer was actually trying to accomplish.

[00:33:36] I think it's really difficult and challenging. I think, again, for folks who are control minded and who like to have an answer already, it's very challenging. That's a really good challenge.

[00:33:45] Holly Hester-Reilly:Yeah, that's interesting to me because I wonder what her team's expectations were of that qualitative resource session, and if she was thinking that she'd looked bad in front of them, but did they really think that?

[00:33:57] Matt LeMay:That's a great question. And the answer is no. They didn't think that. They all thought it was really cool and they followed up afterwards and we're like, wow, that was so interesting. And they learned a lot from it. So again, I think we all have a tendency to inflate in our minds how much other people think about us.

[00:34:10] At all. I think in those cases it's very easy to feel like, oh my God, everybody's thinking about me and, but they're probably not, they're probably thinking about a lot of other things. In the best case scenario, I think they hear one or two things from the customer that really sticks with 'em and that actually shapes their work in a meaningful way.

[00:34:25] But honestly, there are very few times in my career when I've been like, oh no, I'm gonna look stupid in front of my team, and my team actually cares at all.

[00:34:32] Holly Hester-Reilly:Yeah. So do you work with companies of all sizes?

[00:34:36] Matt LeMay:I do. I work with big companies, small companies, medium size companies.

[00:34:40] Holly Hester-Reilly:What are some of the trends that you've seen in what it's like to be a product manager at these different companies?

[00:34:45] Matt LeMay:It's really interesting cause when I researched the first edition of product Management and Practice in 2017, I asked people, what's one thing you wish somebody could have told you or you could have learned about day one as a product manager. And almost all the answers I got were about executive stakeholder management.

[00:34:59] When I started researching the second edition and I asked that same question, almost all the answers I got were, I wish somebody had told me there's no one right way to do product management. You shouldn't stress yourself out. Um, Rage at the universe because your company is quote unquote, not doing product management the right way.

[00:35:15] Nobody's really doing product management the right way. There is no right way. Focus on having a balanced and happy life and doing the best work you can within the constraints of your organization because every organization has constraints. And it is really interesting to me to see that conversation playing out because again, I think there was a belief at some point when I was doing a lot of training work five or six years ago, people would say, how does Facebook do product?

[00:35:39] Okay, load up Facebook on your computer, get out a piece of paper and write down everything that is so bad and broken about the Facebook experience that you would fix it on day one as product manager there and people would run out of paper. And I'd say, look, my point is not to pick on Facebook, but to say like every company has constraints.

[00:35:55] Every organization has challenges. The white papers you read about this is the perfect way of working. Somebody is selling you something in a lot of cases, or somebody is publishing, recruiting, propaganda. It is always different inside these companies from how it appears on the outside. And when people tell me, how does this company, I always tell 'em like, find someone who works there and.

[00:36:14] Go out for a drink with them, find out the reality on the ground, because product management is connective work, which means it's contextual work, which means that it changes day to day, moment to moment based on not just the company you're working for, but the team you're working with and the personalities on that team and the thing that's happening in their lives.

[00:36:31] It's so deeply contextual work, which means, again, you have to be open to. Trying new things and learning new ways of working and recognizing that doing things by the book is not always gonna be the best way for your particular team at this particular moment. So I think we're hitting this really interesting point where there's still tools and techniques and best practices, which are all great, but this idea that.

[00:36:55] There is a small set of companies who figured out the magical secret of how to do product management and every other company's job is to emulate them. I think we're moving away from that, and I think that's really exciting.

[00:37:06] Holly Hester-Reilly:Do you think that's true for methodologies as well as principles? Or is it the principles are there? It's just that the methodologies, there's no one right way.

[00:37:15] Matt LeMay:I think every company. Needs different principles. It's funny, one of the things I often do when I start working with a team is we write up our own version of the classic Ben Horo. It's good product manager, bad product manager document, where we're like, here's what good product managers here do. Here's what bad product managers here do.

[00:37:31] And it's so different company to company. There are some situations where it's like almost an exact polar opposite one company to another. And again, I think that so much of this comes down to what are we actually trying to accomplish? What matters to us? What are we trying to do here at this particular company, on this particular team in this particular moment?

[00:37:48] And it's hard to do that. I think a lot about. Andy Hunt, one of the signs of the Agile manifesto wrote an article called The Failure of Agile, where he talked about how at its heart, agile asks you to think. And that's a hard sell. It's easier to give people rules than to ask people to think, and I think that's true in general.

[00:38:04] And I think, again, thinking contextually requires vulnerability. You have to be willing to say, I'm not gonna just do something because some expert somewhere has signed off on it, and I'm not gonna get in trouble if it fails. Actually saying, no. We as a team are gonna think this through. We're gonna co-create these principles.

[00:38:20] We're gonna adapt methodologies to suit our needs, which means we're going to have to be vulnerable and discuss and address our needs. It's way harder, it's way more challenging, but it's also much more rewarding and much more successful.

[00:38:32] Holly Hester-Reilly:Yeah, so I guess one of the big takeaways that I have from what you've been telling me is like you said, how important it is to think and to think for yourself and to be curious and open and learn. Everything is really contextual and it's different at every company and a product manager is out there, or a director or whatnot is out there and they're struggling.

[00:38:52] To understand whether they're doing it right, if they feel like they're doing it wrong or they feel like it doesn't match what they hear and see what should they do, how do they figure it out?

[00:39:01] Matt LeMay:Yeah, it's a great question, and again, this is where those constraints come in. Super handy. I worked with a company years ago. That was, I think, six months into an OKR setting initiative. They were like, yep. We spent six months trying to come up with our OKRs. I'm like, OKRs in my experience are most effective one.

[00:39:16] They're set quarterly and you've gone through two quarters trying to come up with your OKRs. Let's do it in an afternoon. They were just like, what? We can't listen. You're not gonna know if it's working or not until you're using it, and I think that's a really important thing to get across. Again, these are all contextual systems.

[00:39:32] You're not gonna know if your OKRs are quote unquote, the right OKRs or not until you are trying to use them to prioritize and to decide what you work on and what you don't work. And I told the team once that I don't care if they're North Star metric is how many cheeseburgers can we throw off a roof?

[00:39:46] So long as they come up with it quickly on their retrospect on it regularly. Cuz they'll probably learn pretty quickly that yes, the number of cheeseburgers they can throw off a roof is not actually helping them make better product decisions. So they'll have to adjust and adapt. That's fine with me. But again, you have to start somewhere and you have to commit to retrospecting and learning.

[00:40:03] And I think if you do that, Then whatever your starting point is, starts to feel much less precious, much less like we have to craft this perfect thing and more. Okay, we can set our quarterly OKRs in an afternoon. We can set our product strategy in a half hour. So long as we understand its purpose, we understand how we're gonna use it, and we have time set up to look at it and say, is it achieving that purpose?

[00:40:25] Is it actually helping us do the things that we're trying to do?

[00:40:27] Holly Hester-Reilly:Yeah, that inspect and adapt cycle is so critical.

[00:40:32] Matt LeMay:Yeah, there's something I think about all the time. In the other book, I wrote Agile for everybody. I interviewed this guy Jeff Koss, who runs a textile manufacturing company in Seattle, and somebody told me, you gotta talk to this guy. He's using lean and agile principles to run a profitable. US-based textile manufacturing company, which everybody thought was impossible.

[00:40:49] And I talked to him and I was like, what's your magical agile secrets? And he was like, the thing people don't realize is that continuous improvement means continuously acknowledging that you could have done a better job. Very few people have the emotional resilience for that. It's very hard. Every month or every week to look back at what you've done and say, I could have done better.

[00:41:06] The fact that I could have done better harmed people, it did real world harm and it affected people's lives who looked to me for leadership, who looked to me for livelihoods. So it's easy to talk about continuous improvement and spec and adapt, but to get to that place where you can look at your own work and say, I could have done better and I wanna learn more about and dig in deeper to the ways I could have done better.

[00:41:27] Is really emotionally difficult and I think about that all the time because it is so true and that's something I struggle with constantly. But I try to just push myself into that place of creating that space to retrospect and recognizing that I'm not gonna have all the answers and I'm not gonna do a perfect job.

[00:41:42] And the only way I'm gonna get better is if I am open to taking an honest and reflective look at what I could have done better.

[00:41:48] Holly Hester-Reilly:Yeah, it's such a central principle and it's something that so many people were not really taught to do. The school system is, yes, there's report cards, but it's a lot of finish this thing and turn it in, and rather than the reflection and it's. So valuable to step back and look at what you've been doing and how you could have done it better, which I think is one of the things that coaches help people with.

[00:42:07] I know for myself growing up, I learned that skill through the coaches that I had. Alright, I think we're about out of time. So where can people find you and your books?

[00:42:15] Matt LeMay:Sure people can find me@mattlemay.com on LinkedIn. Instagram at mtl m y where I mostly post to fashion and food photos. I'm Twitter is what it is right now. I am at Matt LeMay on Twitter, but I'm not on there very much these days. I haven't yet fully. Done the MA thing because I'm old and tired, but I might at some point.

[00:42:35] And yeah, I'm easy to find online. matt.com. If you have any questions or want to debate sex in the city with me, I'm always happy to hear from you.

[00:42:43] Holly Hester-Reilly:Awesome. Thank you so much, Matt. It's been such a pleasure to talk to you today.

[00:42:47] Matt LeMay:Likewise.

[00:42:49] Holly Hester-Reilly:The Product Science Podcast is brought to you by H two R Product Science. We teach startup founders and product leaders how to use the product science method to discover the strongest product opportunities and lay the foundations for high growth products, teams, and businesses. Learn more at H two R product science.com. Enjoying this episode. Don't forget to subscribe so you don't miss next week's episode. I also encourage you to visit us@productsciencepodcast.com to sign up for more information and resources from me and our guests. If you like the show, a rating and review would be greatly appreciated. Thank you.

‍