Fucking Ship It Already: Prototype Testing Can Save You Time

So, I was talking to a company the other day, and they had just done a major redesign of their product. Unfortunately, as soon as they released it, they started getting customer complaints. They had removed a particular feature from the main part of the product, and paying customers started to scream.

They were already allowing people to use the previous design, which was a good thing, since folks started switching back immediately. Of course, they went into recovery mode. They started looking at customer feedback and planning a redesign of the redesign to reintegrate the feature they’d removed.

I asked what I thought was a reasonable question: Had they done any prototype testing with current users during the early phase of the major redesign?

Their response was, “We didn’t have time for prototype testing.”

Oh, really? That’s an interesting answer, because they sure has hell had time to do a fairly significant reboot of their redesign after launch to fix a problem that would have been prevented by showing some wireframes to current users.

After all, they already had mockups of the new designs. Showing those mockups to users would have taken a day of work at most.

Look, shipping fast is important. In fact, these days I’d say I do far fewer interactive prototypes than I did back in the days when we were still doing waterfall, mostly because engineers in a continuous deployment process can build, test, and iterate on something almost as fast as I can with an interactive prototype.

But major redesigns that touch all parts of the interface are exactly the kind of thing that you should make time to do prototype testing on. Because in this sort of scenario, more often than not, an interactive prototype, or even just a wireframe or sketch or mockup, can end up saving you a lot of time after launch. They help you get feedback from customers before you go to all the trouble of building something you have to roll back or redesign.

The most important thing to remember is that one of the biggest reasons for shipping fast is to learn as quickly as possible from your mistakes. If you can learn more quickly and efficiently from an interactive prototype, you should do that.

Going really fast in the wrong direction doesn’t actually end up saving you any time in the end. Sometimes glancing at a map before you leave gets you where you want to go faster.

Like the post? Follow me on Twitter.

Fucking Ship It Already: Limited Products vs Shitty Products

In our second installment of Fucking Ship It Already, we deal with a common problem for startups: shitty products.

Look, I know that building a product with one or two engineers and no money is tough. As an entrepreneur, you almost certainly have far more ideas than you have resources to create those ideas. And it doesn’t help that you have people like me screaming, “Ship it! Ship it!” before you’re really ready.

Who could possibly blame you for shipping a product that is, frankly, kind of shitty?

I could. Knock it off.

Let’s take a step back and try to understand the difference between a shitty product and a limited product.

One big difference is that I wholly endorse shipping a limited version of your product. I think it’s stupid to ship a shitty product. But what does that mean?

A limited product is something that may not do much, but what it does, it does well. It makes it clear to the user what it does and what they should do. It solves a serious problem, or perhaps a small part of a serious problem. It doesn’t crash relentlessly. It doesn’t have enormous usability problems.

It is not half a big product. It is a small but whole product.

Most importantly, a limited product is just big enough and good enough that you can learn something important from it.

But a limited product probably doesn’t do anything else. It doesn’t have bells and whistles. It doesn’t have “nice to have” features. It may only support the problems of a small subset of the market. It may only be released to beta users.

A shitty product, on the other hand, often tries to do too many things at once, and it doesn’t do any of those things particularly well.

You really don’t want a shitty product because, when people don’t use it, you have no idea if they aren’t using it because you have a bad idea or the wrong market, or if it’s just because your users are confused and turned off by your shitty product.

Shipping a shitty product is one of the best ways to get a false negative on your idea. People will use products that aren’t “polished.” They will abandon products that are just bad.

Here’s an example - remember when Amazon only sold books? If you were around in the ‘90s, the company that now sells fifteen different versions of everything on the planet only sold actual printed books.

And they did it really well. They made it pretty easy to find books. They had a large selection of books. They shipped the books to you reliably. They had nice descriptions of the books. They improved on the bookstore experience by offering me a giant bookstore in my own home.

