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
September 19, 2019
arrowPress Releases







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


 

MVP Like Nintendo in 1980

by Janessa Olson on 07/02/19 10:55:00 am   Featured Blogs

5 comments Share on Twitter    RSS

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.

 

If you work in or around some kind of software development, you’ve probably heard “MVP” sputtered in passing conversation, or seen it scribbled in a comment of a Google Doc. “MVP” is an acronym for “Minimum Viable Product.” The definition of an MVP is a loaded one, and changes slightly from Product Person™ to Product Person™. One popular definition is, “What can we build that will give us the most validation?” The school of thought I personally subscribe to (and will be using for the duration of this article) describes an MVP as “the smallest solution you build that will bring the most value to your customers.”

At first, all of this probably sounds straightforward enough, but there’s deceivingly a lot to unpack here; in my experience it’s never just “what’s the smallest solution.” In one of my favorite articles about MVPs, they say, “Starting with a solution is like building a key without a door” (9). It’s easy to fall into a cycle of Build/Measure/Learn (as the first definition I mentioned often teaches), but the issue there can be if you start with a bad idea, all you learn is that your idea is bad. There’s no room for iteration, and you’re essentially stuck.

How do you avoid starting with a bad idea? You start with understanding what problem you want to solve. Once you have an understanding of your customer base and the problem you want to address, you can narrow down on what kind of solution could be the best approach. After sending this solution out into the wild, you gather feedback from your customers, which you can use to iterate on the next version of your product.

In my personal opinion (and I just know somebody is going to start a fight with me about this), arguably the most important word in MVP is the “M”: minimum. The amount of work you put into an MVP is critical for many reasons, some big ones being:

  • Development costs money
  • Meetings cost money
  • Time in general costs money
  • EVERYTHING COSTS MONEY*

*Product Managers can’t help but see dollar signs attached to everything they see. This is a side effect from the Product Manager Initiation of looking into the mirror of a dark bathroom and saying “prioritize the backlog” three times.

In my experience, in the beginning you have the most control of “minimum”; it’s flexible, it saves you time (and therefore money), and it gives your “viable” room to grow and change as much as you need.

A very popular visualization of the MVP has been scurrying about the internet for a few years now, which you may have seen in passing, or even taped up on a wall somewhere in your office:

Source: “Making Sense of MVP” (which is a great blog I recommend if you just can’t get enough of MVPs)

If you want my personal opinion (and I assume you do—otherwise you wouldn’t be here reading an article I wrote), this diagram is fine if you’d like to explain what an MVP is to your drunk uncle at Thanksgiving (or perhaps a drunk stakeholder at the holiday party), but I find it to be slightly confusing and misleading in practice. The spirit of it I agree with—start with a simple solution people like and iterate until they love it. It’s the execution, or rather, the items being used as examples that I severely disagree with.

I’d like to take a moment to explain what I mean. A skateboard, a scooter, a bicycle, a motorcycle and a car may be used for similar things (transportation for example, or perhaps some kind of strange illegal street racing situation), but by different people in different market segments, for very different kindsof transportation (or illegal street racing). Just because all of those things have wheels doesn’t mean they’re iterations of each other. Some of the transitions are more believable—skateboard to scooter? Fine, I’ll buy that. But scooter to bike is a pretty big product shift, as is motorcycle to car (both of which have got to be expensive in terms of manufacturing costs). Keep an eye out if your product starts to pivot that hard—it may be time to have a heart to heart with your team about your vision and alignment, and if you trulyunderstand the problem you are trying to solve and the people you’re solving it for.

Please note: Sometimes pivots are necessary because the market is always changing, but it can also be expensive. (“EVERYTHING IS MONEY!” some poor product manager wails as they flip a table and run into the night, screaming.) If you pour a bunch of time into one product only to chuck it out the window when it doesn’t work and go in a new direction, you just wasted a ton of money on something you probably could have learned through prototyping, the more forgiving cousin of Minimum Viable Products.

Since the above diagram causes me severe emotional distress, I offer instead an example of MVP progression I think is near perfection in terms of both vision and execution—Nintendo’s handheld gaming timeline:

*Chef kiss*. Source: History of Nintendo Gameboy

No hard pivots here, folks. Instead when you look at their product progression you’ll see that the iterations are gradual, and if you take time to learn the context behind those iterations you’d learn they were also intentional. Nintendo knows the way to my heart, and it is through intentional design. Also, Pokémon.

