Product Agility

Impact-First Product Teams (With Matt LeMay)

• Ben Maynard & Matt LeMay • Season 2 • Episode 32

Share episode

Send us a text

How can product teams truly maximise their impact on business-critical goals? Matt LeMay, a seasoned product leader, consultant, and author, shares his experience and insights on transforming product management into a key driver of meaningful business outcomes. With a career that includes guiding teams through acquisitions by Google and Intuit, advising giants like Spotify, and building product teams for startups now valued in the hundreds of millions, Matt offers a wealth of knowledge.

Matt discusses how an "impact-first" approach shifts the traditional role of product management from simply facilitating ideas to actively contributing to significant business success. He highlights the importance of aligning team efforts with the core objectives of the business, ensuring that every action taken is purposeful and drives real results.

Key Takeaways:

  • Defining Success: Strategies for aligning product teams with the business’s critical goals to ensure substantial impact.
  • Facilitation vs. Leadership: Why effective product management is about empowering teams rather than leading them with a top-down vision.
  • Managing Dependencies: Approaches to handling dependencies without isolating them from the team, fostering a more integrated problem-solving process.
  • Ethical Considerations: Balancing business outcomes with ethical decision-making in the face of market pressures.

Perfect for product managers, team leaders, and anyone involved in directing a product team's efforts, this episode offers practical guidance on how to lead your team to make a tangible impact on your business.

Links and Resources:

Host Bio

Ben is a seasoned expert in product agility coaching, unleashing the potential of people and products. With over a decade of experience, his focus now is product-led growth & agility in organisations of all sizes.

Stay up-to-date with us on our social media📱!

Ben Maynard

🔗 https://www.linkedin.com/in/benmaynard-sheev/

🐦 https://x.com/BenWMaynard

💻 https://sheev.co.uk/

Product Agility Podcast

🔗 https://www.linkedin.com/company/productagilitypod/

💻 https://productagilitypod.co.uk/

🖇️ https://linktr.ee/productagility


Listen & Share On Spotify & iTunes


Want to come on the podcast?

Want to be a guest or have a guest request? Let us know here https://bit.ly/49osN80

