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

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Brian (00:00):
So, Om, you're telling me that we lost a $2
million deal and nobody sat downto figure out why.

Om (00:06):
Yeah, that's exactly right.
And it's a lot worse than thatbecause your executive team
has already moved on chasingother things that
they're working onin their pipeline opportunity.

Brian (00:19):
Oh boy.
If I had a nickel for every timeI heard the word pipeline
how do you improvethat process of winning deals
if you never looked back?

Om (00:27):
Most companies are just running on hope, not
learning, right?
They'd rather chase the newshiny deal than figure out what
went wrong with the last one.

Brian (00:36):
Alright, well, we need to argue about that if your
company's allergic to learningfrom failures, oh boy I think
there's one piece of advice thenthat's the only piece of advice.
Yes.
Keep, keep their resume updated.
Updated, absolutely.
If this is your first time,welcome to Arguing Agile.

(00:57):
This is my co-host Mr. Om Patel.
And I'm product manager BrianOrlando.
so today we're talkingabout learning from missed
opportunities.
By the end of thisepisode we have, we'll have some
frameworks that you can use torun down, missed opportunities.
And have a missed opportunity.
Retrospective, that sales andproduct actually want to attend
together.
Especially if your sales andproduct in the organization

(01:20):
is like this.
And then we're gonna havesome specific questions that may
expose why your executives areavoiding , their
accountabilities with regard tobeing accountable for their own
predictions especially whenthey say that,
Hey, we definitely should dosomething and just
trust me buddy.
Just do what I say.
And then we're gonna talk aboutthe political tactics that
make learning from failurethat competitive

(01:42):
advantage instead of a careerlimiting move.
That's what I like to call it.
Om.
I like to call it a careerlimiting move.
If you ever watch a dealslip away or a
customer churn andthought, Hmm we probably should
talk about this.
You know, you didn't becauseyou wanted to get promoted
eventually.
Sure.
Well this,

Om (02:00):
This is it that gives you the arguments and the process to
change all that.
That's right.

Brian (02:05):
Hopefully.
So, here's the questionthat should terrify all the
product leaders.
When was the last time thatyour sales team and your product
team sat in the same room anddissected why you lost a deal?
So if you can't remember

Om (02:17):
Yeah, you're not alone.
No, no.
That's a problem.

Brian (02:20):
That's alright.
So

Om (02:21):
the steelman against here is you gotta move on, right?
You can't dwell onthe 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 forretrospectives and
look backs and allof that, right?
And then dwelling on your, yourfailures or your losses.

(02:41):
It kills morale andmomentum, right?
People don't like that.
Our teams don't like that.
So that's the case against,

Brian (02:48):
There's a lot to unpack in this section that I want
to talk about.
But I'm gonna try just for thepurpose of time, I'm gonna try
to hold back my natural tendencyto let go on this
whole section andjust stick with it's like any
team that I've ever heard thatwants to skip a retrospective
and be like, move on Brian.
Don't worry aboutwhy things were
the way they were.

(03:08):
They just are.
You can't dwell in the past.
I'm like, yeah,but that means you
can never learn from any mistakethat you made.
I was at a companyone time where I
worked very hardto get sales, to trust product.
To bring product into the roomduring the sales process.
And because they trusted me tobring product in and integrate
product into thesales process, I had the ability

(03:29):
to tweak certainthings that, from
my perspective, they didn'treally work.
I was like, if we change theorder of the presentation or we
change the order of this, if wejumped into this first or even
something simple like sittingdown and having a
pre-call before wego on site to do
our big song and dance, whateverto figure out like
some pain points, some specific,real specific to the user pain

(03:51):
points so that when we presentedthe demo, we were
already solving some of theirproblems with the functionality
of the demo.
It wasn't just like a it's outtathe box completely generic demo.
It was tailored for them withtheir specific pain points based
off of what I could come upwith, but if I wasn't in the
room, nor was I considered aboutlike, how could we have improved

(04:12):
this if we didn't get the deal?
We never would've learned anyof that stuff, you know?
So this is, this is a problem.
It's like, I understand you'retrying to move fast and like,
I don't have time for that.
I don't need moremeetings, all this
kind of stuff.
But I mean, are weall a team here?
Or what are we doing?

Om (04:26):
Yeah, if you don't really do any kind of look backs, then
nobody learns anything, right?
So you're gonna keep doingthe same thing and hope for a
better result.
If you're a fastmoving team, you still need to
learn and not skip your retro,because if you're skipping your
retro, you're telling me you'vereached that level
of nirvana, that you've learnedeverything there is to learn.
Right.
You've achieved perfection.

(04:47):
It's hard to believe,first of all.

Brian (04:48):
I mean that, that's, even assuming that like your
competitors are not snatching upthose, like those
lost deals, that you never learnanything from you.
You're never doinglike a forensic understanding of
your competitor'sroadmap, how they
solve the thing that you didn'tsolve a thing.
Like that's never comingback in either.

Om (05:04):
Yeah.
I'm hoping that sales would havethat somewhere that if you lose
a deal, who did you lose it to?
Was it your topcompetitor, second
top or whatever.

Brian (05:12):
I'm also hoping that also, but, but it's a hope.
If there is a on the calendarscheduled event where you bring
the things to the retro ingood faith.
Yeah.
To try to be openand transparent.
That would be the time toshare those learnings with
everyone else.
Whereas if you just don't knowbecause you don't know, or
maybe, maybe you legitimatelyare just like bad at your job.
Sorry, I was trying notto do that.

(05:34):
It not having a retro wouldcertainly hide something like

Om (05:36):
Yeah.
But nobody else would knowabout that so it behooves you to
make sure that people understandwhy 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 thenext question necessarily.
'cause you haven't formalizedthe process of retrospectives,
right?
The next natural question to askwould be, well, obviously why,
why did you lose?
Did you lose on price?

(05:57):
Did you, what did you lose on?
Effectively figure that out.
But it's good forthe team to know
that, the productteam to know that because in the
way they build a product thatimpacts 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 aviable position.