In other words, they did one thing - sell books online - and they did it well. It wasn’t until years later that they even branched out into selling things similar to books. And it wasn’t until they were wildly profitable (and no longer a startup) that they started adding advanced features like eReaders, cloud storage, and a marketplace where other people could sell things.

What they didn’t do was do a half assed job of trying to sell you everything immediately. They didn’t promise to sell you toasters and jewelry and smoked salmon but then fail to actually ship any of that to your house or charge you three times for the same item. They figured out how to sell things to people online with one understandable market that they could learn from.

Other examples of products that started out doing one thing really well are Instagram, Google Search, and even Facebook. Remember, Facebook started out solving a single problem on a single college campus.

Now, I’m not saying it’s easy to build a product to sell books or share photos or search the web. It’s not. It’s incredibly hard, and it’s even harder to get right.

But that’s exactly the reason why you need to dramatically limit the scope of your initial product. Even building something that seems easy is hard to do well. Imagine how hard it is to build something really big!

So, when I’m yelling at you to Fucking Ship It Already, I don’t mean that you should ship something bad. I mean that you should ship something limited - something that is small enough to be shippable and usable in a very short amount of time.

And then I mean that you should immediately improve it and ship it again. Do this over and over again as many times as you can for as long as you can.

Eventually, you’ll build the product of your dreams. It will probably be quite different from what you originally imagined, but that’s a different blog post.

Fucking Ship It Already: Visual Design

I asked on Twitter whether anybody would buy a UX book called Fucking Ship It Already. Apparently some of you are interested. So, in the interest of following my own advice, I’m shipping the book iteratively in the form of this blog. You’re welcome.

I’ve talked in the past about lots of ways to do user research faster. Now, let’s talk about a way to make your design process faster. This is not a new idea, but it’s worth reiterating for those of you who are trying to make decisions like this on a day to day basis.

Today’s chapter will cover the fastest and most useful sort of visual design for your lean startup.

There is some tension out there in lean startup land. Many people favor eschewing visual design polish all together, since it’s more important to figure out if a product is useful and usable before spending time “making it pretty.” Other people argue that a good user experience includes things like trust and delight, which can be enhanced by good visual design.

I’ve seen this work both ways. I was speaking with an entrepreneur the other day who told me a relevant story. Apparently, she had spent time on visual polish for a login screen. There were a few things that took awhile to implement, but they made the screen look much better. Unfortunately, the next week she had to rip it all out to change the feature, and all that time pushing pixels was wasted.

On the other hand, I’ve had dozens of people talk about Path’s gorgeous and delightful interface recently. Would they have gotten that kind of buzz without spending time on the visual details? Most likely not.

So, what does this mean for you? Should you spend time on pixel perfect screens and delightful visual design? No. And yes.

Here’s what you should do: spend a little time developing clean, flexible, easy to implement visual design standards.

What That Means

It’s probably not worth your time to fret and sweat over every single pixel on every single new page, mostly because you should always plan on iterating. When you’re a startup, any new feature may be killed or transformed in a week’s time.

If you spend days getting everything lined up beautifully on a product detail page, that could all be blown to hell as soon as you add something like Related Products or Comments.

Many people think that the right answer is to have a grand vision of everything that will eventually go on the page, but things just change far too rapidly for this. Imagine that you’ve carefully designed a tabbed interface with just enough room for four tabs. Now imagine that you need to add a fifth tab. I hope you didn’t spend too many hours getting all that spacing exactly right.

What You Should Do Instead

How about spending time on the basics that won’t have to change every time you add a feature?

For example, you could establish standards for things like:

• An attractive color palette
• Font sizes and color standards for headers, sub-headers, and body text
• Column sizes in grid layouts
• A simple and appealing icon set
• Standards for things like boxes, gradients, backgrounds, and separators
• A flexible header and footer design

Why You Should Do This

The great thing about having standards like these is that engineers can often combine them with sketches to implement decent looking screens without having to go through a visual design phase at all.

