Maybe You're Just Delusional

I tell people to listen to their customers a lot. It’s kind of my thing. Every so often when I’m explaining how to learn about customer problems and incorporate that feedback into a product, I run into a founder who is truly resistant.

“But...my VISION!” they cry. Then they go on to build exactly the product that they want to build without getting feedback from users. And once in awhile this works out, I’m told. But typically I never hear about them, or their products, again.

The sad thing is that vision and customer feedback don’t have to be at odds.

I’m going to give you two different visions that a startup founder might have, and I’d like you to try to spot the differences between the two.

Vision #1

“Pet owners are upset about how much their pets cost. This product is going to make it more affordable to have a pet by getting jobs for the pets so that the pets are bringing in money! It’s called Jobs4Pets, and people will be able to post jobs for dogs, cats, rabbits, whatever. And other people will find jobs for their pets and apply right on the site. We’ll make money by charging a service fee on each of the transactions! Obviously, we’re mobile first, and the jobs will be shown in a Pinterest style layout because that’s the best possible layout for things.”

Vision #2

“Some pet owners are upset about how much their pets cost. This product is going to make it more affordable to have a pet.”

See the difference? I mean, besides the fact that the first one is completely delusional?

In the first one, the deranged...I mean visionary...founder has a vision not just for the goal of the company, but for every detail of the actual product. She’s not just envisioning what the product will help people do. She’s envisioning exactly how the product will help people do that, right down to the layout on the home page.

She hasn’t left room to validate the many assumptions she’s making - that pet owners have a problem with costs, that pets can do jobs, that people will post jobs for pets, that people want their pets to have jobs, etc. If any of those assumptions are invalid, by the way, the entire product will fail, and even her lovely, Pinterest-style layout can’t help her.

But the most important thing to note is that the second vision is entirely compatible with user research.

The founder with the second vision might want to go out and meet lots of pet owners in order to find out how big of a problem cost is for them. She might learn the ways that people are already saving money. She might ask which parts of pet ownership cost the most or are the most burdensome. She might test several different solutions for saving pet owners money and see which one gets the most interest or traction. She might even end up with an entirely different product than she originally imagined, all without sacrificing her vision!

So, how can you balance customer feedback with vision? Try to envision how your product is going to change somebody’s life, not how they’re going to perform specific tasks. Envision the problem that you’re solving, not the specific solution.

Then listen to your users. Observe them. Learn from them exactly how you can solve their problem.

That’s the best way to make sure that your vision becomes a reality.

This was written for Startup Edition. The question was, "How do you balance user feedback with your long term vision?"

Want more information like this? 

My new book, UX for Lean Startups, will help you learn how to do better qualitative and quantitative research. It also includes tons of tips and tricks for better, faster design. 

Buy It Now

Mobile First? Not So Fast! The Importance of Flow and Context.

I recently wrote a post for the O'Reilly Programming Blog called "Mobile First? Not So Fast!
Why "flow" and "context" are more important than screen size."

Here's an excerpt:

Are we done with the Mobile First meme, yet? Can we be? Please?

Look, don’t get me wrong. I fundamentally agree with a lot of the thoughts behind the annoying catchphrase “mobile first.” For example, I agree that mobile devices are now the primary (if not only) mode of connecting for many markets. I also think that having some sort of mobile strategy is absolutely required for almost every product.

The problem is that “mobile first” often equates “mobile” with “small screen” or “responsive layout” or “native vs. mobile web.” Now, those are all incredibly important decisions. But if you’re thinking about the size of your screen or the technology you’re going to use first, you are designing wrong.

Of course, if you’ve read anything else I’ve ever written, you know that the first thing you must figure out is an important customer problem or need that your product is aimed at solving for real people. We’re going to just skip over that whole part where you get to know your most important users. But that’s always first. Promise.

Once you’ve done all that though, you need to start designing. And there are two things that you should always know before you even start considering things like screen size or technology.

Those two things are: Flow and Context.

Read the rest at the O'Reilly Programming Blog >

Want more information like this? 

My new book, UX for Lean Startups, will help you learn how to do better qualitative and quantitative research. It also includes tons of tips and tricks for better, faster design. 

Buy It Now

You Can't Make Good Decisions with Bad Data

I think a critical lesson of the Lean Startup movement is that you have to learn quickly.

The “quickly” part of that lesson can lead to a culture of “good enough.” Your features should be good enough to attract some early adopters. Your design should be good enough to be usable. Your code should be good enough to make your product functional.

