Product Management Webinar: Product Management in Practice

Janna Bastow: Hi everybody and welcome. Thank you so much for joining. This is the product expert series of webinars that we run here at ProdPad. And as I said, it’s a series of webinars. We’ve run a bunch of these in the past. They’ve all been recorded, so you’ll be able to find that on our YouTube channel. There’s been a mixture of presentations and firesides like we’re having here today, and it’s always with a focus on these amazing experts that we bring in, who bring their insights their learnings, their experiences, and it’s always with the focus on the content and the learning and the sharing. So today is gonna be recorded and shared, and you are gonna have a chance to ask questions, and we’re gonna follow up and send that recording to you afterward as well.

Sound good? All right, so a little bit about it before we get started. So this is a tool that was built by myself and my co-founder, Simon, when we were both product managers ourselves we needed tools to do our own jobs as product people. So we definitely felt the same pain that a lot of you are. We needed something that’s gonna keep track of the experiments that we were running. We were asked to, hit a bunch of business objectives, solve a bunch of customer problems, and keep tabs on all the ideas and all the feedback that was building up in our backlog. So building ProdPad gave us control and organization and transparency, and it wasn’t actually long before we started sharing it with other product people around us. And so today it’s used by thousands of teams around the world.

It’s completely free to try. We do have a sandbox mode as well, which you can access, where it has example product management data, things like lean roadmaps and OKRs and experiments, and everything else all fit together in a product management space. So really helpful for trying it out for yourself, seeing how it all fits together, showing it off to your colleagues, that sort of thing. Our team is made up of product people as well. So we’d love your feedback. Get in there, start a trial, and hit us up. Let us know how you get on with it. And on that note, I wanna introduce you to my product expert peer and my good friend Matt LeMay. Hey Matt. I know I know Matt through the Mind the Product network originally like I know a lot of good product people. And I think I first saw you doing a talk at the product leadership event in San Francisco, so I’m casting my mind back. And I, there was one particular idea that stuck out to me from that talk, which was the one page one hour that you mentioned there. But I also remember that your talk was just engaging and funny and it tore down a lot of these product management concepts that we talk about. And you’ve since encapsulated those in, in your book here, we’re gonna be talking about as well.

 We also had a bunch of times that we’ve crossed paths since then. So, very recently we hosted Matt at the ProdPad HQ when he was speaking at Product Tank about how product management relates to Layer Cake. So we might be able to get him to talk us through that ’cause there is a connection and it’s not just ’cause cake is tasty. And also we shared a stage together recently at UX Brighton. Matt closed the show and it was awesome. He had this great gift game and truth bombs that just s- stole the show. So we’re gonna be talking about his book Product Management Practice as well as Cake one-pagers and probably a lot more here today. So, Matt, do you wanna jump in and give an introduction of yourself?

Matt LeMay: Sure. That was a better introduction than I could give. Thank you so much Janna.

 So yeah, like a lot of people I got into the product completely by accident about 12 years ago now. And like a lot of us, I can’t seem to quit it. For all the challenges and all the setbacks and all the bad days, I’ve had ’em, all the literal and figurative tears I just think it’s so exciting to get to work with people to do things together. I think a lot of my journey has been going from a place of being frustrated that my work can only be realized through the collective efforts of a team to really embracing that and learning to accept that in a lot of ways product management is a very high stakes, very low control environment. And if you can learn to accept and embrace that, then I think you can learn to roll with the punches of this crazy thing we call life a little bit more. So that’s [laughs] that’s what I’ve been thinking about lately.

Janna Bastow: That’s a really good way of putting it. And actually, you just touched on something that makes me go quite a lot. Because product management was once called, one of the unhappiest jobs, I think is an American survey of one of the unhappiest jobs in America. And yet I talked to product managers all over the place who have a mixture of feelings, always strong feelings about their job. They either love it or they hate it, or both at the same time. Like what is it about product management that, that makes people love it and hate it and have all the feels?

Matt LeMay: So it’s funny, I was just in Paris last week speaking at a product event and a French product consultant, gave a really great talk and he said, “I don’t think product management is actually intrinsically hard work.” He was like, “Nobody’s forcing you to do anything that’s, too physically demanding. You have predictable hours in a lot of cases, you have a good salary. It’s not actually intrinsically challenging work.” And through our conversation, we got to a point of agreeing that a lot of the challenges of product management are challenges to your ego. There are challenges to your sense of self, to your sense of the ability to accomplish things and, to feel like an effectively accomplished person in the world. I think product management has a tendency to attract very type-A people who like to get things done and who like to do a good job and tend to confound and frustrate us at every possible turn.

But once I think we start to recognize that, okay, this is the nature of the work, again, there’s very little I can actually accomplish on my own and many of my attempts to go off and accomplish something on my own will actually be to the detriment of my team and my business and our users. There’s a radical acceptance in product management where I’ve seen a lot of folks reach a point where the things that once frustrated them, that once left them feeling exhausted or feeling like they needed to stay late and fight every fight until the bitter end. Once they’ve learned how to pick their battles a little bit to say, “Okay, I did my best. I made the stakeholder aware of this, they made their choice. I trust that they might have information. I don’t, I trust that they have their reasons. It’s not my decision. I’ve done my part. I’m gonna disconnect and sleep well tonight and live to fight another day.”

I think once that clicks for people, it can actually be, I don’t wanna say easy work ’cause I don’t think it’s easy, but those challenges can become rewarding and generative challenges rather than just purely frustrating and disappointing challenges.