Also, since these things are reusable and flexible, there’s no wasted effort in creating them. Killing a feature doesn’t make knowing that your H1s should be a certain size and color any less valuable.

The best part is that you save time in a few important ways. First, as I mentioned, you don’t necessarily need to involve a visual designer every time you want to create a new screen. Second, this sort of approach tends to encourage a much simpler, cleaner, more flexible design, since items need to work in various combinations. And lastly, it tends to keep things more consistent across your product, which means that you’re less likely to have to go back later and do a complete redesign after things have gotten hideously out of whack.

It won’t solve all of your visual design woes, but it will make developing new features go faster, and you won’t be quite as sad when they fail miserably and you have to kill them.

Like the post? Want more tips on shipping already? Follow me on Twitter.

Stop Validating Your Product

I talk to a lot of very small companies that are trying to do Customer Development, and the conversations are often the same. The entrepreneur explains that the company is working on a fabulous product, and they want to figure out a) if anybody wants to buy the product and b) if they need to change anything about the product so that more people will buy it.

The entrepreneurs always ask questions like, “How will I know if I have talked to enough people?” and “How do I know if the people who like it are just early adopters?” and “How do I know if I should change the product in response to feedback or if I should just keep trying to find the right market?” The ones who have already been out in the field trying to conduct these interviews all have a sort of glazed, terrified look.

These are all really important questions. I’m going to give you a way to avoid having to ask most of them.

Stop trying to validate your product.

Now, I fully expect a bunch of people to stop reading here and totally miss the point of this post, but for those of you who stick it out, I promise this will make sense in a minute.

The trick is, it is far, far easier to conduct customer development before you have settled on a product or even an idea for a problem.

Why is that? Well, think about products as solutions to problems. Sometimes that “problem” is “I’m sort of bored while I’m waiting for the train” and the unexpected solution is flinging virtual birds at virtual pigs. But often, the problem is something more concrete, and it’s frequently shared by a large group of similar people.

So, instead of focusing on validating a solution, try one of the following techniques.

Validate a Problem

Let go of your preconceptions about how you are going to solve a problem for people and concentrate on first figuring out whether lots of people have a particular problem and what they’re currently doing to solve it.

For example, let’s say that you’ve posited that people have a really hard time finding and making appointments with trustworthy auto mechanics. The mistake you will probably make is to jump right into solving that problem and then going out into the world with some half-baked idea for Yelp meets OpenTable meets AAA and trying to find out whether it solves this problem that you’re not technically sure exists yet.

Instead of doing that, first validate the problem. Get on the phone with lots of different types of people and ask them how they found their mechanics. Talk to them about all of their mechanic-based issues. Find out what causes them the most pain.

Also, this is a good time to narrow down your market. Start with the market “people who have cars and will talk to you,” but quickly start noticing patterns. Do all the busy people have similar problems? What about people who live in cities vs. suburbs? How about people who are new to an area? Try people with special kinds of cars. I’ll bet that they all have very different problems, any of which you might want to solve.

Once you’ve spent time talking to people in various markets with various problems, you’ll come up with all sorts of ideas of how to solve those problems. The great thing is that then you can validate your product idea with people who you already know have a solvable problem.

This is a great way to do things if you have a particular problem yourself, and you want to find out if there are other people like you who have that same problem. By talking to lots of people with the same problem, you’re going to come up with a much better solution than you would if you just solved things for yourself.

Solve a Problem for a Particular Market

A slightly different approach is to pick your market first. Let’s say you have a special affinity for auto mechanics or busy moms or accountants at mid-sized companies.

The trick here is that you’re not going to change your market. You’re going to figure out some massive problem that is being experienced by a large portion of the market, and you’re going to solve it for them.

Your first step is going to be some ethnographic research. You need to really get into the heads of your target market and see what makes them similar and what’s driving them nuts. You’re not going into the research with an idea of the problem you want to solve for them. You’re going to let their needs drive your product decisions.

