The Fortnite Story

The Fortnite you know today is not how Fortnite started off. The original game was built around the “Save the Day” game mode, which was following on from the trend of co-operative survival games.

Recently the news that this game mode was going to be made free to play, it’s previously been behind a fee as per the original model of Fortnite, reminded me of what we can learn from Fortnite’s successful pivot.

Before Fortnite’s battle royale game mode, the one you probably know, there were other battle royale games that were making waves in the gaming industry. Around that time I was playing PlayerUnknown’s Battlegrounds, more commonly known as PUBG. PUBG was a gritty and realistic battle royale game that quickly became one of the world’s most popular PC games.

Fortnite had been having underwhelming success in the 6 years since the first trailer was revealed (2011), but with that 6 years worth of work the team were able to quickly pivot to capture the moment around battle royale games and become the leader in the space they are today.

In game development these days games can often take 5 or more years to produce, and can be quickly shut down when they are not an instant success, so chasing a trend that is happening now with a new project is a big bet on that trend still being popular in 5+ years and being able to overcome the early movers in that space.

The Lesson: Innovate or Be Flexible

There have been a lot of companies that have chased the kind of success that Fortnite has had, it’s very appealing to any executive or publisher to have a game like Fortnite that can bring in over $1 Billion of lifetime revenue and become one of the dominant cultural forces in the gaming ecosystem. This success has seen a lot of companies chasing the “live-service” free-to-play model and failing. A lot of those companies are focusing on the wrong lessons from Fortnite’s success.

One path for capturing the success of Fortnite is to be the innovator in a space, grabbing that first mover advantage and leveraging that to a large enough product to be successful. In game development this is increasingly difficult due to the aforementioned timelines we see for building a game. In more typical software product development where there are shorter timelines, this is a more plausible approach.

In both cases you take a big risk that your innovation will find the right market fit at the right time. Even a lot of the software companies born from products we see now as innovative were not necessarily the first movers in that space, like Facebook with MySpace coming before it. So this path has a low chance of success, regardless of what you are building.

A more realistic path to success, and the one that worked out for Fortnite, is to have in place the right platform, the right team and the right building blocks to pursue the right opportunity. This means you do not need to have the vision of what might be successful in 1, 2 or 5 years time, but instead you need to identify what is growing now, and would be expected to keep growing.

The Fortnite team had a game in place with many of the key elements that made it a success, an art style that would have a wide appeal, a game platform that allowed them to keep producing new content for it, and a game with the right building blocks for an entirely new gameplay loop.

This approach is all about being in the right position to pursue an opportunity in a shorter timeframe, and as such reducing the risk by being able to pivot to another if that opportunity does not turn out how you wanted. Having the right platform to build for more than one idea helps to mitigate the risks. The Fortnite team might not have intentionally done this, but it’s a lesson we can learn from what transpired.

The lessons for software product teams

For engineers, what we can learn from this is to build with more of an open mind to where the product might go. Only build inflexible foundations with rock solid assumptions, beyond that build software that you know will need to change, all software does, especially the successful software.

Create the right abstractions that optimise for the future velocity of innovation as well as what you are building now. This will also improve your engineering design skills.

For engineering leaders we should learn to not over-fit the engineering choices to one specific problem. Think about how what you are building could allow you to pivot on features or product when the opportunity arises. If you are building Fortnite you aren’t going to pivot to an AI company, but the video game gameplay loop that wins out might not be the first one you build for.

Focus on helping your team build the right tools and the right solutions that can be pivoted as the needs change and new opportunities arrive. Help your engineering teams to understand this idea.

It’s not just about the choices your engineering teams make though, it’s also about aligning with the rest of your organisation on taking this approach because everyone needs to be flexible, not just the engineers. For me, writing this piece that I can share with our teams is a step towards helping others understand this idea.

These decisions to build more flexibly do not come for free though, and what executives can learn from this is to have the right combination of patience and speed. You need to give your teams enough time to build flexible enough solutions, and your organisation needs to be geared to move quickly to take advantage of the right opportunities at the right time.

You need to work with your teams to identify ways to pivot the focus of what you are building to meet the right opportunity. It is important to understand where you might want to go as an organisation, and work with your engineering teams to understand what the scope of pivot possibilities would be.

And for everyone, identify the core foundations and the speculative bets in what you are building.

Build with Lego, Not with Cement

The takeaway from this is to build with Lego not cement. Sure you may need a flat surface to start building your Lego on top of, but you should not commit cement to that which you may need to change and rebuild like it’s Lego. Just like in real life though, Lego is expensive and this needs to be accounted for too. It is only together as an organisation that you can find the right mix of building materials.

At Rising Academies we have been moving towards the approach of being able to leverage what we build for future projects, and for future growth in existing projects as much as we can.

For example we built out a user management system for Rori that we are now applying to Tari. This has allowed us to build out a data pipeline and a stable memory for Tari in much quicker time than we would if building it from scratch.

These two projects are both conversational projects, but quite different in how they are built and the tech stacks we have used to get there. Identifying where we can use more flexible systems that we have built, and building them for that in the first place, gives us a lot more power to deliver on the goals of both projects with a small team.

At Rising Academies, one of our principles is “Our first draft is never our final draft”, this speaks to this approach, and the one that succeeded for Fortnite. Their pivot from “Save the Day” to battle royale ironically saved them, and facilitated the success we see. Don’t try and copy the outcome, find success in the process that brought them to where they are today.