Janna Bastow: Yeah, that’s actually really interesting. Your idea around picking your battles, understanding what sort of things you can win, and can’t win. I, one of the things that you put pretty early on in the book, which I really appreciated was managing senior stakeholders, and managing up.

 Which I know is just, it’s so difficult and, you hear people giving advice, but it’s only when you’re actually really in, on the ground doing it. What are some of the things, some of the pitfalls you’ve seen with it and how do you, y- you talk some of the product people that you work through work with through it?

Matt LeMay: Yeah, so when I started working in product, one of the first things I was told is that your job is to basically bat away executives. Like they’re gonna come to you and say, “Build this, do that.” And your job is to say like, no, go away. My team is doing this thing.” And I did that and I got quite good at it, but ultimately my team suffered for it because for better or worse, the reality is in most business environments, those senior stakeholders probably know things that you don’t. They might know that a conversation took place for the company, the goals shifted a little bit. They might know that there’s a big acquisition about to happen that they legally cannot tell you about, but that’s gonna shift the way that the company does business.

I think the biggest mistake I made early on was feeling accomplished whenever I got a senior stakeholder to leave me alone or leave my team alone and let us do our work rather than saying, “Okay, if they’re coming to me, there’s something here. They’re interested in something, they have some information.” My job is to approach them with that same curiosity and be like, “Okay, cool. What about this is interesting? Like, we prioritize these things, but here are the goals we’re working towards. Have these goals changed? Is there something else that we should be aware of? Is there something we can’t be aware of but we need to, at least account for in some way?”

I think a lot of the stories I heard when I was interviewing product managers came down to the grudging, but an unshakeable acknowledgment that again, senior stakeholders might know things that you don’t, and they might be privy to conversations that you are not privy to. And rather than trying to get them to leave you alone and let your team just do what you agreed to do, every opportunity you had to engage with a senior stakeholder is an opportunity to learn more about what matters to them, what their goals are, what they’re working towards to help build that understanding, to help get a better sense of how they work and what they want and to help them understand the trade-offs that are going into your work because in a lot of cases they don’t understand that.

So I think learning to approach those interactions with humility and with curiosity… I mentioned this a little bit in the book, but I’ve even cooled on the word influence because I see people going and like, “I’m gonna influence executives to do what I want.” And it’s like, “U- ultimately, w- what you want them to do might not actually be the best thing.” So if you can inform them, help them understand the tradeoffs that are being made, make sure that they know everything you would want them to know and that you know as much as you can about what they’re thinking about and working towards that’s when I think those interactions become really valuable.

Janna Bastow: Yeah, I think that’s a really good point. In the same vein, you wouldn’t wanna influence your users to tell you something in discovery, ’cause that’s not good user research, right? Just like you wouldn’t want to influence your senior stakeholders to go in a particular direction by, maybe not giving them all the information or, by framing things in your way. I, think about the stake- senior stakeholders like users, right? They have information and so you can pull it out of them.

Matt LeMay: Exactly. And there’s a sickness in modern organizations around the presentation and the clapping at presentation and, and the extent to which people prepare to present ideas to executives and they become these enormous shows with fanfare. And it’s like… “Present to the executive.” And the executives ask serious questions. And if you survive the gauntlet of the executive challenges, then everybody goes, “Yay, you did it. You presented, you had answers to all the questions.” It’s like, yeah, but like, did anyone actually learn anything? Did we actually have a meaningful exchange of information? Were new questions asked that would not have been asked otherwise? Or did you just go out there and per your point, kind of cherry-pick data and try to present a case that’s gonna make you feel good about yourself, even if it doesn’t present the complicated realities of the situation you are building into, the customers you’re building for, the markets you’re building for?

Everything is a trade-off. There’s very rarely if ever a clear right answer in product management. And yet I think so many of the ceremonies and rituals around business feel almost like, like a demented game show where we’re trying to win the approval of the executive who will tell us that our slides were pretty, and our arguments were airtight and we effectively play acted this thing, rather than just going in and asking questions and trying to learn and make the best decisions we can together.

Janna Bastow: Yeah. But who’s perpetuating that? Is that the product managers and the mid-level people coming in saying, here’s the big presentation, or is that more of the expectation of the senior management who, are actually expecting this ’cause this is what everyone else is doing, that’s the bar?

Matt LeMay: Oh, I think it’s everybody. I think it’s like five Spidermen pointing at each other. [laughs]. And I think, shifting the center of gravity around people, how, around how people are rewarded and recognized, that work is incredibly hard to do.

 It’s incredibly hard to do and it takes a lot of discipline and a lot of courage from everybody to actually shift that. And it’s really hard to do that. And honestly, in a lot of cases, it’s not because people are hoarding recognition or trying to resist change, it’s because they don’t want to withhold recognition from others and they don’t want other people to feel like that big presentation they gave was a waste of their time or wasn’t valuable or wasn’t awesome.

So I think one of the things that’s really challenging is that especially for leaders, you have to get comfortable telling somebody like, “Hey, I really appreciate you putting this together, but for future reference, like, this isn’t what I need. Can we do things this way? Can we do things differently? Can you bring me something incomplete? Can you bring me something shorter than this? Can you bring me questions rather than answers? Can we actually work on this plan together rather than you going off and spending however long and presenting this and getting that hit of dopamine that you did a good job and got the recognition you wanted?” similarly it takes courage from product managers and people to show up and say like, I’m not showing up with the big fancy deck, I’m just showing up like, here is the trade-off. Here’s what we’re working on, here are the questions I have for you. What questions do you have for me? Let’s figure this out together.”

