# Product Strategy: Navigating Organizational Drift

**Podcast:** All Things Product with Teresa and Petra
**Published:** 2026-03-03

## Transcript

Hi folks, this is All Things Product with Petra Ville and Teresa Torres.
And we're so happy you're here.
Petra, I understand that you recently read an article about a book called Lost in the Woods, which already sounds fascinating.
I want to read that book.
Hopefully it's in English and not in German.
It's in English.
Or I can get it translated.
And it was literally about people getting lost in the woods, but you saw a lot of analogies to product teams.
And this resonates already because I see a lot of product teams lost in the woods.
So let's get into this.
Tell me a little bit about the article that you read or the book.
Yeah, actually, the book is called Lost Person Behavior.
The author is Robert Kester.
I don't know how you pronounce him properly.
I don't know if he's a German or or not, but in Germany it will be Robert Kester.
And what and he was rigging.
The book is all about how people get lost and how they can recover from that.
So how do they get back?
And literally when they're hiking, right?
How do they find back to the original path?
And it was super fascinating to read because while I was reading that, I thought about hey, there's so much, it has so much to do with how product teams sometimes get lost and how product organizations sometimes get lost, and where companies, entire companies sometimes get lost.
So I thought I'd bring this five things he was talking about, the different ways how one could react to getting lost, and then we see if we can find similarities and stories that we could share uh with our audience.
So that's that's that's my idea.
If you're ready, I share what he said people usually do if they get lost.
Are you ready?
Yeah, why don't we do one at a time?
Okay, we can yeah, but maybe then it's hard to find good examples, and the people are still like, what would be next?
Okay, but we can't we can try.
So the first one is, and that's usually what he describes kids are doing.
That's the tendency that kids are having when they get lost, is they settle in place.
So it's basically they do nothing, they realize that they got lost, and then they like the frightened rabbit, they just like stay where they are.
So is that something that you sometimes observe in product teams?
Uh yeah, quite you know what's funny is if I think about a kid being lost in the woods, that's probably not bad behavior.
No, it's a good idea.
Do you have an opinion on that?
Yeah, the thing is like you're just sort of capability to maybe basically orient themselves.
They know nothing about that the sun is basically shining from south or north, depending on the hemisphere you add, all these kinds of things.
They don't know any of that.
And it's basically what I teach my kids.
So if you get lost, especially in big cities, um, if it's something that is moving, you get off that and just wait for us to find you.
If the thing is not moving, so you're not on the subway, then you just like stay put, find another person that is a parent that have kids with them or something like that.
Ask for help, maybe.
But other than that, we we the adults are finding you.
It's not you trying to find the adults.
So that's basically what I advise my daughter to do.
Yeah.
Yeah, okay.
So let's do it announcing for product teams.
Yeah.
I think it can be.
So the timer I think this is good advice for a product team is almost if we use the kid analogy.
So we do have product teams that operate in environments where they don't have the business context.
There's no um, they're they're still kind of in an IT mindset.
They're literally told to build this exact thing.
Maybe they get evidence that that thing's not working, maybe something goes wrong, right?
They're lost with the thing they were told to do, but they haven't been equipped with anything to know how to compass.
Right?
Yeah.
And so in that situation, it's a little bit like you have to sit there and raise your hand and be like, I'm lost.
Right?
And so I would say that's analogous.
There are like some organizations don't equip their teams to get unlost, and so you probably should do nothing.
Yeah, and then it would be um kind of the the raising of hands would be then towards more experienced people on the team, more experienced leaders, maybe even an advisory board or something like that.
I think for a startup, it could be a good chance to talk to the advisory board and say, like, we're lost, basically.
I mean, a startup probably shouldn't have children teams.
Yeah, ideally not.
You never know.
But the thing is, I still think there is a lot of, especially for mommature organization, there is a lot of danger of doing nothing.
And but I see in particular, so in in the article, there was kind of this example from Xerox back in the days, or I think you and I could say Nokia or Kodak.
So all of them are kind of these examples of the market was changing.
It was obvious that the market was changing, but for whatever reason these organizations thought like it's not a big deal.
We'll we'll survive any anyhow, or the market share that we have will help us to kind of do that.
But those were organizational decisions, not team decisions.
Yeah, like Kodak did develop a digital camera.
The organization chose not to invest in it.
Yeah.
Right?
I agree.
And so I think like if we're looking at this at the team level, here's an example of where I think it would be fine for a team to do nothing other than raise the alarm.
So when I say do nothing, I just mean communicate what you're finding.
You're not in a position to fix it.
Let's say I see this a lot at really large organizations where they're um uh product teams are really IT teams.
They're not building their own software.
Maybe they're managing and configuring third-party software.
We see this a lot with Oracle installations, for example, right?
Indeed.
Right?
So they're working on a product, they don't build the product, they just configure and maintain the product.
They find something that's stuck that's not working.
They don't have the ability to say we can't use Oracle anymore.
They don't have the ability to tell or I mean they can tell Oracle we need this thing, but they can't make that thing happen.
Yeah, right?
And so, like, we don't want them to go wander off and try to start using SAP.
We don't want them to like pick a fight with Oracle and put that relationship at risk.
Like, like they could do harm by trying to solve it themselves.
Yeah.
So the right thing in that instance is probably like, no, really, you have to stop what you're doing and escalate.
Yeah.
Yeah, I like that.
Okay, so there is a difference.
If this tactic is helpful if you're a team or if you're an organization, I like that finding.
Yeah.
It's good.
Should we do the next one?
Let's do the next one.
Okay, next one is chasing shortcuts.
So a lot of people, if they lost in the woods, they're looking for shortcuts.
And in the Article wasn't super interesting um example where this was a big issue when a company decided that they think they can find a shortcut.
And it was actually a German company, which is Volkswagen.
And at some point, they really love some of their emissions vehicles.
And they decided to build a software that is basically giving false data of how much emission a certain vehicle was causing.
It was a big big thing here on the media, and it did cost the company to date more than 33 million just in penalties that they had to pay.
But they thought they were very confident that this shortcut is helpful.
So any other story that you can share where teams were trying shortcuts where it was not working, or were they trying shortcuts and it was working?
But wait, let's go back to the being lost in the woods.
What's an example of a shortcut?
And like when's it good and when's it bad?
Um in this article, or what I think in the article, like if you're literally lost in the woods, what did the article say?
Yeah, so the article did say that if you're used to the Tehran to some extent, then it is likely that you can think of a shortcut or can find a shortcut that is helpful.
In other cases, it usually is more a sign of overconfidence, and shortcuts are not leading you somewhere good.
Okay, so like I can think about I cross-country ski in backcountry area.
I've often had the thought of like, I know the road is over there, yeah.
Right?
I know the resort is over there.
Like I'm trying to keep landmarks in my head so that in the event there's an injury or I'm on my own or I get lost, I have like some sense of I can at least get to the road.
Yeah.
Is that would that be an example of a shortcut?
That's exactly.
That's exactly.
So you have an idea of where you want to end up, and then you know, okay, this is most likely to do it.
But the risk is my map of where the road is might be wrong.
Is wrong.
Exactly.
Okay.
Yeah.
Okay.
So the Volkswagen example feels a little different.
It feels like they just said it doesn't feel like they were going after the road and they and they picked the wrong direction, right?
So like I I want to think of an example of an organization that thought they were going in the right direction and they missed the mark.
Right.
And that's a little bit more.
Yeah.
Yeah.
So maybe you can.
So well, yeah, okay.
So here's what I think is interesting about this one is like you have a shortcut in mind.
Don't blindly follow the shortcut.
How do you test to make sure the road is where you think it is?
So, like an example that comes to mind.
Um, Spotify.
Spotify built their their business on music.
The challenge with music is that they pay license fees to the artists.
It's very it's a very low margin business.
And so they made a decision.
Let's go after let's go after podcasts.
Because podcasts maybe could be a higher margin business.
And so that's like the road is over there.
We're going after podcasts, right?
And so the question would be is podcasts a good strategy.
How do we test that?
How do we know the shortcut is getting us where we want to be?
Yeah, versus it's just heading us in the wrong further in the wrong direction.
Yeah, so that's that's a nice that's a nice example for testing if a shortcut is worth the shortcut, not the detour.
I was about to say detour, which is not true because you've you're looking for something shorter.
Yeah, I agree.
I like that.
Yeah.
Um, and basically every discovery, I think that's that's one thing that you want to look for in a discovery is can we find shortcuts to the things that we're actually trying to achieve?
And that's why this outcomes over outputs discussion is so important because engineering teams oftentimes can help you find these shortcuts that a product person was never even thinking about.
Um, yeah, so that's that's a good example for the shortcuts version.
Then next is my preferred error recovery technique when I'm getting lost.
And this is following the first visible path.
I think oftentimes this is combined with the shortcuts thing.
So in the article, I was talking about find a fence and then follow this fence, because the fence has lead to somewhere, maybe another fence, and then you follow that fence, and hopefully you get back into the civilization at some point.
Same is with streams or rivers, canals, um, all these kinds of things could help you to get to I don't know, a bigger intersection or something like that, and then you maybe can reorient yourself, or there is a sign telling you where you are.
So that's basically following the first visible path that you find.
Can you think of anything product related in there?
What would be a yeah?
I think this is good and bad.
Yeah.
Yeah.
So what comes to mind is my advice of comparing and contrasting.
So the problem I have with this one is the first visible path, right?
So, like, yeah, if the first visible path is a row of trees, but there's a fence, you're probably better following the fence than the row of trees.
Yeah, right.
Um, so I think what's interesting is like when you're genuinely lost, it may look like there's only one visible path.
Um, but there's probably more than one.
Um so I'm trying to think of if there's an instance where literally following the first visible path would be the right thing to do.
Yeah, no, it is hard.
So, but but what I was about to say and about to add, this is where all the mapping comes into play, right?
That's when opportunity solution trees and because the tree in itself inherently suggests that you have multiple roots kind of or multiple branches that you can follow.
So, or the KPI trees that I talk a lot about, they they kind of tree like structures as well.
So both of our work uh revolves a lot around this idea of not the first visible path, but first of all, make more paths visible and then decide to explore the path path to follow.
Yeah, exactly.
Yeah, yeah.
I just I just realized that as an adult human being, you would most likely combine some of these recovery techniques, right?
Because so you might have an idea of where to go direction-wise, and then if you see a fence lying into this direction, that might be the path that you pick.
Um, but that's maybe not the first one that you saw, but you know the direction or something like that.
Interesting.
There's another two, ready?
Yeah.
Using your own navigation.
So just like having this sense of Taoist North, that's where I wanted to go, and then following your own navigation, even if you deep into the woods.
And this is like intuition or like using stars.
No, I think this is more intuition.
Okay, so it sounded more like a random thing.
Yeah, this one concerns me, and it's actually like really trendy right now.
Everybody's talking about taste.
And like I just watched a video of a talk where a woman said we can let go of the design process because nothing great comes from the design process.
And it what bothered me about that is that um I think we're inter misinterpreting process.
Like she talked about like designers spend more time uh on the artifacts that are part of the design process rather than the design itself, in which case I would say that's a bastardization of the design process, because the point of the design process is to make the design better.
But I think there is a truth to this, like in large bureaucratic companies, we tend to focus on the process and not on the thing that we're building.
And I do think there is a craft involved in building, so I'm not suggesting that.
But I think we're swinging the pendulum too far.
We're hearing a lot of people talk about taste and product sense, and we can just follow our intuition.
And I think we can build our intuition for sure.
Yeah, product.
And I think our intuition product sense.
And I think it is a factor, and I think like good product people do have good product sense, but I don't think that means you just belind blindly decide this is north and I'm going north.
I think if you have a compass, you use your intuition and you use your compass.
Right?
Like exactly.
It's a mix of both.
Exactly.
Um I think right now, in this moment in time in the industry, we're we're swinging swinging the pendulum too far.
Like intuition matters, design sense matters, product sense matters, taste matters, um, but we also can be data-driven and customer-centric and combine all of those things.
And actually, it's use we have to use judgment.
That's where taste comes into play.
But our judgment should be applied to all those inputs, not just to I have no data, I'm gonna make on and use my opinion.
Like taste comes into play when we look at all these inputs and we make a judgment on it.
Yeah, right.
Yeah, exactly.
So if my compassion is a good thing.
Yeah, like if my compass tells me one thing, I love it, and the sun is going a different direction.
I gotta, I gotta reconcile those two things.
Yeah, agreed, because there's still too many product organizations operating on this whatever the product person's opinion is, or whatever sales is asking for.
And that's why we have all these you are not your user stickers on product people's um screens, I'd say.
Yeah.
Um and that's overconfidence sometimes in your own opinions, in your own taste, in your own, even in your own experience, because just because you learned a thing a year ago does not necessarily mean it still works today because the world is constantly changing, right?
So yeah, using your own flawed navigation is maybe flawed, I'd say.
Uh last one is before you move on, though, I would do want to highlight one thing.
Like I this is where I I think it's the answer is both.
So, like if I use literally the in the woods example, and I have a compass, and my compass is telling me that direction is south, but I literally see the sun setting in front of me.
Yes.
Now I have a depending on your hemisphere you're on, but yeah.
Right.
So yeah, so I have well still not setting in the south, regardless of your hemisphere, right?
So I reconsidered my so I have data that's conflicting with my own knowledge of the world and what I'm personally observing.
I have to make a decision.
How much do I trust my judgment versus how much do I trust this instrument?
Yeah, exactly.
And this happens a lot with product teams.
All the time.
Yeah.
Yeah, we get conflicting information all the time.
And so when we talk about sense and taste and intuition, yeah, I want to apply it to those judgments.
Yeah.
Not I'm gonna ignore the compass, I'm gonna ignore the setting sun.
I just feel like this way is West.
Yeah, exactly.
This is what I said.
As an adult, you would combine several of these data points and several of these tactics, maybe.
Um the last one is a simple one, Teresa.
Turning back to where you came from.
Yeah, retracing your steps.
Yeah, retracing your steps.
What about this one?
How do we like this one?
I'm trying to think of how this applies in product.
Do you have any product example for this one?
Yeah, I I do.
We just recorded this episode where this product person needs to deal with bug reporting uh instead of engineering taking care of it.
And I think this, for example, is to some extent a good example because for example, there is a bug coming up, and then there is another bug coming up, and then the bugs are starting to pile up.
And then it is not enough to continue to become better in bug fixing.
At some point, you need to basically stop the engine, pause for a moment, look at your quality assurance rules, regulations, and principles, and maybe consider reinforcing them in the first place.
Uh, and that's basically for me, that's that's that's kind of stepping back or turning back to a principle that was in place in the past, but somehow got lost or watered down or forgotten or something like that.
And I think that applies to basically all the product principles that a team could use.
It could be even company values or team values, all the stuff that is on posters.
Yeah, exactly.
All the stuff that you can do is away from our vision.
Speaking of posters, yeah, yeah.
Yeah.
So that's maybe.
Yeah, I like that.
Like even I could think about this in the context of an outcome.
Like we start doing work, we're iterating our way through, we're getting further and further away from our outcome.
Let's stop and take a step back and refocus.
Um this is something with the disc with the discovery habits.
We I often teach that um the next habit is a feedback loop on the previous habit.
So people ask me, like, how do I know I conducted good interviews?
Well, once you start opportunity mapping, if you didn't collect a good narrative, there's no structure for your opportunity space.
So that's feedback that you need to improve your interviews.
And like, how do I know I chose the right target opportunity?
Well, when you run assumption tests on your solutions, you get feedback on whether that problem was the right problem to solve.
And so there's a little bit of like you take a step forward, and that's your feedback loop that tells you you need to take a step back.
Yeah, I love it.
It's an in built-in feedback loop.
I love it.
Yeah.
It's good.
Yeah.
There was an experiment.
I like this.
The audience liked it.
Yeah, this is a fun article.
Yeah, yeah, I loved it.
That's why it resonates.
Can I go check out the book?
Yeah, you should maybe.
So thanks Teresa for bringing it up.
Thanks, Petra.