Published —
What Bear Grylls can teach us about product development
I have spent more time than I probably should thinking about what Bear Grylls and product development have in common.
Stay with me.
Bear is famous for being dropped somewhere deeply unpleasant with a knife, a piece of string and an alarming willingness to eat things most of us would carefully walk around.
His approach can roughly be summarised as:
Improvise. Adapt. Overcome.
Small disclaimer before Bear Grylls fans come after me: he didn't actually invent the phrase. It has its roots in military culture and was famously used in Heartbreak Ridge. But it fits his approach to survival so perfectly that we'll borrow it anyway.
Because behind all the drinking-from-socks and improvised rafts, there is a surprisingly useful way of thinking about uncertain situations.
Plan A rarely survives contact with reality
Bear can prepare before entering the wilderness. He can study the terrain, check the weather and pack some equipment.
Then he gets there: the river is higher than expected. The route is blocked. It starts raining. Something he planned doesn't work.
At that point he has two options:
Continue following the original plan because everyone agreed on it three months ago.
Or deal with reality.
Unsurprisingly, he usually chooses reality.
He has spoken about improvisation as one of the things he loves about survival: taking the few things available and figuring out how to use them creatively when circumstances demand it. He also puts enormous emphasis on adapting quickly and learning to deal with failure.
This is also a pretty good description of product development. In our field, we just tend to make it sound more complicated than it really is.
Products are built in the wilderness too
Obviously, building a new platform is not the same as being stranded in a jungle. There are generally fewer snakes.
But there is one important similarity: you don't know everything when you start.
You don't know exactly how people will use the product. You don't know whether the feature everyone loves in the workshop will make sense once somebody actually has to use it. You don't know whether users will understand the navigation, whether the business model works, whether the integration behaves as promised or whether the clever AI feature is actually useful.
You can make educated assumptions. But they're still assumptions.
This is why I like working in short loops:
Question. Idea. Prototype. Feedback. Decision.
Ask what you actually need to find out. Explore an idea and build just enough of it to make it tangible. Put the prototype in front of real people, watch what happens, and decide on that basis what to change, what to keep and what to test next.
And then you go around again, with a sharper assumption and a better understanding of the problem.
Don't fall in love with the prototype
This is probably where Bear would make a surprisingly good product owner.
If he builds a raft and it immediately starts sinking, I imagine he doesn't gather everyone for a retro on why the raft should theoretically float.
He gets out of the water and builds a better raft!
In product development, we sometimes struggle with this because ideas accumulate emotional weight.
We spent weeks discussing the concept. Someone presented it to management. It made it into the roadmap. There is a beautiful Figma prototype. The CEO likes it.
And then users don't understand it.
That is valuable information.
A prototype isn't there to prove that we were right. It's there to help us find out where we're wrong while changing direction is still relatively cheap.
Adapt doesn't mean give up
There is another part of Bear's mindset I like.
Changing the plan isn't failure, and the same distinction matters when building products.
You can stay stubborn about the problem you're trying to solve while being extremely flexible about the solution.
A feature can disappear. The interface can change completely. The technology can change.
The original concept might turn into something nobody imagined at the beginning. That's fine.
The purpose of iteration isn't to slowly polish your first idea until everyone is too exhausted to question it. It's to make the idea better every time reality tells you something new.
Improvise. Adapt. Overcome. Repeat.
Maybe the product-development version should be:
Question. Idea. Prototype. Feedback. Decision.
It is admittedly less dramatic, but the mindset is the same.
Ask the right question. Explore an idea. Build something you can test. Get real feedback. Make a decision based on what you learned, and start the next loop.
Fortunately, product development rarely requires drinking your own urine.
It does occasionally require swallowing your pride.