Janna Bastow: this is probably why, I- it’s so difficult to break the status quo and this is probably why it makes headlines when you see, I think it was Bezos who told his entire company that no one can do presentations anymore. They all had to do written versions of their articulate everything in written form. Which, all these doing is shaking up the status quo of how people were probably communicating in the business. Doesn’t seem like all that much, but overall, if you think about how it’s gonna get people to react and think about what they’re actually saying, could have a step change for the business.

Matt LeMay: Absolutely. And one of the books, I wrote another book called Agile for Everybody when I still had any interest in talking about agile [laughs]. And I interviewed a guy called Thomas Stubs for that book who worked at Coca-Cola because I read on a blog that, and this is timely, he had finished, his team had finished, an event marketing campaign for the World Cup 2014 early. And like it is very rare to finish an event-based marketing campaign early [inaudible 00:17:14] event-based marketing campaign. And I asked him what agile secrets did you use?” And he was like, “No secrets. I just banned PowerPoint and banned email. I said if there’s a conversation to have, pick up the phone or you get in a room and you talk it out. And that, there, there have been two agencies working on this project that did not communicate very well with each other and that tended to send this kind of long passive-aggressive emails or these long PowerPoint presentations really trying to make arguments at or around each other rather than solving problems and making decisions together. So this very simple rule wound up saving them, tremendous amounts of time. And yes, there were awkward conversations at times when things got tense, but they handled it directly and they were able to move forward rather than… And I’ve done this before. I certainly early in my career and in my personal life would, was a big fan of like the five-page email that lays out my perspective so perfectly that nobody can be mad at me. But it turns out that’s not how humans work and they still can [laughs] and will be mad at you and understandably so. Because when you try to anticipate what you think somebody else is going to say or feel or think and you have a five-page airtight argument with your projection of that person, it is not actually terribly considerate to that person’s perspective or feelings.

Janna Bastow: Yeah, absolutely. Y- you talked a bit ab- you talked a bit about this at the I think it was the Mind the Product engage stage when you talked about the documentation and how you shouldn’t how you bend comments on documents. And ever since then I’ve been really conscious of now like, ooh, am I leaving a comment, or am I actually just suggesting a change on this? Am I getting more involved with it? You wanna talk us through your thinking on that?

Matt LeMay: Yeah, so, I was working with an organization a couple of years ago where every comments thread became a pitched battle over nothing important because everybody wanted to contribute. So you’d send around a document and you’d send it to 20 people and 20 people would leave comments and each of those threads would become a big back and forth, is these the right words? Is this what we really think? Most of those conversations had very little to do with the actual purpose of the document. And yet people wanted to understand each other, they wanted to be considerate of each other, and they wanted to take each other’s feedback and comments seriously. So there was a lot of engagement with things that were ultimately very trivial.

So what I started doing was with that organization, I just turned off comments and I left a little thing at the beginning and said, “Hey, I turned off comments, not because I’m taking this document as something really precious and important, but rather because I’d rather we just make the changes together. So if you have any changes you wanna make, here’s the meeting where we make the changes. And if not, just like ping me on Slack and we’ll talk through it.” And that worked pretty well.

One thing I’ve been doing, which has worked really well, which I actually wanna write something about this week, I’ve been doing a style guide at the beginning of documents with comments that basically say, “If you are uncomfortable committing to any language or any idea, highlight it and read and leave a comment with a suggestion. If you are uncomfortable but willing to commit, highlight it in yellow and leave a comment with a suggestion. And if it’s really just you just wanna leave a thought or a comment with no action required or requested, just leave a comment.” I worked with a company recently that shared a strategy document with 60 people and I was like, “Oh my God, this is gonna be terrible.”

But it wasn’t because that many people actually cared enough to highlight anything in red. There were a fair number of comments, but nobody really felt that strongly about anything to the point where they would throw themselves in front of the document and say, “No, I’m gonna make myself a blocker.” And that presents its own challenges and I think there’s always facilitation work to be done, making people feel comfortable and helping provide space for people to provide that kind of feedback. But I think putting some structure around the way that you use comments, deliberate communication is the thread in a lot of the work that I do. Yeah.

 … but in some layer of deliberate structure around the way the comments are used I think is really important.

Janna Bastow: Yeah, absolutely. You enabled them by giving them a language by which to better articulate what their comment was. ‘Cause, otherwise it’s just, a comment that gets as much weight on the page as the next one. And sometimes it’s the comment is just, yeah, I like this. Or hey, can we change this too? And it’s like, a grammatical error or opinion versus, something else where it’s like I don’t think we can legally do this.” Like these two things [laughs] need to be highlighted in different colors. I imagine, Google Docs in the future, if there’s any product managers from Google Docs, maybe take some hints here and come up with different ways of coloring highlights so we can build this into workflows.

 Yeah. And somebody had a question in the chat here. And this one speaks to me ’cause actually, she sent it to just the two of us. But she said something along the lines of how managers have this mentality of don’t bring me problems, bring me solutions. And this one speaks to me because one of my very first bosses had very much this same line and I took it to heart like I would not go to him unless I had a solution. And I always thought I had solutions, right? I thought that my job, was to come up with solutions ’cause I was a junior product manager and therefore, knew everything. And it was a, I- it was problematic, right? Because I would end up not raising problems when I saw them. I would have to… I felt like I had to step back and go and figure out something before I actually raised something. Now, what’s your take on this?