This is a great method if you happen to have some specific connection with a group or industry. Let’s say you collect porcelain owl figurines. You might desperately want to solve a problem for other porcelain owl aficionados, but you should be open to what problem you want to solve for them. For example, it might be how to get large numbers of high quality porcelain owls. Or it might be ways to contact therapists that deal with severe hoarding issues. Let the user research guide you!

The Easiest Kind of Customer Development

Hopefully you’re noticing a pattern here. The easiest kind of customer development is the kind that you do before you have a very solid product idea.

If you figure out your problems and your market before you come up with an Idea or a Solution or a Product, then when you do build something, you’ve already done a huge amount of the work in figuring out if anybody’s going to use it.

This is really about controlling which variables you’re testing. It’s hard to simultaneously find a problem, a market, and the problems with a real product all at once.

However, once you’ve validated your market and your problem, you can create something that solves that specific problem for that particular market. The beauty of this is that if you build a product for a problem you know exists in a market you know needs it and still nobody uses it, you can be pretty certain that the problem is your product.

Like the post? Follow me on Twitter.

Tiny Tests: User Research You Can Do NOW!

There’s a lot of advice about how to do great user research. I have some pretty strong opinions about it myself.

But, as with exercise, the best kind of research is the kind that you actually DO.

So, in the interests of getting some good feedback from your users right now, I have some suggestions for Tiny Tests. These are types of research that you could do right this second with very little preparation on your part.

What Is a Tiny Test?

Tiny Tests do not take a lot of time. They don’t take a lot of money. All they take is a commitment to learning something from your users today.

Pick a Tiny Test that applies to your product and get out and run one right now. Oh, ok. You can wait until you finish the post.

Unmoderated Tests

Dozens of companies now exist that allow you to run an unmoderated test in a few minutes. I’ve used UserTesting.com many times and gotten some great results really quickly. I’ve also heard good things about Loop11 and several others, so feel free to pick the one that you like best.

What you do is come up with a few tasks that you want to see people perform with your product. When the test is over, you get screen captures of people trying to do those things while they narrate the experience.

Typically, I’ll use remote, unmoderated testing when I want to get some quick insight into whether a new feature is usable and obvious for a brand new user.

For example, if you’ve just added the ability for users to message each other on your site, you can use remote, unmoderated testing to watch people attempt to message somebody. This will help you identify the places where they’re getting lost or confused.

If you’ve done a little recruiting and have a list of users who are willing to participate, you can even ask your own users to be the participants.

And don’t forget, if you don’t have a product, or if you’re looking at other products for inspiration, you can run an unmoderated test on a competitor’s product. This can be a great way to see if a particular implementation of a feature is usable without ever having to write a line of code. It can also be a great way to understand where there might be problems with competing products that you can exploit.

Are you going to get as much in-depth, targeted feedback as you would if you ran a really well designed, in person user test? Probably not. But it’ll take you 10 minutes to set up and 15 minutes to watch each video, so you might actually do this.

Remote Observation

There is something to be said for traveling to visit your users and spending time in their homes or offices. It can be extremely educational. It can also be extremely expensive and time consuming.

Here’s a way to get a lot of value with fewer frequent flyer miles.

Look at the people in your Skype contacts. Find one that doesn’t know much about your product. Ping them. Ask them to do three small tasks on your product while sharing their screen.

Don’t have Skype? Send friends a GoToMeeting or a WebEx link through email.

As with the remote unmoderated testing, this is best for figuring out if something is confusing or hard to do. It’s not very useful for figuring out whether people will like or use new features, because typically the people in your Skype contacts aren’t representative of real users of your product.

The closer the people are to your target market, the better the feedback’s going to be, but almost anybody can tell you if something is hard to use, and that’s information that it would be great if you had right now.

Coffee Shop Guerrilla Testing

Of course, it’s tough to test a mobile app over Skype. You know where it’s easy to test a mobile app? At a coffee shop.

