The F2P Designer’s Dilemma

Like many mobile game PMs and designers, I cut my teeth in premium console game production. Down in the trenches, creative decision-making flowed freely, and we were blissfully ignorant of and unperturbed by broader business realities and performance metrics.

My first few years in games were spent in sound effects design, and the work was as close to ‘pure creativity’ as one could imagine. I recall spending three whole days creating a single sound-effect for an Xbox horror/action game (for vampiric, blood-powered dual sub-machine guns). Those were the days!

F2P changed all of that. The ‘try free’ business model, and broad availability on Facebook, mobile and other ubiquitous platforms opened the floodgates to a colossal new market, a blue ocean of non-gamers who might have never installed a game in the ‘pay first / console’ paradigm. This new market of players preferred more casual, bite-sized experiences to the heavily crafted, polished, 3D epics that dominated the console market.

This new, untapped market expanded rapidly and, by 2009, most of the best job opportunities in game development were in the emerging F2P space. It was perhaps inevitable that, sooner or later, most console developers would make the jump.

For some, the transition from console to F2P was a bit jarring. Where premium games tended to optimize for creativity, immersion and quality of experience above all else, F2P’s mandate was ruthlessly pragmatic: to focus on speed, effectiveness and agility in product design and development, in service of driving players to repeatedly and compulsively engage in the specific, measurable behaviors that the business model demanded.

For many designers and developers fortunate enough to experience the “high art” of premium product design, the subjugation of the old values of originality, depth and quality to F2P’s new mandates: pragmatism, speed to market, and KPI measurement came as quite a culture shock.

Effective F2P developers must be both creative and metrics-driven.

With all that said…

I would venture that ALL F2P designers, whether reared in the console ethos or not, frequently find themselves squeezed by the competing demands of creativity and pragmatism.

Consider the following 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.

This question reminds me of the alleged Mark Pincus (Zynga) quote, which achieved notoriety due to its… inelegant… handling of the same uncomfortable question.

“I don’t [**#%$] want innovation,” (an ex-employee recalls Pincus saying). “You’re not smarter than your competitor. Just copy what they do until you get their numbers.”

Was Pincus wrong? What’s a well-intentioned game designer to do?

In this article, I’ll seek to reframe this question from my perspective as both a product manager and designer, so that perhaps we can bring a bit more confidence and clarity to our decisions about whether to innovate, “copy” a competitor, or aim somewhere in between.

Let’s examine these choices in more detail.

Three Types of Design Solutions

First, we’ll define ‘design solution’ as “a design for a particular system that meets our game’s specific requirements.”

For example,

• Design problem: “Our live, casual game is launching a “Leagued Tournaments” feature, and needs a design for a scoring system that supports 1) promotion of successful players to the next league, 2) demotion of unsuccessful or inactive players, and 3) rewards that improve with league advancement.”
• Design solution: “Our proposed design for MVP launch of Leagued Tournaments is based tightly on Gardenscapes’ Leagued Tournaments, with the following minor tweaks needed to adapt it to our game model: #1, #2, #3 etc.”

When choosing how to approach a particular design problem, I’ve seen three main paths, which differ in 1) whether we research competitors’ solutions, and 2) to what degree we innovate. And over the years, I have learned (often the hard way) to be very explicit about these choices, because innovation is expensive (time, effort, distraction) and adds risk to our projects.

1. Adopt a Proven Solution

For most design problems, adopting a Proven Solution is by far the most effective approach.

Definition: When our design problem is not unique, we can quickly review solutions from other top-grossing games, and choose a solution that is highly likely to work very well in our game with minimal modification. In nearly no time at all, we have an 80/20 solution. And, because F2P live game development is an iterative process, we can always make future improvements if needed.

That last point is worth repeating: We can always make future improvements if needed.

For example, ‘daily login rewards’ is a ubiquitous, proven solution to the problem: “We need a simple mechanism to help drive a bit more retention and stickiness.” And because MOST top-grossing games use similar variants of this solution, we can have a high level of confidence that a nearly identical solution will meet our needs.

Pros:

• Proven Solutions are low-risk and low-cost, having benefited from plenty of iteration and testing at scale.
• They are easy to communicate to engineering.
• Players are already familiar with them.

Cons:

• Proven Solutions won’t meet players’ desire for originality, so we’ll need to solve that elsewhere (via our Key Innovation Targets, which I’ll cover in the next article).

Summary: When your design problem is not unique, it’s smart to start with Proven Solutions, conserving your resources for the more difficult problems ahead.

2. Forward-Innovating Solutions

Definition: When warranted, we can attempt to improve upon a Proven Solution from other top-grossing games. Or, after digesting the competitors’ approaches, we could seek to create a wholly new, alternative solution that we believe will perform even better.

But either approach – improving upon prevailing solutions or inventing your own – is likely to consume an outsized share of your project budget.

For this reason, such innovation should be used sparingly, and only on a few of your most important features. From my experience, innovative designs are generally only appropriate 1) during initial development, to support a major product differentiator or 2) after the initial launch of a product or feature, to further improve its performance.

Outside of these two scenarios, I will generally challenge teams to play it safe and walk the beaten path (Proven Solutions).

Pros:

• Forward-Innovating Solutions can serve as major product differentiators.
• They can improve player experience, KPI, or both.

Cons:

• Innovation is risky. You are betting that your new, un-tested solution is superior to those of (usually multiple) high-grossing competitors, staffed by smart people like yourself. Statistically speaking, this is probably not a good bet!
• High quality, innovative solutions are very expensive and time-consuming to develop, and typically require iteration and tuning. So, you can only afford to innovate in a few key areas.

Summary: Always review your competitors’ solutions first. Innovation is expensive, so choose your battles. Save your innovation budget for your Key Innovation Targets.

3. Pure Design Solutions (start with a blank slate)

Pure Design is great for out-of-box thinking, inefficient in other cases.

Definition: Many designers approach design problems, by default, with the generative ‘bottom-up’ method. They start with a blank sheet of paper and end with a boutique design, meticulously crafted and born of the designer’s imagination.

The defining characteristic of this approach is that it skips an audit of how successful competitors have handled similar design problems.

To many designers, this feels like the intuitive, ‘right’ approach to design. After all, isn’t a designer’s job to… dream up new designs? I can certainly relate, as in my early years as a F2P designer I too succumbed to this logical fallacy:

“As a capable game designer, why copy what I can design myself?” — Novice F2P Game Designer

The problem is, in the vast majority of cases, this ‘Pure Design’ approach is the least effective of the three.

Why? Because most design problems aren’t unique, and have therefore already been thoroughly solved by your (numerous, smart, and successful) competitors.

And, to the same extent that your Pure Design solution is new and original, it is also hypothetical, unproven, and first-generation, and will therefore most likely underperform a mature, proven solution, while taking you more time (and cost) to develop. Not a great tradeoff!

All that said, Pure Design CAN be a great initial exercise, to generate broadly creative ideas, illuminate opportunities, and have a good bit of fun. BUT, it is no substitute for also learning from your competitors before settling upon a design solution.

Out-of-box thinking via Pure Design can be useful in some contexts, woefully inefficient in others.

Pros:

• With Pure Design, it’s possible (however unlikely) to stumble onto superior, innovative solutions.
• Unconventional designs are likely to please novelty-seeking players, provided that the solutions work well and can be easily learned by players.
• Many designers intuitively love this approach — it can be motivating to the team and good for morale.
• As a standalone exercise, Pure Design can generate useful creative ideas!

Cons:

• Competitors’ solutions can provide a great deal of information about what works, what doesn’t and what unanticipated problems may surface. Ignore them at your peril.
• If your design problem is not unique (the dominant case), then you’re likely to invest significant time creating and implementing a design that’s inferior to a Proven Solution already used by your competitors!

Summary: In F2P games, Pure (blank page) Design is a great exercise for generating creative ideas. Just don’t forget to ALSO thoroughly absorb the ideas and solutions of your successful competitors as well. In practice, I’d only recommend using Pure Design as a standalone exercise, for ideation around your Key Innovation Targets.

Three approaches to product / feature design. The RED path is not recommended.