Matt LeMay: Yeah, so this one kind of has two sides to it, right? Because I see the opposite thing happening as well where I’ll work with teams who weaponized this word solutioning, where if somebody starts proposing a solution, they’ll be like, “You’re solutioning. Stop it.” so I think anytime you’re like trying to police what kind of conversation can be had, whether that’s no solutions, only problems or no problems, only solutions it probably chills the conversation.

 One thing I found is that when I’m asked to bring solutions, I think some people understand problems better by looking at solutions. I think that’s just the way that some people’s brains work. And I always try to bring them multiple solutions because I think sometimes by evaluating multiple solutions, by staying in optionality, you can start to understand the problem better, right? So when someone says, “Don’t bring me problems, bring me solutions.” It’s like, “All right, here are three solutions to the same problem. Like, let’s walk through these solutions, look at the trade-offs of each one.” By doing so, you can sometimes start to understand the contours of the problem a little bit better and like what exactly the problem is.

So, for me, I try to always present multiple options. I coach a lot of product managers like you never wanna show up with the one idea you’re defending. I did this, I did a workshop a while ago where I had product managers play-act this. I was like, “One of you pretends to be the executive, the other pretends to be the product manager, shows up with one idea.” They’re like, “Here’s my idea.” And the executive’s like, “That’s bad. Don’t do this. Like, you could do this differently. What about this, what about that?” And then another group, I said, “All right, now you present three ideas.” the executive is like, oh, this one, like, it gives you more, it, it creates less of a battle of wills and more of you versus me dynamic and actually gives decision makers a chance to flex that decision making muscle a little bit and be like I like this about this one, I like this.”

And if you’re, trained and experienced in facilitation, you can start to level up and be like, “Okay, cool. This solution is more geared toward this problem. This solution is more geared toward this problem. So if we’re steering toward this solution, maybe that means that this problem is more valuable to us. Can we agree on that?” So again, I think the trick is always to stay in optionality and stay on that rapid kind of dialectical loop between problems and solutions so that you can use one to better understand the other.

Janna Bastow: Yeah, as a product person, I love problems and I love solutions. I see myself as a matchmaker between them.

 People come to me with all this stuff, all these, solutions, potential problems, ideas, s- suggestions, all this stuff. And I’m sitting here going, “Okay, well if I connect these dots, if I do these solutions, it could solve this problem. Or if I’ve, think that these problems are the m- most important, then it could be these solutions that I try.” and as a product manager, it’s your job not to cherry-pick one thing versus one thing. It’s looking at the set of information as a whole and trying to make the best decisions outta that. This is one of the reasons why product management is so difficult. You’ve got all of this information, all of these choices, so much optionality, so much choice.

Matt LeMay: Yes, and making a decision is often the hardest. So that’s where the layer cake comes in.

Janna Bastow: Yeah, go on.

Matt LeMay: So, when I’ve worked with folks at especially medium to large organizations, I’ll often hear from them like I can’t make a decision because we have our, like company goals and we have our company initiatives and I have my team goals and we have our OKRs and we have my… and they’re all like they’re not aligned with each other.” Like somebody showed me a graphic of how they’re all supposed to cascade with each other perfectly and they don’t. So I can’t do anything and I can’t make any decisions. And I’m sympathetic to that because again when you learn the theory of product management, you do often learn that it’s like the CEO sets the goals and then they cascade perfectly, and then the teams and there’s this per- but like, it’s never that way. There’s always tension between these different layers.

So I’ve started to think of it, I don’t know if any of you have watched the show Nailed It, where people who are untalented bakers or inexperienced bakers, I don’t wanna make any essentializing statements about people’s baking talent bake and they make these like big messy cakes. And I think it’s like that where in most organizations the different layers of organizational goals and strategies are like this messy cake. But like you have to take a bite. You can’t just be like, “No, I’m not gonna eat any cake. I’m gonna starve.” You have to take a bite of the cake and make the best decision you can with incomplete information and information is always incomplete. And once you acknowledge that information is always incomplete, forces you to think, to like see the value in some of the theories more where you’re like, “Oh, it has to be test and learn. ‘Cause, there’s never a complete enough information to not test and learn.”

Like we have to actually like ship more frequently and make adjustments more frequently because we never know that what we’re shipping is really what our customers want until they’re either using it or not using it and we can learn more about how they’re using it. So I think again, once you acknowledge that there is no such thing as complete perfectly cascading information it actually, in my experience, it freed me up a little bit to understand like, oh, okay, like this is where a lot of those ideas actually become pretty common sense, right? Like once you acknowledge that there is never a clear right path you have to do a lot of those things because there is no certainty and there is no safety. So that ability to learn quickly, to adjust course, all those good ideas at the heart of the agile manifesto that we tend to forget about all become pretty again obvious.

Janna Bastow: Yeah, absolutely. 

And I think there’s also an element of people assuming that the grass is greener on the other side or that their company that they’re in is a big mess. Their cake is an absolute nightmare and everyone else’s cake is fine. ‘Cause the reading, they’re learning from the books and the medium articles and the people who write big threads about it on Twitter. And these are the people who you know, often aren’t spending their time actually managing products and, creating these systems.

They’re the ones who did it maybe some time ago and since then have spent their time coaching from the outside and telling people the best way of doing it, which sounds great. But in reality, I get a chance to see inside lots and lots of companies and most people assume that everyone else is leaner, more agile, more put together than they are and they’re all trying to get there and they all feel quite, you pick up on the sense of shame going, “Oh, I, we’re not there yet.” It’s like, “It’s okay. No one’s there yet [laughs].”