Brian (06:20):
Oh, I thought you were gonna say nonsense.
'cause that is what it is.
It's, it's nonsense.
That's a poor excuseright there.
Yes.
There are some takeaways in thiscategory . I'm going to try
once again to present them hereon the screen.
Oh, okay.
Start your firstcross-functional, lost deal.
Retro doesn't even need tobe about you.
Whatever you do with salesor executives or marketing,
whoever's involved.

(06:40):
It's, a cross-functional team.
Mm-hmm.
You're getting together.
I'll leave it up to you there'sso much stuff to
talk about, abouthow 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 woulddo is I'd start with a little

(07:00):
45 minute, you know I tried tomake it as close as possible to
when we know thesale was missed.
Yeah.
it doesn't have to be 72 hours.
I like to have it a day or twoat the most.
I don't like to let toomuch time slip.
You know, obviously ifyou're coming back from a
customer or a client or whateverto whatever you can do but you
know, you kind of

Om (07:19):
for the better though, because the more you
leave it, the lesschance there is of it actually
even happening.

Brian (07:23):
Yeah, it's, just something,
emphasized in themeeting agenda,
emphasized in theopening meeting.
Like better facilitationwould definitely be called for
in a meeting.
Like especiallyin your first one.
'cause it, it's gonna seemlike a finger pointing game,
especially if youhave high level
executive running the meeting oflike, why did we lose X, Y, Z?
I would think a mature salesteam will be beyond this
kind of stuff.

(07:44):
They want all the help thatthey can get.

Om (07:45):
I'd like to think that, but I haven't seen that very often.
That's the downside to it.
It's, I've onlyever seen it when
executives call to action thesepeople and say, why did we lose
this multimillion dollar deal?
Far better for sales and productto get together
and hold this and invite them inas stakeholders.
You say we're gonna do anhonest deep dive.
To figure out whatwent wrong here so that we can

(08:06):
learn from it andnot repeat this.
And I'd like to think thatexecutives would welcome that.

Brian (08:11):
I've got a part two couple
questions here.
You know, what did the customerssay 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 youmight be able to do in surveys,
stuff like that.
You know, what dowe need to change for next time?
This is if you don't have aframework specific
to your company or your product.
These are just some questionsthat I would start
with open-endedkind of questions to start with.

Om (08:31):
Yeah.
Just be mindful that when you gointo something like this, it's
easy to just havediscussions and then just leave
the meeting.
You need to have actionable,you know?
The outcome shouldbe actionable, is what I'm
trying to say.
Mm-hmm.
So that you actually don't endup repeating the
same things again.
Mm-hmm that's theidea behind it.

Brian (08:47):
And then, the last one here is end with a
specific productor sales process
change or, or youdon't even need to be a process
change, but something that youwill do separately
the next time.
So like, even if you have salesand product in the room and
we're all holdinghands now, that's
what I'm saying.
Oh, it's, it's weird.
Don't dig into it.
Then there are other problems.

(09:07):
This section was about gettingproduct and sales in the room.
So I'm interested if anybodylistening has climbed this
mountain, is what I'm asking.
So let us know in the commentsif you have.

Om (09:17):
And while you're there, please like, and subscribe.

Brian (09:19):
Yes, yes.
But the next section I wantto talk about is even if you
get sales and product in theroom there is a bigger problem
and that's, nobody wantsto talk about customer churn.

Om (09:29):
Customer churn is really seen upon as a. Big
failure, we've lost customersthat's a different
question than whydid we not gain a new customer?
Right?
Because you already had thiscustomer that you've lost or
these customers in a worstcase scenario.
So that tends tobe a little more
burning, I guess.
And so people areresistant to it.

Brian (09:49):
Yeah.
Let's talk about that meeting.
That doesn't happen.
The customer churn review.
. Boy, you can havethe best features
in the world andyou can have great
marketing, you can have greateverything else.
boy, if you got the, the hole inthat boat, that
leaky hole in thatboat just keeps getting bigger
it's like, it doesn't matterhow fast you sh
shovel water out,you shovel water out, you bail
water out, right?

Om (10:06):
Yeah.
You kind of try and do thebest you can.
Yes, that's right.
The bare hands.

Brian (10:10):
Oh boy.
Churn.
This is the, I need theSpider-Man meme right now about
who's responsible for churn.
Everyone blames each other ahundred percent.

Om (10:18):
So this is the one, use the, the hole in the boat analogy.
This is where I envision producton one end of the boat, sails on
the other end, and they're bothpointing fingers at each other
and going, but the holes on yourside, yeah, it doesn't matter.
That's right.
The boat's going down.
So why are some ofthe, what are some
of the reasons whythe meeting that should happen?
Never oh boy.

(10:39):
I mean, you gotta scratch thata little bit and just say,

Brian (10:42):
I mean, nobody wants to be the one with their the finger
pointing at and saying it's yourfault, you know?

Om (10:47):
Yeah.
That's very true.
And even if the meeting sortahappens, right?
It gets over veryquickly by people
just placating oneanother saying,
well, we lost thatsale because of the customer's
budget or whatever so it's, whatI'm saying is, on
the surface you could PPO thesethings or you could really deep
dive to learn.
Yeah.
If you just sayit was because of
customer's budget.

(11:08):
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 thatyou're asking for your product?
Mm-hmm.
Or what could youdo differently?
Right.
Maybe you can segmentize yourproducts where you offer fewer
features for lesser amountof money,

Brian (11:23):
yeah.
Well, you're making thesteel main case right now.
So I went aheadand put it on the
screen here for you what I thinkI heard was you making the case
that customers are leaving forbudgetary 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 (11:39):
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 theysee value, right.
You could negotiate onthe budget.
But everything's negotiable.

Brian (11:49):
Yeah.
and of course the other one hereis that well, if
we had a review.
For churn, it would just be abig witch hunt.
Oh.
We'd be attacking development.
We'd be attackingthe bling game.
Yeah.
Product, whoever.
whomever.
Whomever.
That's right.
Those are two solid points.
I don't want to be blamed Idon't know, man.
So budgetary, let's startwith budgetary.