In this article, I’m going to focus on the context behind the MVP for Nintendo that started it all for their handheld journey: the Game & Watch system. One can learn a lot from Nintendo in general, but in this article specifically we’ll learn about how they discovered a problem their customers had, the MVP they created to solve that problem, and how they iterated on that MVP through feedback and intentional design. I encourage taking periodic breaks to play your favorite Nintendo handheld, as nostalgia throughout this article is unavoidable (and dare I say it—intentional).

 

Nintendo, a real MVP of MVPs

It’s safe to say that a vast majority of people on this planet are familiar with the Nintendo Game Boy and its successors, but the same cannot be said about its predecessor, the Game & Watch, for two likely reasons. First, it’s more than 30 years old (and most of us can’t remember what we wore yesterday, let alone what happened 30 years ago), and second, the Game Boy was such a bonkers runaway success it kind of overshadows a lot of things, including much of the mid ’80s to early ’90s, taking a short break when Jurassic Parkwas released.

Mr. Gunpei Yokoi, or as I like to lovingly refer to him: “Papa Nintendo,” the inventor of the Game & Watch and Game Boy. Source: Meiobit

The Problem: It all started with a super bored businessman on a train

The idea for Nintendo’s first handheld came to be when Gunpei Yokoi watched a businessman on a train dink around on his calculator in a desperate attempt to stave off boredom (1). As the businessman slowly died inside, an idea came to Mr. Yokoi—what if he could create a device to help with long commutes such as this?

From this question sprung the Game & Watch beginnings, and Mr. Yokoi took his idea back to the team at Nintendo, where they started the brainstorming process. This also happens to be the beginning of what would become a strong vision for Nintendo’s handheld gaming path. The problem they chose (being boredom), their customer base (almost everyone), and the solution (eliminate boredom that can strike anytime, anyplace).

 

The Solution: The Game & Watch Is Born

The resulting MVP is a handheld (using a calculator chip as a processor, by the way!) (1), housing one game and a clock in the corner, hence the name “Game & Watch.” (Admittedly, for years I thought it meant “play a game and watch said game,” when it’s quite literally “a game and also there’s a watch so you can tell what time it is.”)

The first game was called “Ball”—where you played a shuffling character (named Mr. Game and Watch, as many of you may have seen in Super Smash Bros.) who is juggling some balls, trying to not drop any. In an interview with the original Game & Watch team, they discuss one of the earliest development decisions, which makes a very interesting hint if you’re looking for traces of this vision Mr. Yokoi established:

Kano: It was important throughout the entire Game & Watch series that when a player messed up, they realized the game wasn’t being unfair.
Izushi: They would think, “I’ll try again!”
Yamamoto: If a ball fell and the player was certain that he or she had caught it but the game said otherwise, it would be frustrating.
Izushi: We decided to make it so that in situations where the players were likely to think they had caught it, the game would also recognize it as such. They hadn’t caught it according to the signal, but we made the game’s judgment a little loose. (2)

Note: Mr. Gunpei Yokoi is sadly not a part of this series of interviews, as he died in a tragic accident in 1997 (7).

Example gameplay of “Ball.” Source: YouTube

Were I a gambling sort of gal (and I’m not because I’m too easily distracted by flashing lights and shiny things; I’m practically a magpie with opposable thumbs), I’d place all the chips I had that this decision was rooted in the vision of the Game & Watch being the Ultimate Boredom Elimination Machine™ , which you can’t do if the machine frustrates the player and makes them want to chuck it at a wall. The other reason I say this is because at this point in time, we also can’t be sure the team has done any sort of User Testing to draw this conclusion (at least none of them have fessed up to it), leading me to believe this particular direction is firmly rooted in vision.

 

Feedback

The Game & Watch was one of the first of Nintendo’s successful products. Due to the hardware restrictions of using a calculator chip, each handheld could only house one game at a time, but this restriction would not affect the success. In six years, Nintendo would go on to make 59 independent titles (1), some titles only taking one month to create (2).

Sketches from Mr. Masao Yamamoto’s notebook. Notes from a Game & Watch ideation meeting. Source: Iwata Asks

When “Ball” launched in 1980, members of the Game & Watch team went to stores to help sell the handheld, originally because the store was short-staffed, but made an interesting discovery that would affect the company’s outlook on product price points and feedback forever:

Iwata: Wrapping products properly is important but it must also be a great learning experience to see how consumers choose to buy a product.
Kano: I thought so, too. I can remember to this day how a grandmother and her grandchild came into the store and the child said, “Here! This is what I want!”
Iwata: Her grandchild wanted a Game & Watch system.
Kano: Yeah. But she said, “It’s too expensive.”
Iwata: A Game & Watch system cost 5,800 yen, which was expensive for a toy back then.
Kano: Right. I realized as I stood there how important it was to make a product of corresponding value. You don’t learn that until you stand at a sales location, so it was an important experience to encounter the consumers’ reactions and the atmosphere of the shop. (6)

Nintendo stans user testing and research! I knew it.

Mr. Iwata goes on to say that that sort of thing is good experience for the next time around, and Kano agrees, saying it motivates him to do better. This experience was clearly impactful, as you can see this trend in Nintendo products to this day when they release versions of their hardware that have fewer features, but are more affordable.

 

Iteration

The impact of this lightbulb moment shows when Nintendo launches the Game Boy in 1989. They observed and listened carefully to the things that customers loved about the Game & Watch, such as the game playing portability with a great battery life, and iterated on the things they didn’t, such as introducing many games for one handheld, all while finding a way to manufacture a product that kept the price “of corresponding value” ($89.95 in 1989, or $180 present day).

The Game Boy would go on to sell tremendously, as would its successors. Collectively, the Game Boy and Game Boy Color would hold the spot for highest selling handheld until 2010, when it was unseated by the Nintendo DS, which holds that spot to this day (3). As you look down the timeline of the Game & Watch and family, you can see hints of Nintendo’s iteration (and on occasion, revisitation), with each succeeding product. For example, does this Donkey Kong Game & Watch look familiar to you?

Donkey Kong Game & Watch, released 1982. Source: Super Mario Wiki

It probably does, because it’s totally a DS, some twenty-odd years before the DS was released!

An original DS. Source: Wikipedia

I always can’t help but nerd out when I think about how Nintendo’s product vision for their handheld family spans decades and across multiple iterations. It’s a beautiful dance of innovation while staying true to where you came from. This dance can also be seen in the story they tell their consumers through marketing—take a look at these following three ads, which span across at least twenty years:

An ad for the Game & Watch.

Source: Vintage Computing and Gaming

Source: Destructoid

Did you notice a theme? They all sell their respective handhelds as a solution to boredom. No matter how many handhelds Nintendo produces, they are always looking to their vision of creating fun and eliminating boredom. Keep this in mind when you’re crafting a vision for your product—it should be your proverbial North Star to guide you, not a fluffy collection of words to make your team feel good and then file away and forget about.
 

The Lessons We Can Learn

Nintendo, like many great innovators throughout history, has left us some nuggets of wisdom for us to find, learn from, and take with us on our own respective product journeys:

Your MVP is only as good as how much you understand your customer’s needs
And you can only understand your customer’s needs if you talk to them (or watch them on the train, or sell them your product in the store). The hardest part of this (aside from talking to strangers, which is terrifying on its own) is continuing to talk to your customers, even after your MVP, and even after you’re years into your product. It’s a good idea to never stop talking to your customers; when you stop talking, you lose touch, and when you lose touch, your product relevancy will suffer.

Product Vision: It’s not just a phase, MOM!!!
When crafting your product vision with your team, establish that this will be what guides many of the decisions you make for your product until the sun burns out or someone blows up the Earth, whichever happens first.

Say “No” more than you say “Yes”
Nintendo is really good at saying no, all across the board. They don’t rush out games if they can help it (4). They don’t lay off their people if they have a bad year (5). They don’t put a backlight in their handheld games until almost a whole decade after the release of the Game Boy (I have my own theories, which I am more than happy to elaborate on later**). Specifically with the Game & Watch, the team had to say “no” to a lot of ideas for hardware changes or gameplay features, many of which were probably great, but weren’t actually necessary to make a good product.

Kano: With everyone brainstorming, the ideas would evolve and the games would grow increasingly complicated. Yokoi-san would pare away the unnecessary parts, focus on the core element of what was fun, and emphasize the product’s appeal. (2)

This is a difficult skill to build, but a strong product vision will help you ease into learning when to say “no” to an idea, no matter how great it sounds.

Special bonus: Keep in mind that we all can’t be Nintendo
I’ve said this before and I’ll say it again: in this case of the Game Boy’s bonkers success, Nintendo is the exception, not the rule. If your MVP doesn’t start the metaphorical avalanche that the Game & Watch’s successor the Game Boy did, that does not mean you failed. (Ultimately, as long as you were able to learn something from your MVP that allows you to iterate, it’s hard to say that you failed.) Success of your product is ultimately defined by you and your team, not some dude on Twitter with an anime character for an avatar.

 