Matt LeMay: Yeah, no one’s there yet. I think what people miss when they talk about things like the Spotify model or the Base Cam model or whatever is that these are models that are named for companies because companies experimented with ways of working that at one point in time worked for them and have experimented into new ways since then. But yeah, I mean I used to… So fewer people asking about Facebook now than used to as an example of a company doing product well. But when I did workshops and training people use to say like, “How does Facebook do product management?” I’d say, “Okay, I want you to pull out your computer and a piece of paper. I want you to use Facebook for 10 minutes and write down on that piece of paper everything that’s so broken about the Facebook experience that you would fix it on day one as a product manager there,” and people would run out of paper.

And I’d say, “All right, do you still wanna know how Facebook does product management?” I, I wouldn’t say that to pick on Facebook specifically, but just to say that any organization at scale has human problems. Getting groups of people to build complex systems is not easy. And all the companies, whose white papers and recruiting propaganda you’ve read have their own challenges too. As you said, the grass is not always greener, the grass is different. And I think over time people sometimes find a set of problems or challenges or constraints that they’re more comfortable and feel better working within, but there are always constraints and learning to work those constraints rather than throwing your hands up and saying, “Oh I can’t do anything,” is I think one of the most important lessons for a product manager over the course of their career.

Janna Bastow: Yeah, absolutely. Then, one of the things that I would say to product managers, ’cause the best way to level up is to get experience, right? Is just to get in there and do it and have the years under your belt. Because over that time you’re going to run into things that go wrong and go right and you’re gonna learn from those. But the next best way is to learn from other people’s experiences. ‘Cause, you can certainly fast-track that. And so sitting and listening to other people’s stories, reading other people’s stories, it’s one of the things I really liked about your book is that it’s filled with anecdotes from, product managers. “This is so and so from this company and here’s a little anecdote of how it went wrong for them [laughs], and here’s the lesson on that [laughs].” these are all little things that you can go, “Oh yeah, we’re in a situation like this, I’m gonna not do it that way.” and these are little things that level up product managers ’cause there’s no hard and fast framework, no hard and fast rule. There are just lots of little experiences and decisions that we run into over and over again. And a lot of them are in common.

Matt LeMay: Yeah, absolutely. And that was really important to me when I did both additions of the book that, there were just stories from just pro- from product managers, from like people actually doing the work. Because I think those, you for me, like my worst fear as a consultant is that I’m gonna lose touch with practitioners and start being like, “Do things this way.” so those are the stories and the people I still learn the most from, is people who are like on the ground doing the work. It’s always gratifying to me when I’m like, “Try things this way.” And they’re like, “Yeah, that doesn’t work.” And I’m like, “Thank you.” Like, help me understand how exactly this goes wrong. Help me understand where this broke down. Because it’s in seeing where those ideas break down that you often learn more about how to apply them and when to apply them and when not to apply them.

 So I, it’s my great joy to bring stories from working product managers who might not have the time or the inclination to like write up a Twitter thread or do a post. ‘

Janna Bastow: Cause most of us are working. And I say us, most of them are working, they’re doing [laughs], they’re doing product management stuff day to day, right?

 This is one of the reasons why I tell people in the chat here, to drop your LinkedIn, and connect with other product people.

 And don’t just connect, like reach out, ask what each other’s challenges are in your product. Start figuring out what’s in common, and start going for drinks and coffees and lunches with fellow product people. You learn so much from sharing experiences with other product people.

Matt LeMay: Yeah. People will occasionally reach out and be like, “Hey, can you like mentor me and talk to me?” and the first thing I usually say is, “Honestly, you’re probably gonna get more from just r- reaching out to like working product managers in your network who work for the companies that you might be interested in working for.” Like I have my opinions and I have my experience and I think I’m quite good at the work I do when I’m consulting within organizations, but the kinds of conversations you have, just talking with folks who are doing… Yeah, like, like Kelly here in our chat who wants to talk about product management and government.

 Right. If you’re interested in doing product management and government, which I highly recommend doing, you get to work on things that really impact people’s lives, hit Kelly, up on that offer. T- those opportunities to talk to people who are doing the work are so incredibly valuable. And I strongly encourage everyone here to seek them out and make the most of them.

Janna Bastow: Yeah, absolutely. Now somebody had a question for us in the chat here around, how much of a product manager, how much product knowledge, industry knowledge how much does that play a role in the decisions, and what needs to be built into the product? Like is it important that they’ve got a good grounding in this particular space? Or is it better that they’ve got a grounding in product management practices?

Matt LeMay: I think it totally depends, right? It depends on the organization, it depends on the product, it depends on the role. For me, I think the ability to learn is really the thing that I look for when I’m hiring. Like things change, like you, when people ask me like, “What’s the technical knowledge I need to have?” I’m like, “Gosh, I don’t know.” when I showed up as a product manager 12 years ago, I was like, “I know PHP.” And people were like, “This is a Python shop. Go, we don’t care what you know, grandpa.” And I’m like, “What?” So, I think the real challenge is always being open to learning in context, right? Being willing to ask the technical folks you work with to help explain the systems they work into you. Asking, the p- people…

There are people in a lot of organizations who have like decades of incredible industry knowledge. And honestly, I feel like a lot of product managers don’t reach out to them as much as they should. Don’t say like, “Oh, I want this person to like, just t- explain to me like, how does this work?” Like somebody’s asking like, how do you [inaudible 00:35:56] willingness to learn? I ask a lot of questions like, “What’s something you learned recently that surprised you or what’s something that changed your mind recently?” I really wanna see people’s ability to like speak to the things they don’t know or the things that have surprised them or the things that have changed their mind. The number one thing I interview against when I’m interviewing is defensiveness. Like, if you’re gonna dig in and be like, “No, I’m right.” Then like, I’m never gonna hire you. … I just really look for people who are gonna be flexible and open. And I will say, you in some industries, like if you’re working in highly specialized things, like yeah, there may be situations where you, it just doesn’t make sense to hire someone who doesn’t have that knowledge. But again, I think it depends so much on the product, it depends so much on the situation.