(12:10):
Yeah.
Like the budgetis just there and
like they didn't have budget,they got funding
cut or whatever.
Their company's not doing greator whatever.
So what that means, what I hearin product when I
hear that is likethe 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.

(12:31):
So, so like unanimouslybelieved.
By the customer.
That that's what I hear.
There, there was doubt.
I've been in like a B2C type ofthing where like a buyer bought
the software for acustomer at their company to use
and the companyemployees are like
this, I don't wantto use more tools.
They were never bought into it.

(12:51):
It's just somebody got excited,bought a thing and, customers
were never on board so like thatkind of situation,
like they, that kind of thing Iwould expect to come out when
like, well they bought it thisyear and then at
renewal time theywent in and like,
nobody's using it.
Well how did you go a whole yearin a renewal or
whatever it is whydid it take this long telemetry,
basically, or whatever itmight be, right?

(13:12):
There's a failure there first ofall, why would your salespeople
sell to a company that doesn'twant your stuff?
Like right.
Why are we chasingthose leads over other leads?
There's a lot tobe brought, like
you would think, the category wejust talked about with the, like
the after action of like, howcome we didn't make the sale?
This is the same meeting, butit's how come we didn't retain

(13:32):
this customer?
Again, you can, you can have abig sales team and go out and
get customers and have you'dbe like, Amazon Warehouse people
get 150% turnover in a year withyour customers.
Yeah.
Where they just keep leakingout the boat.
As soon as you get'em in, they just
fall right out andyou, and you're not even paying
attention to why.
The other side of that is youget a customer and you re retain

(13:52):
them for a long, long, long time'cause they're really happy.
But you would never know ifyou don't do any kind of.
Introspection, retrospection,yeah.
Inspection, all of that.
De detection if inflection.
Sorry.
You

Om (14:07):
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 isthis kind of a retrospective
isn't just a quick 15, 20 minutemeeting or half hour meeting.
Mm-hmm.
If, if you're doing it justice,you really need
to go into it, puta receptacle out
by the door, ask people to checkin their egos before they walk
into the room, andreally honestly, try and figure

(14:28):
out what happened.

Brian (14:30):
Right.
We do have a, wehave some slides of the takeaway
for this one.
So I think, let's see what wehave for process for this later.
I wanna move on to the otherpoint that we have written here.
I think that a better versionof this would be part business
development, partcustomer solution,
customer service part sales, youknow what I mean?

(14:50):
Part product roadmap.
So like, it's allthat rolled into
one to say like, before somebodychurn out, we should be doing
like a business developmentreview, even if it's only
internally to see where thatcustomer's trending and
not just for

Om (15:02):
customer service is a great source of information.

Brian (15:05):
Yeah.
I mean, I hate to say it, I'venot seen this be a normal thing.

Om (15:10):
I haven't either.
I've seen some fickle attemptsat it, but really
nothing serious.

Brian (15:15):
Fickle attempts because you wanna sell them something
else, is what I've seen.
Exactly.

Speaker 3 (15:19):
Yeah.
Yeah.
Yeah.

Brian (15:21):
And then the witch hunt, the point, the
point about fingerpointing, right.
in the steelman I'll agree thatthat one's valid
and a good point.
But only from the perspectiveof, yeah, if you
have no framework or process orfacilitator, then make sure
these things stayon rails right.
Yes, I agree withthat, but why are you going into
a meeting where everyone's justcoming in and throwing fruit at

(15:41):
each other with no framework,no agenda, no nothing.
that can't be the way these runthat of course they're gonna
break down if you don't have anykind of framework.
Or good facilitator.

Om (15:50):
Yeah.
But a lot of the times, thosecompanies that are
actually even aredoing this sort of retrospective
and those meetings devolve intosomething like this, they become
blame games.

Brian (15:59):
And then obviously where I'm going with the business
development roadmap is thatyour roadmap, your
product roadmap,like the customer leaving is a
reflection of yourproduct roadmap.
Months ago, likethings you could
have dealt with ifyou were on top of
your BD game, toolate by the time
that this happens.
So if you're afraid to ask whyyour customers are leaving, then
you're afraid of admitting thatyour product strategy is

(16:23):
it's not based on evidence, iswhat I'm saying.

Om (16:25):
Yes.

Brian (16:26):
So let's see.
We had a littlebit of a framework here to try
to recommend.
you need some structure.
If you're actually gonna try tohave a no blame churn review you
need some kind ofexit interview.
It needs to be as close to thecustomer churning as possible.
If you're in B2C, I see peopledoing this with the surveys when
people don't renew or whatever.
a lot of companiesalso try to bring back recently

(16:47):
canceled folks with steepdiscounts and stuff like that.
I don't have anykind of statistics
about how long that lasts, butthere's tactics for that kind of
stuff as well.

Om (16:56):
Service impose are very good tools for sure.
And then asking open-endedquestions like what, what would
it take right forus to retain you
for another year?
And then you really try tounderstand some
of the pain pointsthat were glossed over, perhaps
when even when the customer toldyou that they weren't renewing
But when you're asking thesequestions now you are basically
saying, well, youname your price.
And we'll see if we can meetsomewhere in that region.

Brian (17:18):
Which is funny 'cause it's exactly what
you do when they onboard for thefirst time so the
pattern analysishere, you should be reviewing
all of your churn metrics.
I think quarterlyis way too long, personally.
But I would be reviewing allyour stuff at a minimum, at
your quarterly strategic review.
whenever you do that withthe higher ups, you say, Hey,

(17:39):
these customers are at risk.
These people don't really usethe 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 ofusage and stuff like that.
Again, you're just having aBD conversation here, right?
You're not having a fingerpointing or any kind of that
kind of stuff.
Although I could completely see.
Just from my experience, I cancompletely see it being used as
like a Brian's telling us whatto do Brian's at it again,

(18:03):
here he goes,

Om (18:05):
this is the danger.
Right?
So then the, the team'sdevolve into not doing these
things, right?

Brian (18:11):
Again, sometimes, just because I said it, oh no, I'm
said it, this is getting tooreal for me.
And then let'ssee, and then the,
the adjusting yourproduct roadmap based on those
churn patterns is definitelysomething that you should do.
I mean you know, if, if, if youhave like the, the evidence
from the peoplechurning of things
that you didn't do as opposedto like the evidence of the

