Arguing Agile

AA239 - Why Your Company Never Learns from Lost Deals (And How to Fix It)

• Brian Orlando • Season 1 • Episode 239

Share episode

Lost a $2M deal and nobody discussed why? You're not alone!

Your company is running on hope, not learning.

Product Manager Brian Orlando and Enterprise Business Agility Consultant Om Patel are discussing the potentially career-limiting topic of asking "why does the organization systematically avoid learning from failures?" 

Thanks! We'll be sure to shut the door on our way out... but before we do, we'll explore why sales and product teams never debrief lost deals together, why customer churn meetings feel like career suicide, and why executives are never held accountable for their predictions..

...as well as:
• Why cross-functional lost deal retrospectives rarely happen (and how to run your first one)
• The cost of ignoring customer churn and how to conduct no-blame churn reviews
• Building prediction accountability systems to track strategic bets against reality
• How organizational silos kill learning and prevent teams from improving
• Why "move fast and break things" culture prevents meaningful learning
• Creating learning backlogs and embedding continuous improvement in fast-moving organizations

Today is all about actionable tips, specific questions to ask in retrospectives, and strategies for navigating the political landmines of organizational learning. Today, we're giving you tools to transform how your organization learns from mistakes!

Referenced Episodes:
• AA235 - Changing the Message
• AA199 - W. Edwards Deming: Profound Knowledge for Transforming Organizations
• AA67 - Team Topologies: Organizing Business and Technology Teams for Fast Flow

#ProductManagement #AgileCoaching #CustomerChurn

Team Topologies by Matthew Skelton and Manuel Pais, W. Edwards Deming's work on systems thinking and organizational learning, Amazon's six-pager concept, Arguing Agile Episode 235 (Changing the Message), Arguing Agile Episode 199 (W. Edwards Deming), Arguing Agile Episode 67 (Team Topologies), Silicon Valley move fast and break things culture, 996 work culture

LINKS
YouTube https://www.youtube.com/@arguingagile
Spotify: https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3
Apple: https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596
Website: https://arguingagile.com/

Brian:

So, Om, you're telling me that we lost a $2 million deal and nobody sat down to figure out why.

Om:

Yeah, that's exactly right. And it's a lot worse than that because your executive team has already moved on chasing other things that they're working on in their pipeline opportunity.

Brian:

Oh boy. If I had a nickel for every time I heard the word pipeline how do you improve that process of winning deals if you never looked back?

Om:

Most companies are just running on hope, not learning, right? They'd rather chase the new shiny deal than figure out what went wrong with the last one.

Brian:

Alright, well, we need to argue about that if your company's allergic to learning from failures, oh boy I think there's one piece of advice then that's the only piece of advice. Yes. Keep, keep their resume updated. Updated, absolutely. If this is your first time, welcome to Arguing Agile. This is my co-host Mr. Om Patel. And I'm product manager Brian Orlando. so today we're talking about learning from missed opportunities. By the end of this episode we have, we'll have some frameworks that you can use to run down, missed opportunities. And have a missed opportunity. Retrospective, that sales and product actually want to attend together. Especially if your sales and product in the organization is like this. And then we're gonna have some specific questions that may expose why your executives are avoiding , their accountabilities with regard to being accountable for their own predictions especially when they say that, Hey, we definitely should do something and just trust me buddy. Just do what I say. And then we're gonna talk about the political tactics that make learning from failure that competitive advantage instead of a career limiting move. That's what I like to call it. Om. I like to call it a career limiting move. If you ever watch a deal slip away or a customer churn and thought, Hmm we probably should talk about this. You know, you didn't because you wanted to get promoted eventually. Sure. Well this,

Om:

This is it that gives you the arguments and the process to change all that. That's right.

Brian:

Hopefully. So, here's the question that should terrify all the product leaders. When was the last time that your sales team and your product team sat in the same room and dissected why you lost a deal? So if you can't remember

Om:

Yeah, you're not alone. No, no. That's a problem.

Brian:

That's alright. So

Om:

the steelman against here is you gotta move on, right? You can't dwell on the past, so just chase the next one because yeah, it didn't work, but that's fine. Let's not waste time on that. Because time is money. So move on without time for retrospectives and look backs and all of that, right? And then dwelling on your, your failures or your losses. It kills morale and momentum, right? People don't like that. Our teams don't like that. So that's the case against,

Brian:

There's a lot to unpack in this section that I want to talk about. But I'm gonna try just for the purpose of time, I'm gonna try to hold back my natural tendency to let go on this whole section and just stick with it's like any team that I've ever heard that wants to skip a retrospective and be like, move on Brian. Don't worry about why things were the way they were. They just are. You can't dwell in the past. I'm like, yeah, but that means you can never learn from any mistake that you made. I was at a company one time where I worked very hard to get sales, to trust product. To bring product into the room during the sales process. And because they trusted me to bring product in and integrate product into the sales process, I had the ability to tweak certain things that, from my perspective, they didn't really work. I was like, if we change the order of the presentation or we change the order of this, if we jumped into this first or even something simple like sitting down and having a pre-call before we go on site to do our big song and dance, whatever to figure out like some pain points, some specific, real specific to the user pain points so that when we presented the demo, we were already solving some of their problems with the functionality of the demo. It wasn't just like a it's outta the box completely generic demo. It was tailored for them with their specific pain points based off of what I could come up with, but if I wasn't in the room, nor was I considered about like, how could we have improved this if we didn't get the deal? We never would've learned any of that stuff, you know? So this is, this is a problem. It's like, I understand you're trying to move fast and like, I don't have time for that. I don't need more meetings, all this kind of stuff. But I mean, are we all a team here? Or what are we doing?

Om:

Yeah, if you don't really do any kind of look backs, then nobody learns anything, right? So you're gonna keep doing the same thing and hope for a better result. If you're a fast moving team, you still need to learn and not skip your retro, because if you're skipping your retro, you're telling me you've reached that level of nirvana, that you've learned everything there is to learn. Right. You've achieved perfection. It's hard to believe, first of all.

Brian:

I mean that, that's, even assuming that like your competitors are not snatching up those, like those lost deals, that you never learn anything from you. You're never doing like a forensic understanding of your competitor's roadmap, how they solve the thing that you didn't solve a thing. Like that's never coming back in either.

Om:

Yeah. I'm hoping that sales would have that somewhere that if you lose a deal, who did you lose it to? Was it your top competitor, second top or whatever.

Brian:

I'm also hoping that also, but, but it's a hope. If there is a on the calendar scheduled event where you bring the things to the retro in good faith. Yeah. To try to be open and transparent. That would be the time to share those learnings with everyone else. Whereas if you just don't know because you don't know, or maybe, maybe you legitimately are just like bad at your job. Sorry, I was trying not to do that. It not having a retro would certainly hide something like

Om:

Yeah. But nobody else would know about that so it behooves you to make sure that people understand why you're losing at the game. Maybe sales knows, yeah, we lost this to competitor A, B, C, whatever. and then they don't ask the next question necessarily.'cause you haven't formalized the process of retrospectives, right? The next natural question to ask would be, well, obviously why, why did you lose? Did you lose on price? Did you, what did you lose on? Effectively figure that out. But it's good for the team to know that, the product team to know that because in the way they build a product that impacts what you can sell it for in the end, right? Yeah. So plus margin, so agreed. So fast moving teams say, well, we're just going too fast to stop and learn. And that's definitely not a viable position.

Brian:

Oh, I thought you were gonna say nonsense.'cause that is what it is. It's, it's nonsense. That's a poor excuse right there. Yes. There are some takeaways in this category . I'm going to try once again to present them here on the screen. Oh, okay. Start your first cross-functional, lost deal. Retro doesn't even need to be about you. Whatever you do with sales or executives or marketing, whoever's involved. It's, a cross-functional team. Mm-hmm. You're getting together. I'll leave it up to you there's so much stuff to talk about, about how you could pull something like this together, that it would take the rest of the podcast. But let's, at a high level. Pulled together a lost deal, retrospective a missed opportunity, retrospective, whatever you wanna call it . and along the way, what I would do is I'd start with a little 45 minute, you know I tried to make it as close as possible to when we know the sale was missed. Yeah. it doesn't have to be 72 hours. I like to have it a day or two at the most. I don't like to let too much time slip. You know, obviously if you're coming back from a customer or a client or whatever to whatever you can do but you know, you kind of

Om:

for the better though, because the more you leave it, the less chance there is of it actually even happening.

Brian:

Yeah, it's, just something, emphasized in the meeting agenda, emphasized in the opening meeting. Like better facilitation would definitely be called for in a meeting. Like especially in your first one.'cause it, it's gonna seem like a finger pointing game, especially if you have high level executive running the meeting of like, why did we lose X, Y, Z? I would think a mature sales team will be beyond this kind of stuff. They want all the help that they can get.

Om:

I'd like to think that, but I haven't seen that very often. That's the downside to it. It's, I've only ever seen it when executives call to action these people and say, why did we lose this multimillion dollar deal? Far better for sales and product to get together and hold this and invite them in as stakeholders. You say we're gonna do an honest deep dive. To figure out what went wrong here so that we can learn from it and not repeat this. And I'd like to think that executives would welcome that.

Brian:

I've got a part two couple questions here. You know, what did the customers say they needed? what did we promise? What did the competitor promise? If you can figure that out, that'd be great. You know, what were the gaps? Some of this you might be able to do in surveys, stuff like that. You know, what do we need to change for next time? This is if you don't have a framework specific to your company or your product. These are just some questions that I would start with open-ended kind of questions to start with.

Om:

Yeah. Just be mindful that when you go into something like this, it's easy to just have discussions and then just leave the meeting. You need to have actionable, you know? The outcome should be actionable, is what I'm trying to say. Mm-hmm. So that you actually don't end up repeating the same things again. Mm-hmm that's the idea behind it.

Brian:

And then, the last one here is end with a specific product or sales process change or, or you don't even need to be a process change, but something that you will do separately the next time. So like, even if you have sales and product in the room and we're all holding hands now, that's what I'm saying. Oh, it's, it's weird. Don't dig into it. Then there are other problems. This section was about getting product and sales in the room. So I'm interested if anybody listening has climbed this mountain, is what I'm asking. So let us know in the comments if you have.

Om:

And while you're there, please like, and subscribe.

Brian:

Yes, yes. But the next section I want to talk about is even if you get sales and product in the room there is a bigger problem and that's, nobody wants to talk about customer churn.

Om:

Customer churn is really seen upon as a. Big failure, we've lost customers that's a different question than why did we not gain a new customer? Right? Because you already had this customer that you've lost or these customers in a worst case scenario. So that tends to be a little more burning, I guess. And so people are resistant to it.

Brian:

Yeah. Let's talk about that meeting. That doesn't happen. The customer churn review.. Boy, you can have the best features in the world and you can have great marketing, you can have great everything else. boy, if you got the, the hole in that boat, that leaky hole in that boat just keeps getting bigger it's like, it doesn't matter how fast you sh shovel water out, you shovel water out, you bail water out, right?

Om:

Yeah. You kind of try and do the best you can. Yes, that's right. The bare hands.

Brian:

Oh boy. Churn. This is the, I need the Spider-Man meme right now about who's responsible for churn. Everyone blames each other a hundred percent.

Om:

So this is the one, use the, the hole in the boat analogy. This is where I envision product on one end of the boat, sails on the other end, and they're both pointing fingers at each other and going, but the holes on your side, yeah, it doesn't matter. That's right. The boat's going down. So why are some of the, what are some of the reasons why the meeting that should happen? Never oh boy. I mean, you gotta scratch that a little bit and just say,

Brian:

I mean, nobody wants to be the one with their the finger pointing at and saying it's your fault, you know?

Om:

Yeah. That's very true. And even if the meeting sorta happens, right? It gets over very quickly by people just placating one another saying, well, we lost that sale because of the customer's budget or whatever so it's, what I'm saying is, on the surface you could PPO these things or you could really deep dive to learn. Yeah. If you just say it was because of customer's budget. Well, okay, fine. Let's just get into the why. Was the budget not big enough? Was the budget never approved? Was it too, too much that you're asking for your product? Mm-hmm. Or what could you do differently? Right. Maybe you can segmentize your products where you offer fewer features for lesser amount of money,

Brian:

yeah. Well, you're making the steel main case right now. So I went ahead and put it on the screen here for you what I think I heard was you making the case that customers are leaving for budgetary reasons they just don't wanna renew. The budgets got slashed. There wasn't any money. Right. There's nothing we can do. Nothing to learn here.

Om:

When I hear that, what I hear is they just didn't see any value in your product offering. That's what I hear.' cause if they see value, right. You could negotiate on the budget. But everything's negotiable.

Brian:

Yeah. and of course the other one here is that well, if we had a review. For churn, it would just be a big witch hunt. Oh. We'd be attacking development. We'd be attacking the bling game. Yeah. Product, whoever. whomever. Whomever. That's right. Those are two solid points. I don't want to be blamed I don't know, man. So budgetary, let's start with budgetary. Yeah. Like the budget is just there and like they didn't have budget, they got funding cut or whatever. Their company's not doing great or whatever. So what that means, what I hear in product when I hear that is like the value provided by our product was not like, hands down, we absolutely cannot live without this. You know what I mean? Flat out, hands down. So, so like unanimously believed. By the customer. That that's what I hear. There, there was doubt. I've been in like a B2C type of thing where like a buyer bought the software for a customer at their company to use and the company employees are like this, I don't want to use more tools. They were never bought into it. It's just somebody got excited, bought a thing and, customers were never on board so like that kind of situation, like they, that kind of thing I would expect to come out when like, well they bought it this year and then at renewal time they went in and like, nobody's using it. Well how did you go a whole year in a renewal or whatever it is why did it take this long telemetry, basically, or whatever it might be, right? There's a failure there first of all, why would your salespeople sell to a company that doesn't want your stuff? You know what I mean? Like right. Why are we chasing those leads over other leads? There's a lot to be brought, like you would think, the category we just talked about with the, like the after action of like, how come we didn't make the sale? This is the same meeting, but it's how come we didn't retain this customer? Again, you can, you can have a big sales team and go out and get customers and have you'd be like, Amazon Warehouse people get 150% turnover in a year with your customers. Yeah. Where they just keep leaking out the boat. As soon as you get'em in, they just fall right out and you, and you're not even paying attention to why. The other side of that is you get a customer and you re retain them for a long, long, long time'cause they're really happy. But you would never know if you don't do any kind of. Introspection, retrospection, yeah. Inspection, all of that. De detection if inflection. Sorry. You

Om:

gotta have the intention though, all this, right? Oh man. So yeah, look, this is all, this is all good. This was what I was saying is this kind of a retrospective isn't just a quick 15, 20 minute meeting or half hour meeting. Mm-hmm. If, if you're doing it justice, you really need to go into it, put a receptacle out by the door, ask people to check in their egos before they walk into the room, and really honestly, try and figure out what happened.

Brian:

Right. We do have a, we have some slides of the takeaway for this one. So I think, let's see what we have for process for this later. I wanna move on to the other point that we have written here. I think that a better version of this would be part business development, part customer solution, customer service part sales, you know what I mean? Part product roadmap. So like, it's all that rolled into one to say like, before somebody churn out, we should be doing like a business development review, even if it's only internally to see where that customer's trending and not just for

Om:

customer service is a great source of information.

Brian:

Yeah. I mean, I hate to say it, I've not seen this be a normal thing.

Om:

I haven't either. I've seen some fickle attempts at it, but really nothing serious.

Brian:

Fickle attempts because you wanna sell them something else, is what I've seen. Exactly.

Speaker 3:

Yeah. Yeah. Yeah.

Brian:

And then the witch hunt, the point, the point about finger pointing, right. in the steelman I'll agree that that one's valid and a good point. But only from the perspective of, yeah, if you have no framework or process or facilitator, then make sure these things stay on rails right. Yes, I agree with that, but why are you going into a meeting where everyone's just coming in and throwing fruit at each other with no framework, no agenda, no nothing. that can't be the way these run that of course they're gonna break down if you don't have any kind of framework. Or good facilitator.

Om:

Yeah. But a lot of the times, those companies that are actually even are doing this sort of retrospective and those meetings devolve into something like this, they become blame games.

Brian:

And then obviously where I'm going with the business development roadmap is that your roadmap, your product roadmap, like the customer leaving is a reflection of your product roadmap. Months ago, like things you could have dealt with if you were on top of your BD game, too late by the time that this happens. So if you're afraid to ask why your customers are leaving, then you're afraid of admitting that your product strategy is it's not based on evidence, is what I'm saying.

Om:

Yes.

Brian:

So let's see. We had a little bit of a framework here to try to recommend. you need some structure. If you're actually gonna try to have a no blame churn review you need some kind of exit interview. It needs to be as close to the customer churning as possible. If you're in B2C, I see people doing this with the surveys when people don't renew or whatever. a lot of companies also try to bring back recently canceled folks with steep discounts and stuff like that. I don't have any kind of statistics about how long that lasts, but there's tactics for that kind of stuff as well.

