Are you delivering impact as a product team? | Matt LeMay

In this bonus episode of Talking Roadmaps, Phil Hornby sits down with Matt LeMay to unpack what “impact” really means for product teams. They dig into existential business goals, why teams over-optimize proxy metrics, the dangers of the low-impact death spiral, and how tools like One Page / One Hour and multi-option framing help teams trade velocity theatre for real commercial outcomes.

Matt LeMay is a product leader, consultant, and author of the newly released book Impact-first Product Teams. He empowers product managers, teams, and organizations to maximize their impact on business-critical revenue and growth goals by streamlining processes, simplifying strategies, and focusing on the work that matters most.

Matt’s decade-plus career in product has included acquisitions by Google and Intuit, strategic advising to Spotify, and building out product teams for early-stage startups now valued in the hundreds of millions of dollars. His prior books Agile for Everybody (O’Reilly Media, 2018) and Product Management in Practice (Second Edition O'Reilly Media, 2022) have been translated into over 6 languages, and provide actionable guidance to individuals and teams across countries, functions, and industries.

Matt is the creator of the One Page / One Hour Pledge, a commitment to minimize busywork and maximize collaboration that has been adopted by over 100 individuals and teams at Amazon, Walmart, Adobe, Disney, and more. His work with tech ethnographer Tricia Wang has been included in Google’s official Design Sprint toolkit.

Previously, Matt worked as Senior Product Manager at music startup Songza (acquired by Google), and Head of Consumer Product at Bitly. Matt is also a musician, recording engineer, and the author of a book about singer-songwriter Elliott Smith. He lives in London, England.

Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).

In the next episode we have Anna Prevo, Head of Product Operations @ Ceros. So watch out for episode 23!