(18:33):
new features orthe new customers
or whatever, we talk a lot aboutdiscovery of like trying to win
a new customer, trying to bringin a new market or whatever.
But again, like all that waterthat you're bailing out the
boat because these people areleaving, like is that worth more
than the people you're tryingto bring on?
So the, these are just not likemodern product management and
especially thepodcasts and stuff that I listen

(18:53):
to, the product management andYouTube videos and
stuff like that.
They don't talk about thiskind of stuff.

Speaker 3 (18:57):
That's right.

Brian (18:57):
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 (19:05):
takeaway is if you're not retro expecting, then you're not
doing it right?
Yeah.

Brian (19:09):
Yeah.
Well, so the, we gave tworetrospecting retro expecting.
It's, that's like the, it's likewith pick axi, we gave two,, one
was retrofittingwhy you lost deals
and the second one was why youlost customers
after you made thedeal with them la
later on, renewaltime and stuff.
'cause that's churn.
So there's, we gave you twodifferent things to look at and

(19:29):
said, Hey, you need to be here,here's some very
loose frameworksto help you start retrospecting.
So what do you think aboutthis category?
What's your experiencewith churn?
We'd like to know,so let us know in the comments.
Absolutely.
Okay, so now we've covered lostdeals and churn customers, but
there's another conversation andthat's gonna be a
tough one for mostpeople to have, which is whoever

(19:51):
makes the bets in your company.
Executives productwho, whomever who.
So, yes.
Holding them accountable fortheir for their predictions.
I'll call them predictions.
So, i've got a radical idea.
This is a, Ooh,

Om (20:05):
I like radicals.

Brian (20:06):
Radical because it gets you fired.
But let's ignorethat for a second and say, let's
say we actuallygo back and check
whether these big strategic betsthat executives come up with,
and they had go to a big offsiteand they come back and say,
we're doing this.
Now we're going in this boldnew direction.
And what if we compared theirpredictions to reality on a
regular basis to ask Hey, whatcould we have done in this

(20:30):
time period?
And where would that have leftus as a business?
And I mean, that it soundsreasonable.
It, it sounds like something youwould do with a very, very, very
small business youknow what we is
this why we can'thave nice things?
Yeah.

Om (20:43):
So these opportunity costs discussions don't
happen very oftenif they happen at
all, especially because peoplethat have, turn up at the table
to make those bets, or at leastmultiple levels above your pay
grade, right?
That doesn't mean that theyshouldn't welcome a conversation
around that because they'rebetting the company's money
on here, betting the farm, or atleast a little

(21:04):
patch of the farm.
So yeah, they should welcomethis conversation,
depending, again,this is where do they have egos?
Because if they do, they'renot 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 machineand start grinding away.
But really as a company you'renot gonna get anywhere if you're

(21:26):
not accountablefor your actions.
Those same executives areholding 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 ofthe conversation.
It is not the CEO.
Because these executivesare experts at spinning the
story and pivoted the blame onsomeone else.

Brian (21:47):
CR podcast about changing the
message arguing Agile 2 35.
That's right.

Om (21:52):
Twisting the message.
So this is a case where I, Iencourage if you
have any kind of,especially if you
have any kind ofevidence, right?
Just go and approach thissubtly and say, we did this.
We expected X to happen, but yhappened instead.
Well, don't use the wordyou against the
executives unless you're reallyclose to the revolving door.
Or it will put you there.

(22:13):
So just say, look, we expectsomething 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 notdoing that.

Brian (22:25):
I simultaneously want to disagree
with you and say most executivesegos and also product leaders
there he goes, made outta glass.
And that's just not a thing thatyou could do.
But also I'm in this positionwhere I want to throw out the
steelman side of the argument.
So it's very strange toimmediately be saying you
can't do this.
But most companies, Ithink what they will give you,
like the pointsthat they'll give you is they'll

(22:46):
say a couple things though.
First I expect the first thingthey'll say is like, my time's
better spent trying to get usto figure it out.
You know, it doesn't matterhow we got here, doesn't
matter whose fault or whoseideas it was.
Yeah, let's just move on.
We, we said thisas an excuse in a
previous category as well aslike, Hey buddy, get like, this
sounds a lot likedeflection now the
more I'm saying it you know, heyyou know, that's just a waste of

(23:08):
time and we can our, it's, it'stime to double down on finding
new customers andlet's not worry about, well this
water's coming into the boatthrough these holes day that I
told you not tofix six miles ago.
I told you not to fix it whenwe were still offshore and
now we're in the deep sea and

Om (23:24):
those are nautical miles, but who cares?
That's right.
Wet anyway.
That's right.
Yeah, I agree.
it sounds like deflectionlaced with avoidance right.
So yeah, absolutely agree.

Brian (23:33):
Like you know, the market changes so fast.
That you know, six months we'llbe outta this, or three months
we, one more customer willbe outta this.
What does it matter?

Speaker 3 (23:42):
Yeah.

Om (23:42):
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 anyofficial bank, we'd rather work
on this other thing They'revery good, they're spin masters.

Brian (23:56):
Yeah.
You know, I hateto promote Amazon in any way,
shape or form.
You know,'cause Amazon isquickly revealing themselves to
also much like Palantir to bea very skillful, evil technology
company.
But it's like thesix pager concept
of like, well, youwrite down, like
you put your nameon the paper, you
are the author, you write down.
Your beliefs andyour concepts and your research.
Then you turn it in and in orderto move forward in an initiative

(24:18):
from scratch, likeif there's not even that level
of like a one pager, let alonea well researched six pager,
I have been in companies thatnothing gets written down and
there's no product management.
Just the executives spoutoff whatever shower thought
they came up withthat day, come in,
and then by the end of the day,they've forgotten what it was.

(24:40):
They come in thenext day and say,
why is everyone working on that?
I never said to do whatever.
it's not like they're notschizophrenic.

Om (24:48):
No, they're,

Brian (24:48):
but they just, they're just the, the pace at their
level is as such that they justcan't remember.