Janna Bastow: Yeah, absolutely. Ultimately the space can be learned by having those conversations with enough customers. Like if you don’t go in and you’re not an expert, that’s okay ’cause you will be an expert within the first six months. You’ll have so many conversations with everyone around you that you’ll pick up on it. So, I’ve seen people move from legal tech to FinTech to health tech to, complex spaces and just be able to pick up the concepts. But the most important thing is around being open to learning these things.

 Now, one of the things that I really like is you’d address in the book right up front is that product manager doesn’t need to work 60 hours a week. It’s a long-standing rumor longstanding saying that product managers need to work 60 hours a week to be successful. And honestly, I think someone needs to call BS on that.

Matt LeMay: Oh, I hate it. I hate it so much.

Janna Bastow: 60 hours is a long time. I don’t work 60 hours. I’ve never, I never did when I was a product manager. That’s insane.

Matt LeMay: No, and like there are a lot of people who can’t work 60 hours a week, and excluding those people from our community in our profession is a terrible idea.

Janna Bastow: Yeah, I absolutely agree. I mean I think it’s really good news to hear that in a year full of burnout a year, quitting a year when you know actually after a couple of years of just really hard graft work that you know what to be a good product manager, you don’t need to be putting in the hours. And what can a product manager do to be really impactful with their time?

Matt LeMay: Yeah, so I was talking to Ken Norton a while ago. It was one of my favorite product people. And he said something that really stuck with me in his mind, as product managers climb their career ladder, the thing they begin to understand is leverage. Like, what are the points that have the highest leverage? What are the changes I can make, the things I can do that are really gonna have the most impact, that is gonna cascade the most through the organization? And I think that’s a really smart point. Because I think when I was a baby product manager, I’m like, “60 hours a week is so much.” Like that’s what, 12 hours a day, five days a week, that’s like 9:00 AM to 9:00 PM… Like that is so unhealthy. That’s just bad for you. Like that’s bad and dangerous and sounds horrible. I would never wanna do that again.

And I say again because early in my career I did do that, in part because I was really insecure. I was new to this job, I didn’t know what I was doing. I wanted to show that I was working hard. I wanted to show that I was, this was New York 2010 I was hustling and grinding and doing all those things you’re supposed to do. And per Ken’s point, I did not understand leverage. Like, I just did not understand the impact of the work I did. And I didn’t understand that in a lot of cases the work I was doing was creating more work for my team and was creating unreasonable, unhealthy expectations for my team. There’s a moment in my career I think about a lot. A- as with a lot of product folks, I used a lot of self-deprecation early in my career to make myself feel better and alleviate some of the pressure.

When I had to ask my team to do something, I’m like, “Bruce, sorry, it’s me, the product manager, blah, deadline, blah, product manager. I’m terrible. But it’s okay, I’m working all night and I hate myself.” And I got an email from an engineer I worked with it was just like, “Hey man, are you okay? Do you really think you’re doing a bad job? Like, ’cause I think you’re doing a good job and I want you to be okay.” And I was like, “Oh no. Like I’m really like, this is manipulative.” Like this is not who I want to be. Like I don’t wanna be the person who’s like using self-deprecation as a strategy. I don’t wanna be the person who’s staying late because I want other people to think that I’m the kind of person who stays late.

And I hit a point when I was working at Sanzo, which was one of the best experiences I ever had professionally, where, we’d have our daily Standup and I’d be like, “I’m pretty much done with stuff. So like, if you do need help with anything, come and get me. I’m just gonna be like using the product and making some notes and plan on some user interviews, but like anyone needs help, you know where to find me, got a light load today.” And people will come to me for help. And it was really good. And everybody was like, “How dare you, you’re not working 60 hours a week.”

I remember really clearly at that same company I once really wanted to take the… I think we were working in Long Island City in New York, and I wanted to take the whole team out to this amazing Thai restaurant called Super Thai in Queens. And that thing happened that happens at a lot of organizations where everyone’s like, “A long lunch, can I do this?” And our CTO was just like I’m going so I don’t know what y’all think is so important.” And like the whole team just went and it was such an important bonding activity for the whole team.

So, I used to have a friend who worked in internet radio who said, “There’s no such thing as an internet radio emergency.” And I think at a lot of startups it’s worth keeping that in mind as well that it’s so easy to take on this sense of things being so important. And so like you can take on the weight of the world as a product manager and be like, “Oh, I’ve gotta do all this stuff. I’ve gotta stay late.” But like A, you probably don’t. B, your company probably, you’re an employee, you’re not you don’t owe them more than what you are contracted to do. And I’ve had to learn that the hard way a couple of times. So take care of yourself, pick your battles balance your energy, and manage your time, and you will not only do better work, but you will set a better example for your team and you will be a happier person.

Janna Bastow: Yeah, absolutely. And I think, setting an example for the team is really important. As a product manager you’re sitting in a really key role. People see you n- not, I’m not gonna say CEO of the product, but as somebody who often is a communicator of the management values, right? You’ve got this direct line of communication to management and you’re often setting the pace. You’re often setting the examples for the people on your team.

