Episode #282 Amy Jo Kim - Turbocharge Your Product Design with Game Thinking Live!
You’ve got a groundbreakingly innovative product idea, and you’ve assembled a crack team of designers. You know exactly what you want to do, but you’re unsure of how to do it. Without a framework to drive your product development, it’s Game Over.
Amy Jo will show you how a game designer approaches their product development and how they get to a design that their users love. From her research in how game designers think, you learn the value of refining and testing a simple, stripped down MVP (minimum viable product), long before you start adding all the fancy stuff.
To see the video of Amy Jo's talk, visit the UX Immersion: Interactions section in our All You Can Learn Library.
Amy Jo Kim: What a great looking crowd. It's great to be here. Long ago in my career, I was a UX designer. I love UX designers. You're doing incredibly important work. I've gone beyond that to be a product and game designer. Today, I'm going to take you on that journey so that you too can start to approach what you're doing like a game designer, but with a product design focus. I'm really glad you're here. I'm excited to share with you some power tools that I've collected, iterated, and tested over the years, really the best stuff. It really works in the field. First, I want to know if you ever feel like this. Can you relate to this cartoon? Where you've gone down a cul-de-sac, you thought it was a good idea, and you realize, "Darn. I wish I had known earlier that that wasn't really the right way to go." That's really what this talk is about is how you build a product better and faster. How you can accelerate your path to product market fit. I want to know if you've ever felt like this. You're at the beginning of a project. You really want to accelerate your process. You want to get to that product people love more quickly. Or, maybe, you're getting a lot of feedback from all sides, from your stakeholders, from your engineers, from users, from different users, and it's conflicting. How do you sort all that out? How do you run your user tests and then take that feedback and turn it into product decisions? If you're an entrepreneur, how many of you feel that you're an entrepreneur or intrapreneur? Intrapreneur is every bit as much as entrepreneur is. You're working in a larger corporate setting trying to do smart innovative work. If so, you have probably faced the time where you're sitting around a table with your team trying to figure out, "How are we going to take this great idea, this expansive, engaging idea we have and turn it into the first step, a strip-down simple MVP? How are we going to do that?" I don't know about you, but I've wasted or I should say invested many, many hours with many teams, dozens of teams sorting through these issues. I've felt the pain of projects getting canceled, projects circling the drain, projects launching with great acclaim and then going [makes sound] . I've felt that. What I've collected and I'm going to share with you today actionable techniques to make a better product in less time using a framework I call "Game thinking." As Jared mention, I'm a social game designer. I'll tell you some more about the games I've worked on, plus I worked a lot on products. I'm an entrepreneur. I've done my own VC funded startup and felt the pain the pain of that. For the last two years I've been a startup coach working with dozens of teams in Silicon Valley but also all over the world helping them bring their products to life. Those are some of the companies I've worked with, everything from very large multi-nationals to very small startups. From one it's a couple of guys with a paragraph on a piece of paper and a lot of light in their eyes, and a lot of ideas. I'm going to take you back and help you understand why I'm so passionate about this topic, and where I come from. It would really help you understand how what you're learning here is different from most of the gamification that you'll run across. Years ago, I had this totally awesome gig at Paramount Communications which was then purchased by Viacom. My job was to be a prototype in new product designer for taking Silicon Valley technology and translating it into great brands like MTV, and Nickelodeon, and Star Trek. We worked with top creative there to prototype new ideas. It was a great gig. I learned a ton about early prototyping and also about pitching. I got laid-off, and I started my own business. That was the beginning of my journey as an entrepreneur. I started my own digital design studio, worked on a bunch of projects, some didn't go anywhere, some turned into big hits. I was on the original design team for The Sims, for eBay, for Ultima Online. That was before World of Warcraft, it's similar thing. I learned a ton working with these awesome product leaders both game designers and product designers. I wrote a book that some of you might know called "Community Building on the Web" based on those experiences. One day I got a call. Does anybody recognize who this is? I'll tell you in a moment. This was someone I had known for years. He came up to my house in Half Moon Bay, California where we lived. He told me this brilliant visionary entrepreneur. He told me about a crazy idea he had where people that didn't have any musical talent playing plastic instruments would feel like they were in a band. He asked me if I would help bring it to life. I joined the Rock Band team, right at the beginning, when we hadn't built anything, when we had a crack team of designers working under conditions of extreme uncertainty, not sure if we could really pull it off. Turned out we did pull it off. That game turned into Rock Band. That was one of the pivotal experience of my life. You'll find out a little bit more about what I learned from that that was backed up by later experiences in startups in a moment. One of the things that was amazing about Rock Band was right at the beginning, Alex Rigopulos, the CEO of Harmonix, that's who that was had this idea that this game could take these people without a lot of musical skill, and actually make them better at a real world skill that we translate into the physical world. A lot of people told us we were nuts which happens on every innovative project. Recently, the study was published that worn my heart. Turns out Rock Band players actually do have statistically better musical perception than average people as a result of before and after playing the game. Alex's dream all those years ago really came true. It's pretty widely known now that not all games but some games can really affect and build up your real world skills. There was an interesting thing on Rock Band. I'll admit it, I was a lot less experienced then, and I was really frustrated because part of my job as the social systems designer on the project was to study our aspirational audience. We knew we needed to reach a really big audience, bigger than just Guitar Hero players which is a previous game. For it to make sense, very expensive game to build, very expensive game to market, people were like "Who's going to buy $160 bunch of plastic instruments? You guys are crazy. This is going to fail." We knew we had to nail a larger audience of party gamers, but all our early work when we were bringing the game to life, just bringing the core loop of that playing a song, none of the fancy stuff, just the core loop. All our work at that time was going on with early adaptors, with music gamer freaks, these kind of people, the people that are really into it, and we couldn't wait to play test Rock Band, so I had a lot of trouble with that. It was a paradox. It's like "That's not our addressable market, it's not who we're reaching for. Why are we testing them in these early days? Why not these other people," and then I learned, and you're going to learn too. Rock Band turned into a hit, so it all worked out even though I had my doubts. That led me to working on more breakthrough hits, Lumosity, Happify, Covet Fashion, and I learned a lot again about what worked and what didn't work. I also did design work for major brands on their some core ship little things including "The New York Times" paywall experience for their digital subscriptions, Netflix's Onboarding Experience, bunch of stuff for EA, a lot of mobile games for Disney and some mobile apps as well. I've had a lot of experience and I know how hard it is to get innovative work done within a large organization. I also know it's possible. I've seen it. I've been part of those teams. I've also seen it flop. In 2007, I don't know if you guys remember...Anything you remember Brain Age on the Nintendo DS? That was a pivotal moment for us in gaming. The Nintendo DS is a little part of a game machine, and Brain Age came out. That was the first brain game that came on to the scene. What happened was Nintendo sold huge amounts of hardware to older people who would never bought a DS before and wouldn't consider it, and they bought it just for that game. A lot of VC money started flowing in the brain games and we picked up some of that. We did a brain game startup. That was incredibly valuable and incredibly painful and difficult for me to be the CEO of a startup. It all worked out. We sold to a larger brain games company. I learned a lot, but I also made a bunch of mistakes doing that. I learned some hard lessons that apply now. I'm sharing with you today about what really makes early innovation work and what really gets in the way. I also learned some insights about game thinking and the punch line. In about 20 minutes, you're going to really be all over this. Is that it's really about skill building. It's really about making the customer that you have, the player that's playing the game better than before at something they care about. Things are going along well. I'm working for major brands, working with startups. One of my favorite clients challenged me. He said "We love your work, we love working with you, we're in a hurry, we're running out of money, we need to raise our series B. We want you to take all the tools and the framework you have, package it up with instructions on all my engineers and UI people and testers can use it at an incredibly low cost, much less than you would normally charge. Make a toolkit so we can use it." I said "I'm really busy and that's really hard to do," but he wouldn't let up. He's Israeli. Perhaps some of you worked with Israelis, they're very persistent, sometimes there's yelling, I'm OK with that. I love this guy. This is Ranan Lachman. He's the CEO of Pley. I said yes. It was a really hard challenge I couldn't resist. I packaged it up in to a tool kit into interactive templates with step-by-step instructions. We got way better results than we thought we could. He told me, "That was six months of progress in six weeks." We pivoted the idea. We tested it. We've built an MVP that was much simpler than any of them thought it was going to be. It all worked out. They went on raise their Series B. They're continuing to have a lot of success. That's when this system I'm going to tell you more about later was born -- the getting to alpha system. There's a lot of frameworks and good ideas here. What I've learned is that a lot of people, they believe. They buy into lean. They buy into agile. Yes, I get it. Then, there's a big leap from the theory of lean and agile and, how do you actually do it when you're bringing a product to life. That's the gap that this system fills. That's what Ranan and my other clients are really struggling with. That's what I learned to do on all these other projects. It boils down to a faster, smarter way to test your high-risk assumptions. If you're at all into lean or agile, you know that's a really important part of bringing products to life. Works for games, too. Today, I'm going to talk to you about a subset of this -- a really foundational subset that will get you started -- four strategies for better, faster product design. They all work together. They're not the whole thing, but they're a great foundation to get you started on the right path to game thinking. The first one is deceptively simple. Design your experience to evolve over time. This is design that's all about how it works. It's all about systems, not about graphics and how it looks. You want to ask, "What is my customer's end-to-end experience? How does it evolve over time?" You want to build a customer journey -- not a marketing style customer journey with every touch point -- four key stages that capture how your customer's skill level and what they're ready for evolves over time. There's the discovery stage. Some of this is going to be familiar. Some of it is going to be new. We all know what that is. That's when there's someone who's a visitor. They're not a member yet. They haven't bought your product, downloaded your app, signed up to use your SaaS service. They're discovering it. Is it for them? That's a very specific stage where their learning needs are they need to know if it's for them, if it's worth their time. Onboarding is another stage. The learning needs are really, "How do I learn the ropes? Who's here? How do I start getting value out of this?" Habit building is the next stage. That's not the same as onboarding. You can think of it as your day 21, your day 30, your day 60 experience. Once someone's learned the ropes, once that's out of the way, what pulls them back? What is that repeatable, pleasurable activity that pulls them back, makes them want to come back regularly to your offering? Then mastery, which is completely missing from all of the habit building literature. Mastery is a stage that might sound like it's just for gaming, but it's not. It's for everybody. Mastery is about leveraging the skills and knowledge that someone has built up by using your product. At that point, it might be two to five percent of your overall population of people using your product, but those are incredibly important people. What they want to know is, "How can I leverage everything I've done? Is there something new? Is there something different that I've earned the right to get access to?" Let's look at Slack. How many of you use Slack? Great. That will make it a good. Let's look at what the end-to-end journey looks like in Slack. I want you to pay attention to the narrative over time. As your user, as your customer uses your product, the most important narrative that's occurring is in their head about how they're getting better, and becoming more who they want to be, getting their job done -- whatever it is -- by using your product. How many of you were told to use Slack by your IT department? How many of you found out about Slack through your friends or teammates? Exactly. Slack is mostly discovered and it's built to be discovered socially through your friends and through your colleagues. People pull each other in. In fact, when you start using it, it's almost irresistible not to pull people in because it's fun. It's pleasurable to use. That's much more game-like than most enterprise software. It's the way that people get pulled into new games is through their friends. In that sense, Slack is a lot more like Minecraft than it is like Yammer. Onboarding takes place by having an interaction with a friendly, helpful bot. This is really interesting because Slack is a multiplayer environment. It is in a sense a multiplayer co-op game. You are cooperating with your teammates so you all can do something together. Yet, the first experience you have at Slack is a single-player interaction with a bot, not with a human. Why do you think that is? Turns out, this is an old gaming trick. In onboarding, if you have a multiplayer environment, and there's some ropes you need to learn, if there's some stuff you need to learn to get value out of it... Those of you who've ever played a console game that's strategy or shooter, you've probably played in a training level with a bot. They teach you the ropes before releasing you into the multiplayer fray of real players. They do this because it's much less embarrassing to make mistakes and try things when you're interacting with a bot than real humans who are by definition better than you are, because they're not newbies. It's a very good trick. Slack is all over this trick. I'll tell you more about why that is in a moment. Doesn't mean everybody should do onboarding with a bot, but it's a very useful way to do onboarding. You learn enough to get you going. You learn how to get help when you need it. Then if it pops up again with suggestions, it seems very natural, part of the narrative. Habit building. What happens after you've learned the ropes here in your day 21 experience of Slack? It's fundamentally about using it, but also about customization. Customization is the through line of Slack. You start to discover these layers of customization. You discover the emojis, you customize your channel, you start using the integrations, etc. You don't have to, but it's there for you to grow into once you've learned the ropes. Then, mastery in Slack is also very coherent with its narrative through line, which is master is about even more customization. You've participated in your first channel? Now you can launch your own. You've interacted with a bot? Now you can program one. You've used app integrations? If you've got your own app, you can use Slack's API and ecosystem to integrate, and make it available to more people. In that sense again, Slack is much more like Minecraft with its open API than it is like Yammer. If you want to build a product people come back to again and again, create an experience that gets better as your customers become more skilled. Second principle is to find the fun in your core loop. That's two ideas packed into one, but it's really useful on several levels. Raph Koster wrote a great book called "Theory of Fun." He loves to say that fun is another word for learning. It's really true. The thing is, fun means different things to different people. A lot of people that are new to gamification think fun means competition, especially if they like competition. A lot of people hate competition and find it really off-putting. Fun means different things to different people. You need to know what fun means to your players, to your customers. Little game theory 101 -- enough that you can move on and then pull this out at your next cocktail party. This is a definition of a game that I learned when I first started doing game design. It was in a textbook called, "Rules of Play" and this is very much a competitive theory. It's a system where players engage in an artificial conflict, defined by rules, results in a quantifiable outcome, so far so good. Turns out that's a zero-sum game definition...there's two kinds of games, the first is zero-sum. In a zero-sum game we are framed as opponents. If I win, you lose, and there is a limited resource that is divided up among the winners. That's a zero-sum game. Any head-to-head battle, any rank-order competition, from the Olympics to the leaderboard you saw yesterday on some website, all war simulation games like chess, and polo, and go, and most gambling games are zero-sum games. Here's the thing though, when I was working in gaming I worked on Rock Band, The Sims, these games didn't fall into this definition and I scratched my head and I was like, "What's going on? These are different. They don't have a clear End State. They're more like people having fun playing together." I came up with my own definition and realized that it was very close to a non-zero sum game. Non-zero sum game is a game of abundance versus scarcity. In a non-zero sum game we are partners and we can win together and lose together. Contrary to zero-sum games, the more people that play, usually, the better everyone does. Think about a Kickstarter project. A Kickstarter project is a non-zero sum game. The more people that contribute the better everyone does, and there's a win state and a lose state. Games like Double Dutch on the playground, unless you make it a competition, is non-zero sum, people are playing together. Pictionary has both a partner, is the partners are playing a non-zero sum game and the competition itself is zero-sum. Martial arts is practiced in the United States, is often non-zero sum, everybody wins together, and then a charity walk is a great example. The more people that play the better everyone does. Be sure that you don't jump to conclusions, and that you find out what kind of fun your customers are looking for. It's really important if you know, do they want to be partners or opponents? Do they care about self-expression or exploration? In the workshop tomorrow we're going to delve deep into this with some tools, but I just want you to think about his now, and make sure that when somebody pitches you their gamification strategy think about this and make sure you can see through simple attempts to say everybody's competitive, and everybody wants a leaderboard, because it's just not true. That's the finding the fun part. Let's talk about a loop. This is Dan Cook, he's one of my idols, and a really, really good friend, awesome game designer. He likes to say that, in a loop you're learning a skill and updating your mental model, that's what leads to player delight. That's a really profound statement and important to understand. You're UX designers. You know about updating mental models, same with gaming. Think about a fake planning page. A lot of times when I start working with a startup somebody on the team says, "Well I do Lean Startup and I know a fake planning page is the right MVP every time." Sometimes a fake planning page is really valuable. It can help you test market interest, but if you remember back to that four stage journey, that's the discovery stage, the fake landing page. It has nothing to do with testing your core value prop, or your core product experience, so don't let it fool you into thinking you've learned something you haven't. Now we can get a little closer with an operant conditioning loop. How many of you know what operant conditioning is? Those of you who don't, guy named BF Skinner, early 1900s, behavior psychology, and there's something called a Skinner box, which is a term that was used for, basically, using external rewards and tracking minute little behaviors to manipulate overall behavior. A lot of games, especially some of the Zynga games, sort of had that property and here's the thing, by the way, this is from the habit loop which is a New York Times best-selling book about "The Power of Habits," and this is an operant conditioning loop. There's some sort of cue, like a click, there's some routine which often isn't even conscious, and then there's a reward that's designed to shape behavior. You can actually shape short-term behavior with this. I did it in grad school, but you will never get long-term engagement or player delight because it has nothing to do with updating mental models and helping people become more skillful. It's just behavior manipulation. If you want to drive long-term engagement and you want your customers to be delighted with the experience you need to focus on skill building. That's the thing that makes your customers more awesome and makes them want to stick around. This is a skill building core loop, we're going to dig into this in a moment, and this is a model that I've developed. It's a very simplified model of a core system, a core feedback loop. The thing to understand is that when you look at games, and products, and all kinds of things, every complex system that works started as a simple system that works, that was then developed. You really need to boil down what you're building into the simplest possible system, get it working, and then build from there. This is a tool to help you do that. You can think of it as your 21 day experience, and again, so many of the mistakes that I help startups avoid, and diagnose, and fix are around them being very excited about something they've built, that's actually onboarding, not...this is much harder to get right than pretty onboarding. Let's talk about Slack. Let's talk about how their core loop came into being, how they found the fun in their team collaboration tool. Here's Slack's core loop. It's one of many but it's like the simplest one. Those of you who use it can recognize it. There's an internal trigger, by the way, there's many kinds of triggers. You always want to start with an internal or emotional one that's native to the person. The internal trigger is FoMo, you want to connect with your team, you want to, "What's going on, I need to stay up to date?" The activity, or activity chain, it can be either, is reading and responding to updates, similar activity to Facebook, and to Twitter, and to Instagram. It's very engaging. The feedback loop is there's no more updates, I've no more unread's, I'm done, I've done it. Very similar feedback loop to email. The investment path, which involves progress, is really around customization. Customize your channel, your expressions, everything like that. That gets you more and more invested. Any of you who've ever customized a character in a game, know how hard it is to walk away from something you've customized. Remember, skill building is the thing that actually makes customers better than before, it makes them more awesome. The core loop is your ticket to making your customers more skillful. If you want to build long-term engagement don't start with pretty onboarding, or don't start with discovery, start with a very simple, stripped down, skill building core loop. Again, tomorrow in the workshop we're going to dive deep into it and map these out for your own projects. Another one is to connect early with your superfans. Remember that story I told you about Rock Band? Where I was puzzled why we were testing so early on these superfans, these early passionate customers, instead of on our addressable market? It turns out this is Paul Buchheit's quote, he runs why Y Combinator now, he knows startups, he knows something about them. I love this quote and it took me years to really understand it. If you want to create something awesome, create something that just a few people love, even if a lot of people don't get it right away. A lot of people thought we were crazy with Rock Band and thought it was stupid. The superfans didn't, they couldn't wait to try it. How many of you have heard of "Crossing the Chasm" by Geoffrey Moore? This is a great book and it's a whole program. Geoffrey Moore, in 1991, told the story of how he took a hobbyist's computer that was popular in garages and at hobbyist meet-ups, and turned it into a worldwide consumer hit. That story was about Apple, and he was the marketer who took Apple across the chasm from being an early adopter hit, into being a mainstream hit. What most people don't know is that Geoffrey Moore's work was based on a model done by this guy three decades earlier. This is Everett Rogers. Rogers was a scientist at Bell Labs. He was not an entrepreneur, or marketer, he had no agenda. He was a scientist who collected a whole bunch of data about how innovation spread in populations, this is pre-Internet, and then map that data into something called innovation diffusion theory. It's exactly what Moore's book was based on. What Moore introduced was the chasm. The chasm between early adopters and early majority. It turns out this is critical. If you want to cross the chasm, what you have to do is first get that early hit. Find a few passionate early customers. Lots and lots of people get excited about crossing the chasm before they've really nailed their early adopters. The big lesson I learned on Rock Band, and eBay, and The Sims, and Covet, and all those games is that you can't cross the chasm if you haven't nailed your early customers. If you're innovating, that strategy just doesn't work. Some people really know how to do this. Will Ride is one of them. I've worked with him on a number of projects. He's the guy behind The Sims and Sim City. It was fascinating to watch him because he had this group of early passionate superfans. They were world builders and simulation enthusiasts, really geeky, even as geeky as Will, and he would nurture them, he had a mailing list, he'd invite them to meet-ups. I didn't really understand what he was doing. He would show them early versions of the tools we were using to build The Sims. He would invite them into these crude world building experiments we were running. He was so smart to do it because those people gave us crucial early feedback on really crude experiments. They had the imagination to see what it could become and give us actionable feedback. No, they weren't our ultimate market, but they were our partners, our co-collaborators as we were bringing the ideas to life, with lots and lots of small high learning experiments. That's how The Sims turned into a hit. The hit emerged from lots of chaos and lots of small experiments. Same thing with Stewart Butterfield, he took what was a multiplayer co-op game that he and his team were working on called Glitch, and built an in-house collaboration tool which turned into Slack. That thing they iterated on their core loop for three years before they added much else, and this is embedded in that story, is a very smart thing that you can follow, too. If you're trying to do something new and innovative start to echo Paul Buchheit's advice, solve a real problem for a very small group, not for the big market, for a very small edge group. If you can really nail that you can build on that and grow from there. So if you want to accelerate your innovation, start by finding and delighting your early passionate customers, the few, your superfans. Then lastly, this is something I learned in the last few years. It saved me so much time. It saved my clients so much time. I'm excited to share it with you. It's about building a game thinking road map. I love this quote from Frank Lloyd Wright. We can all relate to it. You software gets built and you're like, "Darn! I wish I had fixed that in wireframes," or, "I wish I had fixed that earlier." It's much easier to fix it earlier in the process. This is really all about how to get that information as early as possible. To recap, skill building makes your customers more awesome. Game thinking helps them leverage their skills -- these game thinking tools. A game thinking road map can show you as a creator, as a developer, what you should work on when. This is one of the hardest things about bringing products to life. I wrestle with this on every product I work on. I've done dozens of products. Let me take this apart for you. Up there in the X-axis we have the player's journey -- the customer's journey -- that we just reviewed. Then down the Y-axis, we have the developer's journey, which is you start with MVP early prototypes. First playable, we call that in gaming. Then, you're going to go through alpha and beta, developing it, you're going to launch, and you're going to expand after launch. Whether you're doing it internally with enterprise or externally, there's a similar process. The question is, "What should you work on when?" What I've learned through this process is that if you focus on your core loop -- your day 21 experience first -- let the onboarding be as simple as it can be. You can be the onboarding. It can be fill in a form if it's on a mobile app. Keep it super simple and focus on that core loop -- testing it, iterating it. Then, move on, develop onboarding more as you get closer to beta. Develop your discovery phase more as you get closer to launch. Then, develop mastery later. You think about it all the way, but that comes later. You're going to learn a lot about what your mastery system should be by interacting with your super fans. Putting all that together can really save you a lot of time. It'll help you know what to build first in order to get to a product that people love and want to come back to, which is the goal. Thinking about how this applies to Rock Band, I told you how frustrated I was that I didn't understand why we were testing with all those geeky, early adopters, those Guitar Hero super freaks. It turns out that was really smart. We spent a good six or seven months working on playing a song, getting the feedback right, getting the feel right. I was so frustrated because I wanted to design levels, and I wanted to design cool avatars, and tattoos on them, and clothes, and all that fun stuff -- all the stuff that you see. It turns out that system underneath it, the feel of it, getting that right, if we, the people I worked with really taught me this, if we didn't get that right, none of that other stuff mattered. It's the same with you. If you don't have a strong core loop, you're building a leaky bucket. That's part of why you start with it. Same with Slack. They didn't start with a lot of fancy onboarding. They didn't even start with something they wanted to ship. They needed something that would work for them. That core loop, the Slack team, while they were building this game as a distributed team, they tried stuff and found what worked for them. When the game failed financially, they pivoted and said, "What do we got? We have a few dollars left." "We got this tool. We've been building it for three years. It works really well for our team. Maybe it could work for other teams," and Slack came to be. I want to do a real quick case study of Happify, which was one of the projects that got a tremendous value out of these game-thinking tools and had a pretty major pivot and some challenges to our thinking. I thought you could relate to it. This was run by two brilliant Israeli entrepreneurs. There's a theme here. I really like Israeli entrepreneurs. They had this idea because they'd had a profound experience learning science-based happiness skills in their own lives. They wanted to turn that into a game-like experience for people. We struggled. We didn't have any money up front. We needed to build a prototype, really nail our early customers, and prove at the business model. We had weeks to do that. We went ahead and we clarified our product strategy using the MVP canvas, something I'll talk about more later. We had three hypotheses to find passionate customers for this. We tried them all out really lightweight before we built a line of code, found the ones that really made sense that also made sense for our business model, focused on those as our early super fans, prototyped our core loop. It turned out that customers who were really converting and interested were moms who had their first kid, who are recently out of the workforce, who are fairly affluent, and depressed because they were home. That's who we targeted first. These entrepreneurs...they came out of the gaming industry. They wanted the interface to look like a tower defense game. We mocked it up and showed it to the moms. Really rough prototypes -- so rough we were uncomfortable showing them. That's key. You want to test things uncomfortably early. We showed it to them and they're like, "That doesn't look relaxing. That doesn't look fun." Then, we backed off and were like, "Uh-oh. What does look like fun?" We dove in and we said, "What do you do to make yourself feel better when you're a little blue?" This is what we heard -- Pinterest. "I go to Pinterest. I look at pictures of three-layer cakes I'll never build, but maybe I could."
Amy Jo: Can you relate? "I go to Pinterest. I see cute puppies with really nicely tied bows on them. Everything looks so orderly and beautiful." That's what we heard. We completely redesigned the interface to look like Pinterest, and to be a stream, and to be much more flat and 2D. Then, everything took off. This all happened before we built a line of code. The result is that Happify is now the market leader in digital happiness. They're doing really well. They're actually being adopted by insurance companies as part of medical programs. They've got a whole host of competitors nipping at their heels. There you have it. That was a whirlwind tour of game thinking, four strategies for faster, smarter product design. I want you to think for a minute about what it would be like if you could take this and apply it to your product. What would it be like if you could use this and really supercharge and accelerate your product development? What would it be like if you didn't have to sort through lots of feedback and you could find exactly the right five customers to talk to early to iterate your development the fastest? What would it be like to take those customer insights and very quickly turn them into product-ready form that would tell you what MVP to build and why? What if you could do all that in a few weeks? That's what this system provides. That's the transformation that it provides. I've learned a lot. I'm very data-driven. How many of you would consider yourselves data-driven? Just curious. I'm a very creative person too, but I'm data-driven. I don't believe things until I see data to support it. I've been testing this system since Ranan, my very first person for the system. I've been testing it. I've tested it with hundreds of entrepreneurs and I've seen what works. He got a tremendous amount out of it. Megan Berwick is a enterprise SaaS entrepreneur. She used the system to test, and refine, and pivot her ideas, and actually attract enough early clients that she quit her corporate job, and launched her own SaaS enterprise startup, which she's now running as the CEO. Amanda Pouchot similarly had already founded Levo League. Some of you may have heard of this. She knew from that experience what happens when you don't get this right early on. She had that experience. She used these ideas to test her idea for a new product for parents of school-age children and got such good results that she too quit her job and pursued it full-time with a distributed team, all of whom are using these techniques now to keep moving fast. That's my data -- that and hundreds of other experiences. If you love this stuff, first of all, go try these techniques on your own. You're all really smart. I'd love it for you to try it and let me know. If you want to make really fast progress, and you want online tools, and you want templates, and a framework, and coaching and guidance to go through that quickly and supercharge your fast path to product market fit, then you can sign up for updates here. We're going to be launching in early May an online master class that's available to anybody worldwide who wants to apply game thinking to their project, and innovate faster and smarter. Thank you for listening. I'd love to stay in touch. Please follow me on Twitter. That's where I share lots of tidbits and design tips. You can subscribe to my blog. You can check out our Getting to Alpha programs. I hope that you take these ideas and use them to streamline your path to success. Thank you.
Jared: Thank you very much. I have a question, which is, "How have you seen the best way to convince management about some of these ideas?" If they start to hear, "Our banking system needs to be a game..."
Amy Jo: No, I never said anything needed to be a game. You're right, they might hear that.
Jared: Right. How do you do that?
Amy Jo: The way that I've seen work best -- and I'd be curious if you guys have seen this, too -- in a large corporation -- I've actually seen a lot of failure as well as a lot of success -- the success all has a similar pattern. There is a small team who is working on a small win. First of all, you pick a small project to work on. What you need to do to convince management is you need the freedom to do a project that's small and you need a win. Then, they will be convinced. You don't use words like, "This is a game." A lot of times, big corporations will pull me in to give them a workshop and a talk to explain that. What this really is is operationalizing the best of lean and agile through a lens of driving long-term engagement. If you explain it that way, there's no game in there. I've seen a lot of resistance because people are used to things. Where I've seen tons of success is there's some stakeholder who believes in it. They have a small project. It's under the radar, but it's proved. The other thing is measurable metrics that you can use to show them. One of the things I do in the MVP canvas I mentioned earlier is specify the early metrics. How are you going to tell if you have a win or not? You need metrics. You're not running hundreds of data points. You need a different kind of metric -- early metrics. It's a special kind. I found that combination of clear metrics, small win, and then internal stakeholder, that's the thing that management...at that point, they don't care about the rhetoric. They care about the win. Have you guys ever seen anything like that -- that process?
Jared: Who has questions for Amy Jo? One back there. Microphone coming to you. Here you go.
Audience Member: Hi. I'm wondering if you have any comments about incorporating game thinking in enterprise apps.
Amy Jo: Yeah, I think it's a great idea. I told you about Megan Berwick. She's an enterprise entrepreneur. She has a SaaS startup. It's total enterprise. It integrates with sales force. What Jared said about convincing stakeholders is really key. In terms of the process, you'll get better results faster if you do it this way. It's tricky because a lot of times, people don't know how to identify and test a core loop, which is why I've developed ways to help people, because it's hard. I've actually seen this work very well in enterprise. You have to tweak it to work. Here's the other thing, is what's the alternative? The alternative is do it the way you've usually done it, which will either be waterfall or maybe it'll be a lot of wireframes. The punchline of this whole thing is that if you want to bring a complex system to life, figuring out your core systems very early in the process and then iterating those is the fastest way to create a coherent product that works for everybody.
Jared: Other questions? Thank you very much.