Om (24:55):
Yeah.
Yeah.
They avoid writingdown stuff because it creates an
indelible record of damningevidence.
So you don't do that.
Because you never said it.
If you did, maybeyou misheard so
there's all thesethings that they use kind of to
you that's put thewhole thing that's gaslighting.
Oh, it is, it's gaslighting.
Absolutely.
Somebody else mayhave said that.
That's definitelygaslighting, so
what, what do you,what can you, so

(25:16):
what's another, doyou have any more on the, on the
steelman side ordo we move over?

Brian (25:20):
do I need anymore?
No, I think I rest my case,your Honor.

Om (25:22):
Okay.
Well, exhibit one rapid marketchanges is, is often kind of
doubted as, oh, we have to worryabout, we don't have time for
all that stuff.
'cause which isn't the nextthing, right?
Yeah, that's great.
The problem is it masksaccountability well, at
various levels

Brian (25:39):
in mass accountability.
The, as the product manager,my job is you discovery, the
market discovery and userdiscovery, market research, user
research, that research needsto 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 writingthings down.
We have to be putting ourexperiments on paper somewhere.

(26:00):
And if you're gonna come inand say, I don't
need any of yourexperiments, just
do x, y, z, likethe, whatever the
scoring rubric isthat we all get
judged by, you'rebasically coming
into the fightingring and saying like, I don't
need to train.
Like I can just knock it out.
One punch, no training.

Om (26:17):
You're right about documenting or writing
down stuff if you want to beevidence driven or data driven.
Yeah.
Because otherwise it's someone'sopinion against someone else's
opinion.

Brian (26:24):
That's, I mean, there's no other way to calibrate
your prediction mechanismfor business other than.
User research, market research.

Om (26:33):
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 andyou'll still keep selling
those things Or whatever, . Butyeah, I agree.
Evidence-based is the way togo, and the only way to do that
is to write downnumbers don't lie.
So sometimes they don't lie.

Brian (26:49):
So I don't think it's a huge step.
If we back up, typicalcompanies, let
product management do this.
Say, oh, you got an idea.
Just bring into productmanagement.
They just shuffleit off on product
management, which this could beanother podcast by
the way, is like, Hey, managingall the ideas.
Like what, what if you havelike a lot of stakeholders that
have good ideas.
A lot of people just shove thestuff off on the
product management and say, justgo talk to the product manager.
And then the product managerssay, well, we're overwhelmed

(27:11):
because the executives bringus this and the
employees bring usthis and customers bring us this
and we don't knowwho to serve and
what to work on.
Because you don'thave a framework
for like, quickly, researchingtesting ideas or
having the peoplebringing you the ideas, help in
the research andtesting, thereby contributing to
that machine of idea testing adeep bucket of users, bucket

(27:34):
of users.
Why am I, why arethey 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 nauticaltheme today.
What?
It's aquatic themedpodcast today.
They're not you know, if youdon't have a set of users to go
back to who are your test users?
how do you get ahold, how doyou incent them?
Whatever.
Then you're reallystarting from ski.
I mean, it's no wonder you don'tknow how to do
any of this stuff.
Exactly.
You have no framework.

(27:55):
Modeling through.
Yeah.
That's what you're doing.
So, I mean, good luck forthat while the luck is good,

Speaker 3 (27:59):
right?
Yeah.

Brian (28:00):
Yeah.
I mean, the beststrategies here, like they're
actively tracking predictionaccuracy.
If people are helping testideas, now you've
got all kinds ofmetrics that you
previously didn't have about whocomes up with what
idea and which one's tracked.
Directly to revenue generatingideas or customer satisfaction,
elevating ideas, customerdelight, you can track that.

Om (28:21):
Whatever your success metrics are.
Yeah, absolutely.
And those kinds of prediction,initiatives, they get better
over time.
'cause you get toimprove your craft
as you go forward

Brian (28:30):
you know, that's interesting.
Interesting because likenobody does it.
That's the takeaway here, that we're talking about is
building some kindof prediction, accountability.
. It's called ExecutivePrediction Accountability
System.
But it doesn't have to belike that.
It's just, just ideas, right.
Accountability tracker ofsome sort that shows like the
benefits from the ideas when youcan show them.
And like a, a wayto do this, number

(28:51):
one is to createa log to actually
write the ideas down somewhere.
Right.
, And then obviouslyyou have to figure
out how to, howto test it in the market, how to
measure them afterthe fact, that kind of stuff.
Figure out what features spawnedfrom them.
I don't think that this is toooutta line to just
say, Hey let me figure out whereto write my ideas.
And the ones thatget used get spun
up into a ticket in whatever aLM tool you use.

(29:12):
I mean, might bea good a LM tool might be Jira.

Om (29:16):
Yeah.
There's many ways totactically handle these ideas.
They could also just bestraight into your LM tools.
They're not things that teamsare working on.
Right.
But they're being vetted untilsomething comes through and then
it hops over intobecoming a feature or whatever.

Brian (29:30):
And then the reality check side of this
is you revisit these revisit.
I mean, I don't know if aquarterly is too long to revisit
these pools.
I mean, they're large pools ofideas, so I don't
think quarterly is, I mean, ifyou don't have a better cadence
than this, you don't have afaster cadence of ideas, or if
you're doing it for the firsttime, quarterly
is probably okay.

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

. Brian (29:53):
Oh, oh.
And then the last part is thatyou know, you're tracking some
metrics over time.
You know, it's which ones dowe get right versus which ones
we get wrong.
They probably won't be measuringRight, wrong.
'cause some ideas will panout into other ideas degrees.
But you know, just somethinglike that.
So that, that's just a smalltakeaway that you
might go back toyour workplace and
try track ideas.
And where do thoseideas lead to?

(30:13):
They lead to features,they lead to improvements that
customers like.
Do they lead to more money?
Do they lead toclosing of sales?
Who knows?
But if you're not tracking wherethey came from
then the executive that rolls inwith the shower thought that he
had in the middle of the night Imean, he's just as right as your
most researched product manager.

Om (30:31):
Absolutely.
that's scary.