Go outside. Find a Starbucks (other coffee shops are also acceptable if you refuse to go to Starbucks, you insufferable snob). Buy some $5 gift cards. Offer to buy people coffee if they spend 5 minutes looking at your product. Have a few tasks in mind that you want them to perform.

In about an hour, you can watch a dozen people use your app. And if you don’t manage to get any good feedback, at least you can get coffee. But you’ll almost certainly get some good feedback.

This type of feedback is great for telling you if a particular task is hard or confusing. It’s also great for getting first impressions of what an app does or the type of person who might use it.

Five Second Landing Page Testing

Sometimes, all you want to test is a new landing page. What you frequently want to know about a landing page is, “What message is this conveying, and is it conveying it clearly and quickly?” Even the tiniest of tests can seem like overkill for that.

For landing pages, I use UsabilityHub’s Five Second Test. You take a screenshot or mockup of the landing page you want to show. You upload it to the site. You enter a few questions you want people to answer after looking at it.

If the whole setup process takes you more than 5 minutes, you’re doing it wrong, and within a few hours you can have dozens of people look at your landing page and tell you what they think your product does.

This sort of Tiny Test is wonderful for testing several different variations of messages or images that you might put on a landing page. You can get people’s real first impressions of what they think you’re trying to tell them.

CTA Testing

The most important thing to get right on any screen is the Call To Action. After all, you can have the most gorgeously designed images with a wonderfully crafted message, but if people can’t find the damn Buy button, you’re screwed.

But, as with the landing page tests, this is something that takes 5 seconds. Basically, you want to show people a screen and see if they can figure out where they should click. Guerrilla testing works pretty well for this, but even that may be overkill here.

For CTA testing, I often use UsabilityHub’s ClickTest product. Again, you just upload a mock and ask people something like, “Where would you click to purchase the product shown on this page?” or “Where would you go to advance to the next slide?” or whatever CTA you’re testing.

A few hours later, you get a map of where people clicked. If there are clicks all over the place, you’ve got some work to do on your CTA.

The advantage to doing something like this over a/b testing is simply that you can get it set up very quickly with just mockups. You don't have to actually implement anything on your site (or even have a site) in order to test this way. But, if you have enough traffic and a good a/b system already set up, by all means test that way, as well.

What Are You Waiting For?

There you go. Five different options for wildly fast, incredibly cheap feedback on your product. You don’t have to hire a recruiter or write a discussion guide or rent out a usability lab. In a few cases, you don’t even have to interact with a human.

Are they perfect? Do they take the place of more substantial research? Will you be able to get away with avoiding talking to your users forever? No. But they’re easy, and you can do one of them right this second.

So...do one of them right this second!

Like the post? Follow me on Twitter.

STFU About What Women Want

In a recent post on TechCrunch, Penelope Trunk tells us (again) that most women don’t want to do startups.

First, I’d like to extend that to Asians, African Americans, Gays, and Latinos. Oh, and white men. Most of them don’t want to do startups either, because most people don’t want to do startups for a whole host of reasons.

Penelope tells us that women are different though, because women don’t want to join startups because women want to have babies. As evidence, she points out that most women downshift their careers as soon as they have babies, which of course makes startups impossible.

It’s not that women don’t join startups because of lack of opportunity or sexism or doing what’s expected of them or anything else. Now that we have completed defeated bias, all women can choose to do anything they want, and they are choosing to have babies rather than go to startups. Case closed!

Here’s the problem: Penelope, and other people who say things like this, are making my life a whole lot harder, and I’d like them to knock it the fuck off.

I’m not going to argue that most women don’t want to stay home with their children. Frankly, I don’t care what most women want to do.

I know what I want to do, and what I want to do is to work at startups. I don’t want to have children. I’ve never wanted children. I never will want children, and I certainly wouldn’t want to give up working at startups for them.