Om:

Service impose are very good tools for sure. And then asking open-ended questions like what, what would it take right for us to retain you for another year? And then you really try to understand some of the pain points that were glossed over, perhaps when even when the customer told you that they weren't renewing But when you're asking these questions now you are basically saying, well, you name your price. And we'll see if we can meet somewhere in that region.

Brian:

Which is funny 'cause it's exactly what you do when they onboard for the first time so the pattern analysis here, you should be reviewing all of your churn metrics. I think quarterly is way too long, personally. But I would be reviewing all your stuff at a minimum, at your quarterly strategic review. whenever you do that with the higher ups, you say, Hey, these customers are at risk. These people don't really use the software. We can't count on them to renew, in my opinion or whatever. And it can be based on data.'cause you got real data of usage and stuff like that. Again, you're just having a BD conversation here, right? You're not having a finger pointing or any kind of that kind of stuff. Although I could completely see. Just from my experience, I can completely see it being used as like a Brian's telling us what to do Brian's at it again, here he goes,

Om:

this is the danger. Right? So then the, the team's devolve into not doing these things, right?

Brian:

Again, sometimes, just because I said it, oh no, I'm said it, this is getting too real for me. And then let's see, and then the, the adjusting your product roadmap based on those churn patterns is definitely something that you should do. I mean you know, if, if, if you have like the, the evidence from the people churning of things that you didn't do as opposed to like the evidence of the new features or the new customers or whatever, we talk a lot about discovery of like trying to win a new customer, trying to bring in a new market or whatever. But again, like all that water that you're bailing out the boat because these people are leaving, like is that worth more than the people you're trying to bring on? So the, these are just not like modern product management and especially the podcasts and stuff that I listen to, the product management and YouTube videos and stuff like that. They don't talk about this kind of stuff.

Speaker 3:

That's right.

Brian:

They don't. All right. So some takeaways from this one. There are no takeaways. Sorry. No. The take, the take. The, the biggest biggest

Om:

takeaway is if you're not retro expecting, then you're not doing it right? Yeah.

Brian:

Yeah. Well, so the, we gave two retrospecting retro expecting. It's, that's like the, it's like with pick axi, we gave two,, one was retrofitting why you lost deals and the second one was why you lost customers after you made the deal with them la later on, renewal time and stuff.'cause that's churn. So there's, we gave you two different things to look at and said, Hey, you need to be here, here's some very loose frameworks to help you start retrospecting. So what do you think about this category? What's your experience with churn? We'd like to know, so let us know in the comments. Absolutely. Okay, so now we've covered lost deals and churn customers, but there's another conversation and that's gonna be a tough one for most people to have, which is whoever makes the bets in your company. Executives product who, whomever who. So, yes. Holding them accountable for their for their predictions. I'll call them predictions. So, i've got a radical idea. This is a, Ooh,

Om:

I like radicals.

Brian:

Radical because it gets you fired. But let's ignore that for a second and say, let's say we actually go back and check whether these big strategic bets that executives come up with, and they had go to a big offsite and they come back and say, we're doing this. Now we're going in this bold new direction. And what if we compared their predictions to reality on a regular basis to ask Hey, what could we have done in this time period? And where would that have left us as a business? And I mean, that it sounds reasonable. It, it sounds like something you would do with a very, very, very small business you know what we is this why we can't have nice things? Yeah.

Om:

So these opportunity costs discussions don't happen very often if they happen at all, especially because people that have, turn up at the table to make those bets, or at least multiple levels above your pay grade, right? That doesn't mean that they shouldn't welcome a conversation around that because they're betting the company's money on here, betting the farm, or at least a little patch of the farm. So yeah, they should welcome this conversation, depending, again, this is where do they have egos? Because if they do, they're not gonna welcome this. They'll say, well, I'm the executive here, right? I'm the adult in the room. So get back to your machine and start grinding away. But really as a company you're not gonna get anywhere if you're not accountable for your actions. Those same executives are holding everybody accountable for their own actions, right? So why not them, right? Yeah. Who does that? Like, who makes that happen? I can tell you who it isn't. By the way, this is easy part of the conversation. It is not the CEO. Because these executives are experts at spinning the story and pivoted the blame on someone else.

Brian:

CR podcast about changing the message arguing Agile 2 35. That's right.

Om:

Twisting the message. So this is a case where I, I encourage if you have any kind of, especially if you have any kind of evidence, right? Just go and approach this subtly and say, we did this. We expected X to happen, but y happened instead. Well, don't use the word you against the executives unless you're really close to the revolving door. Or it will put you there. So just say, look, we expect something to happen. Something else happened instead. Can we examine why? and again, framing it that way. You're not in there saying, well, you Ms. Campbell. I don't know you're not doing that.

Brian:

I simultaneously want to disagree with you and say most executives egos and also product leaders there he goes, made outta glass. And that's just not a thing that you could do. But also I'm in this position where I want to throw out the steelman side of the argument. So it's very strange to immediately be saying you can't do this. But most companies, I think what they will give you, like the points that they'll give you is they'll say a couple things though. First I expect the first thing they'll say is like, my time's better spent trying to get us to figure it out. You know, it doesn't matter how we got here, doesn't matter whose fault or whose ideas it was. Yeah, let's just move on. We, we said this as an excuse in a previous category as well as like, Hey buddy, get like, this sounds a lot like deflection now the more I'm saying it you know, hey you know, that's just a waste of time and we can our, it's, it's time to double down on finding new customers and let's not worry about, well this water's coming into the boat through these holes day that I told you not to fix six miles ago. You know what I mean? I told you not to fix it when we were still offshore and now we're in the deep sea and

Om:

those are nautical miles, but who cares? That's right. Wet anyway. That's right. Yeah, I agree. it sounds like deflection laced with avoidance right. So yeah, absolutely agree.

Brian:

Like you know, the market changes so fast. That you know, six months we'll be outta this, or three months we, one more customer will be outta this. What does it matter?

Speaker 3:

Yeah.

Om:

Yeah. and sometimes people will, executives will pull the wool over eyes and say, well, we didn't really expect to win that. It was just one of those things. We cost it anyway and see if any official bank, we'd rather work on this other thing They're very good, they're spin masters.

Brian:

Yeah. You know, I hate to promote Amazon in any way, shape or form. You know,'cause Amazon is quickly revealing themselves to also much like Palantir to be a very skillful, evil technology company. But it's like the six pager concept of like, well, you write down, like you put your name on the paper, you are the author, you write down. Your beliefs and your concepts and your research. Then you turn it in and in order to move forward in an initiative from scratch, like if there's not even that level of like a one pager, let alone a well researched six pager, I have been in companies that nothing gets written down and there's no product management. Just the executives spout off whatever shower thought they came up with that day, come in, and then by the end of the day, they've forgotten what it was. They come in the next day and say, why is everyone working on that? I never said to do whatever. it's not like they're not schizophrenic.

Om:

No, they're,

Brian:

but they just, they're just the, the pace at their level is as such that they just can't remember.

Om:

Yeah. Yeah. They avoid writing down stuff because it creates an indelible record of damning evidence. So you don't do that. Because you never said it. If you did, maybe you misheard so there's all these things that they use kind of to you that's put the whole thing that's gaslighting. Oh, it is, it's gaslighting. Absolutely. Somebody else may have said that. That's definitely gaslighting, so what, what do you, what can you, so what's another, do you have any more on the, on the steelman side or do we move over?

Brian:

do I need anymore? No, I think I rest my case, your Honor.

Om:

Okay. Well, exhibit one rapid market changes is, is often kind of doubted as, oh, we have to worry about, we don't have time for all that stuff.'cause which isn't the next thing, right? Yeah, that's great. The problem is it masks accountability well, at various levels

Brian:

in mass accountability. The, as the product manager, my job is you discovery, the market discovery and user discovery, market research, user research, that research needs to be written down somewhere. So if you're saying like, well, the market moves really fast. I'm like, yeah, it does, but what does that mean? We have to be writing things down. We have to be putting our experiments on paper somewhere. And if you're gonna come in and say, I don't need any of your experiments, just do x, y, z, like the, whatever the scoring rubric is that we all get judged by, you're basically coming into the fighting ring and saying like, I don't need to train. Like I can just knock it out. One punch, no training.

Om:

You're right about documenting or writing down stuff if you want to be evidence driven or data driven. Yeah. Because otherwise it's someone's opinion against someone else's opinion.

Brian:

That's, I mean, there's no other way to calibrate your prediction mechanism for business other than. User research, market research.

Om:

There's no other way to do that meaningfully. Yeah. I couldn't agree more. I mean, people will say, well, I've been in this game for 34 years, right? Yeah. I mean, selling Cadillacs and you'll still keep selling those things Or whatever, . But yeah, I agree. Evidence-based is the way to go, and the only way to do that is to write down numbers don't lie. So sometimes they don't lie.

Brian:

So I don't think it's a huge step. If we back up, typical companies, let product management do this. Say, oh, you got an idea. Just bring into product management. They just shuffle it off on product management, which this could be another podcast by the way, is like, Hey, managing all the ideas. Like what, what if you have like a lot of stakeholders that have good ideas. A lot of people just shove the stuff off on the product management and say, just go talk to the product manager. And then the product managers say, well, we're overwhelmed because the executives bring us this and the employees bring us this and customers bring us this and we don't know who to serve and what to work on. Because you don't have a framework for like, quickly, researching testing ideas or having the people bringing you the ideas, help in the research and testing, thereby contributing to that machine of idea testing a deep bucket of users, bucket of users. Why am I, why are they in a bucket? A pool of users. That's what I'm trying to No, they're in, well, this is a, it's a very nautical theme today. What? It's aquatic themed podcast today. They're not you know, if you don't have a set of users to go back to who are your test users? how do you get ahold, how do you incent them? Whatever. Then you're really starting from ski. I mean, it's no wonder you don't know how to do any of this stuff. Exactly. You have no framework. Modeling through. Yeah. That's what you're doing. So, I mean, good luck for that while the luck is good,

Speaker 3:

right? Yeah.

Brian:

Yeah. I mean, the best strategies here, like they're actively tracking prediction accuracy. If people are helping test ideas, now you've got all kinds of metrics that you previously didn't have about who comes up with what idea and which one's tracked. Directly to revenue generating ideas or customer satisfaction, elevating ideas, customer delight, you can track that.

Om:

Whatever your success metrics are. Yeah, absolutely. And those kinds of prediction, initiatives, they get better over time.'cause you get to improve your craft as you go forward

Brian:

you know, that's interesting. Interesting because like nobody does it. That's the takeaway here, that we're talking about is building some kind of prediction, accountability.. It's called Executive Prediction Accountability System. But it doesn't have to be like that. It's just, just ideas, right. Accountability tracker of some sort that shows like the benefits from the ideas when you can show them. And like a, a way to do this, number one is to create a log to actually write the ideas down somewhere. Right., And then obviously you have to figure out how to, how to test it in the market, how to measure them after the fact, that kind of stuff. Figure out what features spawned from them. I don't think that this is too outta line to just say, Hey let me figure out where to write my ideas. And the ones that get used get spun up into a ticket in whatever a LM tool you use. I mean, might be a good a LM tool might be Jira.

Om:

Yeah. There's many ways to tactically handle these ideas. They could also just be straight into your LM tools. They're not things that teams are working on. Right. But they're being vetted until something comes through and then it hops over into becoming a feature or whatever.

Brian:

And then the reality check side of this is you revisit these revisit. I mean, I don't know if a quarterly is too long to revisit these pools. I mean, they're large pools of ideas, so I don't think quarterly is, I mean, if you don't have a better cadence than this, you don't have a faster cadence of ideas, or if you're doing it for the first time, quarterly is probably okay.

Om:

The ones that you're actually doing AB testing or whatever, I mean, they'd be, they'd be bubbling up to the top of that. Mm-hmm.

. Brian:

Oh, oh. And then the last part is that you know, you're tracking some metrics over time. You know, it's which ones do we get right versus which ones we get wrong. They probably won't be measuring Right, wrong.'cause some ideas will pan out into other ideas degrees. But you know, just something like that. So that, that's just a small takeaway that you might go back to your workplace and try track ideas. And where do those ideas lead to? They lead to features, they lead to improvements that customers like. Do they lead to more money? Do they lead to closing of sales? Who knows? But if you're not tracking where they came from then the executive that rolls in with the shower thought that he had in the middle of the night I mean, he's just as right as your most researched product manager.

Om:

Absolutely. that's scary.

Brian:

Have you had an idea in the shower and then spent six months of development time working on it?

Om:

An executive who never reviews their predictions isn't a strategist, they're just someone with opinions and a bigger salary.

Brian:

Oh boy.

Om:

So we've talked about meetings that don't happen and you know, this, the oak structure that, prevents learning in the first place. Let us know what you think about this topic down in the comments below.

Brian:

So we talked about meetings that didn't happen. We gave some retro ideas, but we haven't talked about the organizational structure. You know, we're coming to the end of the podcast when we're talking about organizational structure. Organizational structure that prevents learning in the first place. So that's what we're talking about now. So if you wanna know why your company never learns from missed opportunities, arguably it might be a culture problem. I would argue it's a structural problem in the organization. When sales, product, customer support or customer success, when they report to different executives and they all have their own OKRs and their own silos. I just don't see, like what we talked about earlier in the podcast is just getting a cross-functional team together and talking about why we failed and what we can do better. I see that being much, much harder now that we've got all these games

Speaker 3:

going on.

Om:

so one of the difficulties of having cross-functional organization teams is it impedes expertise and efficiency. That's the steelman argument right there functional specialization creates expertise and efficiency creates and promotes it.

Brian:

I mean, I know that's the argument, but I mean, yeah, that's kind of a weak sauce argument I think. Definitely I think there's

a whole book:

Team Topologies about this.

Om:

We did a podcast on that.

Brian:

Yeah, we did. We did a podcast on team Topologies called Team Topologies Organizing Business and Technology Teams for Fast Flow by Manuel Pius and the other guy, it was arguing Agile 67 6 7, arguing Agile. Six seven. That's right. Kids.

Om:

Wow. Six seven. That's right. Kids,

Brian:

hang, hang on, if we do retrospective every time, om will have all these different teams doing their own retrospectives. And then we gotta do cross-functional retrospectives and then we gotta do executive retrospectives. What would all these meetings om, that's meeting overload.

Om:

Meeting overload something. So then we're admitting we're just too busy to improve.

Brian:

Oh, I thought you were gonna say, too busy to fail. Too

Om:

No, you're not too busy to fail. You're failing all the time.

Brian:

It's like too big to fail. Only with, yeah, too big to fail. Minus the federal government. That's

Om:

right

Speaker 3:

yeah,

Om:

We're too busy to improve.

Brian:

Functional specification creates expertise and efficiency. That, I mean, that, that functional expertise one like that, boy, that one I, I've a lot, I've heard a lot of people rattle that Sabre of that oh, we gotta have all the DBAs over here and we gotta have all the programmers that are backend over here, and all the front end people over here. Like, we can't have anybody talk to each other how, how dare you? I'm surprised that this management model, that that's what I, that's what it really is. I'm surprised it still persists.

Om:

I think it has its roots in efficiency. You know, we can't be hiring, of course, hiring 15 DBAs, we hire one, right? And we'll time slice them 30 times.'cause 15 into one doesn't go. So functional silos on the surface looks like they optimize efficiency at a local level. Right, but at a macro level, right. Do they

Brian:

If you are not incented on the whole, on the system, that's what I'm trying to say. Optimizing the whole, sorry. Yeah, yeah, yeah. We did a Deming podcast like everybody in the world should listen to it. We did arguing Agile 1 99 w Edwards Deming, profound Knowledge for transforming organizations. I mean, it's a quick whatever, hour and a half.

Om:

Almost two hours, I think.

Brian:

It's an hour 53. Yeah. Almost two hours arguing as a 1 99. You can hear all about the games that people play and how to destroy a system and like it, he wrote the book on that almost 50 years ago at this point yeah, it, I'm, again, that's why I say I'm amazed that this stuff is still like, brought up and promoted. Like it was the, the newest, hottest thing, like a forward deployed software engineer it's, which is the newest, hottest thing. It's new, it's newest, hottest thing that's like completely not new at all it's just nobody remembers pep Pepper. Strong remembers. So yes, if you're playing games and you don't consider anyone else's work and you're only scored on your own goals, we're not playing as a team. We only hit goals ourselves. Yeah. Then, yeah, I guess it's a point, but I, I don't know. It's not a good point. That's what I'm saying.

Om:

You as an organization are not a learning organization at that. Right, because you're not learning, you're not doing that perspective. You're not learning by doing cross-functional look backs and understand how you can improve together as opposed to locally individual silos.

Brian:

And also there's so many games here, that's all I can think of is I can't move my brain past all the games that play when you're in those silos. I had a CTO come to me one time and say, Brian, you just gotta keep these developers busy with enough work. I'm like, what are you talking about? Busy with enough work I would rather have every single developer in the organization trying to solve our top problem and like sitting over each other, looking over the shoulder at the laptop of one single person, pitching ideas. Because like, I don't, I can't explain to the CEO why a single develop. Is not working on our top problem that's not a conversation that he will have any kind of grace about. You know, he'll say we have a problem what if there's a blow up in production? Right? Like, oh, I'm not fixing the blow up. I'm over here working on widgets. Why are you doing that? There's customers down.

Om:

Yeah. Well the flip side of that from the executives would be, well, why? You have multiple people working on the same problem.

Brian:

Yeah, yeah. I have worked for and spoken with both of those types of people. Yes, yes. But you knows, I think the learnings that come from solving problems or at least being in the room when those kinds of critical problems are solved and knowing that you're working on the most important thing, I don't know. That's a tough discussion to have.

Om:

it is a tough discussion and sometimes executives will. Relent a little and say, well, you can have your team retrospective and they can have theirs. And they can have theirs so at that point, all you're doing is checking a box.

Speaker 4:

Yeah.

Om:

I think that's pretty much it,

Brian:

the only point I would have that would be valid for any of those folks that are like, how many people do you need to work on one bug? I will say well, in the companies we're, it's the most important thing and they clearly make the sanction and they don't care how many or how few people are working on it. Right? Like those people eat your lunch. Then go buy another lunch and eat that one while you're still sitting trying to figure out the first one. So you know, they're outperforming you left and right.

Om:

Yeah. At the end of the day, what are you prizing? Like, what are you measuring? Are you measuring reducing paint for your customers in the shortest possible time or are you saying we're just gonna look for efficiencies or utilization of individuals or however? Right. So it comes down to that.

Brian:

And also you can measure yourself right outta my office with that attitude is what I Absolutely. So like the takeaways here are very similar to our previous takeaways where you're if you've never had a cross-functional, if you have a lot of silos you wanna pull together some kind of cross-functional retro for hopefully a semi-serious reason. So you're gonna actually pull together learnings that. You can pull together learnings as a group that any one silo would not be able to come to on their own.

Om:

And these don't have to be very structured or formal. They can just be sort of like root cause analysis for anything mm-hmm. That you're experiencing as a, as an organization. Right. Get the right people together and go to task.

Brian:

Yeah. And it doesn't have to be the same people every time as well. Course not. Yeah. I mean, in product it could be an analysis of what opportunities did we pass going back to the category we talked about earlier. Yeah. What do we pass on? And now what does that opportunity look like in retrospect if we had worked on it? And maybe it's like nothing obviously you wanna have some kind of rigor to where you pick those ideas. You don't want to be picking softballs. yeah, sure. But yeah, I mean that's one. Hopefully the executives are involved in this. I mean, hopefully you have an executive sponsor. I would think that you're doing something like this, some sort of cross-functional learning opportunity. You probably do have an executive sponsor that you have some sort of horsepower from the top. This is like every agile transformation. You've get that one person on the exec that says like, Hmm, we should be learning from our failures over here. And everyone looks at them begrudgingly and says, Hmm, fine. You can have this person for 30 minutes.

Om:

Alright, so if you've had experiences where multiple teams came together to find what went wrong, et cetera, let us know. Let us know. Anyway, what you think about this particular subject down in the comments below.

Brian:

So we talked about diagnosing structural problems and now om it's time on the podcast for us to move fast and break the law. Oh no, it's not, it's not, that's not speeding. It's not time to move fast and break the law. It's, it's time. It's time, it's time to move fast and break things. That's what it is. Move fast and break things. It's, it's the rallying cry of modern tech companies Move fast and break things, especially in silly con valleys. Silly con. They're so silly.

Om:

Silly with a dash Oh between silly and con.

Brian:

But say, here's what nobody's gonna tell you. That's right. Nobody, nobody in the whole world, . When you move fast without stopping to learn what you broke, as you're moving fast and breaking things, then you're, you're just, you're just the, what was the, what was the the cartoon character that spun around a Tasmanian then you're the Tasmanian Devil. Yeah. Then you're the Tasmanian Devil. You just spinning around, breaking things at increasing speed.

Om:

You're, you're breaking things at higher speed all the time. All right. Well, good luck keeping that funded, because that's gonna run dry pretty quickly.

Brian:

We're funding Tasmanian devils.

Om:

I mean, look, this, this sort of thing you would think through just natural evolution would weed itself out pretty quickly because who'd wanna fund that sort of thing for any period of time. But these are the executives that just hop over onto the onto greener pastures and spin up new teams that keep thrashing.'cause that's what this is expensive. Th trash. You go around in circles or. Ellipses and you never come out of the orbits.

Brian:

I mean, hey, I love a good steel man. And now's the time. Like I wanna actually use the steel man logo at some point in the podcast. So here , speed. Not the movie speed, not Keanu Reese, not that. Yeah. Yeah. Not, no, we're not, we're not on any buses. They're not going to under 50 miles an hour or whatever it is. Speed itself creates competitive advantage. And if you're not sure about that, I got every AI vendor in the world, every AI tool wrapper in the world trying to sell you a product that's saying. Speed will fix all of your idea problems. If speed will fix your, all of your problems spiritually,. Om: Categorically, spiritually, metaphysically speed will fix all your listen. It sounds ridiculous to say it out loud, but I mean that's what they're pedaling this Absolutely. And have been for months, months and months and months. Everything you guys are talking about in this podcast. That's just bureaucracy. You're you're killing my momentum. you're crushing my vibe, man.

Om:

Yeah. You're adding latency. That's very true. I'm vibing, Be build it and they'll come. Yeah. Good luck with that. Good luck getting that funded too.

