In one of our previous articles, we discussed three core steps to bringing an idea to success: Find the Problem, Find the Solution, Get Hard Proof (Cash in Hand).
This way of thinking is as old as commerce itself, but the question is whether it can be applied to video games.
The answer is partly yes, and when applied correctly, it can significantly strengthen a game project.
How gaming companies often approach game development today usually starts with a small cross-functional team: a designer, an artist, a developer, sometimes a product manager. Based on an initial hunch, deal, or asset, the team builds and iterates on prototypes, then invests more into polishing a minimum playable prototype and running limited technical launches to test player behaviour and metrics. If results are promising, production continues; if not, the team typically returns to prototyping and starts over.
And here comes the catch: the results. Did the team and company spend time and money on tests that failed to answer the core question? In many cases, yes, even if engagement metrics were collected.
What’s missing is hard proof: no player actually reached for their wallet. As you can see, the risk here is quite big in terms of time and resources spent until realising that no player wants this product, or a very small part of them do.
We challenge this approach by leaning instead on the steps: Find the Problem, Find the Solution, Get Hard Proof, treating them as guiding principles rather than a rigid process.
Gameplay validation, user acquisition, and marketability still matter, but the primary goal is to get cash in hand as early as possible.
Find the problem:
Unlike when we are looking at real life problems, which can be solved via some products or services, games are a bit different than regular products.
They satisfy the need for having fun and be entertaining. However, we can still find a problem or if we rephrase it, we can find an unmet need or also not satisfied unique experiences.
Looking at it this way, we can see there are different genres, play modes, story arcs, art styles, gameplay types, and so on.
Some satisfy players, some don’t, and those gaps create demand for experiences current games can’t provide.
It could be a mod community building something they want but can’t get. It could be a retro gameplay that players return to out of nostalgia, but nothing similar exists today.
It could be a clunky mechanic in a popular game that ruins the fun, or an experience that doesn’t exist yet. Look for these clues in the market, in player discussions, and in what people are already trying to solve.
Research comments on popular games, forums, app stores, etc., and count repeated issues—aim for around 50–100 people (desired number, but the more the better) mentioning the same thing.
Find the solution:
Once you’ve identified a market gap, look for lead users who are already trying to solve it themselves.
They might be building a community around an old game, making mods, or cloning a mechanic — all signals that the need is strong enough for people to invest time in it.
Talk to these lead users (usually 1–3 people) to understand their motivation, how often they would play, and how urgent the need is, why they are working on it, had they looked for similar gaming experiences, how often would they play such a game if there was one, etc.
In other words, try to get as much information about their motivation and needs – how strong the urge is. Your lead users should be around 1-3 people. We explained that those are rare to find,
but what they are doing is the best starting point you would have.
Get Hard Proof (Cash in Hand):
The idea here is to find out if enough people are willing to pay for the solution. This is the time to ideate, experiment, and build prototypes that solve what users are looking for.
- Games are different from other mediums, so for beginners or small teams, here are things to watch out for:
- Do not attempt to build AAA worlds full of environments, characters, story, etc.
- Do not attempt to design every single aspect of the game
- Do not invest in finding an art style, and especially not in developing and executing a new one — it is expensive and time consuming
- Do not try to build tech infrastructures or “best coding practices” early on — also time consuming and pricey
- Do not focus on “soft” metrics like retention, stickiness, CPI, marketability, etc. Companies build mechanics for day 0–14 and beyond
- Keep your scope based on your abilities; a solo dev cannot build a AAA game overnight
- Free-to-play games cannot provide hard proof because the product is free; no real cash exchange happens, so this method does not apply.
Free-to-play can validate differently, but not with early cash-in-hand proof. Possible way to test payment is to make it premium.
For general game development we care about only two things: does this game solve what users are looking for, and are they willing to pay for it?
So we build our minimum playable prototype around those questions.
A minimum playable prototype is a simplified version of the game that includes just enough gameplay and features to test the core experience and payment intent.
That is why when building our prototype we will focus on answering these two questions:
- Are players going to like and play this game, and does it cover what they are looking for?
- Are they going to pay for it, and if so, how much?
That is why our prototype will focus on providing the setting needed to answer those questions. To answer the first one, you must deliver the gameplay your users are looking for.
To answer the second, you need a launch setup that lets users pay early, such as a demo with pre-orders or unlock-able content (chapters, game pass, etc.).
The exact monetization strategy depends on your chosen model, which is out of the scope of this article.
How long should you spend building your prototype? Depending on scope, aim for 2–3 weeks for internal builds, and 1–3 months for a minimum playable prototype on a small to medium game.
Based on your genre, audience, and platform, aim to get hard proof within the first few days using a highly targeted test. If enough users spend money, that’s your best indicator the game is on track, and it’s time to gather feedback and refine the prototype.
How much money and how many users are enough? The prototype’s job is to answer those two questions, and you should define the numbers based on projected yearly income: calculate your costs and target profit, and use that to guide pricing.
For example, if you identify 60 people online looking for this game, the conversion rate from that group can be projected onto a larger market.
Rule of thumb, the hard proof metric is not the kill switch and you should have other data around your tests. However this proof should be the main aim of your market test.
But do you need to pay for marketing? Yes, at this point you should, and you should track impressions, CPI, likes, and other metrics.
However, the only metric that truly matters here is cash in hand; everything else is supplementary. Other metrics matter, but only after early payment proof.
Conclusion
The fastest way to validate a game idea is not through polished prototypes or soft metrics—it’s by getting real money from real players as early as possible.
Find the unmet need, build the simplest playable solution, and prove demand with cash in hand – this will be a strong indicator that you might be onto something and possibly a successful product.