So, when a publication like TechCrunch spews some nonsense about what women want, it means that the next time I go into an interview with a male founder (and they are overwhelmingly male for some reason that I’m not going to address here, but that Penelope assures us has nothing to do with bias) who has read that nonsense, he may be thinking, consciously or subconsciously, “she doesn’t really want to work at this startup because she wants to have a baby.”

And frankly, that sucks for me and all the other women like me. Oh, did I mention that there are lots of other women like me? There are.

But let’s just look for a moment at what all of these other women, the ones with babies and without startups, are choosing to do. They are choosing to stay home because of...I don’t know what the current argument is. Hormones? Biology? Bad government policy? Nature?

It couldn’t possibly be bias or lack of opportunity because, of course, some women are choosing to work at startups, so it would be trivially easy for all women to choose to work at startups, right?

Except that my father’s law school class of 1963 had 3 women in it. That’s right. Three. Now, clearly more women could have joined the class. His law school didn’t have a 3 woman quota or anything.

But the women of 1963 chose not to go to law school. And I’m positive that there were all sorts of blowhards opining that women didn’t go to law school because they were too busy having babies, and this was perfectly normal, and we shouldn’t do a damn thing to promote more women going to law school because WON’T SOMEBODY PLEASE THINK OF THE CHILDREN.

After all, we weren’t actively STOPPING women from going to law school (any longer). It was their choice! Except that, as Penelope points out, more than 50% of the law school graduates now are women.

So, far more women are now choosing to be lawyers. You know, despite the fact that they still have babies. What women wanted, with regard to law school attendance, somehow changed between 1963 and today.

Similarly, long before women had the right to vote in the US, many women didn’t actually want the right to vote. Some even felt that women were biologically not capable of voting well. And for years after they had the right to vote, many people still felt that it was the wrong decision.

How many women in the US do you know who don’t care about voting? Fewer than felt that way a hundred years ago, right?

The point is that “what women want” changes over time. What people want changes over time. Because what we want is hugely driven by social norms and massive cultural shifts and all sorts of things that may seem biological at the time but turn out not to be.

In other words, if suddenly there are a ton of women at startups kicking ass and being awesome, it might turn out that more young women want to join startups in the future. And 25 years from now, we’ll all be laughing at the idiots who said things like “women don’t want to vote...er...go to law school...I mean...join startups!”

Penelope, do you vote? Do you know women who went to law school? I do. And I am forever grateful to the women who fought not just for the right to do these things but to make them seem like totally normal things to do.

I salute the women who said, “Hey, wait a minute. Maybe having a vagina doesn’t determine what I have to want from life! Just because a lot of women want something, doesn’t mean that I have to want the exact same thing!”

And I’m still a little annoyed at the women who said, “Oh, women don’t WANT to vote. Voting is for men!” I take that back. I’m a lot annoyed at them. They sucked.

So stop doing it. Stop assuming other women want to make the same choices you do, especially when society has such an enormous and invisible impact on your choices. Stop assuming a young woman just starting her career knows everything about all of the wonderful, exciting career choices she could make.

And mostly, stop making it ok for other people to assume that I want what you want. That’s clearly not true, since what I want most right at this moment is to punch you in the face.

I am a woman. I want to work at a startup. I don’t want to have children. I want to vote. I want to wear stiletto heels and write jQuery, sometimes at the same time. In other words, I am an individual, and I have all sorts of wants that are neither determined nor predicted by my gender.

I am a woman, Penelope, but you don’t have any idea what I want. So, kindly shut the fuck up about it.

Give the Users What They Really Want

Recently, I’ve been trying to teach startups how to do their own user research. I’ve noticed that I teach a lot of the same things over and over again, since there are a few things about research that seem to be especially difficult for new folks.

One of the most common problems, and possibly the toughest one to overcome, is the tendency to accept solutions from users without understanding the underlying problem. In other words, a user says, “I want x feature,” and instead of learning why they want that feature, new researchers tend to write down, “users want x feature," and then move on.

This is a huge issue with novices performing research, When you do this, you are letting your users design your product for you, and this is bad because, in general, users are terrible at design.