Brian:

All right. Well, I didn't say they were good steelman points, but the steel men have spoken. Yeah, they have. It's raining steel men. That's what I'm saying. They have radical like speed. I mean, it's again, the steel man, I can't even try to defend it. I like, I can't even try to defend it.'cause it's like, it's a whole career fighting against like, well speed because you think it's the way to go. Great. And then if we meet your deadline that you made up, that was never a deadline in the first place. Like isn't this how like agile software develop was even born in the first place? It's like, we gotta have this by this date. And I just made up the date. Anyway, look, it's, you're not learning anything. It's speed for the sake of speed. Somebody set the original deadline anyway., It's expensive thrashing if you think about it, because we're gonna deliver, we're gonna take six months, eight months, nine months, whatever. You know, we're gonna deliver something. Customer's gonna hate it. There'll be change requests. Everyone's getting upset. There's more money getting poured into it. Margins are getting tighter and tighter. This is, this is like the beginning of my career development, like early two thousands development.

Speaker 3:

Yeah.

Brian:

Yeah. And that's the way it was. It wasn't really every week, but it felt like every week there were new deadlines and there were just as ridiculous as the last deadlines and release day. You were working super late. It was this now, now you've got 9, 9, 6 culture, now 9, 9 6

Om:

again. Oh my goodness. And you're gonna wash out some really good people. That's right. In that same culture and so it sort of dilutes the whole thing because you lose good people. What happens? you end up with people that are not as good, but they're still thrashing then what happens? fast forward another 90 days.

Brian:

I don't know. You're gonna get people, I think you're gonna get more nine, nine Sixers in there that think that well, if you're not, if you're not working 9, 9, 6, then you are the problem. That's right. You're not working hard enough. That's right. You just gotta get rid of that pesky wife and kids, and you'll be able to be 9, 9, 6 for life. Oh boy. I don't know where we're going in this podcast, but I like it you spent no time building feedback loops. You've spent no time building a culture that attracts people that can learn from their mistakes. In fact, you're going the opposite direction. You're building a culture of people that deflect and blame basically.

Om:

Without using the word, but yeah. Absolutely.

Brian:

Yeah. So this one, the embedding learning in your organization. if you're just moving fast and breaking the law over here then hey, maybe we can't help you. But if you're moving fast and your culture is one where you think that you can't slow down because no one, you might get blamed for slowing down or you might get yelled at for slowing down or whatever. here's some stuff I'm showing on the screen and some stuff here. Some things you can try. After a significant failure, whatever that failure is I'm calling it failure, call it whatever you want, right after any kind of significant incident, let's say that it was, could be a lost deal. Going back to the first section of the podcast. Could be a production outage, which trust me, if you're breaking fast, moving fast and breaking things, you're gonna have these outages you know, or miss deadlines, which all the deadlines a reminder. All the deadlines are fake anyway, so

Om:

That's true. All losing customers.

Brian:

That's true, that's true. Any of these things. So pick one of these and you know, just have a quick, have a quick call a quick retro on the one problem. One cause one action. It's a little deviation in the Mike Miller. One, one problem will cause that one action. Yeah. One, one. Yeah. Figure out what you can do. What One action. Are you going to take and you know, what, how are you gonna make it better? What, what, what was the cause and what, what action are you gonna take away from it? And then if you don't have a learning backlog, so this is like the technical debt equivalent of what are the things that we need to learn around here? Which I think of like everyone should have some sort of like AI tools on this backlog right now of like, the team doesn't know how to work with generative code tools. Maybe you don't have co-pilot or whatever. Start figuring out how that stuff works into your daily working process. simple stuff like that. I mean, that's a simple example. You can think of more complex examples like better ways of doing things and actually deprecating the way you were doing things before in order to learn better and faster ways. And this is just ongoing, continuous forever in the world of that, because you just should be doing this anyway. Except we don't think about it in terms of , our whole team is going to be contributing to doing this at the same time, pushing everyone's skill level up. But the category we're talking about this stuff directly, conflicts of like, well we are, we are always just like racing to the next deadline. There's no time to take vacations, there's no time for retrospective, there's no time to question whatever, you know? Yeah. There's no time for product management. There's no time for bathroom breaks.

Om:

Yeah. Far off. Yeah. So I mean, some of this stuff is going to require you to cut across organizational structure and silos, et cetera, but try chipping away at it. You'll be surprised.

Brian:

So, okay, I think if we're gonna wrap up this podcast with a, with a zinger, it's gonna be, if you cannot articulate what you could have done instead, you didn't make a decision. You just reacted and called it his strategy in retrospect. Which is not what we're talking about retrospective. That's not what we're talking yeah. In hindsight, yeah. You kind of miss a point. Yeah. So, so most organizations they don't, they don't learn from missed opportunities.'cause I don't think that they believe that they have missed opportunities.

Om:

Even though they're hitting them in the face over there.

Brian:

So if anyone asks a question what, what could we have done instead? I think they're risking their career at that point, that company. So just keep that resume updated.

Om:

Keep that resume updated folks. But yeah, do let us know in the comments below What your experience has been.

Brian:

And if you can think about opportunities at your work that you could have taken but did not. Like I'm also interested to know if anyone actually has a process that they revisit those on any kind of basis. Sure. Yeah. Because again, like most of the companies I've ever worked at, revisiting a decision. They'll say Ooh, Brian, oh, you're pointing fingers. Revisiting old decisions, even if there's evidence there, yeah. So this was an interesting topic. It is. I wanted to have this podcast for a while. We haven't been able to get to it'cause we had tons of stuff that was in front of it. But yeah. Learning from missed opportunities, even understanding what missed opportunities there are you know, so, yeah. If you have any of those please let us know in the comments and also

Om:

like, and subscribe.