**The main article is done, but here’s where I expand on my running theory of why it took Nintendo a decade to backlight their handhelds, as I promised earlier.

 

Technically, the first backlit handheld was the Game Boy Light, which was an exclusive release to Japan back in 1998 (8). This, in my opinion, doesn’t count, because since the next handful of systems after it were not backlit, it was more of a one-off than anything else. The first backlit handheld which resulted in every handheld following also being backlit was the Game Boy Advance SP, which launched in 2003. Remember: the Game Boy line started in 1989 (or we could call it 1980 if we want to include the Game & Watch), which is a very long time to not include a backlight, especially considering many of Nintendo’s competitors backlit their handhelds much sooner.

Instead, Nintendo waited over a decade to add a backlight. I came up with my hypothesis as to why a few years ago, while I was examining the progression of their handheld design. My hypothesis is rooted in Nintendo’s vision for handheld gaming we discussed earlier—being the Ultimate Boredom Elimination Machine™ for their customers. This boils down to two main things: playtime and cost.

Me right now.

To try to keep this as short as I can—backlit handhelds in the ’80s and ’90s cost much more to make (and therefore sold at a higher price point), and also had a much shorter battery life. So not only was the value of playtime compromised, but how much it cost to the customer was, too. These are both things Nintendo takes seriously, as they are also both things which their handheld philosophy is rooted in. Therefore, they didn’t add a backlight until they were able to ensure playtime was not sacrificed and cost of the console didn’t spike as a result.

I argued for a long time about this theory with Tom, the first manager I had as a PM (and bless him for even entertaining me on this in the first place. He’s great). Tom believes that Nintendo’s decision was firmly and solely rooted in manufacturing costs and nothing else. I insisted that that was only part of the reason, folding up into a much larger vision that is Nintendo’s philosophy on handheld gaming. Writing this article has only further convinced me that I am right. Nonetheless, Tom and I will probably argue about this until the day we die, which is the only way I would ever want it (but I’m pretty sure I’m right).

 

References

  1. “Using a Calculator Chip.” Iwata Asks, iwataasks.nintendo.com/interviews/#/clubn/game-and-watch-ball-reward/0/1.
  2. “Test Models with Little Bulbs.” Iwata Asks, Nintendo, iwataasks.nintendo.com/interviews/#/clubn/game-and-watch-ball-reward/0/2.
  3. “DS Finally Outsells Game Boy, Best-Selling Handheld Ever.” Destructoid, www.destructoid.com/ds-finally-outsells-game-boy-best-selling-handheld-ever-173069.phtml.
  4. Parkin, Simon. “Shigeru Miyamoto: A Rushed Game Is Forever Bad.” The Guardian, Guardian News and Media, 27 Apr. 2012, www.theguardian.com/technology/gamesblog/2012/apr/27/shigeru-miyamoto-rushed-game-forever-bad.
  5. Campbell, Colin. “Why Nintendo’s Satoru Iwata Refuses to Lay off Staff.” Polygon, Polygon, 5 July 2013, www.polygon.com/2013/7/5/4496512/why-nintendos-satoru-iwata-refuses-to-lay-off-staff.
  6. “Absorbed In Development.” Iwata Asks, Nintendo, iwataasks.nintendo.com/interviews/#/clubn/game-and-watch-ball-reward/0/3.
  7. Staff, IGN. “Game Boy Inventor Dies in Car Crash.” IGN, IGN, 7 Oct. 1997, www.ign.com/articles/1997/10/07/game-boy-inventor-dies-in-car-crash.
  8. “Game Boy Light.” Nintendo, nintendo.fandom.com/wiki/Game_Boy_Light.
  9. Maurya, Ash. “Don’t Start With an MVP.” Love the Problem, Love the Problem, 29 Mar. 2018, blog.leanstack.com/dont-start-with-an-mvp-aa883de5cd18.

 

(This article was originally posted on Kongregate’s Developer Blog.)


Related Jobs

Cold Iron Studios
Cold Iron Studios — San Jose, California, United States
[09.18.19]

Senior Systems Designer
Insomniac Games
Insomniac Games — Burbank, California, United States
[09.18.19]

Character TD (Rigger/Technical Animator)
Disbelief
Disbelief — Chicago, Illinois, United States
[09.18.19]

Junior Programmer, Chicago
Disbelief
Disbelief — Chicago, Illinois, United States
[09.18.19]

Senior Programmer, Chicago





Loading Comments

loader image