Ooh! An Example!

I participated in some user research for a company with an expensive set of products and services. Users coming to the company’s website were looking for information so they could properly evaluate which set of products and services was right for them. Typically, users ended up buying a custom package of products and services.

One thing we heard from several users was that they really wanted more case studies. Case studies, they said, were extremely helpful.

Now, if you’re conducting user research, and a customer tells you that he wants case studies, this might sound like a great idea.

Unfortunately, the user has just presented you with a solution, not a problem. The reason that this is important is that, based on what the actual underlying problem is, there might be several better solutions available to you.

When we followed up on users’ requests for case studies with the question, “Why do you want to see case studies?” we got a variety of answers. Interestingly, the users asking for case studies were all trying to solve entirely different problems. But were case studies really the best solution for all three problems?

These were the responses along with some analysis.

“I want to know what other companies similar to mine are doing so that I have a good idea of what I should buy.”

The first user’s “problem” was that he didn’t know how to pick the optimal collection of products for his company. This is a choice problem. It’s like when you’re trying to buy a new home theater system, and you have to make a bunch of interrelated decisions about very expensive items that you probably don’t know much about.

While case studies can certainly be helpful in these instances, it’s often more effective to solve choice problems with some sort of recommendation engine or a selection of pre-set packages.

Both of these more quickly help the user understand what the right selection is for him rather than just give him a long explanation of how somebody else found a good solution that might or might not be applicable to the user.

“I want to know what sorts of benefits other companies got from the purchase so I can tell whether it’s worth buying.”

The second user’s “problem” was that he wanted to make sure that he was getting a good value for his money. This is a metrics problem. It’s like when you’re trying to figure out if it’s worth it to buy the more expensive stereo system. You need to understand exactly what you’re getting for your money with each system and then balance the benefits vs the cost.

This problem might have been solved by a price matrix showing exactly what benefits were offered for different products. Alternatively, it would be faster and more effective to display only the pertinent part of the case studies on the product description page - for example, “Customers saw an average of 35% increase in revenue 6 months after installing this product.”

By boiling this down to only the parts of the case study that were actually important to the user, it gives you more flexibility to show this information - statistics, metrics, etc. - in more prominent and pertinent places on the site. This actually increases the impact of these numbers and improves the chance that people will see them.

“I want to see what other sorts of companies you work with so that I can decide whether you have a reputable company.”

The third user’s “problem” was that he hadn’t ever heard of the company selling the products. Since they were expensive products, he wanted the reassurance that companies he had heard of were already clients. This is a social proof problem. It’s like when you’re trying to pick somebody to put a new roof on your house, so you ask your friends for recommendations.

His actual problem could have been solved a lot quicker with a carousel of short client testimonials. Why go to all the trouble of writing up several big case studies when all the user cares about is seeing a Google logo in your client list?

Why This Matters

This shouldn’t come as a surprise to any of you, but users ask for things they’re familiar with, not necessarily what would be best for them. If a user has seen something like case studies before, when he thinks about the value he got from case studies, he’s going to ask for more of the same. He’s not necessarily going to just ask for the part of the case study that was most pertinent to him.

The problem with this is that many people who might also find certain parts of case studies compelling won’t bother to read them because case studies can be quite long or because the user doesn’t think that the particular case study applies to him.

Obviously, this is applicable to a lot more than case studies. For example, I recently saw a very similar situation from buyers and sellers in a social marketplace asking for a “reputation system” when what they really wanted was some sort of reassurance that they wouldn’t get ripped off. I could name a dozen other examples.

The takeaway is that, when somebody asks you for a feature, you need to follow up with questions about why they want the feature, even when you think you already know the answer!

Once you know what their problems really are, you can go about solving them in the most efficient, effective way, rather than the way the user just happened to think of in the study.

Instead of just building what the user asks for, build something that solves the user’s real problem. As an added bonus, you might end up building a smaller, easier feature than the one the user asked for.