Introduction:

Currently the games industry is a multi-billion dollar industry. Many of the AAA titles cost millions to create and gain even more in revenue. The industry is rapidly growing into unimaginable proportions. Games are no longer limited to something you play on the street with a piece of chalk. Most people nowadays own at least one gaming console or play games on their computer. Gaming has become a very big part in a lot of people's lives. For many it's their go to activity for relaxing and leisure. (The reason for this i will discuss in a different article)

For companies to exist they need to make money. The equation is very simple:

Create thing - people buy thing - receive money

Sadly, it's not as simple to just create something and throw it out into the world and make your fortune. Sometimes this works but this is by far a reliable business model. On top of this there are others who are trying to do the exact same thing as you are trying to do. We know them as competitors. As industries grow, competitors rise. This means that for companies in order to keep making money they need to release better products than their competitors. 

From my time in the industry i have seen that Game Design (and development) is an incredibly uncharted terrain. Development teams are relying on unproven theories as their basis to make money. I spent a lot of time trying to figure out how to make good games in a reliable, affordable and consistent manner. Undoubtedly, these big companies are doing the same thing (for obvious reasons). 

Product Design: Problem? SOLUTION!

There is a many differences between Product Development and Game Development although the Design of both are incredibly similar. As mentioned before Game Design is in very uneasy baby shoes while Product Design is already in hiking in strong mountain climbers. The reason for this easily explainable. Games only became of a commercial significance roughly around 1990 - 1995 while Product Design has been a source of generous commercial interest for a lot longer, early 16th century (If not longer, had a hard time finding the date where Product Design became a big thing). Looking at those two dates we can see that Product Design has had a lot longer to develop. To make mistakes and learn from them. After all this time and learning they have developed the following overarching process:

1. Identifying a market opportunity
2. defining that problem
3. creating a solution for that problem 
4. testing that problem

Once a problem has been defined you can start measuring your solution to that problem.
For games this is incredibly difficult since we're creating experiences rather than actual solutions to problems, we are pretty good at the first two steps but the last two present a serious challenge. Currently the best test we have boils down to: Do you like this? 
The opinionated nature of the answer to that question is only one of the many problems it has.
Sadly i do not have a new test question to assess whether or not your game will be a success. We can however assess individual aspects of the project and combine those to give us a more detailed look at whether or not starting a project and maybe even investing money in it is a good decision. 

A Strong Beginning: Desirability, Feasibility and Viability

During my time in Product Design these three values lay at the core of each concept we created. If we did not have a strong answer to all three of these values we were bound to encounter major problems down the line. And possible make the project a lot more costlier.

Desirability: Do people WANT this product?

Creating a product that no one needs is doomed for failure. Creating an office chair that double functions as a toilet might be extremely handy but will probably not be a market success as people prefer to do their business in a private area for a variety of reasons.

For creating games this is where like and dislike comes to show it's incredibly annoying head. You will never be able to create a game that appeals to all gamers. You will always be targeting a specific group of players, what and how big that group is depends on the concept. There's various questions that can be asked here. The amount and what kind of questions will vary depending on other other variables... confusing, i know. Here's an example:

When you develop for a console (PS4, PC, Mobile, Handheld, Xbox,...) these questions should appear in your thought process.

These three questions (there are more) are confounded with the console variable but consistent throughout all projects so you might as well start with them. As you continue through your development cycle you will start identifying more questions. The later in the project the more specific the question will be (Usually). It's important that you do your best to find a specific answer to each of them. Not answering these questions might lead to design holes and possible project dependencies not being identified.  Example:

All of these answers can be measured. As long as the answer is either yes/no or a number you can measure it. If you can measure it you can assess it and if you can asses it you can 

Feasibility: Can we MAKE this product?

There's a reason we don't have teleportation devices yet. They're obviously incredibly handy in all situations that require physical re-location. It's just not possible to build such a device (yet?). 
If your product can't be created it's not worth pursuing.

In development terms this includes a couple of things:

These three will come together to create your scope. Depending on your scope you can tackle smaller and bigger projects. A team of 5 people that have never handled game development before probably won’t be able to handle the creation of The Elder Scrolls 6.

Often times estimates are incorrect. And project's planning and deadlines are entirely based on these estimates. Later on in a project estimates usually become better and better. But for the start of a project identifying possible risks is a much more reliable way to assess whether or not a concept is feasible. If there are risks that lay at the core of your product it’s probably not worth pursuing. The reason why AAA companies like to make sequels so much (Call of Duty, Tomb Raider, God Of War, are just a few examples) is because these concepts already have a fan-base, thus creating one is no more of a risk factor.

This does not solely apply to fan bases and sequels though. It also concerns things such as unexplored territories (VR/AR), not having your core gameplay loop figured out, and more. Anything that you cannot predict for the future is a potential risk. This includes everything that can influence the project (Team, money,…). If you have a time frame of 10 weeks and create a project that you think you will be able to create in 10 weeks you will most likely not deliver the product you promised because you’re assuming nothing will go wrong, project and team wise. (Weather and natural phenomena can also affect your project, depending on your location you may or may not want to take this into account).

Viability: is this product SUSTAINABLE?

Games are only games when they are being played by other people. You have to create a game that can keep players engaged for longer periods of time. This is where things such as grind, time gating, repeatability,… come in there exist there so that players can keep playing for a longer amount of time.

This also concerns wether or not you can build a sustainable business out of a project. Many startup game companies end up shutting down not because the game they made was bad. They shut down because they are counting on this one project being a success and carrying them through. Then go through the whole thing again and hope that this one will give them enough revenue to continue for another couple of years.

Big companies are less affected by the impact of a project that fails. Nevertheless will they also prefer a sustainable franchise over a flop.

CLOSING

Figuring out these values will help you measure your project's success as you go through development. You will undoubtedly encounter situations where your solution to a project issue did not turn out the way you hoped it would. This will present you with the choice: You can pivot or gut it out and keep going the way you're going. Whichever you choose you will be able to measure it's effectiveness again and again and again until you have reached the solution that fixes the problem.