And if you’re sitting there working 60 hours a week, other people are gonna feel like they do that, they need to do that. Then the company creates this culture of like, it just has to work harder and harder. And if doing that, like ultimately means that the company, the bosses, the execs, they’re never going to pitch in and hire more people when the company needs it. 

Matt LeMay: If you’re having to work they’re gonna hire people and those people are gonna get upset. So there’s a story in the book about this, which kind of blows my mind where I was interviewing a product leader and he was like, “Yeah like we have these product owners, all they do is complain about how overworked they are, so I’m gonna hire more product owners.” He came back to me a couple of weeks later, he was like, “I hired more product owners freaked out. Like, ‘Why are you taking things away from us? Are we doing a bad job?'” And I was like, “All right, what goals are they working towards?” He was like, “Oh my God, we don’t have our goals defined.” Which is almost always what the, Oh my God moment, winds up being. Whether it starts with a question of role clarity or it starts with a question of like how people measure their own success.

If people don’t know what success looks like, they’re gonna find proxies. People wanna be successful. So this team had taken on overwork and like, “Look at all the products I own,” as their sort of informal proxies for success because they didn’t have a way of looking at the impact of their work. So I think about that a lot because I’ve seen that bizarre dynamic where executives are like, “All right finally, we’re gonna hire more people.” And people freak out and like, “Why are you hiring more people? Why are you taking work away from us?” And it’s like literally last week you were crying about how overworked you are and now you’re upset that there are people coming in to take away your work. And again, I think so much of it just comes down to like, can you be clear about what success looks like and specific enough for people to understand that?

Janna Bastow: Yeah, that’s a really good point. It’s really good to have that insight. Something else you said in the book wanted to ask you why are, it’s fine, phrases, the phrase, it’s fine. Why are they the two of the most dangerous words in product management?

Matt LeMay: Yeah. So, one of my guiding principles for product management is clarity over comfort. And looks fine or like, that’s fine, is not a statement of clarity. It’s a statement of like, it’s like a dismissive statement, right? It’s like, yeah, sure. Only specific affirmative buy-in. That’s part of why I like giving people choices, right? ‘Cause, you can’t give people a choice and get a response of, yeah, that’s fine. You are forcing people into actually engaging and looking at different options and making a decision. I’m actually putting together, if any of you are joining from Hamburg or Berlin, I will be there for product bank events next week, and I will be given a talk about how to say no without saying no. Because I also think that no is actually not a terribly clear statement, right?

I remember in high school when we would have exams, my least favorite questions were always the really complicated yes, no questions, where it’s like, “So and so was born in this year and moved to this city and this year and did this and this, and then died in this year. True or false?” I’m like, “What? Any number of those things could be true or false. This is impossible.

 And I feel like a lot of product management conversations play out the same way, where it’s like, “All right, we’re gonna build this feature for this customer and we’re gonna ship it on this date, and it’s gonna be this and this, yes or no?” And it’s like, “What? No, this should not be a yes or no question. This shouldn’t be like a sure or no.” Like, we need to really get into optionality and stay in optionality. So, one of the things I learned the hard way I thought naively early in my career that if I showed something to executives and they said yeah, it looks fine.” I was like, “My ass is covered. They said it looks fine. So if it turns out it wasn’t what they wanted, I can’t get in trouble.” Spoiler alert, I could and I did get in trouble. So that was real.

Janna Bastow: [laughs]. Yeah. Oh, you’re absolutely right. Oftentimes if somebody says it’s fine, they just haven’t been paying attention, right? They’ve just gone it sounds like you’ve come up with something good enough. We’ll just let it, we’ll let it slide. Yeah.

 … whereas if you, as you say, you pull in those options, you get them looking at it, thinking about it, you’ll be able to get some engagement with it and then probably some actual thoughts and way to improve it.

 You’ve got a particular tool that I love using. I mentioned this earlier on, which is the one-page, one-hour thing, which is really great for getting that early engagement. You wanna talk us through that?

Matt LeMay: Yeah, so this started in my own work with my consultancy in the states where, was talking to product teams and I was like, “Work smaller, work incomplete, share stuff with each other.” And my business partners would laugh at me and I was like what’s so funny?” And they were like, “You still show up to us with like 50-page workshop plans and just want us to tell you how great they are.” I’m like yeah, but you’re like my business partners and you’re really smart and I want you to see how hard I’m working and how great I… oh, I see.” So again, I feel like in a lot of cases the challenge is to shift the center of gravity around rewards and recognition. Again, many of us learned in school that if you’re given a 10-page paper right, and you write a 12-page paper, you’re probably not gonna get a C on it.

So I was in the habit of over-delivering as a way of getting rewards, right? Getting recognition. So in an attempt to combat that, I wrote out a pledge and shared it with my business partners and said, I promise to spend no more than one page and one hour working on anything before I bring it to the team. Please hold me accountable to this. And sure enough, when I would then come to them and be like, “Oh yeah, I knew we were on the same page, so I went ahead.” They’d be like, “Why did you do this? No, you made a promise. Don’t do that.” So part of the idea was that if you actually make an explicit promise to each other, you can start to shift that center of gravity. You can start to go from like, “Wow, you worked really hard on this a hundred slide deck that I now need to read and share with other people.” To like, “Hey, why didn’t you share this with me when it was just one page and you had only worked on for one hour? Like, I thought we had a deal together.”