Started out in product. I mean, I would say candidly speaking, got promoted to quit and had to learn very quickly while trying to minimize the damage I was doing to the people and teams around me. But the thing that really struck me was that so much of the work I was doing felt like facilitative work. I wasn't necessarily a visionary. I wasn't the person who had the great ideas or even who really led the team through executing those ideas. I helped set up the team for success. I put the systems in place. I helped bring out the best in people and I really got this sense that product, as I understood it was a facilitative role, not a visionary role. Welcome to the Product Agility podcast, the missing link between agile and product. The purpose of this podcast is to share practical tips, strategies and stories from world class thought leaders and practitioners. Why I hear you ask? Well, I want to increase your knowledge and your motivation to experiment so that together we can create ever more successful products. My name is Ben Maynard and I'm your host. What has driven me for the last decade to bridge the gap between agility and product is a deep rooted belief that people and products evolving together can achieve mutual excellence. Hello, welcome. This is the product Agility podcast. I am your host, Ben Maynard. For those of you who have listened to this podcast before, you probably knew that I should think about changing the way I start my podcast once again. But today, I am not important. I am not important any of the days. To be fair that we have these conversations because today we are joined by Matt Lemay. And Matt is an author of three books, I think it's fair to say 3, two of which are out in the wild and one which is yet to be born. That is true. Yeah. So as well as being an author, he's also a consultant and he helps teams make an impact. And that's going to be the focus of our conversation. Now, Matt is somebody whose name I've been aware of for quite a while. And I always tend to say that because I always, I just basically stalk people in my spare time trying to find people to come on the podcast. And, and I've been really, I, I say this with everyone and I, and I, I do honestly mean that I'm genuinely excited to have you here, Matt, because I think what you've got to share and the thing, the way that you'll share it is genuinely interesting and engaging. And I think everyone listening is really going to get something from this, particularly because the the the superset of the topic, the big theme here is product teams. And we're going to be looking at how they can make an impact, even if they perhaps they can't, and maybe why they feel like they should just get off the lazy asses and try harder. Oh, your words, not mine. Yeah. I thought that was a new book. Get off your lazy asses and try harder. Hustle Culture Manifesto for crushing it 24725 eight. Because if you can only find 24 hours in a day and seven days in a week, then you're not trying hard enough. Exactly so. And Matt has this amazing ability, which I pointed out to him earlier, but he comes out with such lovely, eloquent sentences I can never even begin to repeat or do justice for. But I just sound like a very poor analog, a very dumb copy of Matt when I try and paraphrase things back. And that's part of the reason why I'm excited, because I really like listening to what you have to say. Matt, for our listeners, could you perhaps fill in some of the gaps on the intro that I gave? Sure. First and foremost, thank you for that lovely intro. I I am both deeply flattered and, and wish you had set the bar just a bit lower for the conversation. And I have a new book coming out shortly called Impact first product teams, which I suspect will be the majority of what we talk about today. Yes, I hope so. Now, just as a points of figure, I was talking to a not even a potential podcast podcast guest, an actual person who's coming on the podcast who said how much he enjoyed your first book because you actually did the stuff you're writing about. Which I think is a bit of a boon really, because I think there are so many books out there written by people who've had a thought and they haven't actually tried it or they've just picked and chosen bits from existing case tellies about where they have perhaps believed that people are doing the thing that they're writing about. So I think it's fantastic that you've got solid experience in the thing you're going to talk about. And and I said today, it's about teams having an impact, particularly product teams, what we kind of really delve into it. I'm just wondering what is your experience then of helping product teams make an impact to the business? Sure. So I mean, I started in product about 14 years ago. I was the first product manager at Bitly in New York. Oh, really petty days of link shorteners paying my rent. But Lee is still doing doing quite well. So I have some, some friends who are working. They're doing, doing phenomenal work. But I, I started out in product and kind of, I mean, I would say candidly speaking, got promoted to quit and had to learn very quickly while trying to minimize the damage I was doing to the people and teams around me. But the thing that really struck me was that so much of the work I was doing felt like facilitative work. I wasn't necessarily a visionary. I wasn't the person who had the great ideas or even who really led the team through executing those ideas. I helped set up the team for success. I put the systems in place. I helped bring out the best in people. And I really got this sense that product, as I understood it, was a facilitative role, not a visionary role. I think that has informed a lot of the work I've done since then. I really prefer working with and through a team as opposed to working for a team. I think that product work is at its best when everybody on the team understands not just their own individual perspective on the work that's being done, but can really understand each other's perspective, understand the way that decisions are being made holistically and make those connections between the choices they're making and what the business needs to see as a result of those choices. So in the last couple years in particular, I've worked as an independent consultant and with business partners for the last 10 years or so. I've worked with Spotify and MailChimp and Google and some very early stage startups and some very big CPG companies. And I realized about a year ago that the last two to three years of work I had done had all been about helping teams understand, articulate and work towards a business level impact. I don't think I that that's what I was doing at the time, but when I had a moment to look back and take stock, so much of the work that I had done with teams was around setting goals that were impactful enough to be meaningful to the business and specific enough to drive day-to-day decision making on the team level. And helping teams work through some of those very wicked challenges of attribution and estimation and really figuring out how to do that when your goals are market level enough to be outside of your immediate control. So when your goals are not simply things you can do or ship or check off a checklist, but things that require actions from people and markets and customers outside of your control, how do you keep your goals at that altitude while still staying engaged and motivated as a team? That's been a lot of the work I've been doing. And I realized I had enough stories and experiences and folks I'd talked to to hopefully wrap some of that up in a book that would be helpful to folks. And that is the book that I am finishing up right now. When we say business impact, I would like an example or some examples if you may, because oh, please, I know that everyone has different experiences and I know that one person's business impact is another person's local optimization. Yes. So I'd love just to frame the conversations, right, give us some examples. Well, I think you touched on something really important there, which is that business impact will mean different things to different businesses with different business and funding models. For example, I was working with an early stage startup that was working to raise its next round of funding and they had been working on kind of a mix of growth and revenue generating features. So they had primarily existed as AB to B business, and they had grand ambitions to pivot to B to C and grow their user base exponentially. They had some folks working on features which would create more revenue from their B to B customer base and others working on things that would ideally expand to AB to C customer base. This often makes me nervous, and I think it is often true that you have different teams within a company optimizing locally in a way that might not be adding up to more than the sum of its parts. So I, I met with the founder of the company and I said what needs to be true for us to raise this next round, if our next big milestone is to raise this next round of funding and if we want to raise it as a growing business, what needs to be true? And the founder of this company, very, very smart woman said, I don't know, but I know somebody who does. We got on a call with one of the lead investors and we put together an actual business case for here is what will need to be true for us to raise the next round in the manner we seek. And it largely revolved around a specific number of active users. The investor said, look, if you want to really grow this business, I want to see this many active users to know there is an opportunity here that would befit the scale of the investment you're asking for. Brought that back to the team and they said we're going to have a really hard time doing this because this isn't what we've been working towards. We've been working a little bit towards this, a little bit towards that, a little bit towards growth, a little bit towards revenue. So what we did was we basically put together 2 scenarios, 1 in which we get to where we need to be to raise this big round as a B to C business. The other where we pivot and focus in the shorter term on revenue so that we have enough runway to give ourselves the time we might need to actually do the things we would need to do. And wound up making a soft pivot towards that revenue generating use case because that was what we needed in order to really realign towards what we considered our our green light or best case scenario. we go. But I use that example because it's an example in which business impact and revenue are not synonymous, right? Says you think business impact, money, PNL responsibility. But for a growing business, revenue might actually not be what you're optimizing for at all. You might be optimizing for growth so that you can raise around in a more mature business. There might be specific promises that have been made to investors that are again, not on the order of revenue, but where a specific team, for example, if it's an innovation team, might be responsible for exploring new business or monetization opportunities or expanding into new territories. To me, being an impact first product team starts by asking the question, what does success mean existentially to this business? What is the next major milestone for this business? What are the promises that have and made around that milestone? What are the things this business must achieve to be successful on the terms it has publicly set And from there teams are I think much better position to figure out what their contribution towards that overall success and health of the business is going to be. Oh you say right, you say right. What I am curious about, yes, there's a few things you earlier it said, yeah, you're not a visionary as such, but you facilitate. Yes. And there's something which I said in the talk a little while ago and which I I believe that originally visions were for visionaries. I thought they need to be a visionary to have a vision. But I thought, no, that's actually very true. And where I ended up was actually what people need is the to be given the context where they're able to care about something. Yes. And if you provide the context where people can care and then they can create some kind of motivational empathy, then you can achieve some awesome shit. But unless people create that context, but you don't stand a chance. And whether that context is just in a meeting, whether that context is organizationally, whether that context is actually understanding what the what promises have been made by senior leaders in an organization, which then mean that's what impact means. It's, it's understanding that context and creating that context so that people can actually care about the thing you're trying to achieve is massively important. Massively important. Absolutely agree with you. I think and I'm going to be careful how I I put this, I think that the discourse around customer centric and user centric product management. has been a really important counterweight to senior stakeholder driven product management, right. The idea that we should listen to our users, we should build things that people actually need is a really important counterweight to the idea that we should build whatever executives tell us to build. But I think some folks have taken that to a place where they see the user and the business as fundamentally at odds with each other, where they say, well, we're a user, we need to be user centric. We're going to fight against the business if they tell us to build stuff because we're not here for the business, we're here for the users. And I think a lot when I was working with a company a couple years ago, I worked with a phenomenal engineering manager, just phenomenal. And she went to the CEO of this company and said, I'm concerned that engineers are not talking about the business model. The CEO said, wait a second, I have product managers coming in here all day complaining that we're too business centric and not customer centric enough. And now I have you coming in and saying that you want engineers to be talking about the business model. I'm very confused on this engineering manager. She thought about it for a second and she said, OK, I think I understand what's happening here. When I say the business model, I mean our exchange of value with customers. I mean the fundamental commercial heart of the company, which is how we engage with our customers. When people say we're too business centric, I think they mean we're too politics centric. We're too focused on our own organization, on who reports to whom, on who's angry at whom and whom is in whom, whom's favor from moment to moment. But when you actually look at the business model, when you look at the business as a commercial entity that exchanges value, that is an intrinsically customer centric lens through which to understand the business. And I still think about that a lot because I think that we do. Sometimes we talk about a company being too company centric or too business centric. And my experience, that's rarely a company where people are deeply engaged with the business model, but more often a company where people are very reactive to the internal politics of the organization, which often is apart from and further insulates folk. From the business model, I don't know how relevant this is, but there's something which someone said to me, I think it was doing some training that I was given. And if this is you, you're listening to this, then please drop me a line on LinkedIn because I'd love to credit you with this. And they said to me that, you know, organizations, businesses are like beach balls and so much that they're made-up of lots of different sections in each section of different colour. And what people are very good at is looking at their section or looking at what annoys them about what's happening around their section and just talking about their section. So, oh God, it's so blue. And I hate the fact it's blue. And I don't understand how what blue is, what do with any of it? And why can't we be more like a purple? And they only talk what they're struck. That's all you can see from your perspective. And part of the the benefit we can get from good facilitation or getting people together is getting people to share their different stripes of the beach ball. So we can begin to understand there is a bigger hole here. And what I think is one thing could be another. So when people are complaining about being too business focused and we begin to understand the bigger picture was, oh, well, I didn't mean I didn't mean like how we operate as a business and what the exchange of value is. What I meant was the politics or the bullshit that goes along with it. And there's something, there's a certain great benefit in having people come together and create their shared understandings and more around the whole rather than just being focused on their piece. Well, and that's part of why I think, you know, one of the one of the things I'm writing about, which comes from Christina Watkeys book Radical Focus, which is fantastic, amazing book, just incredible second, second edition or first edition. I've read both of them. She says in that book that she has this visual that I lean on so much in my in my own work, which is basically that rather than seeing goals as a multi level cascade, they're kind of an orbit around the company level goals. That rather than saying you have your company level goals, which cascade to department goals, which cascade to big team, which cascade to little team, every team, department, big team, little team, it's all one orbit around the company goals. And I love that concept. That's so powerful to me, in part because it forces you to see more sides of the beach ball. It almost matches that visual metaphor. Perfect. Yeah. Right. Where we're all just around this one. Circular entity. Rather than all of us being off in our little in our little silos. I think in a funny way we've been operating under this belief that the atomization and separation of team level goals and activities is itself an intrinsically valuable goal. That if you can have 10 teams working on things where there are no dependencies and no overlaps, that that means that we've somehow accomplished something. when in fact I think the opposite is usually true. If you've broken down goals and activities to the point where you can have 10 teams working fully independently of one another, then it is to me incredibly unlikely that you are going to actually take on those bigger opportunities. That you are going to do the work that needs to be done. That you are going to actually have an impact beyond simply just pushing out a lot of fiddly little bits into a system that then becomes even slower and harder to wrangle by virtue of those fiddly a little bit. No, I just look here because I've got my OK, our workshop deck here. I'm running more than next week actually. And I had, I recreated the picture from Radical Focus. No, Excellent. And I was just looking and I just realized I've got the wrong version of the slides I've been working on because I've got the old version of my diagram for it. But it's such a great metaphor. I'm going to use the beach ball part of it next week as well. Yeah, it's so, so important. So important to kind of get that it's that autistic view. And if anyone hasn't read radical focus first or second edition, don't really mind, like go out and buy it. Do yourself a favor. It's a fantastic book. It's my it's my most gifted book. I think of the year. I only found the beginning at the beginning of the year, thanks to Jeff Got Health and George Seiden. You kind of turn me on to it a little bit because I was working with them on some lean UX stuff. And yeah, it's just it's a brilliant book and so, so fantastic to read and just challenges. I think it challenges the status quo in so much. I think, OK, ours for a long time have kind of been misconstrued. You can get away of having five key results for each, which ultimately let everyone focus on their one piece so heavily that they actually had or their own pieces. They had no real focus on anything. And then you were lucky if they made an impact to the business. It's just another mechanism to control. And I love her approach to say, no, let's let's have very various of one. OK, let's stick on three key results. And that's kind of use that she communicates through storytelling. I think that's so valuable for a way to really understand. I think we have a tendency and product world to rely a lot on frameworks, which makes sense. But a story brings brings to life how humans interact in a framework. And really, you know, I've said often that all frameworks are communication frameworks. That's what they are. Their way is to organize and structure human collaboration and communication. But I think that the way that that Christina Wadke writes kind of brings to life what that actual human interaction looks like within the frame. Work which to me is always so interesting and gives me layers of understanding beyond simply having a framework. I can point to and say we should do things this way. So I agree with you. I think that that bit of understanding narratively what happens when you have too many OK R and how that can impede focus even if you are doing it quote UN quote according to the framework is so important to bring to life. Yeah, no, it's just an awesome book. I need to, I want to get her on the podcast. That's one of my goals. I need to find someone I can schmooze who knows her. I'm sure it won't be that hard. But yeah, I'd love to get her on because I think she's just yeah, it's just just one of those people like her. And for me, to the people that I think are just the most amazing, amazingly challenging creative minds just just because of their absolute bloody minded focus on as little as possible. Have you had Adam Thomas on? No, you should have Adam Thomas on. He has a concept called survival metrics, which I have leaned on really heavily, which is essentially if you have your success metrics, which is here's what we want to do to succeed. Survival metrics are basically what is the highest floor we can have in order to continue investing in something. So the idea is that you are essentially pre planning a pivot by committing upfront to what the bare minimum is we need to hit in order to consider something survivable. And I have found that concept so helpful because it's a chance to have those conversations before they become untenably political. I will stalk Adam and if anyone, Adam, if you're listening, let me know. And if anyone else also looks up Adam's stuff and they'll have a look at it and drop me. Like I just shout out people whose work I find inspiring all day. Yeah, but then but brilliant people in this community. And that would make a really interesting podcast episode. But not today's podcast episode, Matt. Oh, not today, no, no, today's. Let's just kind of draw this back onto our original female so and I was Safeway in. So we've spoken about people having too much of A focus on just one part of the beach ball or stuff go getting cascaded down South. Actually, what you end up with is something which is just what you have to do with no understanding of why or the business impact, customer impacts, and those teams are stuck in that situation right when they feel like they can't have an impact. Should they even bother trying? Yes, that is probably the fastest answer I'm going to give you today and I'll tell you why. Because if those teams fail to have an impact and if the business fails to reach its existential objectives, it will be their problem, even if it wasn't their fault. Which is to say, even if your team can say we built exactly what you told us to, we're a feature factory, you told us to build this thing and we built it, not our fault. It's they're still likely going to be responsible for that. I mean, I think one of the things that's become very clear over the last couple years and I, I don't think this is fair or just, but this is the reality of how a lot of organizations operate, is that systems of power exist to protect people with power. So the way that a lot of organizations are set up, if a strategy fails, the team executing the strategy is often going to bear the brunt of that before the person who developed the strategy. Do I think that is fair and just? No. But when you look at companies that are laying off product teams and saying these teams aren't having an impact, they're doing work around the work, they're doing things that aren't important to the essential blah, blah, blah, like, well, somebody presumably gave those teams a directive. Which was not setting them up to have an impact, right? You notice that in a lot of these statements, they're not saying we gave these teams really important strategic objectives, but due to market conditions, they were not able to reach those objectives. There's often a tacit acknowledgement that these teams have not effectively been directed at the most impactful work, but then it is still the teams who find themselves bearing the brunt of that. So in my, you know, in my experience and in my way of looking at things, it is in the best interest of everybody on a product team to proactively understand how their work is important to the overall success of the business. So that even if they then come to realize that their work is not directly aligned with the most important things for the business, they can have that conversation in the open and say, hey, it looks like, you know, this company has a, a really, really important revenue target. Our work is not necessarily directly revenue generating. However, we believe it's important for the long term future of the business for the following reasons. You as somebody on a product team are so much better off understanding that argument and helping to shape that argument as opposed to being entirely reactive to how your team's work is discussed by people who might not really understand your team's work. Couple of things I wanted to cover and unfortunately, just due to limitations in human speech, I can't talk about both things simultaneously. So I'm trying to decide which one I've got 1 by 1, I think. I mean, traditionally that's how it's done. And who am I to break with tradition? You know, not today at least. So for a little side alley, when we say a product team, sure, what's your, we talk like you say, what's your, not your definition, but what kind of composition would you say makes a good product team from a skills and an experience perspective? So my opinion here is that there are a lot of different combinations of humans and skills that make a good product team. What is most important for our product team is to have unified goals. When a product team has goal clarity, they do not need to worry as much about role clarity. And I have found that time and again when I've been brought into teams, we need goal clarity. It's not entirely clear. We have a product owner and a product manager and they're fighting over who should do what. What's the absolute non overlapping definition of every role? And you know, for a long time I would go in and try to come up with that and, and it never worked. It never seemed to get anywhere. And eventually I just noticed that the teams that didn't ask me for help with that were teams that had clear, you know, kind of outcome or impact level goals. That said, this is what success looks like. So we are naturally going to work together to try to achieve that. The teams who were debating who should do what, what is the absolute? Role clarity of a team where once we didn't have those goals in place. The the analogy I use sometimes is if you get a bunch of friends together and you're all going to prepare a recipe nobody argues over who's certified to peel potatoes, you figure it out. You know what success looks like. If you invite 10 people over and say, what do we want to have for dinner? It's going to be a nightmare. It's going to be really hard to actually get anywhere together and you might start worrying about who's responsible, who has decision rights around dinner. Who's gonna how are we going to do this? Who's the best position person to and like it just kind of spins endlessly without any real results. So I, I am very non dogmatic about how product teams should be organized. I think so long as you have folks who when working together can achieve something, can make changes of some kind and do something, and you give those people goals that they can work together towards achieving goals that necessarily harness everybody's individual efforts towards a collective goal, then I think A-Team can succeed. So the problem then is that for many organizations, what they've done and picking up something you mentioned earlier when they try and they can't think of the right contentious way to put this right, but they really believe that dependencies cannot exist. Yes, Some dependencies don't have to exist. Most dependencies have to exist, probably not in the way that they currently exist in your organization, yes. And then in people's desire to remove dependencies, all they're doing generally speaking is abstracting those dependencies away from the team as a unit up to a higher level of management who are so far away from the work. So whereas before A-Team may better own the business problem, own the customer problem, and then deal within that team having the right the one. I think you know, whether it's skills, behaviors, mindset, I think the biggest and most important thing is that that the context and the ability to transform to learn based upon what they're faced with. Then they would still have those dependencies and there's still be dependencies between teams, but they would figure out ways to solve them because they had a good clear goal which motivated them. They didn't care who did what particularly as long as they kind of reached the outcome they wanted to achieve. The moment you abstracts those dependencies away and the teams can't own whole meaningful problems and there's someone else's management dependencies between lots of different teams. Because then actually they're quite, they're very strip of the, the beach ball is very narrow, yes. And then they haven't got the time, the capacity, the energy to think about what's before or after because they've got a long list of varying types of work to work through as they have that team, as they have that team. And so they actually don't have the context they can really care and motivate themselves to solve some of the problems. And I think this is one thing that really frustrates me because anyone that's worked in a team that have been creating a product, whatever role you've had, is it you? You need to talk to people to resolve the dependencies because dependencies are never not going to exist. And we can try and abstract them away from the teams and we can try and bring everything together at the end. And all we're doing is adding insult to the injury. And then we add then the biggest piss taker of all is, and that's when people start saying, what's my role? How do I know what I'm accountable for? How do I know what I've done my bit And we haven't got a team anymore. We've got a group. And then we're talking about measurement, clarity and accountability. And the moment we try and do that, you know, we're just trying, we're trying to put people in the box and can find them. And I think it's such a pity. But then we turn up with these fantastic team focused approaches to try and help them. And they, they, they haven't got the context to give a shit about it because they just know that they've got to do their job and do their job well. And that's what they're going to be rewarded for. And that's what they're motivated by, not the bigger, higher purpose. I think you touched on something really interesting there, which is this idea that what, how the way many organizations approach dependency management is actually theoretical dependency abstraction and then resolving those theoretical dependencies as functions of management and, and sort of the organizational layer as opposed to his actual product problems as opposed to, OK, well, if we have two teams, as you said, there are always going to be dependencies. How do we actually work together in a way that's going to make this better for our business and for our users? You know, I, I think one of the reasons people sometimes take issue with a more kind of framework and best practice approach to product development, especially at an organization level, is that these intermediate things can, can very easily become sort of seductive goals of their own, right. So dependency management is not intrinsically a goal saying like, look, we cascaded our goals so there are no dependencies. That doesn't mean you did anything. That doesn't mean you actually delivered any value. That's sort of an abstract exercise. And I'm thinking a lot about this point you made, which is that it's basically an abstract exercise for management. Like it's something that management can participate in and say, look, it's OK, our season, we cascaded all of our OK Rs perfectly, as if that in and of itself is something of intrinsic value. You know, a lot of my work with teams, if I come in and say one of the first questions I, I ask is often, do your lowest level OK Rs add up to your highest level OK Rs in media? If you add up all your L fours, do they immediately add up to your L ones in a way that everyone can understand? And if the answer is no, I'm like, then get rid of your fours. Let's try that with our L3. That's not a good answer. Get rid of we. I've never run up with more than two layers of OK ours if we really want to. Get there, which again perfectly recreates the Christina Wadki visual of the company goals in the middle and team goals orbiting around them. But I I think it's it's really interesting. I hadn't thought about it in those terms, that in a sense that cascading process is a way to fight product battles by proxy at a management level and for the proxy to to seem more important than the work itself. Yeah. Which it never is. But it goes back to what you were saying earlier, I believe. Which is it? We that the the the management structures that are in place are there to. It's about self preservation, it's about keeping, it's about the people that are affected by any change. They don't, they don't want things to change because that's what they're there to do is to maintain that status quo. I mean, our bodies, we call it homeostasis. It's so to regulate temperature and stay the same. And organizations have a similar stasis, the status quo they're trying to maintain, and that's what people are employed to do. People generally speaking, aren't employed at a management level to change things for the better, to manage things so that they can maintain level of status square and keep on plodding on as they have been. Yeah. I mean, I, I think part of the challenge is that, you know, it's funny that the word accountability is when I go back and forth on and struggle with a lot because it's a word that's really easily weaponized, right. You know, I work with a lot of I have worked with with, I don't want to say a lot of it. I work with some leaders who are like, people here aren't accountable. But usually that's not, it's not just a problem for the people building product management is not accountable either, which is kind of because at the end of the day, accountability exists whether or not we want to acknowledge it. And that's part of what compelled me to write this book is that if your company goes out of business, you don't get to turn around and say, well, I did product management the right way. So I still have a job. You don't if your team gets let go because somebody who you've never spoken to before looks at your, you know, at the salaries y'all are being paid and says we can't afford this anymore. You don't get to say no product teams should not have PNL level responsibility because I read it on LinkedIn and still have your job. Accountability exists whether or not we want to acknowledge it. And I think that we ignore that at our own peril. And I think that we, when we ignore it, we also, frankly, let the systems of power that exist operate without as much transparency into the way they wield accountability. You know, I, I think a lot about good hearts law and this idea that once a, a target becomes a target, it ceases to be a good measure. But with most of the organizations I've worked with, they're, they don't set real targets. They're afraid to set targets because when you set a target, there does have to be some shared reckoning with that target. Right. You when you have a transparent target that everybody within a team or within an organization understands, then everybody in a sense has the ability to advocate towards that target, which makes it much harder for power to operate without any accountability. It makes it much harder to shift the goal posts at the last second. And I've really come to believe, and this is really counterintuitive for me and I'm sometimes surprised to hear myself say this, but that having those those clear accountability business level targets that pertain to the overall success of the business actually creates a healthier decision making environment than exists in the absence of those targets because there are trade-offs to make. So one of the examples I use in the book, you know, imagine that you're working on a team that is responsible for lapsed subscriptions to a subscription product and you're looking at this and you're like, OK, there are some folks whose credit cards are just, we're just taking money from them every month, but they're not using the service at all. What do we do? Well, there's pretty a pretty clear ethical answer to that, right? But if you don't know what your revenue targets are, it's very hard to know how to approach that. If let's say that you look at it and there's, you know,$1,000,000 a month on the line in subscriptions that are inactive, If your team is responsible for $1,000,000, that's a serious blow to the business. You're going to approach that very differently. If you have a revenue target of a million, If you have a revenue target of 100 million, then who cares? We can let it go. We can make that up. It's going to be worth the goodwill. But again, I think that in the absence of clear impact level targets, we cannot make those decisions effectively. It is actually harder to make both ethical and sustainable decisions because we don't know what trade off we're making and we don't know how that trade off affects the business. And if we don't know those things, we are actually worse positioned to make those trade-offs and to advocate for those trade-offs than we are if we are just doing quote, UN quote, the right thing. In a vacuum without an understanding of what then has to be done in order to make the right thing and still exist as a business. So you say that there is a higher order of accountability for a team, which isn't just making a business impact, it's making that business impact in an ethical way. I think so. I mean, I think that you know, ethics under late capitalism. Let's talk about it. You know, it's, it's tough, right? Because I think that ethics run through every decision that a team and a company should make. I think that when companies behave, let me put it another way, I don't think that having impact level goals makes it impossible for companies to behave unethically, but I think it makes those unethical decisions more transparent. I think that when we know what goals we are working towards, if we are compromising ethics towards achieving those goals and everyone's going to have their own different, different definition of ethics and their own personal threshold for being willing to participate in systems that they believe to be unethical. When those trans trade-offs are made transparently, I think people are better able to ask themselves, am I comfortable participating in the system? Are the trade-offs that are being made trade-offs that I am comfortable participating in and and backing. And I think the most we can ask from companies is to make those trade-offs in public so that the people who are participating in those systems can understand what trade-offs are being made. Because I think that capitalism as it is currently practiced in its current state is not necessarily conducive to ethical decisions. I think that a growth at all costs mindset does not ethical necessarily lead to ethical behaviors. But I think that when a company is transparent and honest, if they are saying growth at all costs is the goal we and you will be working towards, that empowers people much more to either say, yes, that is the type of decision I want to make or know that is not the type of decision I want to participate. It's not something that comes up very often. I think that many teams, maybe it's the nature of the work that they're in, but they never questioned maybe the the ethical side of this. It's not something that in all my years of kind of helping new organizations make product teams a reality, it seems that can own a, a problem and solve it for a person and maybe even get to meet that person or meet some proxy for that person. You know, one of the things which never comes up is surname and turns around and says, I'm concerned that we're not ethical enough. I think I've been very fortunate to to work with some really exceptional people who've put ethics at the at the heart of the work that they do and and who've really lived and breathed that and who've done so in a way that is thoughtful and empathetic. And still pragmatic. I mean, I think, you know, it's interesting because if you cascade things down to that kind of feature or output level, I don't think teams necessarily have much view into those ethical trade-offs, right? If you're just being told build all these features, the question of to what end is not necessarily one that you're going to ask and consider. But again, when your goals hue closer to the goals of the business at large, I think that necessarily involves product teams more in some of those questions of OK, but what are we trading off? What can we trade off? What compromises and sacrifices are we willing to make short term and long term? And if we're doing this just towards the goal of, you know, crushing our competition, amassing monopolistic market power and then using that to enrich our shareholders, is that something that we want to be involved in? Which is a very fair question and maybe not a question that enough people ask themselves. Yeah. So rapidly kind of getting towards the end of our time, we've covered a lot of ground. Why should people buy your new book as well as listening to this episode? What? What haven't we have a list in the book? I mean, I think a lot of what's in the book is how to hold space for uncertainty and how to do estimation and how to hold this intrinsic tension between the importance and the uncertainty of working on the order of impact, right? It's really it is against our human nature to want to be accountable to things outside of our control. There's a fundamental emotional level at which folks, myself included, will resist this, where if you say, all right, your team is accountable for growing the business this much or for growing revenue this much, you say, well, I can't control that. What if our competitor launches something that is, that just blows us out of the water? What if there's a global pandemic and suddenly the market shifts in ways we never could have predicted? It's it feels bad to be on the hook for things that are outside of your control. And I think part of my goal with this book was to acknowledge that openly and to say, this doesn't feel good. This isn't a book which you can read and say, aha, I now have all the knowledge I need to succeed no matter what at product management. But rather to acknowledge that the reality is that your success is outside of your control, that you cannot control and cascade everything to the point where market level outcomes are entirely within your control. Best you can do is stay close enough to those market level goals that you change course. If, if there is a competitor who launches something, you don't just say, well, we committed to these level five goals, so we're just going to keep marching towards those. But rather, OK, macro conditions have changed enough that our approach, our strategy, everything that is downstream of the impact we seek to drive now has to change. But because we are keeping that impact front and center at every step of the product development process, we are staying adaptable at every stage of the product development process so that we are more likely to actually achieve that impact and contribute to a successful business. Thank you, Matt. My pleasure. Thanks, Ben. I've learned a lot. It's been a really lovely conversation. It has indeed. Thank you so much for having me. Yeah. And I don't that I was very poor at repeating back what you'd said, but it turns out it worked their way around as well because you made something I said sound much better. So I'm going to take what you said about dependencies. So I'll take that. Thank you very much, Matt. I will put your LinkedIn profile into the show notes for this so that people can find you on link and Contact. And you're happy for people to contact you. If you have any questions, you can find me. I'm pretty easy to find. mattlanae.com. I have a contact one there. You can just e-mail me. May have guessed that Matt at me mattleme.com might be me. Spoiler alert, it is. So honey, e-mail me there. You're welcome to. I'm not on the sad husk of Twitter that much anymore, so you can find me on LinkedIn until I figure out another way to have my silly little thoughts without feeling complicit in horrible things. Speaking of ethical trade-offs, well, let me know when you find what the other alternative is. Sure. Well, in less and less time on LinkedIn at the moment, I need to probably get back on a bit more, but that is a different conversation. Matt, thank you so much for coming on and everyone, thank you very much for listening. If you have got to this point in the episode, then why don't spend another 30 seconds, go onto a podcast platform and leave us a review motivated by positive words. And we're motivated by people letting us know who they liked, why they liked them. And most importantly, Spotify and Apple Podcasts or whatever the Apple version, whatever Apple finger using. I'm not an Apple type person, but I think the algorithm quite likes reviews. It makes it look more popular. And then so when people are searching, we're more likely to pop up more people listen. The more downloads we get, the more opportunity for us for us to entice more and more guests, but to also go to keep these episodes coming every week pretty much about fail so. Please do leave us a review now, everyone. Thank you very much for listening. Matt, thank you very much for coming on. And hopefully our paths will cross a conference or something at some point in the future, or maybe just randomly around London or some other city, who knows. I'll keep an eye out for you. And that's all. Thank you very much. This has been the podcast. We'll be back again next week. Just something that is, that just blows us out of the water. What if there's a global pandemic and suddenly the market shifts in ways we never could have predicted? It's it feels bad to be on the hook for things that are outside of your control. And I think part of my goal with this book was to acknowledge that openly and to say, this doesn't feel good. This isn't a book which you can read and say aha, I now have all the knowledge I need to succeed no matter what at product management, but rather to acknowledge that the reality is that your success is outside of your control. That you cannot control and cascade everything to the point where market level outcomes are entirely within your control. The best you can do is stay close enough to those market level goals that you change course. If, if there is a competitor who launches something, you don't just say, well, we committed to these level five goals, so we're just going to keep marching towards those. But rather OK, macro conditions have changed enough that our approach, our strategy, everything that is downstream of the impact we seek to drive now has to change. But because we are keeping that impact front and center every step of the product development process, we are staying adaptable at every stage of the product development process so that we are more likely to actually achieve that impact and contribute to a successful business. Thank you, Matt. My pleasure. Thanks, Ben. I've learned a lot. It's been a really lovely conversation. It has indeed. Thank you so much. Yeah, and I don't that I was very poor at repeating back what you'd said, but it turns out it worked their way around as well because you made something I said sound much better. So I'm going to take what you said about dependencies. So I'll take that. Thank you very much, Matt. I will put your LinkedIn profile into the show notes for this so that people can find you on link and contact and you're happy for people to contact you if you have any questions. You can find me. I'm pretty easy to find. mattlemay.com. I have a contact form there. You can just e-mail me. May have guessed that matt@mattlemay.com might be me. Spoiler alert, it is. So let me e-mail me there. You're welcome to. I'm not on the sad husk of Twitter that much anymore, so you can find me on LinkedIn until I figure out another way to have my silly little thoughts about feeling complicit in horrible things. Speaking of ethical trade-offs, well, let me know when you find what the other alternative is. Sure. Well, in less and less time on LinkedIn at the moment. I need to probably get back on a bit more, but that is a different conversation. Matt, thank you so much for coming on and everyone, thank you very much for listening. If you have got to this point in the episode, then why not spend another 30 seconds, go onto a podcast platform and leave us a review motivated by positive words. And we're motivated by people letting us know who they liked, why they liked them. And most importantly, Spotify and Apple Podcasts or whatever the Apple version, whatever Apple thing you're using. I'm not an Appley type person, but I think the algorithm quite likes reviews. It makes it look more popular. And then so when people are searching, we're more likely to pop up. More people listen. The more downloads we get, the more opportunity for us, for us to entice more and more guests. But to also go to keep these episodes coming every week, pretty much about fail. So please do leave us a review now everyone. Thank you very much listening. Matt, thank you very much for coming on. And hopefully our paths will cross a conference or something at some point in the future or maybe just randomly around London or some other city, who knows. I'll keep an eye out for you. And that's all. Thank you very much. This has been the Projectity podcast. We'll be back again next week.

People on this episode

Head Shot

Ben Maynard

Host