Matt LeMay: evaluation

Transcript context

…So what is it that you think people are thinking instead most often? It's interesting. We live in a world where for the last 20 years of product development, we've been all about best practices. We love best practices. And I love best practices too. I think best practices can be really valuable, can be really useful. I love how much knowledge sharing there is out there. When I started 15 years ago, it was so much harder to get any sense of how anybody was doing anything. But I think the downside of this is that there are a lot of folks who are really, really fixated on doing things the right way. And a lot of the writing and thinking about doing things the right way exists in kind of this middle layer, between impact and day-to-day work. So if you have impact, the overall success of the business, revenue, growth, profits. Then from there you set objectives and you do initiatives, and then you do bets, and then you make a strategy, and then you do your day-to-day work. I think the tendency among a lot of product teams is to key to those middle pieces, to say, "Okay, what we're doing is on strategy. What we're doing is part of objectives. We did OKRs, right? We spent three weeks coming up with our OKRs for three months. It's OKR season, everybody. We have to pretend to care about our goals, and I read a book that says we have to have five to seven objectives with five to seven key results, and we want the score of each one to be a 0.6 or a 0.7." And at the end of the day, you've actually spent so much time and energy being really clever and cascading these things into these intermediate steps, that each step has incurred more and more risk that we might not achieve that impact we seek to drive. Each time we abstract things out, each time we cascade things from impact to something else until we wind up with a checklist of features to build, we're assuming that if we then build that checklist of features... We will have a successful business. But honestly, most of the companies and teams I work with, if I ask them how their lowest-level goals add up to their highest-level goals, they look at me like I just asked them the most impossible question in the world. Because by the time you get things down to that level, maybe it's going to work, maybe it's not going to work. There are assumptions baked into each of those levels. You might go through the motions of doing OKRs the right way or doing strategy the right way, but that doesn't guarantee that your strategy is going to work. It doesn't mean that your OKRs are going to add up to what your investors or your shareholders need to see. So I think there's a tendency among product teams to really sweat the middle, and to get really stressed out if the middle is not in perfect theoretical harmony with itself. If the objectives are a little out of line with the initiatives, are a little out of line with the bets, are a little out of line with the domains. e is not in perfect theoretical harmony with itself. If the objectives are a little out of line with the initiatives, are a little out of line with the bets, are a little out of line with the domains. But at the end of the day, I don't think I've ever worked for a company where these things add up to a perfect breadcrumb trail you can trace back from, "We prioritized these bits of work in this sprint because it adds up to this objective, which is part of this strategy, which adds up to this initiative, which is part of this bet, which will deliver this much impact." It's just not how things work in the real world.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.