Previously, in “How to Fail in F2P Mobile Games…”
In Part II of “How to Fail in F2P Mobile Games” we touched on three distinct approaches to product and feature design: Adapting Proven Solutions, Forward-Innovation, and Pure (blank slate) Design.
Now, in Part III, we’ll discuss how a clear understanding of and consistent focus on our key product goals can shed light on these difficult, daily choices.
Let’s return to this fundamental, critical question:
“Should we copy a feature (or product) from our competitor, improve on a competitor’s design, or invent our own approach?”
– F2P Game Designers, every day of the week.
I have three recommended rules for approaching this problem:
Rule #1: Focus ALL Innovation on 2–4 Key Features, representing ~30% of total scope. Use Proven Solutions, unabashedly, for the other 70%.
My recommendation: Choose 2–4 major game features or areas, comprising roughly 30% of your game feature scope, as your “ Key Innovation Targets. “ These features should be highly valuable to your target players, and the key focus of your marketing and product positioning.
For the remaining (70%) of your game feature scope, I recommend tightly conforming to Proven Solutions. By saying “no” to innovation outside of your KITs (Key Innovation Targets), you limit non-KIT design time to < 30% of your total budget, leaving 70% for your KITs. To stack the odds in your favor, designers should choose feature references (games) carefully in order to pluck Proven Solutions that are as plug-and-play as possible.
When done properly, your designers should expect to spend 70% of their time creating, testing, and refining the innovative 30% (2–4 KIT features) of the game.
Most designers and teams will appreciate having clear objectives, and the breathing room to focus on KITs. Your players will benefit from this approach too, as they will already be familiar with 70% of the game systems and only need to learn, at most, the innovative 30%. Don’t underestimate this benefit, as heavy tutorialization creates agony for both your players AND your development timeline.
Note that this paradigm does not reduce the time that you spend innovating. We just choose to direct all of that effort toward those 2–4 Key Innovation Targets — the features that will become our primary product differentiators — and we consciously agree to leverage Proven Solutions for the rest (in order to meet our launch date).
The real objective here is a bright line leaving NO room for ambiguity, creating a massive level of clarity for the development team, execs and other stakeholders. By consciously identifying all of the areas in which we will NOT innovate, we are able to prevent unnecessary conversations, quicken meetings, speed development, reduce risk, and laser-focus the creativity and imagination of the entire team on the 2–4 key areas that matter most.
Rule #2: ALL other innovation goes to the backlog
Great! So now you have defined your Key Innovation Targets: the 2–4 unique features that will be most meaningful to your target audience, and most critical to your game’s ability to achieve product-market fit.
After some necessary due diligence, your next task will be to deliver a test product to that market, with those 2–4 innovative features, as quickly and inexpensively as possible.
This test launch will confirm whether your hypothesis for product-market fit was valid, i.e. whether there exists a sizeable market of users craving your 2–4 innovative features enough to 1) grok your key differentiators in a targeted ad, 2) download your game, and 3) stick around and engage with it.
Said more simply, the ONLY goal at this stage is to find out if your 2–4 KIT features resonate strongly enough with your target market to justify further investment.
Sidebar: In most cases, the answer will be no, which is why you want to get to this answer quickly (more on this in the next article)!
All features aside from your Key Innovation Targets can be thought of as “Supporting Features” which, for the purposes of this initial product-market fit testing, simply need to ‘exist’ (and to not ‘completely suck’) while allowing players to have a reasonable initial experience with your KITs.
These Supporting Features are likely to include the typical F2P fodder: store, offers, currencies, leaderboard systems, quests, daily rewards, item and inventory management, notifications and announcements, mailbox, chat, player profiles and so on. Because nearly all of these features exist as Proven Solutions in other top-grossing games, and because players are generally quite comfortable with the status quo, your team should be unabashed in copying them.
BUT, what if your team has credible, creative ideas on how to innovate on and/or improve these Supporting Features too?
Let me be clear:
Do not waste innovation budget on Supporting Features prior to product-market fit testing.
If you thought, for example, that an innovative leaderboard design was critical to players, then you would have chosen leaderboards as one of your Key Innovation Targets.
But, you didn’t. You instead decided, explicitly, that innovation in other areas would be more meaningful to players.
So, capture all of your team’s great ideas, but put them in the feature backlog for now.
If your product’s KITs resonate strongly with the market, there will be plenty of time for further innovation and polish.
If your KITs don’t resonate, innovative and/or polished Supporting Features aren’t the problem, and won’t save you. The target market, or the Key Innovation Targets will need to change until you find product-market fit.
Rule #3: Get your team 100% aligned.
To reap the rewards of focused innovation and rapid testing, your team needs to be 100% clear on your 2–4 Key Innovation Targets, and fully bought-in on the deferral of all other innovation until after product-market fit testing.
In my experience, achieving and maintaining this alignment can be quite challenging, given developers’ natural inclination to analyze, critique, create and improve!
“If we backlog all of our good ideas, the product will be ‘average’ and fail product-market fit testing!”
– Hypothetical designer
“Plus, why WOULDN’T we improve a feature if we know we can do it better?”
– Hypothetical designer
These are common sentiments that come from a good place: wanting to make a great, successful product. However, they are based on some incorrect assumptions, and can be quite harmful to products and teams.
- “The market responds STRONGLY to innovative Supporting Features.” RARELY TRUE. Designers are accustomed to focusing on small details, and can always find ways to further perfect products. As a recovering perfectionist, I’ve learned over the years that the broad market judges a product by very different criteria than game designers. Generally speaking, new players (particularly in the casual and hyper-casual markets) will form a quick, initial impression given a product’s theme, genre, and core mechanic, and then decide whether to stick around. While polishing all features to a high shine will move the needle for lifetime value, we’ve repeatedly seen that casual and hyper-casual players will happily engage with largely ‘unpolished’ games if they resonate with the core mechanic and premise. More on this in the next article!
- “We always have time for more innovation.” WE DON’T! If we want 70% of designer time focused on our KITs, we’ve only left 30% for Supporting Features — the bare minimum for implementing Proven Solutions. Any deviation from Proven Solutions requires unscheduled time, which will come at the expense of our KITs: not a good tradeoff. Keep the good ideas flowing, but put them on the backlog until you’ve proven product-market fit
- “Innovation only costs designer-time.” FALSE. Innovation is expensive and its costs are borne by the whole team. It requires implementation, tuning, QA, and communication overhead; innovation also dramatically increases the risk that features need rework, meaning additional wave(s) of unplanned support and effort. Welcome to crunch time!
- “Different always means better.” BUT, DOES IT? Again, we must make a first-order distinction between KITs and Supporting Features. It’s true that a game needs a few differentiators to stand out. It does not follow that ALL game features will benefit from differentiation. A Proven Solution is (definitionally) proven, and any amended version has yet to be. So while it’s certainly possible that changes or improvements could yield meaningful gains, it’s more likely to yield no results, or even negative results relative to the Proven Solution, while costing precious time.
- “But, [X specific feature] is worth an exception.” HIGHLY UNLIKELY. Yes, a small innovation here or there could certainly make the product slightly ‘better.’ But, the actual KPI benefits are likely to be undetectably small. These benefits likely pale in comparison to the incredible clarity and efficiency that a bright-line rule of ‘all other polish and innovation goes to backlog’ brings to the team, process and product.
Wrapping Up
To summarize: for most projects, I recommend choosing 2–4 Key Innovation Targets as product differentiators for your initial test release, and using Proven Solutions for everything else.
By focusing your efforts on the few features that will truly define your product’s success or failure, you avoid wasted effort, unnecessary bugs, meetings, and overhead. You mitigate the possibility of late-nights and crunch time. Everyone (your players, your developers, your investors) stand to benefit.
In the next article, we’ll discuss how to bring a product to market for the first time!