Brian (30:33):
Have you had an idea in the shower and then spent
six months of development timeworking on it?

Om (30:37):
An executive who never reviews their predictions isn't
a strategist, they're justsomeone with opinions and a
bigger salary.

Brian (30:45):
Oh boy.

Om (30:46):
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 thinkabout this topic down in the
comments below.

Brian (30:56):
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'recoming to the end of the podcast
when we're talking aboutorganizational structure.
Organizational structurethat prevents learning in the
first place.
So that's what we're talkingabout now.
So if you wanna know why yourcompany never learns from missed
opportunities, arguably itmight be a culture problem.

(31:18):
I would argue it's a structuralproblem in the organization.
When sales, product, customersupport or customer success,
when they report to differentexecutives and they all have
their own OKRs andtheir own silos.
I just don't see, like whatwe talked about earlier in
the podcast is just getting across-functional
team together andtalking about why
we failed and whatwe can do better.
I see that beingmuch, much harder

(31:40):
now that we've gotall these games

Speaker 3 (31:41):
going on.

Om (31:42):
so one of the difficulties of having cross-functional
organization teams is itimpedes expertise
and efficiency.
That's the steelman argumentright there functional
specialization creates expertiseand efficiency creates and
promotes it.

Brian (31:58):
I mean, I know that's the argument, but I mean, yeah,
that's kind of a weak sauceargument I think.
Definitely I think there's

a whole book (32:06):
Team Topologies about this.

Om (32:08):
We did a podcast on that.

Brian (32:09):
Yeah, we did.
We did a podcaston team Topologies called Team
Topologies OrganizingBusiness and Technology Teams
for Fast Flow by Manuel Pius andthe other guy, it was arguing
Agile 67 6 7, arguing Agile.
Six seven.
That's right.
Kids.

Om (32:24):
Wow.
Six seven.
That's right.
Kids,

Brian (32:26):
hang, hang on, if we do retrospective every time, om
will have all these differentteams doing their own
retrospectives.
And then we gotta docross-functional retrospectives
and then we gotta do executiveretrospectives.
What would all these meetingsom, that's meeting overload.

Om (32:38):
Meeting overload something.
So then we're admitting we'rejust too busy to improve.

Brian (32:45):
Oh, I thought you were gonna say, too busy to fail.
Too

Om (32:47):
No, you're not too busy to fail.
You're failing all the time.

Brian (32:50):
It's like too big to fail.
Only with, yeah,too big to fail.
Minus the federal government.
That's

Om (32:54):
right

Speaker 3 (32:54):
yeah,

Om (32:54):
We're too busy to improve.

Brian (32:56):
Functional specification creates expertise
and efficiency.
That, I mean, that, thatfunctional expertise one like
that, boy, thatone I, I've a lot,
I've heard a lotof people rattle that Sabre of
that oh, we gottahave all the DBAs
over here and we gotta have allthe programmers that are backend
over here, and all the front endpeople over here.
Like, we can't have anybody talkto each other how, how dare you?

(33:18):
I'm surprised thatthis management
model, that that'swhat I, that's
what it really is.
I'm surprised it still persists.

Om (33:24):
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 slicethem 30 times.
'cause 15 into one doesn't go.
So functional silos on thesurface looks like they optimize
efficiency at a local level.
Right, but at a macrolevel, right.

(33:46):
Do they

Brian (33:46):
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 likeeverybody in the world should
listen to it.
We did arguing Agile 1 99 wEdwards Deming,
profound Knowledgefor transforming organizations.
I mean, it's a quick whatever,hour and a half.

Om (34:05):
Almost two hours, I think.

Brian (34:06):
It's an hour 53.
Yeah.
Almost two hoursarguing as a 1 99.
You can hear all about the gamesthat people play
and how to destroy a system andlike it, he wrote
the book on that almost 50 yearsago at this point yeah, it, I'm,
again, that's why I say I'mamazed that this stuff is still
like, brought up and promoted.
Like it was the, the newest,hottest thing, like a forward

(34:27):
deployed software engineerit's, which is the newest,
hottest thing.
It's new, it's newest, hottestthing that's like
completely not newat all it's just
nobody remembers pep Pepper.
Strong remembers.
So yes, if you'replaying games and
you don't consideranyone else's work
and you're onlyscored on your own
goals, we're notplaying as a team.
We only hit goals ourselves.
Yeah.
Then, yeah, I guess it's apoint, but I, I don't know.

(34:48):
It's not a good point.
That's what I'm saying.

Om (34:50):
You as an organization are not a learning organization
at that.
Right, because you're notlearning, you're not doing that
perspective.
You're not learning by doingcross-functional look backs and
understand how you can improvetogether as opposed to locally
individual silos.

Brian (35:06):
And also there's so many games here, that's
all I can thinkof is I can't move
my brain past all the games thatplay when you're in those silos.
I had a CTO come to me onetime and say, Brian, you just
gotta keep these developers busywith enough work.
I'm like, what areyou talking about?
Busy with enough work I wouldrather have every single
developer in the organizationtrying to solve our top problem

(35:28):
and like sittingover each other,
looking over the shoulder at thelaptop of one single person,
pitching ideas.
Because like, I don't, I can'texplain to the CEO why a
single develop.
Is not working onour top problem that's not a
conversation that he willhave any kind of grace about.
You know, he'll say we have aproblem what if there's a blow

(35:48):
up in production?
Right?
Like, oh, I'm not fixingthe blow up.
I'm over here workingon widgets.
Why are you doing that?
There's customers down.

Om (35:55):
Yeah.
Well the flip sideof that from the
executives would be, well, why?
You have multiplepeople working on
the same problem.

Brian (36:02):
Yeah, yeah.
I have worked forand spoken with both of those
types of people.
Yes, yes.
But you knows, I think thelearnings that come from solving
problems or at least being inthe room when those kinds of
critical problems are solved andknowing that you're working
on the most important thing,I don't know.
That's a tough discussionto have.

Om (36:21):
it is a tough discussion and sometimes executives will.
Relent a little and say, well,you can have your
team retrospective and they canhave theirs.
And they can have theirs so atthat point, all you're doing is
checking a box.