So, I think the idea of like working generatively and sharing incomplete things is an idea that we can all agree on in theory. Again, the real challenge is shifting an organizational culture so that people actually have the incentive to work that way. And so they can still get that recognition for working in an incomplete way rather than getting recognition for presenting finished, polished, fancy things at each other. So you can take the pledge at onepageonehour.com. I periodically update the website with anyone who wants to have their name and organization listed. a lot of folks from a lot of fancy organizations have signed it. And it is one of my joys in the world to help share this very simple mechanism for taking an idea that, again, I think most of us can agree is a good idea in theory and giving teams just a shared language and a sense of grounding in how to apply it together.

Janna Bastow: Yeah, I absolutely love it. So I’ve shared the URL there, onepageonehour and absolutely worthwhile pledge to take worthwhile e- exercise to get involved with. It just cuts down on all the presentation-making and all the time wasted in people sitting alone at their desks when they could be having conversations with each other. And speaking of which there’s been some chat in the chat here around roadmaps. And I know that there’s some stuff that actually goes along nicely with this one page one hour, ’cause we had this conversation think it was in Hamburg when we were hanging out around how a roadmap should be something really simple, right? Don’t over-complicate your roadmap into this huge beautiful document that’s, gonna blow the minds of your execs. Instead, keep it really simple. I like to think of the roadmap as being a prototype for your strategy.

Matt LeMay: So I just did a workshop in Copenhagen, which was really fun. It was the first time I did this workshop. And it was called Generative Road-mapping. And I’ve done this in companies, but I’ve never done it as a workshop before where we basically, we were talking about Twitter ’cause it was on our minds. We’re like, “Alright, let’s imagine you have to present a roadmap to Twitter’s investors to make a case for how you’re gonna get the company profitable.” and everybody had 10 minutes to just paper prototype what a roadmap could look like. And then we did a bracket-style. So two people would join up, and they’d be like, “Do we like yours or mine? Let’s make some changes and integrate them.” And we just kept doing that bracket style until we wound up with two of them. And it was so interesting ’cause the ways that people visualized information were so creative and so surprising.

One person did theirs as, like a tree where they were like, we’re gonna lay- we’re laying the roots now and then the tree’s gonna grow. And I was like, “Oh, I really like that because that’s a visual metaphor that can help people understand a [inaudible 00:52:09] horizon.” Somebody else imagined it as a wheel with like different pieces. So I’m really into just like doing rapid generative visual prototyping for roadmaps just to be like, what is the right and visual language to communicate what we’re trying to communicate right now, keeping it really quick? And it’s been so fun to just see like the fun, interesting visual metaphors that people come up with like, Yeah.

Janna Bastow: Yeah, I love that. I think the roadmap should be more creative. You, I think we fall in on some of the usual looks of them. But honestly, I mean it’s whatever allows you to get your assumptions outta your head so you can check them with other people and have conversations around it.

 Now you also mentioned in your book uh, something called the Roadmap README.

Matt LeMay: Yes. That is the first step I always do. And that was part of this exercise as well. Before making a roadmap, I sit down with the team and we write a README document, which is like, who is the audience for this roadmap? What is the purpose of this roadmap? What are they to take away from this roadmap? What are they to not take away from this roadmap? So, per the conversation in the chat right here, like, the distinction between a product roadmap and a delivery roadmap is one that might mean something different in every organization. So rather than assuming that like everybody has the same idea of what that difference is, just write out here’s what this communicates, here’s what it does not communicate.

Like it might say, it says for example, like the broad themes we tend to [inaudible 00:53:36]. It does not say exactly when we are going to deliver these exact features. Or you might say, it does say when we are gonna deliver these features, it does not say what problems we’re solving. There’s a different document that does that. So really think through what is the purpose of this and making sure that README travels with the roadmap. I tell people like, that is the first page of your roadmap argument. The roadmap does not travel without it. I found to be a really helpful exercise.

Janna Bastow: Excellent. I love that. Now we probably have time for just one more question ’cause I wanna be conscious of the hard stop that you’ve got here.

 So thank you so much for taking the time to chat with us. I had a question here from Saielle, our friend Saielle, via Mastodon. She said “What would you say is the most overlooked general practice in product organizations today?”

Matt LeMay: Oh, I’m so glad Sael asked this because my question is gonna come by way of [inaudible 00:54:31] Sael made at the product which is facilitation. The practice of facilitation is so undervalued, and that is as Sael pointed out because it is largely fem coded. Facilitation is seen as something that like women and fem people do. Like, it’s like kindergarten teaching. It’s the soft stuff as opposed to the horror visionary stuff that like the real visionary leaders do. Facilitation is everything. You cannot do any of the things we are talking about without facilitation. The ability to actually get people in a room together to align on a decision and to talk through those things is far and away the most valuable skill you have in an organization. Like I’ve seen so many organizations completely ignore and like condescend to and not recognize folks who excel at facilitation.

And if there is one thing I could change in the product management world, it’s that we would have more folks in leadership positions who are facilitators and who value facilitation. Because it is so, so, so, so important. And it is so not taken as seriously as it should be and not valued as much as it should be for reasons that tie into a lot of the egregious biases that we deal with on a day-to-day basis in the business and technology world. So, thank you Sael for that question. For any of you who are Mind the Product Mind the Product subscribers, please watch Saielle’s talk the F words on product management from this year’s Mind the Product. ‘Cause, it was a barn burner, it was amazing.

Janna Bastow: I’ll definitely drink, drop the link for that in the transcription and the notes. But thank you so much for raising that point. It’s such an important point and I think it needs to be amplified. So I really appreciate that. On that note, I wanna say a huge thank you for taking the time to chat with us today. Matt, it’s been wonderful having you here today. So thanks again everyone for joining. Great to have you here. Matt and everybody take care and see you next time. Bye for now.

Matt LeMay: Thanks ,y’all.