Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 15, 2019
arrowPress Releases







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

How to Fail in F2P Mobile Games, Part III: Nebulous Product Goals

by Matthew Emery on 10/10/19 10:38:00 am

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

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.

This article was originally published on LinkedIn — please like and comment there!

 

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.

As a general guideline, I recommend a 70/30 split between emulating Proven Solutions and innovation, with a clear line between the two.

(Above) As a general guideline, I recommend a 70/30 split between emulating Proven Solutions and innovation, with a clear line between the two.

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 (details in the next article!), 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.

No alt text provided for this imageTo 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.

  1. “The market responds STRONGLY to innovative Supporting Features.” RARELY TRUEDesigners 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!
  2. “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
  3. “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!
  4. “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.
  5. “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

No alt text provided for this imageTo 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! Connect with me or follow me on LinkedIn to receive it.

Need help with your game? Message me, or book a time on my calendar.


Other recent articles you might enjoy:


Related Jobs

Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States
[10.14.19]

Animator
University of Utah
University of Utah — Salt Lake City, Utah, United States
[10.14.19]

Assistant Professor (Lecturer)
HB Studios
HB Studios — Lunenburg/Halifax, Nova Scotia, Canada
[10.14.19]

Experienced Software Engineer
Take Two Interactive Software Inc.
Take Two Interactive Software Inc. — Westwood , Massachusetts, United States
[10.11.19]

Producer





Loading Comments

loader image