Speaker 4 (36:32):
Yeah.

Om (36:32):
I think that's pretty much it,

Brian (36:33):
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 theyclearly make the sanction and
they don't care how many or howfew people are working on it.
Right?
Like those peopleeat your lunch.
Then go buy another lunchand eat that one

(36:54):
while you're stillsitting trying to figure out
the first one.
So you know, they'reoutperforming you
left and right.

Om (36:59):
Yeah.
At the end of the day, whatare you prizing?
Like, what are you measuring?
Are you measuring reducing paintfor your customers
in the shortest possible time orare you saying we're just
gonna look for efficienciesor utilization of individuals
or however?
Right.
So it comes down to that.

Brian (37:15):
And also you can measure yourself right outta my
office with thatattitude is what I Absolutely.
So like the takeaways hereare very similar to our previous
takeaways where you're if you'venever had a cross-functional,
if you have a lotof silos you wanna pull together
some kind of cross-functionalretro for hopefully a
semi-serious reason.

(37:36):
So you're gonna actuallypull together learnings that.
You can pull together learningsas a group that any one silo
would not be able to come toon their own.

Om (37:44):
And these don't have to be very structured or formal.
They can just besort of like root
cause analysis foranything mm-hmm.
That you're experiencingas a, as an organization.
Right.
Get the right people togetherand go to task.

Brian (37:57):
Yeah.
And it doesn't have to be thesame people every time as well.
Course not.
Yeah.
I mean, in productit could be an analysis of what
opportunities did we passgoing back to the
category we talkedabout earlier.
Yeah.
What do we pass on?
And now what doesthat opportunity look like in
retrospect if wehad worked on it?
And maybe it's like nothingobviously you wanna have some
kind of rigor to where you pickthose ideas.

(38:20):
You don't want to be pickingsoftballs.
yeah, sure.
But yeah, I mean that's one.
Hopefully the executives areinvolved in this.
I mean, hopefully you have anexecutive sponsor.
I would think that you're doingsomething like
this, some sort ofcross-functional learning
opportunity.
You probably dohave an executive
sponsor that you have some sortof horsepower from the top.
This is like every agiletransformation.
You've get thatone person on the exec that says

(38:41):
like, Hmm, we should be learningfrom our failures over here.
And everyone looks at thembegrudgingly and
says, Hmm, fine.
You can have this personfor 30 minutes.

Om (38:51):
Alright, so if you've had experiences where multiple teams
came together to find what wentwrong, et cetera, let us know.
Let us know.
Anyway, what youthink about this
particular subject down in thecomments below.

Brian (39:04):
So we talked about diagnosing structural
problems and now om it's time onthe 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 andbreak the law.
It's, it's time.
It's time, it'stime to move fast
and break things.
That's what it is.
Move fast and break things.
It's, it's the rallyingcry of modern tech companies
Move fast and break things,especially in silly con valleys.

(39:28):
Silly con.
They're so silly.

Om (39:29):
Silly with a dash Oh between silly and con.

Brian (39:32):
But say, here's what nobody's gonna tell you.
That's right.
Nobody, nobody in the wholeworld, . When you
move fast withoutstopping to learn
what you broke, as you're movingfast and breaking things, then
you're, you're just, you're justthe, what was the,
what was the thecartoon character
that spun around a Tasmanianthen you're the Tasmanian Devil.
Yeah.
Then you're the Tasmanian Devil.
You just spinningaround, breaking things at

(39:54):
increasing speed.

Om (39:55):
You're, you're breaking things at higher speed
all the time.
All right.
Well, good luck keepingthat funded, because that's
gonna run dry pretty quickly.

Brian (40:02):
We're funding Tasmanian devils.

Om (40:03):
I mean, look, this, this sort
of thing you wouldthink through just
natural evolution would weeditself out pretty
quickly because who'd wanna fundthat sort of thing for any
period of time.
But these are theexecutives that
just hop over ontothe onto greener
pastures and spinup new teams that
keep thrashing.
'cause that's whatthis is expensive.
Th trash.
You go around in circles or.
Ellipses and you never come outof the orbits.

Brian (40:24):
I mean, hey, I love a good steel man.
And now's the time.
Like I wanna actually use thesteel man logo at some point
in the podcast.
So here , speed.
Not the movie speed, not KeanuReese, not that.
Yeah.
Yeah.
Not, no, we're not, we're noton any buses.
They're not going to under 50miles an hour or whatever it is.
Speed itself creates competitiveadvantage.
And if you're not sure aboutthat, I got every AI vendor in

(40:46):
the world, every AI tool wrapperin the world trying to sell
you a product that's saying.
Speed will fix all of youridea problems.
If speed will fix your, allof your problems spiritually,.

Om (40:59):
Categorically, spiritually, metaphysically speed will fix
all your listen.
It sounds ridiculous to sayit out loud, but
I mean that's whatthey're pedaling
this Absolutely.
And have been formonths, months and
months and months.
Everything you guys aretalking about in this podcast.
That's just bureaucracy.
You're you're killing mymomentum.
you're crushing my vibe, man.

(41:20):
Yeah.
You're adding latency.
That's very true.
I'm vibing, Be build it andthey'll come.
Yeah.
Good luck with that.
Good luck gettingthat funded too.

Brian (41:27):
All right.
Well, I didn'tsay they were good
steelman points, but the steelmen 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 steelman, I can't even
try to defend it.
I like, I can't even tryto defend it.
'cause it's like, it's a wholecareer fighting against like,
well speed becauseyou think it's the way to go.
Great.

(41:47):
And then if wemeet your deadline
that you made up, that was nevera deadline in the first place.
Like isn't this how like agilesoftware develop
was even born inthe first place?
It's like, we gotta have thisby this date.
And I just made up the date.
Anyway, look, it's, you're notlearning anything.
It's speed forthe sake of speed.
Somebody set the originaldeadline anyway., It's expensive

