Building product the "right way" is all well and good, but doesn't matter much if your company goes out of business. Whether or not it's fair and just, product teams ultimately bear the consequences of their work's impact–or lack thereof. To deliver high-impact work, the business needs to be everybody’s business, including individual engineers, designers, and product managers. In this talk, product consultant and author of Product Management in Practice Matt LeMay shares his experience helping product teams at companies ranging from early-stage startups to Fortune 500 Enterprises define success, prioritize what matters, and make themselves indispensable.
← All talks 
Build Turing Fest 2024
The Business Is Your Business with Matt Lemay
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
All right. Good morning, everybody. I am so happy to be here with you in Edinburgh this fine morning before the rain sets in and stays in until I go back to London where it will almost certainly also be raining. It's great to be able to do these in person.
I still feel the joy of being in a room with people after having done a lot of these from my apartment, which is so weird because you finish a talk and it's like, well, that happened. I'm sweaty. Time to go take a nap.
And I will still be sweaty, but I will stick around to say hi to folks. Here's the gratuitous fancy slide. I've worked with a bunch of different companies as a consultant and as a product leader. I've written two books for O'Reilly. Product Management and Practice is now in its second edition.
I'm really proud of that one. And I just finished the first complete draft of my next book, Impact First Product Teams, which is a book about business impact for product teams. And I was having kind of a hard time articulating why I wrote this book and what it's about until I spoke to a friend of mine who works in product and and and kind of talked to her about, you know, it's about how we have all these things.
We do all these processes. We're focused on doing things the right way, but does any of it matter? Are we actually focused on building a successful business? And she said, I think I get it. So most product management discourse is about the middle.
It's about strategy, objectives, bets, outcomes, initiatives. And what you're talking about is kind of drawing a straight line between the business impact of the work that we do and the day to day decisions that we make as product teams. And I said, thank you. I now know what my book is about.
And I would say somewhat uncharacteristically for me, this book is very timely because the reality is that those of us who work on product teams feel a degree of tenuousness in our jobs that I certainly have not experienced before. Know, for somebody who's working in tech, think especially for those of us who are engineers Which I am not there's a sense in the past of like we are the in demand special magical tech workers of the future and our jobs will never be vulnerable, but I certainly
feel that vulnerability. And if you read the tech news or if you just talk to folks, I think that vulnerability has permeated our world in a way that it hadn't until quite recently. But that, of course, has not stopped the discourse from going so discourse on LinkedIn.
And it's been interesting to see the discourse on LinkedIn absorb some of this vulnerability and this tenuousness. Yes, I I laugh and then I cry when I see this, then I laugh again. There's been this debate, which has always been bubbling under the surface, but it's now, I think, really come to the fore of our product teams responsible for the success of their business.
I don't know if some of you have seen this debate over zero interest product managers this idea that there are some product managers who get hired cost the company money But don't return any of that investment. There are other folks who are saying listen revenue is a lagging indicator.
It's too far removed from the day to day decisions that most product teams make. Product teams cannot be accountable for revenue targets. It's impossible. I'll say that for me personally, I definitely fell into the grumpy. No, we can't be responsible for revenue targets camp.
Product people can be grumpy. We are sometimes more justified in being grumpy than other times. But a lot of the things I've heard in my work working with product teams when I say, alright, how are we helping the business succeed? Are things like product teams cannot be responsible for business impact because it is the wrong way to do things because I read about it on LinkedIn.
I feel like product management is one of the only roles where people feel justified saying this to other people. I've gone into companies and said, okay, how are we contributing to the success of the business? And I hear like, how dare you ask me that question?
That is the wrong way to do things. Meanwhile, my friends in sales are like, do you see what happened over there? I have a friend who sells wine, and she's like, your job is so weird to me because if somebody wants to know how successful I am, they ask me how much wine did you sell?
And I tell them how much wine I sold. In Your job you get to say You'll get to ask me what success means. That's not my problem. I'm doing things the right way. That's got to be nice This was my favorite one impact metrics like revenue are lagging indicators Do you even know what lagging indicators are?
You can't ask me to keep track of lagging indicators. How dare you? How very dare you sir madam and to be clear? These are all things that I have said at various times when I'm a product manager. My very favorite one to say was we're just building the stuff that you told us to build, so if it doesn't work, that's your problem.
You want me to build these features? Okay. I will go build these features. And if the features don't add up to a successful business, you're the one who told me to build the features, that's your problem, buddy. The problem is six months later, it turns out that that is very much my problem because somebody is looking at a spreadsheet of all the expenses the business has and saying, who are these people and what do they do?
And if the answer is, oh, I asked them what they do, and they told me that they can't ask me that because it's the wrong way to do things. That is a very, very tenuous position to be in. So I think the reality here that we need to acknowledge is that whether or not it is just and fair, and we can debate relentlessly, whether it is just and fair, whether product teams should bear the consequences of this, or whether the executives who hire and give mandates and
strategies to those product teams should bear the consequences of it. The reality is that we as product teams bear the consequences of low impact work. If we do work that does not contribute to the success of the business, somebody is eventually going to say, why have we hired these people?
And if we do work that really doesn't contribute to the success of the business, then eventually we won't have a business anymore. This is the reality of the work that we do. Now how exactly this is playing out? If you look at some of these articles and you read the statements made by the folks who are making these layoffs, there are some very helpful clues as to both why this is happening and what we need to do about it.
So in this article about Spotify laying off seventeen percent of its workforce, there's this quote from the founder and CEO of Spotify, Daniel Ek, where he says, today we still have too many people dedicated to supporting work and even doing work around the work rather than contributing to opportunities with real impact.
Work around the work. And I read this. And first of all, my heart broke for all the folks I know who are on supporting and ops teams whose job is literally to do work around the work and to do supporting work, which I don't think is a bad thing if, again, that work is contributing to the success of the business.
But this idea that we have too many teams kind of faffing about and not enough teams contributing to the heart of the commercial success of the business. I read this, and I said, this is how every company I've ever worked with is set up.
This is a systemic and structural problem. And I started mapping out for the companies I've worked with ranging from startups to enterprises. What's really happening here? What is the pattern that is contributing to these damaging outcomes for teams? And what I landed on was this image, which I call the low impact death spiral.
And as I started to map this out, I realized that just about every company I've worked with and certainly every medium to large sized company I've worked with is caught in the throes of this very death spiral and if you are using products made by these companies if you're using Google Docs or if you're using Spotify or if you're using really any enterprise or medium to large tech companies products you are probably feeling the effects of this death spiral in your day to day experience.
So it starts with low impact work. It starts with a team saying, as I often said, we can't be responsible for these things. It's too complicated. It's too much. It's out of our control. There's too much executive scrutiny. We don't wanna work on this stuff that's going to require so much tedious collaboration that's going to make the CFO appear out of nowhere and suddenly care about the work we do.
It's not worth it. We're going to go off over here and maybe build some new features, maybe run some little experiments that don't have much impact. We're going to do this. It's what we were told to do. It's not our responsibility and we're not going to invite too much scrutiny.
What happens as you build those things? The product becomes more complicated. You start to push in these little features, these little new things. You start to build this shell of miscellaneous stuff around the commercial heart of the product. Suddenly, coordinating becomes much more difficult.
When you have a hundred frustrating little features in a product, doing anything that breaks through that shell and actually impacts the core of the product is much more difficult, and this is where we get to the symptoms that most executives recognize. They say too many meetings to manage dependencies.
It's too hard to make any major changes. Teams are doing work around the work and they try to solve this by putting band aids over these symptoms. They say, we need to have more program management layers. We need to have more folks who are just responsible, but all of that just adds more and more and more impediments to teams actually doing high impact work.
So what happens when we have more dependencies and conflicts to manage And it comes time for product teams to decide what they are going to work on. They go right back to that low impact work, because the more conflicts, more meetings, the more work there is to do around the work, the less incentive there is for teams to take on work that is actually going to invite that scrutiny, is going to require that coordination, that is going to deliver major meaningful results for the business.
Now what I really want you to take away from this is that nobody's coming to save you. If you are a product team, that program management layer that's coming in is not suddenly going to take that scrutiny away. It's not suddenly going to make impactful work easy for you.
But because that low impact work is the root cause in this, every product team has the power to break the spiral. If you are working on a product team, high impact work is available to you. You can step into this responsibility. You can say we are going to take ownership of the impact of the work that we do before we find ourselves on the defensive.
Before that CFO appears and says who are you and why are we paying you this money again? You can have a point of view on why your work is critical to the success of the business, and I would go one step further and say in this moment You need to have a point of view if you do not have a point of view on why your work is important to the business you are in an unacceptably tenuous position So what I'm gonna walk through with you sharing some stories
from my work is how teams I've worked with have broken the low impact death spiral and they have done it by Understanding what success means to the business setting team level goals that contribute to the businesses success and keeping their day to day work connected to those goals.
All of these things are challenging to do, but all of them are doable. So let's start with this first bit, understanding what success means to the business. A couple years ago, I was working with a startup like you do that had built a pretty successful b to b business.
They were building a multimodal learning platform, and they had found really good product market fit with ad agencies and learning organizations at large companies And they said gosh we are crushing it. Our customers are happy We have built a sustainable small business Everything's going really well.
And yet, we're also starting to get some interest from outside of our little b to b world. There are some folks in the broader world who've told us your product is so cool, The most dangerous word you can hear when you work in product.
It's so cool. We love it. So based on just the feedback we're getting its time. It's time for us to go after the big b2c pivot. We are going to become the platform for content creators across the entire world. Hooray. Now for me having gone through this with companies.
I am not saying hooray. I'm like, okay Nervous. So I'm thinking about this. I'm trying to kind of hedge my words be like, oh, that is great. I think we could do that, but what is a deliberate path to that? And I finally asked, okay.
How much growth would we need to see if we want to raise our next round of funding as a b to c business? So you're saying we're gonna be a b to c business. We're gonna raise our next round as a b to c business.
How many users do we need in order for our investors to say, yes, I am willing to invest in you. I am willing to make this bigger investment for you as a b to c business. And the founder of this startup, really, really, really great founder.
She says, I don't know, but I know someone who does. Let's get our investors on the phone. So we got our first round of investors on a call, and I walked them through an exercise that I've run with a number of startups and small companies and teams at bigger companies where we look at our red light, green light, and yellow light scenarios.
In other words, if our next milestone is to raise this round, what are the numbers we need to hit where we're like, hell yeah. Crushing it. We're raising the round. We follow along with this b to c pivot. What are the numbers where we're not sure we're there yet, but we can survive.
We can live to fight another day our yellow light and what are the best numbers we could hit and still be completely screwed. And we put together a document like this, which I think every company that is working towards a milestone needs to have.
This is inspired by Adam Thomas' work on survival metrics. I have a template available at bit. Ly slash strategy underscore survival. But there's something I wanna point out about this that that really surprised me. When we talk about impact, a lot of people assume that we mean money.
Right? Impact. Yeah. Yeah. Yeah. Money. But in this particular case, the green light scenario involved more users and less money, and the yellow light scenario involved more money and fewer users. In other words, for this company to achieve its goal, they wanted to focus on growth, but if they could not achieve that growth, then they needed to focus on revenue, because if they didn't have enough money coming in, they would be out of business.
And when I work with companies to define success, it is important that we get to this level of specificity. It's also important that we make product teams aware of the existential realities of the business because especially at smaller companies, a lot of product teams are not aware of the existential realities of the business.
They don't know what numbers need to be hit for the business to continue to exist. In this case, that was very true. We went to the product team, and we said, how close are we to achieving our green light goals? We met with investors.
We just need to have a thousand monthly users. That's not a big number probably. How close are we? And the product team was like, oh my god. We are screwed. We're not gonna have a thousand monthly active users anytime soon. We haven't been building for that.
We've been kind of building for revenue and kind of building for growth, but there's no way we're gonna make this happen. Which meant because we had this document in place, we could go back and say, all right, we're not going to hit that thousand.
Again, let's focus on getting that monthly recurring revenue to where we need it to be so that we can buy six months of runway so that we can make the pivots we need to do to continue investing in the growth of the business.
Just gonna show this GIF again. Boom. Product teams of companies of all sizes need to know what specifically success means. If you don't understand the next milestone of your business, whether that's a quarterly earnings report for a publicly traded company or the next round of funding for a start up, you cannot make effective decisions.
And yes, this is someone else's problem. It's above your pay grade, etcetera. But if your company fails to deliver on expectations, it puts you in a vulnerable position. This next step is the most important one. Set team level goals that contribute meaningfully to the business's success.
If you take nothing else away from this talk, take this away. Your team needs to have goals that you are confident contribute to the success of the business. So a couple of years ago I worked with another company, a bigger company that was making the transition as a lot of companies do from having feature mandates, go build these features to having outcomes over output, right?
Everyone wants to say this. We used to be command and control, we used to be go build this feature, we were a feature factory. Now we're giving teams outcomes to achieve. So I was tasked to work with a team that was very important to the growth of the business that had been building these features and was now trying to work against goals.
And I said, alright team, what are your goals? And they said, we have those. Here's the PowerPoint presentation. It's ten slides long and it has our goals. I said, okay. This is the fact that you are sending me a large document to read rather than telling me what your goals are in one sentence, which I can understand is troublesome.
Where did these goals come from? And they said, oh, we cascaded them from a bigger team goal, which is in a bigger PowerPoint presentation. Okay, where did those come from? Oh, came from department goals, which come from a bigger PowerPoint presentation. And where did the we cascaded those down from company goals and now I just live in PowerPoint.
My life is PowerPoint. I have like a hundred slides that I have to keep track of together. I don't know if any of you have found yourself in this situation where you're trying to do this like, oh, we're doing goal setting the right way because we read about it on LinkedIn.
And you wind up with like a hundred slides that make no sense. And nobody can actually have a conversation about goals because it is too complicated to be conversational. So I said, okay. Yeah. Yeah. Yeah. Yeah. Yeah. That's really good. But if we do this, how much does it affect this?
And this is often the first question I ask teams I work with. When they say, we cascaded down our goals, we have ten levels of OKRs. Okay, great. If we do this, how much does it affect that? And the answer I got was, I don't know.
How are we supposed to know that? That's impossible. Again, this is an untenable situation. If your team is working against goals that are so complex cascaded so many levels that you have no idea if they are contributing meaningfully to the success of the business, you are in a tenuous and vulnerable position, and it is excruciatingly likely that you are doing low impact work.
So we took a step back and said, alright, what is the company trying to achieve? And this was actually pretty straightforward. The company has a specific increase in revenue they want to achieve by the end of the year. And I said, How do we contribute to that?
And what I want to emphasize here is that this wasn't like and then we used the magic impact formula to figure out exactly what the right number was. We had a conversation And this conversation wasn't easy. We had to use our critical thinking capabilities.
We had to communicate as people. And there were two parts of this conversation that really helped us get where we needed to get. The first one was why were we building these features in the first place? So yes, we had feature mandates. We were told go build this, go build that.
Why were we building all these things in the first place? And what the team said to me was, well, we're building all these features because people who use multiple products or features for our business are worth more to us than people who only use one.
And I said, that is very interesting. How much more valuable? And they were like, we actually have numbers. Like, we can say that a multiproduct user is worth this much more to us than a single product user. We're starting to make that connection.
We're starting to draw that straight line between our day to day work and the overall success of the business. And then this other question, how much would we need to achieve to feel good about our contribution as a team? We're a pretty big team.
So if we say each multiproduct user is worth this much more than a single product user, How many do we need before we feel good about the work that we're doing? And from this conversation, we came to this conclusion. Our team's goal is converting ten thousand of our single product users to multiproduct users before the end of the year because the customer lifetime value of multi product users is greater and this will contribute meaningfully to the company's revenue goals.
Again, we didn't use any magic process. We talked about it. We as a team took responsibility for saying, can we describe in one simple statement like this, what our goal is and why it's important to the business. So what can you learn from this?
For starters, this comes from Christina Wadke, my business book hero. It's in her wonderful book Radical Focus. It's also in this article. Most companies cascade goals like this. They have a company goal. They cascade those down to department goals. They cascade those down to bigger team goals.
They cascade those down to team goals. And before you know it, it is impossible to add those back up. You have created a level of abstraction where we have the illusion of control at the team level, but we no longer can say how our team goals add up to a successful business.
What Christina Watkins recommends is instead of that we think about each level of goals as orbiting around goals. The company goals are the center of gravity and no team or department is more than one understandable explainable step away from company goals. Once you see this, you cannot unsee it.
Good OKRs work that way. Good North Star metrics work this way. Whatever framework you use works this way. So when I work with teams now, I ask them to go through a checklist as they set team level goals. Number one, are our team goals no more than one step away from company level goals, right?
Can we explain the impact we're having on the business in one step? More multi product users, because multi product users are worth more, that makes more revenue, One step. Does our team contribute to the company level goals enough to justify the existence of the team itself?
Do we feel good about this contribution? Does this contribution make us feel secure in our existence? And last but not least, do our team goals involve specific enough timelines and targets to drive subtractive decision making? Again, we had a number ten thousand by the end of the year.
We need that order of specificity. We need impact, and we need specificity. When we talk about team goals, if we are in the low impact, low specificity quadrant, make unimportant number go up, we're not gonna do anything meaningful. We are destined to be a low impact team.
But if we play on the other quadrants, we're also not quite there yet, right? If we're high impact, low specificity, make important number go up by some amount, might not be enough for the business to still be in business, but some amount number go up good.
If we have high specificity low impact, then we get that joy of specificity, but what we're doing is probably pointless. High impact, high specificity is where good decisions live, And I wanna emphasize here that when I say high specificity, I don't mean perfection.
We came up with that ten thousand number not by running complex mathematical equations, but by saying, is a thousand good enough? What about a hundred thousand? Too much. What about twenty thousand? Too much. Five thousand. Ten thousand good. I often, when I work with companies, say, let's just run a couple orders of magnitude and see what feels good.
Is it ten, a hundred, or a thousand? Is it ten thousand, twenty thousand, thirty thousand? Which is not orders of magnitude, but you get the point. Can we get into a number that feels good enough to cross off our boxes on the checklist?
And then we get to perhaps the most challenging part, which is keeping our day to day work connected to our impact level goals. And again, with teams that have impact level goals, this is doable. If you don't have impact level goals, you can't do this.
So that team I worked with in the last story, we set our goal, ten thousand multiproduct users. They all go back to work. They're doing their work. A month later, one of their product managers comes to me and says, I get that we have these goals, but I I'm stuck.
Because we have three things we could build, and I don't know which one we should build. And I'm like, cool. Let's talk about it. And they go, I need a framework. What's a priority what's the right prioritization framework? And I say, let's start with an easy one. Let's do ICE.
Let's kick some ICE. So ICE, for those of you who've used it, impact, confidence, and effort. Right? We score the impact, score the confidence, how long it's gonna take. And I say, okay. For each of these three things, what is the most number of multi product users we might get out of it?
I say the first one, about a hundred, like, you know, it touches on this landing page that not that many people use, but we think it's gonna be really good. We can build it right now. I'm like, okay great. We can talk about that later maximum a hundred.
What about the second one? I think we could get three thousand. It's annoying. We'd have to work with a lot of other teams. There's a lot of coordination. We don't I'm like, okay cool three thousand. We have a number. What about the third one?
Like, we're probably not gonna get that many, but it's really fast. We could do it right now. I'm like, okay. Okay. Our goal is ten thousand by the end of the year. Which of these is worth talking about? And grudgingly, the answer was three thousand.
If we're only gonna get a hundred towards a goal of ten thousand, then it's probably not worth doing the work to scope it further. And this is where, again, we run into that challenge of doing things the right way versus doing the right things.
Because the next question was, okay. Okay. We got to impact, but let's do confidence and my answer was I don't care l o l. If only one of these is gonna get us towards our goal, that's what we should be focusing on. What I keep coming back to in product development world, whether we are engineers, designers, or product managers, we are constantly in this battle between focusing on the right things and doing things the right way.
And doing things the right way gives us this sense of control and safety. If we follow the process, if we do agile, if we pick the right prioritization framework, then we did it the right way. But the reality is that focusing on the right thing is messy and scary.
It means that we look at things outside of our own control. It means in a very weird, but real way grappling with our own mortality a little bit. It means saying that yeah, the success of our business is outside of our control. We can't just flip a switch and make a successful business.
We need to stay closely connected to our market. We need to stay closely connected to our customer. We need to be willing to try and test and learn new things that throw our best plans into disarray. That is our job. Whether or not we like it.
So again these conversations are not easy. They're uncomfortable and I wanna leave you with the question I've started with with a lot of teams and I encourage you to bring this conversation to your team because it is gonna be a challenging but critical conversation.
If you were in charge of the company, would you fund this team? If you were the CEO of this company, would you invest in this team? If your team can't answer that question, you have some really important conversations to have. If your team starts to get nervous and look around and be like, I don't, then you have some really important conversations to have.
And if everyone defensively says yes because we're doing things the right way and they told us to do this, then you really have some important conversations to have, and those are not gonna be easy conversations. I leave you on this note not to be a downer, but because the most important work I've done has started with this conversation.
There is a path forward, but you and your team need to chart that path together bravely. And that's me. Thank you very much. Thank you, Matt. That was excellent. I think a pretty killer question.