While this might drive a lot of perfectionists nuts, I’m all for it. Good enough means that you can spend your time perfecting and polishing only the parts of your product that people care about, and that means a much better eventual experience for your users. It may also mean that you stay in business long enough to deliver that experience.

I think though that there’s one part of your product where the standard for “good enough” is a whole lot higher: Data. Data are different.

You Can’t Make Good Decisions With Bad Data

The most important reason to do good research is that it can keep you from destroying your startup. I’m not being hyperbolic here. Bad data can ruin your product.

Imagine for a moment an a/b testing system that randomly returned the wrong test winner 30% of the time. It would be tough to make decisions based on that information, wouldn’t it? How would you know if you were choosing the right experiment branch?

Qualitative research can be just as bad. I can’t tell you how many founders have spent time and money talking to potential customers and then wondered why nobody used their product. Nine times out of ten, they were talking to the wrong people, asking the wrong questions, or using terrible interview techniques.

I had one person tell me, “bad data are better than no data,” but I strongly disagree here. After all, if I know I don’t have any data, I can go do some research and learn something.

But if I have some bad data, I think I already know the answers. Confirmation bias will make it even harder for me to unlearn that bad information. I’m going to stop looking and start acting on that information, and that may influence all of my product decisions.

If I “know” that all of my users are left handed, I can spend an awful lot of time building and throwing out features for left handed people before realizing that what I got wrong was the original premise. And, of course, that problem is made even worse if I’m not getting good information about how the features are actually performing.

You Have To Keep Doing It

Unlike any given feature or piece of code, collecting data is guaranteed to be part of your process for the life of your startup.

One of the best arguments for building minimum viable products and features is that you might just throw them out once you’ve learned something from them (like that nobody wants what you built).

This isn’t true of collecting data. Obviously you may change the way you collect data or the types of data you collect, but you’re going to keep doing it, because there’s simply no other way to make informed decisions.

Because this is something that you know is absolutely vital to your company, it’s worth getting it right early.

Data Collection Is Not a Mystery

Most of your product development is going to be a mystery. That’s the nature of startups.

You’ve got a new product in a new market, possibly with new technology. You have to do a lot of digging in order to figure out what you should be building. There’s no guide book telling you exactly what features your revolutionary new product should have.

That’s not true of gathering data. There is a ton of useful, pertinent information about the right way to do both qualitative and quantitative research. There are workshops and courses you can take on how to not screw up user interviews. There are coaches you can hire to get you trained in gathering all sorts of data. There are tools you can drop in to help you do a/b testing and funnel tracking. There are blogs you can read written by people who have already made mistakes so that you don’t have to make the same ones. There is a book called Lean Analytics that pretty much lays it out for you.

You don’t have to take advantage of all of these things, but you also don’t have to start from scratch. Taking a little time to learn about the tools and methods already available to you gives you a huge head start.

Good Data Take Less Time Than Bad Data

Here’s the good news: good data actually take less time to collect than bad data. Sure, you may have to do a little bit of upfront research on the right tools and methods, but once you’ve got those down, you’re going to move a hell of a lot faster.

For example, customer development interviews go much more quickly when you’re asking the right questions of the right people. You don’t have to talk to nearly as many users when you know how to not lead them and to interpret their answers well. Observational and usability research becomes much simpler when you know what you’re looking for.

The same is true for quantitative data collection. Your a/b tests won’t seem nearly so random when you’re sure that the information in the system is correct. You won’t have to spend time as much time figuring out what’s going on with your experiments if you trust your graphs.

Good Data Does Not Mean Complete Data

I do want to make one thing perfectly clear: the quest for good data should be more about avoiding bad data than it is about making sure you have every scrap of information available.

If you don’t have all the data, and you know you don’t have all the data, that’s fine. You can always go out and do more research and testing later. You just don’t want to put yourself into the situation where you have to unlearn things later.

You don’t have to have all the answers. You just have to make sure you don’t have any wrong answers. And you do that by setting the bar for “good enough” pretty damn high on your data collection skills.


Like the post? Please share it!

Want more information like this? 

My new book, UX for Lean Startups, will help you learn how to do better qualitative and quantitative research. It also includes tons of tips and tricks for better, faster design. 

Buy It Now

The Best Best Practice

I get asked for a lot of what I call "generic" advice, which I'm not really very good at giving. People will ask questions like, "Should I make a prototype?" or "Should I build a landing page?" or "Should I do more customer development?"

