Chapter 1. Early Validation
Figure out if people will buy your product before you build it.
Learn which research methods are best for early validation.
Understand user pain in order to build a more compelling product.
Most startups begin with an idea for a fabulous new product. Most startups also fail. These two things may be more connected than you think. The problem is that the vast majority of startup ideas are based on things that somebody thought sounded cool or interesting, rather than something that solves a real problem for real people. This is why companies need to spend time validating their key hypotheses as early as possible.
What is a hypothesis and why do you need to validate (or invalidate) it? A hypothesis is an assumption that you’re making. And, trust me, you are making a lot of assumptions when you start a company. For example, you are almost certainly assuming that there are people who will want to purchase the product that you’re building.
The problem is that some of these assumptions are wrong. If the ones you got wrong are important enough, you’re going to be out of business. Let’s talk a little bit about how to avoid building your company on a lot of invalid assumptions, shall we?
First, instead of thinking that you have to come up with a brilliant product idea out of thin air, I’d like you to shift your thinking a bit. Think about every product as a solution to somebody’s problem.
Let’s look at some examples. Word processors solved the problem that it was tough to edit something once we’d typed it. GPS navigation solved the problem that we were likely to get lost when away from our homes. Even Angry Birds solved the problem of how to deliver more pleasure hormones to our brains while we were stuck waiting for a train.
One of the most common mistakes that people make when thinking of a product idea is solving a problem that simply doesn’t exist or that isn’t bad enough for people to bother fixing it.
Whenever you hear about a company “pivoting”—which is Lean for “changing your product into something entirely different”—it simply couldn’t get enough traction with its original idea, and it had to switch to something more promising.
Some pivots may be necessary, but you want to minimize them as much as possible. To be fair, you probably can’t avoid them completely without learning to tell the future. And that’s OK. It’s the nature of startups to change, sometimes quite drastically. But typically, you get only so many pivots before you run out of money, so it’s in your best interest to validate your idea early, while it’s still relatively easy to change. In fact, the earlier you start to validate your idea, the less likely it is that you’ll have to pivot later.
Let’s look at how you can do that.
A Market, a Problem, and a Product Walk into a Bar
Before diving into some practical tips for how to do early validation, let’s go over the difference between a market, a product, and a problem.
A market is the group of people you think might want to buy your product. For example, if you are building a tool to help tax professionals or realestate agents or school teachers, that’s your market.
A problem is the reason that those people are going to use your product. If your product doesn’t solve some sort of a problem for people, then there is very little chance that they’re going to bother to give you money.
A product is simply the way that you’re going to solve the user’s problem. It’s the end result of what you’re building. It’s the thing that people, presumably in the target market, are going to pay you money for.
I know this all sounds a little simple, but it’s an important concept. A lot of startups are products in search of a market, and sometimes that works just fine. After all, how many people knew they needed to buy their books online before Amazon came along?
Other times, though, it can be disastrous. Every time a startup goes out of business because it “couldn’t get traction” or it didn’t “go viral,” there is an excellent chance that there simply wasn’t enough demand for the product because the product didn’t solve a big enough problem for its market or it didn’t solve the problem in a way that worked for users.
Because of this, it’s important that you spend time validating the problem, the market, and the product as early as possible.
Validating the Problem
Let’s imagine that, instead of spending time brainstorming brilliant ideas of products that nobody’s ever thought of, you’re going to go about finding a product idea in a totally different way. You are going to discover a problem that exists within your target market that you are capable of solving.
Remember, if there’s no problem, then there is no compelling reason for people to purchase your product. Even if your idea is brilliant, innovative, and disruptive, early validation will help you refine your ideas and learn more about your users.
This isn’t always easy to do. In fact, this may sound cryptic, but sometimes the best types of problems to solve are the ones that the users don’t really know are problems until you fix them. How about an example to make that a little less confusing?
Before email came along, many of us did just fine communicating by phone or fax. It wasn’t perfect, but we got things done that we needed to get done. Of course, if you tried to call someone in a foreign country or if you wanted to connect with lots of people at once, there were some pretty obvious drawbacks to the phone and fax model. But we lived with it, because it’s what we had.
Then some genius came along and said, “What if you could type out the message you want to send and send it really far away or to dozens of people at one time?” That particular product solved a serious problem that most users couldn’t have identified as a problem.
OK, sure. This probably isn’t exactly how email was created. My point is that by using some of these techniques to observe potential users in interesting markets, you’ll pretty quickly be able to identify some of the things that people are doing that you could make better. Once you’ve identified those things, it’s much easier to come up with a product idea that people will like enough to use.
If you agree with Eric Ries—that “a startup is a human institution designed to deliver a new product or service under conditions of extreme uncertainty”—then think of early problem validation as something you do to reduce that uncertainty.
You can’t guarantee yourself success, but early problem validation allows you to predict and avoid failure early in the process rather than after you’ve already spent all your investors’ money.
You’ll know that you’ve validated a problem when you start to hear particular groups of people complaining about something specific.
Validating the Market
Just because a problem exists doesn’t mean enough people are going to be excited to pay for the solution. This is why you have to validate your market.
Your goal in validating your market is to begin to narrow down the group of people who will want their problems solved badly enough to buy your product. Your secondary goal is to understand exactly why they’re interested so you can find other markets that might be similarly motivated.
Markets are notoriously difficult for startups to choose. There is a tendency among entrepreneurs to go for the broadest possible group of people who might be interested in purchasing a product. They will release a product aimed at “women” or “doctors” when what they should be doing is picking narrower markets like “urban moms who work full time outside the house and don’t have nannies” or “oncologists in large practices who don’t do their own billing.”
By starting with smaller markets, you’re more likely to find groups of people with very similar problems that will be easily solved by a small initial product. Don’t worry if the initial market isn’t very large. You can always expand your product later. Worry about finding a market with a single, overwhelming problem that you can solve.
You’ll know that you’ve successfully validated your market when you can accurately predict that a particular type of person will have a specific problem and that the problem will be severe enough that that person is interested in purchasing a solution.
Validating the Product
Just because you have discovered a real problem and have a group of people willing to pay you to solve their problem, that doesn’t necessarily mean that your product is the right solution. For example, millions of people want to lose weight, but that doesn’t mean that every exercise and diet plan is guaranteed to be a big seller.
Validating your product tends to take much longer than validating your problem or market. This is an incredibly iterative process that I’ll discuss in detail throughout the rest of the book.
The important thing is to keep coming back to the question, “Does this product really solve the identified problem for the specified market?”
You’ll know that you’ve validated your product when a large percentage of your target market offers to pay you money to solve their problem.
Some Tools for Early Validation
Now that you know what you want to validate, let’s look at a few useful tools for getting feedback about your problem, market, and product. Each of the following methods is a type of user research that is especially useful for this sort of early validation. In fact, they are all possible to perform long before you write the first line of code.
Ethnographic Studies (or, You Know, Listening to Your Users)
The most effective way to better understand the problems of your potential users is to go out and observe a few of them in person. You don’t have to go all Jane Goodall and live amongst the chimps for years at a time, but you do have to spend some time getting to know the people for whom you are building a product.
This is your chance to ask open-ended questions about their problems and their lives. It’s an opportunity to observe their behaviors and to learn what sorts of solutions they’re currently using to solve their problem.
Here’s an example. Many years ago, I did user research on a product aimed at people who process payroll for small businesses. Try not to nod off. It gets (slightly) more interesting.
While watching half a dozen people process the payroll for their businesses, several patterns emerged. The most important one, for the purposes of designing the product, was that there was no pattern.
Different users performed payroll tasks in completely different orders. Sometimes the same people would perform tasks in different orders during different payroll runs. It all depended on what needed doing that week. Sometimes they needed to add a new employee or terminate an old one. Sometimes they had all the information they needed, while other times they didn’t. Often they’d get halfway through and have to go do one of a dozen different tasks. It was an incredibly nonlinear, interrupt-driven process.
This was not the kind of information we could have learned if we’d just asked people what was involved with processing payroll. This was the kind of information that we could get only by watching people go through it.
It turned out to be extremely useful information when designing the product, because it ended up having all sorts of implications for the way we saved user data and the way users accessed different parts of the product.
Learning about your users’ problems is only a part of what you get when you do these sorts of ethnographic studies. You get a deep understanding of the people who make up your market, which you simply can’t get from other forms of research.
Sure, you can observe how people do things, but you can also learn why they do them that way. One company that helps busy moms get deals on groceries spent quite a bit of time going shopping with women before it ever wrote a line of code. It learned about more than just coupon usage. It also learned the shopping patterns that women had—when they shopped, how many stores they went to, how often, and how they budgeted.
This sort of information allows you to build a product that not only solves a problem for users but that also fits naturally into their lives and schedules. It helps you build something that doesn’t force users to learn new patterns in order to use your product, because your product fits seamlessly into their existing processes.
It can also help you invalidate ideas pretty quickly. For example, before we went to watch people process payroll, the product owners had come up with several ideas for making payroll more collaborative. However, once we started watching users perform their tasks, it became very clear that, for the types of businesses we were targeting, there was never more than one person performing the payroll tasks. Collaboration would have been a wasted feature unless the company decided to move into an entirely different market.
How you can do it right now
First, figure out who your target market is. Be specific. “Women” is not a good target market. There are simply too many of us, and we’re all quite different from one another. Honest.
“People who process payroll for small businesses” is a great example of a market, since it’s a clear job description. People who fit into that market are likely to have a lot of similar work-related needs. Another great example is “people who spend more than four hours a day on Facebook and play at least three different social games.”
You will notice that these are large enough groups to be markets but are specific enough to have some very similar behavior patterns. That’s important. Remember, this is a market to which you want to sell your product. If you want to sell a lot of your product, it makes sense to pick a market that has enough people to eventually support your growing business. The specific part is important because you want to be able to easily identify those people for your research.
A lot of people skip this very important step of identifying a potential market and just go out and talk to anybody they can find. This often includes friends, family, or random strangers on the street.
Here’s why that’s a terrible idea. Let’s imagine you are interested in creating a product for people who drive cars. Now let’s imagine that you find two people who will talk to you: One of them is a NASCAR driver, and the other is my mom. I guarantee that you will find virtually no overlap in what these two people are looking for in an automotive product. None.
On the other hand, if you find five NASCAR drivers or five grandmothers who live in the suburbs near their extended families, you are very likely to get quite a bit of overlap. That overlap is a pattern, and it’s what allows you to make early decisions about what features your product should have and how you should market it to your potential users.
Now that you’ve picked your specific market, find five people who are in it. If you can’t do this fairly easily, either you’ve picked too small a market, your market is too hard to reach, or you’re just not trying hard enough. In any of these cases, rethink your career choices or find someone with some knowledge of the market to help you.
If one or two of the people you’ve identified are nearby, go visit them at their homes or offices or wherever you expect them to use your product. For those who don’t live near you, do some sort of screensharing through something like Skype, GoToMeeting, or FaceTime, so that you can both talk to them and remotely view their surroundings.
Start off by asking them to show you how they currently perform some tasks that relate to the problem you’re trying to solve. For example, you could ask them to walk you through exactly how they process their payroll. Meanwhile, you would ask them why they do things in a particular way and what other things they have tried.
Your goal is to get a good overview of their current practices and problems. It’s also to spot patterns of behavior. Is there a specific problem encountered by each of the test participants? Have they all complained about a particular piece of software? Are they all performing tasks in a specific way that could be made easier?
Whatever observations you make and patterns you find, I guarantee this will change the way you think about your problem space and give you dozens of ideas for features that will make a truly useful product.
For example, one company I was working with wanted to create a new first-time user experience for its product. It felt that not enough people were making it through the registration funnel and becoming full members of the site. Before starting the project, the team members sat down and came up with dozens of ways they might close some of the holes in the funnel, but they weren’t sure which way to go.
The thing is that they’d been through this process before with very little luck. They’d made lots of changes to the first-time user experience with very little to show for it in the way of improved metrics. So, instead of simply taking their best guess, as they had before, I recommended that they observe some users, both new and existing, and see if they could discover new ideas that might be likely to improve the user experience.
Unsurprisingly, after they’d observed five or six new users going through registration and spoken to a few current users, they discovered that the visual design of the registration process was giving new users an entirely different idea of what to expect than the actual product. New users going through the process assumed it was a product for children because of the fun, cartoon-like graphics. Serious, paying users of the product, on the other hand, tended to be older.
By changing the look and feel of the first few screens of the product, the team was able to significantly increase the number of qualified users who made it through registration and became full members of the site. It was as simple as not scaring away the types of people who would want to use their product, but it was not an insight that anybody on the team would have come up with without watching users.
The beauty of this method is that it takes very little work, and it can save you huge amounts of time later by making sure that you’re solving a real problem that actually exists.
Landing-Page Tests
OK, great. Now you’ve talked to some people, and you think you see a shared problem that you can solve. It’s still not really conclusive evidence, right? I mean, what if those were the only five people in the world who have that problem? Or what if lots of people have the problem, but nobody’s willing to pay you to help them solve it?
These are valid concerns, and you can address them long before you write the first line of code. The trick is to sell the product before you build it. Well, OK, technically that’s kind of fraud, so how about you just advertise the product before you build it?
By building a few one-page sites, you can get a ballpark figure of the number of people who are interested in paying you to solve their problem. And the great thing is, you can start doing this before you start building anything. This means if nobody shows any interest in using your product, you can keep looking for new product approaches very cheaply until you find something that people are interested in using.
To be clear, I’m not just talking about direct-to-consumer Internet products here. Although you’re using the Internet to advertise your ideas, you don’t have to be building the next Amazon.
Have a concept for a premium day spa for pets? Why not build a website for it first and see how many people try to make reservations for Poodle Pedicures? It’s a hell of a lot cheaper to build a landing page than it is to get salon chairs designed to fit a variety of dogs.
With landing-page tests, you can start to validate both your market and your product. By advertising a real thing (or several real things) that you are going to be selling, you’re getting the best kind of feedback that people are willing to pay you for what you’re making. You can also get a sense of which version of your product has the biggest potential market, which can be a huge advantage in deciding what to build first.
How you can do it right now
First, create a landing page that offers your magical (and fictional) product to the general public. Put a big button that says “Buy” or “Pre-order” on the landing page. For this, you may want to hire a decent graphic designer or artist who can make something that looks legitimate.
Alternatively, you can get decent designs from places like 99Designs or by using available free blog templates.
Drive a little traffic to your landing page with AdWords, Facebook ads, or any other method you think might get the right sort of people to view your offering.
Then check to see how many people click on your ads and what percentage of them click on your fake Buy button. Something like Google Analytics is useful and free to use for this purpose.
If you don’t have any technical experience at all, you can do this with a Facebook page or use a service like LaunchRock, which will handle all the metrics stuff for you.
Prototype Tests
Great, by now you’ve validated that a particular group of people has a specific problem. You’ve also validated that they’re willing to pay you to solve that problem, or at least are interested enough to sign up and give you their email addresses. You are way ahead of the majority of startups who are busy building something that nobody wants, but you still need to make sure the thing you’re building solves the problem you validated.
I know that’s a little confusing. After all, you’ve listened to people, you’ve tested their interest, and now you’re building something that is specifically designed to solve their problems. Why on earth wouldn’t it be right?
Because building products, even when you know what problem you’re solving, is still hard. In fact, there might be hundreds of ways to solve the particular problem that you’re addressing. You need to take the time to make sure that your approach and your implementation will actually end up working for your end users.
Here is the worst possible way for you to try to figure out if your idea solves somebody’s problem: Ask them. The vast majority of entrepreneurs seem to think that explaining their concept in detail to a few people and then asking whether it’s a good idea constitutes validation. It does not. People have a very hard time understanding a description of a product, and your friends may say your idea sounds pretty cool when you describe it to them. But it’s an entirely different situation when potential users are confronted with a real product.
Here is the best possible way for you to try to figure out if your idea solves somebody’s problem: Show them something and observe their reactions. Ideally, the thing you get in front of users will look and feel like the product, but you won’t spend months writing code before you can start testing.
Let me back up. I’ve observed a large number of entrepreneurs doing what they think is product validation. This typically involves the entrepreneur excitedly describing exactly what his magical product is going to do. He often goes on and on until the potential customer’s eyes have developed that sort of hunted look that you see when you corner an animal. At the end of the sales pitch, the entrepreneur “validates” the idea by asking, “So would that solve your problem?”
Even ignoring the fact that most of these potential customers would agree to practically anything just to get the entrepreneurs to shut the hell up, this is still the worst thing you can possibly do.
Nobody in the world can possibly tell you whether some abstract concept you just explained will solve a problem that they have. Even if they could somehow understand the wild abstractions you’re presenting them with, they couldn’t honestly tell you whether they would pay money for your solution. They just can’t. You’re asking them to predict what they will do in the future, and those of us who aren’t psychic can’t do that.
Don’t believe me? Let’s do an exercise. Let’s say that I told you I was going to create the perfect way for you to lose 10 pounds, and it was going to be amazingly easy and cheap. Imagine what that looked like. I can now guarantee you that what you imagined is entirely different from what everybody else reading this book imagined. It’s also almost certainly completely different from what I was talking about.
This is important because when you ask somebody to imagine something and then ask them if they would buy it, they answer by telling you whether they would buy their ideal imagined solution, not your actual product. Consider the above example. You might have bought something that fit your ideal product that would help you lose 10 pounds. You almost certainly wouldn’t buy the real product.
So what’s the alternative? Instead of describing what you’re going to build, why not show them what you’re going to build? Simply observing people interacting with a prototype, even a very rough one, can give you a tremendous amount of insight into whether they understand your potential product and feel it might solve a problem.
Prototype tests are the single best way to validate your product as early as possible. By validating early, you make sure that your product is compelling and usable while there’s still time to fix it if it isn’t.
How you can do it right now
I’ll go more into various different methods of prototyping later in the book, but the important thing to understand here is that the closer you can get to showing people a real product, the more accurately you can predict whether people will use that product.
The most important thing is that whatever you’re showing people has to be interactive enough that people can imagine they’re using a real product. People have to be able to poke around the prototype by themselves and learn about what it might do for them without any interference from you. They have to be able to discover features and understand what the product is offering without you constantly chiming in and telling them what should be happening. The more you have to explain or describe what happens, the more you’re going to bias the experiment.
Even at a reasonably high fidelity, though, an interactive prototype still takes far less time to build than an actual product. In later chapters, I’ll give you some tips for how to balance speed and usefulness in developing the right sort of prototype for whatever you’re testing. Won’t that be fun?
Early Validation Isn’t the End
So that’s early validation, or at least a few examples of how to implement early validation. When Eric and Steve talk about getting out of the building, those are some very useful places to go and some reasonably easy things to do when you get there.
For those of you who think that’s the end of the interaction that you need to have with your users, you are sadly mistaken. We’re going to keep going back to those core ways of interacting with users throughout the development process. I’ll even have some tips later in the book about how to get better at validation, so don’t feel like this is the last you’ll hear of these topics.
The important thing to remember is that you need to solve a real problem, and in order to find that problem, you need to listen to real people. It’s nowhere near as easy as I’m making it sound, but the only way to get better at it is to do it. Over and over and over. Why not start now? I’ll still be here when you get back.
Loosely Related Rant: Pain-Driven Design
I have a problem with both User-Centered Design and Customer-Driven Development (CDD). This may come as something of a shock to people, since I’m constantly giving advice on better ways to talk to users and to improve customer development efforts.
The problem I have with UCD and CDD is not the methods. The problem is that people so often misunderstand them. People hear “user centered” and think, for some insane reason, that we are encouraging them to turn their entire design process over to the user. They hear “listen to your customer” and think that we want them to blindly accept every ridiculous feature request made by somebody with a credit card and an opinion.
Guess what? I rarely speak for entire communities of people, but I think I can safely say that nobody in the User-Centered Design or Customer-Driven Development business is asking that of anybody. If they are, they’re idiots and shouldn’t be listened to anyway.
Unfortunately, a lot of us have debunked this myth by explaining that we don’t really think that customers can predict future behavior (even their own) or that they’re going to have some grand design vision for your product.
We just think that customers are great at talking about their problems and pain points, and that those are good things for you and your designers to know when you create a new feature or product.
I’m suggesting that we come up with a new name that will be harder (or at least more fun) to misinterpret: Pain-Driven Design.
What Is Pain-Driven Design?
The Pain-Driven Design (PDD) methodology requires that, before you start a design for a product or a feature, you need to figure out what is causing pain for your users and potential users. The desired outcome of PDD is to make that pain go away by some brilliant method of your devising. You then check to make sure you made your users’ pain go away without causing them any more pain.
Is there a clever analogy?
There is! Imagine you’re a doctor. You want to help people feel better. The first thing you need to do is talk to patients who come to see you.
Now, of course, you’re not going to ask them what disease they have and how they think you should treat it. You’re going to ask them, “Where does it hurt?” You’re also probably going to ask them a lot of other questions about how they normally feel, what their medical history is, what their family is like, and other things like that. You’ll probably also, if you’re a good doctor, examine them, double-check their reported symptoms, and check for symptoms they may not even know they have.
Then, when you have figured out what is causing them pain, you will determine a good course of treatment that is likely to work based on your knowledge of various diseases, your extensive medical training, other work in the field, and how the patient reacts to treatments. You will then closely monitor their progress and adjust your approach as necessary.
Pain-Driven Design is a lot like that. You will talk to your users and potential users and find out what causes them pain when they are trying to solve a problem. You will interview them about their habits, likes, and dislikes. You will observe them using the product or competitors’ products, looking for commonly appearing symptoms. You will then decide how to go about curing their pain. And, of course, you will closely monitor all your users to see how they respond to your treatment.
Since you have a large number of users, and there aren’t any pesky rules against human experimentation in this context, you will run tests to see which treatment performs best.
Does it work before I have a product?
Sure it does! Presumably your eventual product will solve somebody’s problem, yes? Maybe her problem is that it is too hard to find a great restaurant while traveling, or that she is sort of bored while waiting for the train. OK, those don’t seem like big problems, but they are problems nonetheless and should have solutions.
Since you don’t have a product yet, you need to figure out how people are currently solving this problem. Are they using a similar product? A completely different one? Are they simply suffering in silence without even knowing that their lives would be infinitely better if this problem would go away?
You can discover these things by asking people how they’re dealing with their problems and what the pain points are with their current solutions (or nonsolutions). You can learn more about their pain by watching them suffer through it. Don’t worry, it’s not so bad to watch them suffer, because you know your product will help them!
What if I already have a product?
It still works! You see, no matter how much you love your product, unless it is perfect it’s causing pain to somebody. I’m sure it’s not on purpose. You’re not a monster. But something about your product is confusing or hard to use, and it’s driving at least one of your customers crazy.
Again, examine them. Find out when they feel the most pain while using your product. Watch brand new people use your product to see how much pain it takes to learn. Watch old customers use your product to figure out what weird workarounds they’ve created to avoid the pain you’re causing them.
Find all the pain points. Then come up with devastatingly clever ways to fix them.
What if my product is disruptive?
Often people think this doesn’t apply to them because their product is so wildly different from anything else on the planet that it’s solving a problem users don’t even know they have. Or it’s revolutionizing something or other that will transform how humans interact with everything.
But the product is still solving a problem, right? Even if it’s solving that problem in a completely novel way or solving it for a new group of users, presumably if people are going to adopt the product, the product will be solving a particular problem for them.
That’s great. Even if people have never seen anything like your product, you can get a huge amount of information by talking to users about how they currently solve their problems as well as their general environment for problem solving. And once your disruptive product has been launched, chances are it’s causing some people pain, so you should observe people interacting with it to learn where the pain points are.
What if my customers try to tell me how to fix their problems?
Well, I suppose you could plug your ears and scream loudly so that you won’t be in danger of hearing them talk about their solutions. Or you could listen to their solutions and then politely follow up to make sure you understand the underlying pain that they’re trying to cure.
Frankly, I prefer the latter approach, but it’s up to you.
One interesting thing that I’ve found in my many, many years of listening to customers is that sometimes the customers are right about the solution. I know; crazy! I mean, we’ve been assured by hundreds of people that listening to customers’ solutions is completely useless and that they’re always wrong!
Guess what? They’re not.
This doesn’t mean you should take their word as gospel, but I can’t imagine that people within your company have a patent on coming up with the right solutions to customer problems. Just because an idea for a solution comes from a user doesn’t automatically make it useless or wrong, even if the anti-UCD crowd seems to think so.
How will Pain-Driven Design be misinterpreted?
Who can say? I sort of hope somebody reads only the title of this rant and writes a scathing retort about how I’m a horrible person for advocating that designers be subjected to pain until they come up with better designs (note: They shouldn’t, except in certain very specific cases, and they know who they are).
Or maybe they’ll dissect my doctor/patient analogy and point out all the ways in which it’s flawed (note: There are 17 ways...see if you can spot them all!) and thereby conclude that, since my analogy isn’t perfect, my methodology must also be crap.
But I hope a few people will say, “Hey, that Pain-Driven Design methodology is just a catchy name for understanding our customers’ problems so that we can come up with better solutions!” And more importantly, I hope a lot of people will say, “You know, that Pain-Driven Design sounds like a great idea, and we should try it in our organization!”
Go Do This Now!
Learn from your users before you build: Try a contextual inquiry or a customer development interview.
Test your market early: Try a landing-page test.
Figure out what sort of pain you’re causing customers: Try some observational usability on your product or a prototype.
Get UX for Lean Startups now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