• Transcript

  - It's interesting. I mean, I think people have a tendency to be too clever for their own good sometimes. In a lot of cases we try to bake a strategy into the metric. I'll give you an example. I was talking to someone a while ago and I asked him, "What's the one metric that matters for your business?" You know, early stage startup, what's the thing that matters the most? And he said, "Retention." And I said, cool. Why?" He said, "Well, because if we don't have this much money coming in by this date, we go out of business and retention is the best way for us to get that money." I said, "Okay, but if you weren't going to get there from retention, would you want to at least make an effort to get there from new user acquisition?" And he said, "Well, yeah, of course."

  - Welcome to Talking Roadmaps, and we're again having another bonus edition. We're joined Today by Matt LeMay, the authors of "Product Management in Practise" and more recently "Impact-First Product Teams." I'm looking forward to talking about in particular things about impact-first, but we might bring in a few of the all the topics as well. Matt is known, I'm sure, to everyone out there. But Matt, please give us a quick introduction to yourself.

  - My name is Matt. I've been working in product 15 years. I really am interested in how people work together to do things that are greater than the sum of their individual contributions. I also play music in my spare time and cook beans and hang out with my friends sometimes. That's my riveting introduction.

  - If you're enjoying the channel, subscribe, hit the bell, and give us a like. And such an understated version of it. In fact, you know, I'm feeling like I need to talk to you about music because we have some intro music, but it's like just off the shelf. And then I remember listening to Randy and his podcast. It's like they've got Ana doing the music. It's like, maybe I need Matt LeMay doing my music.

  - I did, I actually did all the interstitial music for my audiobook for the "Impact-First Product Teams" audiobook because it was a phenomenal way to procrastinate when I did not want to sit in very seat and read my own book and periodically clap loudly so I'd be able to edit the many, many times when I spoke too quickly or misspoke or otherwise flubbed it.

  - The joys of those claps. Yeah, I mean, when I work with an actual videographer, again, I do a lot of that sort of stuff. I don't really do it on this channel, interestingly enough. Maybe I should. I need a clapperboard.

  - There's no mistakes in this channel, just happy accidents.

  - Let's start with that really fundamental question. What does impact actually mean for a product on a Tuesday afternoon?

  - To give the answer that we all give, it depends. It depends on your business model really, right? Depending on your business model, your funding model, the stage of your company, there is likely some milestone in the future that will determine whether your business is successful in the broader market. Whether that's a next fundraise if you're a startup, or your next quarterly earnings report if you're a publicly traded company, there is some market-determined set of promises or expectations that exists out there that will determine the existential success of your business. And impact to me is the contribution towards that goal, whatever it may be.

  - That was so philosophical. Are you sure you're not Greek? I mean that sounds very much product speak, how do we say it in language that speaks to the everyman?

  - Yeah, so it's probably money, is the short answer, if you are working for a for-profit business or really any business that does not exist in a model where its funding exists entirely separately from any profit motive. Like there's some definition of success that depending on your growth trajectory, again, might be top line revenue, might be profits, might be something to that effect. But you can generally assume that if your business model is the, is the fire, the engine of your business, then impact is the fuel you pour on that engine.

  - I mean, I was having that conversation only the other day. It's like people were talking about metrics and it's like, well, okay, what's the one that actually matters? What's the, if I have to choose one and make, align my initiatives to it, to drive it, what is it? And it took a surprisingly long amount of time to get an answer.

  - It's interesting. I mean, I think people have a tendency to be too clever for their own good sometimes. In a lot of cases we try to bake a strategy into the metric. I'll give you an example. I was talking to someone a while ago and I asked him, "What's the one metric that matters for your business?" You know, early stage startup, what's the thing that matters the most? And he said, "Retention." And I said, "Cool. Why?" He said, "Well, because if we don't have this much money coming in by this date, we go out of business, and retention is the best way for us to get that money." I said, "Okay, but if you weren't going to get there from retention, would you want to at least make an effort to get there from new user acquisition?" And he said, "Well, yeah, of course." So you know, in that example, retention isn't actually the end goal, right? Retention is sort of the strategic proxy for what we think is the best path to get to that existential milestone. But the existential milestone is having a certain amount of money in the bank by a certain day so that we still all have jobs to do. And I think that at times, again, we try to be a little clever for our own good and say, "Well, it can't be that simple. We have to put a few other layers in there. We have to have some plan expressed through the metric itself." In my experience, I think especially at smaller companies, just being like, "Look, here's what we need to do to still exist," or, "Here's what we need to do to move our share price up," for a bigger company. Just being that clear about the top line goal is really, really valuable.

  - And I mean I think that ties really closely to the whole outcomes versus output, or even choose inputs, outputs, outcomes, impact, sort of debates, like we try to find a proxy that is a driving or input metric, an outcome that we can measure more quickly, that's a leading metric. But there's a working hypothesis that goes to it's driving that impact. And that's exactly the scenario you just gave. Retention was the assumed driving hypothesis of the revenue. But it might not be right.

  - It might not be right. And we might also hit a certain point where if we have teams marching towards a now impossible retention goal or a retention goal that's simply not at the right level to achieve that revenue goal, we might actually want to look at alternate levers we have. And I think that discipline of keeping all levers in play and really using those cadences, not just to say, "How are we doing?" but, "What are we changing?" Are we going to reallocate some resources? Is there one of those kind of outcomes that, as you said, that where our hypothesis has been maybe challenged and another one where our hypothesis has been proven out, and if so, can we reallocate our work towards the stronger hypothesis? Those questions of not just how do we shift output but how do we shift our thinking around that entire system are questions that I wish teams asked more frequently.

  - And I think sometimes it's almost like the mindset of the organisation that is expressed there. Like I remember working for a previous company and it was a manufacturing company and its entire mindset was about if we have the factories full, we are making money. So if you wanted to justify anything, if you could show that it directly correlated with we're going to be making the factories busier and fuller. It was an easy ask. Anything that was about speed to market, that bypassed that, just was hard work, because that simple hypothesis in the whole organisation was that's our profit mechanism.

  - It's simple until it isn't, right? That's the thing, is that it's quite easy for those hypotheses to go untested for long enough that they kind of calcify not just into assumptions, but into assumptions that kind of permeate every decision that's made throughout the entire organisation.

  - Almost becomes a religious kind of belief in the organisation. And so we're obviously trying to high impact, I guess. I know you have a concept of the low-impact death spiral. Come on, let's give people an overview of that.

  - Sure. I mean, so this, the simple summary of it is that low-impact work begets further low-impact work. That when you do low-impact work, when you add low-engagement fiddly features, then every time you want to do something meaningful, you have to account for all of those low-impact, low-usage fiddly features and coordination to do anything meaningful that touches on the commercial engine of the product becomes more and more difficult. The more low-impact work goes into the system, the more complicated the system, the more coordination and dependencies you have to navigate in order to do high-impact work. This is my biggest pet peeve right now is that we still have so many folks, especially with AI talking about just speed. If we can ship stuff faster, ship stuff faster, but if you ship more low-impact stuff faster, then you are actually making things worse. If you ship 20 largely useless features very quickly, then you have to contend with 20 largely useless features the next time you want to build one actually useful feature or change to the core experience or something that is more likely to actually drive that impact. So I think as the cost of shipping for its own sake gets lower and lower, the risk of organisations jumping headlong into the low-impact death spiral and measuring their success by their ability to run headlong into that low-impact death spiral is only going to get worse and worse.

  - I mean it sounds like Agile on speed, because that was, it was all about velocity. We'll increase our velocity, we'll ship more, we'll ship faster. Is it the right thing?

  - Yeah. And you know, with Agile, it's such a shame because I think the intentions and the principles of the Agile movement remains so valuable. This idea of prioritising adaptability and collaboration and these real fundamentals that are every bit as valuable now, if not more so. But my kind of unified theory of everything when it comes to Agile is that any movement that poses a meaningful threat to the status quo will ultimately be co-opted by the status quo. So you know, you can look at it with like the history of counterculture, right? There's a great book called "The Conquest of Cool" about how 60s counterculture as we imagine it was already manufactured by advertising companies because the second it posed a threat to sort of the consumerist status quo, it was already co-opted to become a movement that just encouraged a more specific aesthetic of consumerism. And I think that with Agile, which was really a challenge to corporate hierarchies, it was immediately co-opted as a way to reinforce corporate hierarchies. So when people are like, "We need a new Agile manifesto," or like, "We need," I'm like, it's not an issue of the wording of the manifesto or the principles of the movement, it's the fact that the moment a movement is successful enough to pose a challenge, it will be co-opted to support the various structures it was intended to challenge.

  - In fact, I remember in "Product Management in Practise," you talked a lot about kind of your own journey through the Agile world and kind of being very much a zealot in the early days and having the perfect boards and et cetera and then realising the challenges there.

  - Yeah, one of my favourite, when I was working more in Agile world, I worked with a product owner at a big company where they used to have physical backlogs, which captured like the last 10 years of every idea that had ever been uttered in the presence of the team. And one day in a fit of frustration, he tore down the backlog. He literally physically tore down the backlog and said, "If we're not hearing about it from our customers, I don't ever want us to speak about it on this team." And that was an epic gesture that I still think about a lot. And which is less fun to do when you have a Miro board or a bunch of Jira tickets.

  - Yeah, hitting deleting Jira is still quite a pleasure. I mean if I could hit delete to the whole instance of Jira, I might even feel happier. Fine, and we all know as you started with, it depends, there is no perfect model, no perfect practise. And some of the, in some organisations, that way of working is still probably a massive step forwards from other places. But we're, that mindset of if we're not hearing it from the customers, I might extend it a little bit to internal customers or stakeholders, because we do need to serve our business as well. But if we're not hearing from them, then it's probably not high impact. But okay, so you talk about, is it existential realities for your business, for the business? And I mean, I'm feeling quite a philosophical vibe coming through. How do we help our product teams understand what that existential reality is?

  - You know, it's really funny. I've sat in rooms with a lot of product teams and asked them, "How is the business defining success in this next quarter or this next year?" And they really struggle to answer, because in a lot of cases those conversations don't really carry to the product team level. In some cases we wind up looking at the last town hall that the CEO delivered and saying, "What did they say about what's important to the business?" Sometimes we wind up looking up investor documents saying, "What is the market looking to for this company? What are the profit forecasts? What do the markets want to see to consider this business a success on its own terms?" In a lot of cases, those conversations play out at an altitude that feels quite far removed from the day-to-day work of product teams. And you know, when I do workshops around this, we usually start by doing this on behalf of another company. You know, we'll do sort of an analogous learning exercise where it's like, all right, imagine what would this be for Spotify or what would this be for Google. And then we bring it back to the context of their own business. And again, in some cases, people know the fundamentals of another business better than they know the fundamentals of their own business, because when you read up about another business, you have that distance where you can start to look at it more holistically and say, "If this business is something I have an investment in or something that I'm curious about, then of course I'm going to want to know how they measure success and what success means to them. But if all day I'm in Jira filing tickets and looking at my backlog, then I'm probably not going to think about my own business, even if those fundamentals are going to determine some very meaningful things about how I am evaluated and compensated."

  - And so, I mean, we, I think most organisations typically they ladder up or ladder down those objectives to try and create that bridge, right? I also, I love going to that last town hall. That's usually my first point. It's like, what's the most important thing? Like, because if that's what's been talked about, that's important. But I know you're not a fan of laddering down of those sort of objectives. Maybe you unpack that a little for me.

  - I'm a fan of a ladder with one step. So my thinking on this is highly informed by Christina Wodtke's book "Radical Focus," which I still think is far and away the, one of the best business books, one of my favourite business books ever. She blurbed my book, which is a huge honour for me. There's a little Christina Wodtke blurb on the back, but there's a visual in the second edition of "Radical Focus" which basically says rather than thinking of this multi-multi-level cascade, imagine the company goal, that existential milestone we talked about, as the centre of gravity, and every other team or department goal orbits one step around it. And once I saw that, it was a truly mind blowing moment because I feel like whether you're doing OKRs, KPIs, North Star metrics, however you do it, if you do it well, then every team can describe in one step why their goals matter to the business. And I think that as I've worked with more teams around thinking about these things this way, what I've come to see as the primary risk of that multi-level cascade is that as you cascade things down, they tend to get farther away from the market, farther away from the customer, and more and more just becoming a to-do list or a list of features, right? Those kind of assumptions you talked about, that the outcome is going to drive the impact, that the output is going to drive the outcome, every level down we cascade, we build more of those assumptions and more of that risk in. And by the time we have level six, level seven OKRs, if you have 10 teams working towards highly cascaded goals, there's six or seven levels of risk that those highly cascaded goals won't actually deliver the impact that the business needs. And that to me just feels like an unacceptable amount of risk to take on, right? If you tell me that every team at your organisation is working feverishly towards goals that may or may not deliver success for the business, that feels like an awful lot of risk to take on and a lot of time and effort to put into taking goals that are impactful and frankly watering them down until they're no longer impactful but they're things you can check off and can give you that sense of control and mastery which again is often antithetical to working towards the market and customer level goals that actually matter.

  - Yeah, I mean, I find that teams spend way too much time getting to those goals as well. If you're cascading, it's going to take you three a quarter just to get from the company level one to the local one as well.

  - It feels so clever, doesn't it? When we look at it, I mean I've been in those, in those week or month long OKR setting processes, and it makes you feel really clever. You're doing important work. You're having big serious conversations and saying like, "Oh," well, but again, in each of those big serious conversations we are baking in a lot of assumptions, right? And we are often again pursuing control over impact. We're saying, well, or we're pursuing, the thing that still really bothers me is when we say, "Oh well, we have to cascade these goals down until there's no overlap, there's no dependencies." And of course there are dependencies. Like I worked with one team once where we set impact level goals for the team and they said, "Well, but if we follow these goals, we'll have to work with marketing." And I was like, "Yeah, of course you'll have to work with marketing."

  - That's the work, that's the job.

  - Like, you like, "Oh, we as a product team will have to work with the people who bring our product to market." Like, yes, I highly suspect you will. That's not a bug in the system. That doesn't mean we haven't perfectly set our little perfectly tidy, zero overlapping goals. The purpose of a goal setting activity is to articulate in an actionable sense what success means for each team, not to go through this abstract exercise until each team has these perfectly neat little goals that fit together in theory but add up to nothing.

  - And I find even it goes a little closer to home. Like that's working with another function that's outside of product and tech. Even when those goals say, "Well actually I might need to work with that other squad that sat next to me," and that adds friction. And yes, we do try to design our organisations to minimise those generally because it is easier to move faster. But my experience, the things that really have an impact almost always cross more than one boundary.

  - I was doing a workshop a couple weeks ago with a company where they were trying to get all their product teams to those one step away from company goal goals. We went through it, we set them at the team level, and what we saw was that there were four teams that were basically trying to impact the same thing, but sort of at different levels of the funnel, right? Like one team was like, "Oh well, we're really trying to get more people in the door." And the other team was like, "Oh, we think we can convert more people at this step." Through that lens, rather than these being dependencies, we were able to say like, "Okay, well if these teams work together, then they can really amplify each other's efforts, right?" It's not, oh no, our metric is dependent upon your metric. It's if we look at these together and we coordinate up front and more frequently, then if we have this many more people coming in and we shift the conversion rate this much, we can look at these in a system and really figure out where the most important levers are, where in this system we can have the most impact the most quickly to make sure that we are achieving these company-level goals. And those are such important conversations. And I feel that sometimes in the wish to, as you said, kind of work within our teams, work within our silos, atomize our goals down to the point where they don't have any dependencies, we miss out on those opportunities which are often, as you said, where the most impactful work actually happens.

  - Yeah, I suspect that's another mechanism for that low-impact death spiral, right? You're doing smaller and smaller work that has less and less impact because you're going for the easy with less coordination, less kind of overlaps and making your day to day easier, but your goals harder to achieve.

  - Well, and I think, you know, that that velocity fetish is also something that gets in our way here because work that requires coordination does require coordination there. You do need to work across teams, you do need to have conversations. The things that ship probably will not ship as quickly per se as they would if they did not impact as many teams, if they did not involve coordination, if they didn't have real risks associated with how they will impact, again, that commercial engine of the business. But the thing that worries me is that I see the implicit incentive in so many organisations hewing towards low-impact work, which is to say again, the teams that ship a lot of low-impact stuff, those are our, they get stuff done. Those are our fastest, our most effective teams. They're the teams that often invite the least scrutiny from executive leadership. I worked with one team once that talked about how they don't like taking on things too close to the heart of the product, because the Eye of Sauron descends on them, which is suddenly the CPO, the CFO, the CEO, all these people who otherwise would be happy to leave them to do their work, suddenly have very strong opinions about the work they're doing and really need to be involved. Ideally, this would be celebrated as a sign that the work they're doing is really important. But, and I get this, in practise, it's mostly just annoying. It slows you down. You have to explain things to a lot more people. You have to have a lot more of those alignment conversations. And it's very easy to fall into a trap where you look around and say, "Wait, these other teams are shipping a lot of things really fast. We're celebrating all those new, cool, shiny things they're doing. Why would I want my team to be the one that not only is moving more slowly, but is moving more slowly on things that a lot of very important people have a lot of very strong and at times contradictory opinions about?" It's just not incentivized in the real world in most organisations.

  - And those big things probably also carry more risk of going really, really well or really, really badly as well, not just slowly.

  - Yeah, the analogy I use in a lot of talks is if we were all product managers working on a car and I gave you the option of either fine-tuning the engine or bedazzling the car with rhinestones, if you put rhinestones on the car, every time the CEO walks by, there's more rhinestones on now than there were before, right? You can just do this sort of linear progress towards more visible and understandable success. And the best part is if the car doesn't run, it's not your fault, because that's whoever had their hands in the engine. That's not your fault. That's the engine team's problem. You know, I've heard for the engine team isn't really a best in class product team. I' heard that engine team, they're just not really product led. They're not really doing things the right way. But like, why would you stick your hand in the engine? It's your hands are going to get dirty and if the car doesn't run properly, it's your fault. The problem, I often say, is that when the car does stop running, if the hood is completely covered with rhinestones and glue, you're not going to be able to lift it anymore. So a lot of that work, that low-impact work that feels like it does no harm, again, is just building out this death spiral, leading the company deeper and deeper and deeper into this spiral of low impact but high internal cost and high complication stuff.

  - And I can see this overlapping a little bit with a recent conversation with Nesrine Changuel where the rhinestones are also really surface delight. They look cool, but the engine is really deep delight, because when you put your foot down, it really delivers that delight and the value that you really want.

  - Nesrine's book is phenomenal. I have a copy of it. Where is it? Right here, "Product Delight."

  - We talked about those alignment conversations. You're the author or creator of the concept of "One Page / One Hour" and creating that kind of brief, quickly put together, should we say, strawman approach to starting that conversation. I employ it on a regular basis. With AI helping me accelerate how far I can get, a lot to kind of get to that one page in a good place where I've had the chance to think it through, like when I sit in a car, I just sit and chat with my AI now and then I format it into something when I get out the car and it's quick, bish, bash, bosh. But I have that paper to start the conversation. I mean, I've kind of said a bit about it myself, but like, kind of I know it's a super important part of your approach, and can you speak to how that helps get to that impact?

  - Yeah, I mean, if you don't have a concise starting point, it's very hard to know what you're even talking about in the first place, right? This is, I work with teams where I ask them, "How do you define success?" And they send me a hundred-slide deck. And if you need a hundred slides to answer that question, then you can't answer the question. If you need 15, 20 pages to have a strategy, nobody's going to actually internalise that. It's not actually going to guide decision-making in a meaningful way. And I think, especially when you're looking to work collaboratively, when you're looking to bring people together, bringing those misalignments to the table up front is how you get alignment. You get alignment by identifying misalignment. But if you don't have a concise document, then you're going to hide misalignment rather than bringing it up. One of my favourite, my favourite "One Page / One Hour" story. I was working with a company and their leadership team, five people cross functional leadership, had put together like a hundred-slide deck that was going to be their, the kind of everything deck. The here's our strategy, here's our operating model, here's everything we do. And I asked them if I could spend one hour bringing it down to one page. And they said, "Sure, who cares?" So I presented this one-pager back to them, and they tore me a new one. I have rarely been spoken to the way I was spoken to in that meeting. "This is garbage. We hate this. We would never say this." And as they each went through telling me what I had gotten wrong, it became clear that each of them had written 20 slides but not read the other 80 slides, that they had not aligned on any of these things because each of them felt like their job was to get their point of view represented in this document. But when you have a hundred slides to work with, there's very little need to actually work through your misalignments, right? Because you kind of skim what everyone else said, you say what you want to say, you pat yourself on the back, and you get on with it. So this one-pager, once everybody realised what had happened, the conversation really changed direction because they realised that they were not aligned. The reason this document was 100 pages was that they couldn't actually write a one-pager because they don't agree on some of the fundamental things about how they think the company should operate. So I think the beauty of working in that one-pager, however you start there, is that it forces you to be concise enough that there will probably be stuff that people vehemently disagree with. There will probably be stuff that people look at and say, "Oh, I'm not sure about that." And that's exactly what you want, because the process of aligning is, again, the process of making sure that we are on the same page about important things and making sure we're on the same page about what's important.

  - Yeah, I mean, the approach I used recently was there were five of us doing an off-site, and all five of us wrote a one-pager, and then Amazon style, we asked. We all took the first 20 minutes to read each other's papers and then compared notes. And it happened that we were all pretty well aligned, but the interesting bits were in the bits where we weren't.

  - Well, and also, you wouldn't know you were, like, you wouldn't necessarily know you were all aligned on some things if you hadn't done that, right? I really like that of starting with everybody kind of, I've seen that happen sometimes when it's like a team seems really misaligned because they're hung up on a few details where they're misaligned. But when you ask everybody to kind of do that generative exercise, it turns out that we're mostly on the same page. And that can be really valuable in and of itself.

  - I often find myself essentially saying the phrase I like is that we're violently agreeing. We're like, we're agreeing on like 90%. And it's this little bit we're arguing about. Sometimes we can just put that on the side, because actually we probably never even get to that part. All the time, it's like, okay, that's the bit. That's the, we do need to take this on, but let's do it in a more constructive way now because we are so aligned. Let's just deal with the differences. Yeah, it's just understanding where everyone's coming from and those base assumptions is so powerful, I find.

  - Well, I think also that the time box is really important, right? Because it's so easy, you know, I do this when I, when I help teams set goals. I'm like, we're spend an hour setting your goals and then we'll see if they work, right? We won't know if they work till we try using them. But I do see a lot of teams fall into it. It's like, oh, no, we need a month to come up with our strategy. We need a month to come up with our goals. And it's like, if you need that long, you're probably over-complicating it. You probably are kind of baking more and more assumptions and very clever things into this thing, which is not intended to be super clever, right? In "Good Strategy Bad Strategy," Richard Rumelt says that a good strategy is obvious. And I really like that. I think we seek to be clever at our own broader detriment sometimes, when sometimes it's like, this is pretty straightforward in theory, but how we get there and what we do is where it gets much more complicated.

  - Yeah, I mean, your mention of 100-page slide decks is very much a bugbear of my own as well. I, wherever possible, try not to use slides, but if you're in a corporate world, it is almost unavoidable, I've found.

  - Well, here's the interesting thing. I found that oftentimes leadership will be very excited about asking for a "One Page / One Hour" approach, but then will not follow it themselves, right? They'll say, "Oh, we want to see more one-pagers, we want to see more works in progress, we want to see more unpolished things." But then they will still only communicate in very polished, extensive decks. And you know, I think there is an anti-pattern at a lot of organisations where people obviously, if they want to be upwardly mobile within an organisation, they want to communicate the same way that the bosses communicate, right? They want their own work products to resemble that of leadership. So over time I can tell them, "Oh, this is how I like to work, this is what we want to do." But if they have an opportunity to present something that looks like something leadership would present, they're probably going to take that opportunity and I don't really blame them for it.

  - You never get fired for hiring IBM, like if you're going for the safe path.

  - Yeah, well, and I think, I think that in a funny way, you know, the medium becomes the message, right? Because when you have this polished but vapid document, then you are presenting a polished but vapid message, because you don't actually want to be challenged, right? You don't actually want the Eye of Sauron to descend upon you. You want leadership to nod politely and then get on with their day, so you can say, "Yay, look at this. Like, people seem to not ask us hard questions, that went really well," and it's like, well, did that go really well? Is that what you really wanted? Is the goal here just to like get done with the meeting or is there an actual purpose to this? Are there ways we can ask some questions or present some things which are going to potentially bring some of those misalignments forward. And again, I think if you're presenting a very soothing 20-slide deck, it's very difficult to do that.

  - So what's a practical way of reducing that presentation culture then?

  - It's tough. It's really tough. I mean, I think there's almost like two tiers of, there's sort of this cycle in presentation culture which in the book I wrote about Agile, I call it a report and critique culture, where there's sort of two, you wind up with two unofficial classes of people, the ones who report and the ones who critique. So the ones who share the decks and the ones who tell them what's wrong with them. And everybody's kind of trying to get into the critique chair. Everybody wants to be the one who gets presented to, not the one who presents to others. So I worked for the company once, that was very much in this. I was coming in as a consultant and folks who were the reporters in their own hierarchy were looking forward to being the critiquers in our hierarchy. So they were like, "Well, I have to report to leadership, so you're going to report to me, and I'll tell you what's wrong with it." And I was like, "That's not really how I work. Like, we're going to co-create stuff, we're going to do things together, we're going to get out of this report and critique loop." So I think identifying that loop is a really good first step because in a lot of organisations, there's reporters striving to become critiquers, right? There's people who are in this loop where they see their job as to like, be an effective reporter until they can sit in the critiquer's chair. But what that means is that you are basically seeking to avoid critique, not to gain clarity. My favourite thing I said in "Product Management in Practise" is that good product management is about choosing clarity over comfort every single day. And I think that the reality is that a lot of decisions are made in pursuit of comfort, not in pursuit of clarity. So this is a long-winded way of saying that practically speaking, it's a major shift for how most companies work. And that surprised me. I was like, oh, how hard can it be? You're just going from a 20-slide deck to a one-pager. But it's not just the 20-slide deck, right? It's that sense of control, it's that sense of comfortable avoidance that comes from being able to hide things in a longer deliverable. It's that sense of upward mobility that comes from presenting something that looks like what leadership presents, or maybe even getting to critique someone else's presentation and tell them which parts you liked and which parts you didn't like. So it is a more complex and multifaceted cultural move than I think I've appreciated at times. But as with most complex, multifaceted things, it moves person by person, conversation by conversation, document by document. Each of those little decisions begins to shift the culture at large.

  - I couldn't agree more. I've been back in a role doing product work for the last seven months. And two, three months in, I realised the biggest benefit I could bring was clarity. And that's when I switched back to, okay, I need to be writing my one-pagers. I need to be getting my thoughts out. And I know you've been in and done a session for us in our community practise not that long ago. And in there, one of the things I really, really took away and took absolutely to heart and have implemented in every single paper I've written since then is the three or more scenarios angle, because it's just been so powerful. Getting certain leaders to read the one-pagers has been challenging because they want the deck that's presented to them. Getting to the clarity that I knew where I was going if I then even I had to convert it into a deck, I'd at least done the thinking to get there. But that multiple scenarios piece was super powerful. So maybe you could unpack that concept for the audience.

  - Yeah, so I did a, with a company I was working with, we did like a little role play exercise which was really interesting, where we had one person kind of playing product manager and another playing executive. And in the first scenario, the product manager presented one option, said like, "Here's the thing we want to build." And the executive immediately started saying, "Well, here's what's wrong with it. What about this, what about that? Here's what's wrong with it." And they got kind of locked in this oppositional dynamic, right? Where it was a negotiation between yes and no. We tried it with two other people where we had the product manager present three options. And three is the magic number, right? Because it's not A or B. There's, you have to dimensionalize it a little bit to make a choice across three options. And said, "Here's A, here's B, here's C. Our recommendation is for B, and here's why." And what you saw was that the person playing the executive, the questions they asked actually helped get us closer to clarity, because the questions they were asking were in some cases revealing some of their own thinking at a more systems level, right? So not just like, I like this, I don't like that, but like, oh, this one seems to be optimising for this, whereas that one seems to be optimising for that. Which of these are we actually optimising for? So I think there is just something. There's like a purely magical thing where if you present three or more options, again, three is my favourite number. But if you present three options, you get out of that adversarial position. You get out of yes or no, or A or B. And in doing so, I think you always learn a little bit more about what you are actually trying to achieve.

  - I think that brings us all the way back to the start of this conversation. It helps to reveal if it's not clear what that objective, well, that most important thing we're driving is, because, yeah, you start to have the conversation about, well, actually is this one that you're recommending really taking us in the direction that we believe that is actually our goal, often poorly articulated. And then it starts to unpack that same conversation for me.

  - Yeah, I remember I worked with a CEO once who, we were doing this exercise. This was when I worked at Songza, which is a now defunct music startup. But it was one of the best experiences I've ever had professionally. And their CEO would, every quarter when he wrote OKRs, he'd have his office door open and be like, this is not just me disappearing. I want to be as connected to the team as possible. Come in, let's iterate on these. And I came through and I was basically like, "Look, I got some things we could build that are going to increase the number of users, some things that are going to increase revenue, some things that are going to increase revenue per user. You have objectives related to all of these things, but I don't know which one's most important because I could make the case for any of these. What are we actually trying to do?" And we went back and forth and eventually he was like, "Well, I'd go for the one that's revenue per user, because what we really want is to build that flywheel where even if we keep growing at our current level, that's fine if we have user growth and revenue growth going in the same direction." So that really helped us systematise all of that and say, "Okay, well, if we're looking at these different things, if we're actually using this as a way to make decisions," but it's, you know, three goals can be used to justify three different decisions. If we actually practise making these decisions and say, which direction do we want to go in? Then that's going to be really, really clarifying.

  - Well you know me and my love of decision making and having context there. So I'm going to switch gears a little bit as we start to kind of bring ourselves to a close. One kind of more, I guess, a little more still philosophical, bring the Socrates back out again. What belief from your early product career do you now think is wrong? And maybe what triggered that, the change in that belief?

  - I mean, I think early on in my career I was definitely one of those, you need to work yourself to death to be an effective product manager, people, one of those, oh, you need to work 60 hours a week and you need to be like, willing to do whatever it takes, and you need to be willing to do all this. And I think I've given up on that line of thinking for a number of reasons. Number one, I just frankly haven't seen companies reciprocate that degree of effort and care for the people who work for them, so I am hesitant to ask people to make sacrifices on behalf of a company which may or may not warrant those sacrifices. But I think more broadly, I think really effective product management frees up time rather than filling up time, like really effective product management. I was talking to someone a while ago who was on his way to visit the French office for the company he manages, and he said, "They are the most effective product managers because they're not into busy work culture." They're not into like working 9-9-6 hours, like they wanted do their work effectively and go home and have a full balanced life. And as a result, they're actually doing the most meaningful stuff because they don't want to be wasting time and showing off all this stuff they're doing that doesn't actually mean anything. So I think, coming from New York startup world, I was a little like drunk on the hustle culture when I started out. I subtly rewrote one thing from the first edition to the second edition of "Product Management in Practise," where the guiding principle for execution, which is one of the core skills in the book, in the first edition was no work above, no work beneath. So like, do whatever it takes. In the second edition, I changed that to all efforts in service of outcomes, because I've seen that idea of like product managers should do whatever used to sort of weaponize especially existing biases across different groups of people and who should be doing what and used to justify some bad behaviour that I don't think should exist in the product management world. So my thinking on that has changed a lot, and I think I've had to kind of check in with myself more about what personal insecurities might have left me feeling like I need to over demonstrate value.

  - I think any of us who started products some time ago probably went through that same journey. I definitely lived that hustle culture. I think it was very pervasive in the early days in particular when there were so few of us, right? There weren't, like you now see so many product managers in an organisation. Well, we were a handful in most companies back in the day.

  - Well, now it's just a job, right? Which is great. I think there's, I think certainly there was a time in my life where I probably over ego-identified with my job and my title and like what I was doing. I'm a product manager and now I'm like, it's a job. It's a really good job sometimes. It's a less good job other times, but it's a job. And hopefully, you know, I think the thing that surprised me most when I was researching this book was that the most commercially minded product people I spoke to were also the happiest. You know, I worried that, oh, they must be the most stressed out because they're chasing market level goals that are outside of their control. They have to stay connected to their customers. They can't just have the comfort and safety of kind of cordoning themselves off and just shipping stuff. But they were the happiest because they were like, "Yeah, this is my job. Like, I go to work, I try to make my company successful on its own terms and then I go home, and I'm not fighting this quixotic battle to make my company product led or like, make sure we're doing the right thing or like, make sure that they our company doesn't understand they have to change everything." It's like, no, I do the best I can from where I sit to make sure that my team contributes to the business and then I go home and do the other things I want to do with my life. And I think there are always things to learn from that.

  - But I think there's also something, there's something in that that comes with a little bit more age and maturity as well to accept that. Well, okay, I'm going to ask you my penultimate question. If you had to distil your philosophy on impact for product teams into one or two sentences, what would it be?

  - The moment you think you're being really clever, you've probably done too much. I think that that's what I keep coming back to is I'll work with teams. They're like, "Our goal is to achieve this much revenue." I'm like, "Great." And they're like, "By doing these 12 things." And I'm like, "No, no, no, that's not your goal. Like, that's your roadmap." So I think a lot of what I, I think I said this in the book somewhere, but like the moment you feel like you're really cooking is probably when you've gone too far.

  - That said, I really love NCTs for the ability to, for example, in the tasks part, just to capture those 12 things but then have that really clear heuristic of, if I achieve none of my commitments, either revenue, and all the tasks, I've probably failed or I have failed, but if I achieve my commitment, and none of the tasks, it's all good.

  - Well, that's one of the things I talk about in the book also is that product people get really nervous when everything's going well but they don't know why or they feel like they can't attribute it to their own team. If they're like, well, everything's going up into the right, but I feel like that's really what marketing is doing or that's really what this other team is doing. I'm like, "Well then go talk to them, figure out what they're doing that's awesome and how you can help and contribute to it." Like this is not the time for you to hide in fear and worry that you are not going to be able to take credit for something good that's happening. Like understand the good thing that's happening.

  - Is this anything else I should have asked about high-impact teams that I haven't?

  - No, I think that, I think we've covered a lot of ground. You know, again, the thing I keep coming back to is like the work is hard enough. Tying things back to impact is hard enough. Sometimes the most straightforward high-level goals actually leave us the most leverage to adjust course and figure out what we need to do. So yeah, it's, as we come out of this planning season and go into actually doing stuff season, think about how maybe there is only really one season which is the figure out what we're trying to do and adjust course until we're doing it the best we can season.

  - So Matt, it's been absolutely great having you here. As always at the end of the show I do like to give our guests a chance to pitch themselves, how people can get in touch with you, how they can be useful to you. And obviously I will just remind people, do go and pick up a copy of the book.

  - Yes, you can pick up a copy of the book. Everything you would want to know, all things Matt LeMay, are at mattlemay.com so you can learn more about the book. You can learn more about my consulting work. There's even a link in my bio to my music world, my other little secret life where I do recording and mixing work and tour with my friend Will's band. All your Matt LeMay needs, mattlemay.com.

  - It just leaves me to, Matt, it's been a pleasure having you here again as a returning guest and just to chat with a friend as well. Maybe have you around season three sometime, when something else to talk about.

  - I hope so. Pretty good at running my mouth.

  - Great to have you, thanks, Matt.

  - Thanks, Phil.