Validating Product Ideas. Tomer Sharon

with monster drinks and Soylent, this book is your bitter greens. And in a world abundant with ideas, the infrastructure to produce them, and the capital to fund them, Tomer offers perhaps the single most important tool—the ability to recognize ideas worth pursuing.

      Tomer’s motivation grew out of his own research. After hundreds of interviews with founders, venture capitalists, and product designers, he found them asking the same questions: How do I know who my users are? What do people need? Can people actually use the product? These are the questions that he guides readers through answering in a book that can be put immediately into practice in product development.

      This book is not fodder for cocktail conversation. You will not read it on the subway ride to the office and wow your colleagues with a tweetable headline for the company blog. This book doesn’t herald a new fad in design. Rather, it charts a course to master the fundamentals that are all too often overlooked.

      If you are new to product research, use this book as a primer. If you are a pro, use it as a gut check and a checklist. Use it to clear your head when you feel like you have too many opinions and not enough sound judgment. Use this book, and you will be practicing the hard and rewarding discipline of fast, high-quality, impactful product research.

      —Benjamin Gadbaw

      Designer, investor, teacher

INTRODUCTION

       Eighty-six percent¹ of product ideas are born from a developer’s personal pain. These ideas are for products nobody needs. Developers believe research with users is a waste of time. They perceive their product as a coding exercise. To validate their idea, they ask their sister if she likes it. She says yes.

      I live in North New Jersey, East Coast USA. For four years, we leased a house in which we had a detached garage (see Figure I.1). We never parked our cars there because the driveway between the garage and the street was 100 feet (~30 meters) long and shoveling that much snow in the wintertime was not a skill I had acquired (or wished to acquire). We mostly used it to store “outdoorsy” toys for our kids. Every winter, when the weather turned very cold, the keypad to open the garage door froze over and stopped working. Definitely a problem.

      To open the door, once a year, I crawled into the garage through a small window (which became smaller and smaller every year, I have no idea why) and turned the garage door system from Automatic to Manual. This way, the kids were able to open and close the garage door while bypassing the frozen keypad. When spring arrived, I switched the door opening system back to Automatic. Same story every year.

FIGURE I.1 My garage door problem. The keypad froze during winter and instead of calling a technician, I crawled through the window and switched the door to manual.

      I had a problem and found a bypass for solving it. The problem was that my garage door keypad froze over every winter. The solution was to pick up the phone, talk with my landlord, get a quote from a technician to fix it, argue with my landlord about the cost, get another quote, and so on. Yet, I wasn’t doing that for some reason. I didn’t care enough about this problem to solve it properly.

       Why I Wrote This Book

      My story isn’t unique. We all have problems that we work around for one reason or another instead of doing the logical thing. In my story, the important problem was my relationship with my landlord, not the frozen keypad. It’s the same thing with product development and user research. In far too many cases, people, teams, and organizations develop products that nobody needs, that do not solve any problem, or even worse, solve problems that users don’t care enough about.

      In this book, you’ll learn how to answer your most burning questions about your users (or potential users) with quick-and-dirty research techniques that anyone can apply. You’ll learn (among other things) how to identify what users really need, who these users are, and how they currently solve problems they care about.

       The Structure of the Book

      The structure of this book is simple: it’s based on interviews I held with 200 startup founders, enterprise product managers, and venture capitalists from all over the world. During those interviews, I asked what questions they asked themselves about their users (or future users). I gathered hundreds such questions together, which I then, with the help of 50 entrepreneurs, organized into eight groups. Each group of questions was summarized into one question, which became a chapter in this book. Furthermore, each chapter is a step-by-step, how-to guide that answers the question at stake with one to three user research methods (see Figure I.2).

FIGURE I.2 Each question (asked in a different stage of a product’s lifecycle) represents a chapter in the book.

       Goals of This Book

      The clear result of my interviews with 200 product managers and startup founders was that there’s a need for lean user research guidance that is specific, approachable, and easy to implement. The following are the goals set for this book.

       Change How People Answer Their Most Burning Questions About Users

      Probably the most important finding of my research was uncovering the top questions that product managers, startup founders, and venture capitalists ask themselves about their users or potential users (see Figure I.3). The good news is that they ask the right questions. Not only that, but they even know the order of importance of these questions. Sadly, the bad news is that people answer these questions in invalid, unreliable, and sometimes unbelievable ways. Here are some representative examples:

      • Who are my customers?

      “We look at analytics data.”

      • Do people need my product?

      “Doh, of course they do, because we created it.”

      • Is the product usable?

      “We focus on UX. We use the product ourselves.”

      • Is our product better than the competition?

      “We have no competition,” then (after acknowledging they do),

      “We do things differently.”

      • Is our product getting better?

      “We improve it all the time, so yes.”

      • Do people want the product?

      “I asked my sister, and she said yes.”

FIGURE I.3 The top questions product development practitioners, startup founders, and venture capitalists ask themselves.

       Shorten the Road Between Wanting to Do Research and Actually Doing It

      This book will show you how to do research, including detailed steps, templates, examples, videos, resources, and practice exercises. You’ll have everything you need to start your own research to answer your questions about users. Basically, you’ll have everything you need with this book, its companion website (leanresearch.co),