Some people eat too much junk food. Others bite their nails. My guilty habit is investing hundreds of hours of work into things that never work.

Flash back to my first few years at Google: the road to success was clear. I’m handed a project, build it real nice-like, and collect warm belly rubs from the senior engineers.

Eventually I reached the esteemed level of senior engineer and I became responsible both for executing a vision and finding a good one in the first place.

All of a sudden, building hard things wasn’t enough. Hard things only counted when they made an impact.

At least for me, “finding what’s worth building” has proven a much stickier problem than the actual building itself. The majority of my career in the last 7 years – at Google, and eventually at startups – has hinged on that problem.

I’d be lying if I said that transition has been smooth.

Thankfully for everyone reading, I just watched an astonishingly excellent video from an indie video game developer named Jonas Tyroller about just this subject. In that video, he clearly lays out many of the truths I myself have had to learn through blood, sweat, and coffee. Watching that video felt as if he personally reached through the screen, caressed my cheek, and whispered “you’re a total idiot” to me-from-seven-years-ago.

Jonas is an independent game developer who’s been making games and releasing videos for 11 years. That means there’s full documentation of his journey going from making games that look like this:

To games that look like this:

Importantly for us, he’s not just talented at making games but also incredibly thoughtful about the way in which those games are made. (Note to the reader: these two facts are probably related.)

Fundamentally, his lesson is this: game development requires a good search algorithm. For the less computationally-minded, a search algorithm is just a plan you can follow to find the best option given your limited point of view. Looking for the deepest point in a lake? Want to find the best path from your house to the grocery store? Need to find the best fishing spot in town? These are all searches, and a search algorithm gives you a set of steps to find the best – or at least a very good – answer.

The key tension in search algorithms is that you’re weighing time spent exploring options versus time spent actually doing the damn thing: after all, any time spent scouting fishing spots is time spent not fishing.

Jonas has devoted an enormous amount of effort to “searching for fun games” and offers some genuinely terrific insights that are applicable both to his own domain of making games and my personal domain of “finding useful things to build”.

Go wide first, then narrow

Start by entering an “exploration phase” where you’re trying lots of very different ideas by building really crummy prototypes that test just a single thing. In this phase, your primary goal is to test very different hypotheses and gather samples about which seem most promising.

He uses the analogy of “finding the deepest spot in the lake” – if you only ever test one small area of the lake, why should you have any conviction you’re in the right spot? Instead, you want to make big jumps between your samples. Your early prototypes should be very different from each other.

Only once you’ve sampled lots of different ideas should you start to reduce the size of your jumps and start moving into real work on a single project.

Don’t get stuck at a local maximum

Local maxima are an inherent challenge in any search algorithm. What’s a local maximum? Imagine that you’re fishing in a nice pond, but there’s a river absolutely teeming with salmon just over the hill: you’re at a *local *maximum because anywhere you look from your current perspective is worse, but there’s a global maximum that’s far better out of your immediate field of vision.

The key suggestion that Jonas makes to avoid local maxima is to look for and frequently take opportunities to inexpensively make big jumps in your search, even after you’ve “chosen your pond”. As a concrete example from the “building companies” world, it may turn out that the chat interface you’ve built for your video game may be a much better business than the video game itself: this is more or less the story of Slack. It certainly took resources for the team to explore this route, but they weren’t starting from scratch and the exploration of applying their existing infrastructure to a new domain paid off. They had reached a local peak with their video game, but a much larger peak was just out of sight.

Make exploration cheap

You have two goals when exploring: be fast, and be sorta accurate. Speed is more important than accuracy.

The key to prototyping quickly is to only prototype one thing at a time. Prototypes must be built with the intention of being thrown away. The point that Jonas makes is that if you’re prototyping art (in my world, design/branding) and gameplay (functionality) at the same time, you’re not prototyping at all: you’re just building the stupid thing. That’s far too slow. Instead, prototype each axis independently.

The goal of making prototypes cheap isn’t to “reduce time spent exploring” – instead, cheaper prototypes allow you to explore many more potential futures, improving your search.

Lastly, keep a list of things that you’d like to explore. When there’s downtime and you have extra staffing, get a teammate to explore one of those ideas.

Spend more time exploring and less time iterating on bad ideas

The ultimate message is that people often spend far too much attention iterating on the little things and far too little on finding the bigger truths.

Prototype; learn; evaluate; repeat. That’s how you can find the best plot to build your castle.

(You can find a link to Jonas’s original video here.)