(42:09):
thrashing if you think about it,because we're gonna deliver,
we're gonna takesix months, eight months, nine
months, whatever.
You know, we're gonna deliversomething.
Customer's gonna hate it.
There'll be change requests.
Everyone's getting upset.
There's more money gettingpoured into it.
Margins are getting tighterand tighter.
This is, this islike the beginning of my career
development, like earlytwo thousands development.

Speaker 3 (42:28):
Yeah.

Brian (42:29):
Yeah.
And that's the way it was.
It wasn't really every week, butit felt like every
week there werenew deadlines and
there were just as ridiculous asthe last deadlines
and release day.
You were working super late.
It was this now, now you've got9, 9, 6 culture, now 9, 9 6

Om (42:45):
again.
Oh my goodness.
And you're gonna wash outsome really good people.
That's right.
In that same culture and so itsort of dilutes the whole thing
because you lose good people.
What happens?
you end up with people that arenot as good, but they're
still thrashingthen what happens?
fast forward another 90 days.

Brian (42:59):
I don't know.
You're gonna get people, I thinkyou're gonna get more nine, nine
Sixers in there that think thatwell, if you're not, if you're
not working 9, 9, 6, then youare the problem.
That's right.
You're not working hard enough.
That's right.
You just gotta get rid of thatpesky wife and kids, and you'll
be able to be 9, 9, 6 for life.
Oh boy.
I don't know where we're goingin this podcast, but I like it
you spent no time buildingfeedback loops.
You've spent no time buildinga culture that attracts

(43:20):
people that can learn fromtheir mistakes.
In fact, you'regoing the opposite direction.
You're building aculture of people
that deflect andblame basically.

Om (43:28):
Without using the word, but yeah.
Absolutely.

Brian (43:30):
Yeah.
So this one, the embeddinglearning in your organization.
if you're just moving fast andbreaking the law over here then
hey, maybe we can't help you.
But if you're moving fast andyour culture is one where you
think that you can't slow downbecause no one, you might get
blamed for slowingdown or you might get yelled at
for slowing down or whatever.
here's some stuff I'm showing onthe screen and some stuff here.
Some things you can try.
After a significantfailure, whatever

(43:52):
that failure is I'm calling itfailure, call it whatever
you want, right after any kindof significant incident, let's
say that it was, could bea lost deal.
Going back to the first sectionof the podcast.
Could be a production outage,which trust me, if you're
breaking fast, moving fast andbreaking things,
you're gonna have these outagesyou know, or miss
deadlines, whichall the deadlines a reminder.
All the deadlines arefake anyway, so

Om (44:11):
That's true.
All losing customers.

Brian (44:12):
That's true, that's true.
Any of these things.
So pick one of these and youknow, just have a quick, have
a quick call a quick retro onthe one problem.
One cause one action.
It's a little deviation inthe Mike Miller.
One, one problem will cause thatone action.
Yeah.
One, one.
Yeah.
Figure out what you can do.
What One action.
Are you going to take and youknow, what, how are you gonna
make it better?
What, what, whatwas the cause and
what, what action are you gonnatake away from it?

(44:33):
And then if you don't have alearning backlog,
so this is likethe technical debt
equivalent of whatare the things that we need to
learn around here?
Which I think of like everyoneshould have some sort of like AI
tools on this backlog rightnow of like, the team doesn't
know how to work with generativecode tools.
Maybe you don't have co-pilotor whatever.

(44:53):
Start figuring out how thatstuff works into your daily
working process.
simple stuff like that.
I mean, that's a simple example.
You can think of more complexexamples like better ways of
doing things and actuallydeprecating the way you were
doing things before in orderto learn better and faster ways.
And this is just ongoing,continuous forever
in the world ofthat, because you just should be
doing this anyway.
Except we don't think about itin terms of , our whole team is

(45:15):
going to be contributing todoing this at the same time,
pushing everyone'sskill level up.
But the category we're talkingabout this stuff directly,
conflicts of like,well we are, we are always just
like racing tothe next deadline.
There's no timeto take vacations,
there's no timefor retrospective,
there's no time toquestion whatever, you know?
Yeah.
There's no time for productmanagement.
There's no time for bathroombreaks.

Om (45:36):
Yeah.
Far off.
Yeah.
So I mean, some of this stuff isgoing to require
you to cut across organizationalstructure and silos, et cetera,
but try chipping away at it.
You'll be surprised.

Brian (45:47):
So, okay, I think if we're
gonna wrap up thispodcast with a, with a zinger,
it's gonna be, if you cannotarticulate what you could have
done instead, you didn't makea decision.
You just reacted and called ithis strategy in retrospect.
Which is not what we'retalking about retrospective.
That's not what we'retalking yeah.
In hindsight, yeah.
You kind of miss a point.
Yeah.
So, so most organizations theydon't, they don't

(46:09):
learn from missed opportunities.
'cause I don't think that theybelieve that they have missed
opportunities.

Om (46:13):
Even though they're hitting them in the face over there.

Brian (46:15):
So if anyone asks a question what, what could we
have done instead?
I think they're risking theircareer at that point,
that company.
So just keep thatresume updated.

Om (46:23):
Keep that resume updated folks.
But yeah, do let us know inthe comments below What
your experience has been.

Brian (46:27):
And if you can think about opportunities at
your work that you could havetaken but did not.
Like I'm also interested toknow if anyone actually has a
process that theyrevisit those on
any kind of basis.
Sure.
Yeah.
Because again, like most ofthe companies I've ever worked
at, revisiting a decision.
They'll say Ooh,Brian, oh, you're

(46:48):
pointing fingers.
Revisiting olddecisions, even if
there's evidence there, yeah.
So this was aninteresting topic.
It is.
I wanted to have this podcastfor a while.
We haven't beenable to get to it
'cause we had tonsof stuff that was
in front of it.
But yeah.
Learning from missedopportunities,
even understanding what missedopportunities there are
you know, so, yeah.
If you have any of those pleaselet us know in the
comments and also

Om (47:09):
like, and subscribe.

All Episodes

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

Episode Transcript

Popular Podcasts

Las Culturistas with Matt Rogers and Bowen Yang

Crime Junkie

The Brothers Ortiz

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}AA239 - Why Your Company Never Learns from Lost Deals (And How to Fix It)