If you've asked this in email, you've probably gotten an unreadable 5,000 word manifesto that is essentially a brain dump of everything I can think of on the topic. If you've asked me in person you've almost certainly had to listen to me blather until your eyes glazed over.

Wherever you've asked, I've probably started the response with the words, "Well, it depends..."

And it does depend. What you should do right now with your product depends on a tremendous number of factors.

However, I think I've got some better advice for you.

You see, there aren't really Best Practices in Lean UX that apply in every situation. There are merely things that would be extremely helpful, except in cases where they'd be a huge waste of time. You can learn all the techniques in the world, but you still have to know when to apply them.

Every time you are wondering, "should I do this thing?" you should immediately ask yourself the following three questions:

• What do I hope to learn by doing this?
• How likely is it that I will learn what I want to learn by doing this?
• Is there a faster, cheaper, or more effective way that I could learn what I want to learn?

An Example!

Somebody recently asked me if his company should build an interactive prototype of a proposed new feature. 

I asked him what he hoped to learn by building an interactive prototype. He said he wanted to know if people would use the feature. I explained that, actually, interactive prototypes aren't terribly good for figuring out if people will use your new feature. They're only good for figuring out if people can use your new feature. 

So, by building an interactive prototype, you're very unlikely to learn what you want to learn. A more effective way to learn if people will use a new feature might be a Feature Stub (also called a Fake Door). 

Note: A Feature Stub is where you put some sort of access in your product to the proposed feature. For example, if you were wondering if people would watch an informational video, you might put a link on your site called Watch This Informational Video and then record how many people clicked on the link. If nobody clicked your link, you wouldn't bother to make an informational video. 

To be clear, it may be that he should also build an interactive prototype in order to figure out if people can use the feature as designed. However, his first step should be to learn whether the feature is worth building at all. If nobody's going to use the feature, it's best to learn that before you spend a lot of time designing and building it.

It's All About Learning

The reason these questions are so important is that Lean Startup is all about learning quickly. If a particular Best Practice helps you learn what you need to learn, then you should use it. If not, you shouldn't. At least, not just yet. In other words, it depends.

Want to learn more? Buy this book.

My new book, UX for Lean Startups, will help you learn how to build great products. It also includes all sorts of Best Practices and when you should use them. 

Buy It Now

10 Reasons Founders Should Learn to Design

I know, I know. Founders and entrepreneurs are already being told that they need to learn how to code, hire, raise money, and get customers.

Screw that. What founders and entrepreneurs should really do is learn how to build a great, usable, useful product. And that means learning the fundamentals of research and design.

Don't believe me? Here are 10 reasons you should learn to be your own UX designer (or at least learn enough about UX design to fake it).

1. You can't build a great product if you don't know what problem it solves for which people. UX design and research helps you figure that out.
2. The only thing harder to find than a great designer is a unicorn.
3. It is almost impossible to judge somebody else's UX design skills unless you have designed things yourself. 
4. The only thing more expensive than a great designer is a faberge egg. Sitting on top of a unicorn. 
5. It's much easier to manage somebody who is doing a job you truly understand. 
6. Jason Putorti already has a job.
7. UX design is a team sport. You don't want to get picked last for the team, do you? 
8. You have a million fabulous feature ideas. It's easiest to communicate them to your team and customers through design. 
9. You should already understand your product and users better than anybody else. This just takes it to the next logical step. 
10. Adding extra people to the Build>Measure>Learn loop does not make it faster. 

Convinced? Great! First, share this list with people!

Now, here's a book to help you learn how to do enough user research and design to get your product into the hands of people who want to buy it. 

It's called UX for Lean Startups. It's by me. It will help you learn how to build great products. I promise. 

Buy It Now

Design Hacks - The Talk

I write a lot about user research - generally tips and tricks for people who don't have much experience with it. The reason for this should be obvious. Understanding your user, by any means necessary, is always the first step in creating a compelling product.

Seriously, you can't build a product without understanding the problem you're solving and the people for whom you're solving it. Various forms of research are the best way of understanding people who aren't you. It's really as simple as that.

But I've also seen another common problem. A whole lot of folks have learned how to go out and listen to their customers and understand problems, but they still make bad, hard to use products that don't really solve a problem. It turns out that, while learning your users problems is a necessary first step, it's not the only step.

You also have to be able to create something that people understand and want to use, and you don't do that by simply trying random ideas until one of them sticks unless you have an infinite number of monkeys and typewriters. If you are constrained with respect to monkeys, typewriters, or VC funding, you might want a little guidance on what to do once you understand the problem.

Getting your design closer to right on the first, second, or third try will speed things up considerably. It's hard to learn anything from a badly designed, unusable product other than the fact that people hate badly designed, unusable products. And believe me, that lesson has been learned. Kind of a lot.

That's why I'll be giving a talk at Lean Startup Circle on Wednesday, March 20th. It starts at 6:30.  There will be other interesting speakers, as well. You can sign up here: http://sanfrancisco.leanstartupcircle.com/events/102633722/

I'll be talking about Design Hacks. These will include a few general tips on producing a good design. It will also include some (free) resources for getting good design ideas. Time permitting, it will include an example or two of how to think about new features for your product in a way that makes them easier to design.

This talk is NOT for design experts. Sorry, you'll be bored out of your minds.

This talk is perfect for founders and engineers who don't have experience with turning what they know about their users into useful designs. And, as always, I'll be hanging around afterward to answer specific questions about your products.

Once again, to see the talk, sign up here: You can sign up here: http://sanfrancisco.leanstartupcircle.com/events/102633722/

If you want to hear about future events where I'll be speaking, you can follow me on Twitter.
If you like to read about things like Design Hacks, the book is available for pre-order.

Don't Make Your Users Feel Like Idiots

I’m a smart person. I’ve been using the Internet since the early 1990s. I know how to program. I only feel the need to point this out, because I’m about to share with you a story in which I come across as a complete, blithering idiot, and I’m feeling a little defensive about it.

I got an email from an event that I won’t name, but I’m guessing a few of you are getting emails of your own. If you didn’t make the same mistake, then bask in the glory of being better at computers than I am. If you did make the same mistake, welcome to the club. You’re not alone.

The email I received was several paragraphs long and told me all the places and times where I could pick up my badge for the event. It also said that they were introducing something new this year called a QuickCode. The email instructed me to bring my photo id and my QuickCode to pick up my badge.

Then it had the following line:
Laura Klein’s QuickCode:

That’s it. After that, it went on to give me more badge-related information.  “Aha, I thought. The automated system has failed to print my QuickCode.”

I immediately wrote back and said that I didn’t get my QuickCode. To the credit of the organization, I was immediately written back to by a very polite person who explained that the QuickCode was an image and even gave me instructions on how to turn on images in my email, in case I didn’t know how.

I was, as you might imagine, embarrassed. I mean, of course I know how to show images in an email. I just want to make that clear, because I’m coming off as enough of an idiot without you thinking I can’t use Gmail.

What I didn’t know was that the QuickCode was an image. Because I’ve never seen a QuickCode. Because a QuickCode wasn’t a thing to me until an hour ago. Because a QuickCode is just a name that somebody made up for a bar code that they’re using to help with their badging system.

Obviously the people writing the email knew what a QuickCode was, so it wasn’t at all surprising to them that you’d have to turn on images to see one. For those of us (ok, me) who had never heard of a QuickCode, this wasn’t immediately obvious. A QuickCode could just as easily have been a string of numbers and letters that could have been printed in the email. Of course, when I went back and re-read the email, the first paragraph did mention “scanning” the quick code, so I might have figured out what it was, but there were a lot of paragraphs in the email that I quickly skimmed. This is not unusual user behavior.

The interesting thing is that they could have avoided my acting like an idiot and subsequently having to deal with my support email by just including the phrase, “If you don’t see your QuickCode, try turning on images in your email.” They could have made that the alt text for the image so only people who didn’t have images turned on would see it.

Why am I telling you all this? I’m telling you this because we make assumptions of this sort in our interfaces every day. We assume people know that a QuickCode is an image, even though they’ve never heard of a QuickCode. We assume people know what our products do, even though they’ve never heard of our product. We assume people know where to go within our products to find the things they’re looking for, even though they weren’t in the meeting where we determined our product structure.

We are almost always wrong.

The moral of this story is not (just) that your users are going to do stupid things sometimes. It’s not even that they’re probably only going to skim our very long emails. The moral is that we constantly need to be asking ourselves what we really expect a user to understand about our product, and we need to have ways to preemptively help them in places where we’re presenting new concepts or unfamiliar terminology.

Users don’t know our slang. They don’t know our jargon. They don’t know our product. If we want them to use our products successfully, we need to teach them what they need to know without making them feel like idiots.