Seven More Ways People Suck at Customer Development

I’ve spent many years talking to users about how to improve products. It’s a big part of the job of any UX professional. With the recent emphasis on lean customer development and MVP, talking to customers is no longer limited to a couple of people in an organization. These days, everybody is learning from customers, and that’s a great thing for the usability of products.

Unfortunately, it does cause a few new problems. The main one is that most people who are new at talking to users kind of suck at it.

I’ve written a bit about the mistakes that inexperienced user researchers make when talking to users. However, there are several other serious problems that are far more likely to occur when the people doing the interviewing are deeply invested in the product. If you’re a founder, an engineer, a designer, a product owner, or anybody else with strong, emotional ties to your product, and you’re trying to learn by talking to users, you need to make sure you’re not falling into any of the following traps.

The Big Sale

Often, when you’re sitting down with a potential customer to talk them about your product, your first impulse is to make as good an impression as possible. This is perfectly natural. The problem is, it can really get in the way of getting good information from the potential customer about how to make your product better.

If your goal is to understand what’s not working about your product or what’s preventing people from buying it, stop trying to sell your product to the potential customer. Don’t read off a list of features that are in the product or that will be in the product. Don’t tell the customer how awesome the product is or how good it is at solving all their problems. And, for the love of God, don’t tell them about your Vision for the product.

What should you do? Shut up and let the customer tell you about their problems and how they’d like to solve them. Listen to the customer tell you about his perception of your product and what he sees as wrong with it. Your goal isn’t to convince the customer that your product is great. Your goal should be to let the customer help you make your product great.

How to Make Your Product as Awful as a Corporate Intranet

Recently I was dealing with intranets for a couple of largish companies, and I realized something. In every company where I've worked or contracted, intranets have been a problem. For some reason, the vast majority of intranets turn into huge, unwieldy, out-of-date, unusable link farms with bad search results. I’m told there are exceptions, but I’ve never seen them. Even small companies have big, awful intranets.

I started to figure out why intranets are so bad, and I came up with a list of problems that all of the ones I’ve seen seem to share. That’s when I noticed that these problems are in no way unique to intranets.

Many products I’ve used or worked on have had at least some of these problems.

None of the products I’ve used has ever managed to combine all of these problems into one enormous, unholy mess in quite the same way that a bad intranet can, but that doesn’t mean you shouldn’t give it a try! To help you out, here is a list of horrible things you can do to make your product just as bad as a typical intranet. Good luck!

Never throw anything away

The first key to really ruining your product’s usability is to never throw anything out.

Have a new feature, link, or module? Throw it onto the main screen along with everything else you’ve ever released! If even one person thinks it’s important or useful, you must be sure to support it until the end of time. This will ensure that your interface is so cluttered that nobody will be able to use the 10% of your product that is actually interesting to 90% of your customers.

Don’t put anybody in charge

It is very important to make sure that no single person is responsible for your overall product. If you want a really terrible product, make sure to enforce this total lack of responsibility and ownership.

6 Ways You May Be Failing at Customer Development

Listening to users can be difficult for a small company. Most start ups, especially lean ones, don’t have a dedicated person or team whose only goal is to connect with users, gather feedback, test products, or design new features. Often these roles are being filled by founders, engineers, or product owners. This isn’t necessarily a bad thing. In fact, having all sorts of employees connecting with users can be great.

The biggest problem I’ve noticed in situations like this is that the people who are talking and listening to users aren’t really very good at it.

You see, learning from customers can be hard. Sure, people will tell you it’s as easy as sitting down and watching somebody use your product or asking a few questions– and don’t get me wrong, that alone can be valuable! But actually getting the right information from customers and turning it into a product can take some training and practice.

What You Are Probably Getting Wrong
Let’s take a look at some of the most common and costly mistakes I’ve seen when people are trying to do their own customer development without much experience or guidance.

Bad Interviewing Technique
There are a whole host of problems that people commonly have when they first start moderating studies or interviewing users about products. I covered five of the biggest issues in this post for the Sliced Bread Design blog, but there are dozens of ways to screw up an interview.

But why does interviewing technique matter at all? Because that’s how you’re going to get information from your customers! Good technique makes it a lot more likely that you’ll be able to elicit open, honest, actionable feedback from your users. Bad technique means you may not learn anything useful or, even worse, that you may bias the user enough so that you only hear what you expected to hear.

Needless to say, it you’ve never run a user discussion session before (or even if you have), it can’t hurt to brush up on techniques like not giving a guided tour of the product, letting the user fail, not leading the witness, asking open ended questions, letting the user explore, and shutting the hell up. There is a lot more to being a successful interviewer, but fixing those few common mistakes will make getting good user feedback a whole lot easier.

Not Turning Data into Action
Once upon a time I did some work for a company that boasted of being committed to customer development. They brought people into the office weekly and chatted with them. They solicited customer opinions in surveys and forums. They did everything right! Except, when the time came to make product decisions, those discussions with customers were often conveniently forgotten, and the company just implemented features with very little regard for the data they had so painstakingly collected.

Which Metrics Equal Happy Users?

This post originally appeared on the Sliced Bread Design blog.

One of the greatest tools available to me as an interaction designer is the ability to see real metrics. I’m guessing that’s surprising to some people. After all, many people still think that design all happens before a product ever gets into the hands of users, so how could I possibly benefit from finding out what users are actually doing with my products?

Well, for one thing, I believe that design should continue for as long as a product is being used by or sold to customers. It’s an iterative process, and there’s nothing that gives me quicker, more accurate insight into how a new product version or feature is performing than looking at user metrics.

But there’s something that I, as a user advocate, care about quite a lot that is really very hard to measure accurately. I care about User Happiness. Now, I don’t necessarily care about it for some vague, good karma reason. I care because I think that happy users are retained users and, often, paying users. I believe that happy users tell their friends about my product and reduce my acquisition costs. I truly believe that happy users can earn money for my product.

So, how can I tell whether my users are happy? You know, without talking to every single one of them?

Although I think that happy users can equal more registrations, more revenue, and more retention, I don’t actually believe that this implies the opposite. In other words, there are all sorts of things I can do to retain customers or get more money out of them that don’t actually make them happy. Here are a few of the important business metrics you might be tempted to use as shorthand for customer happiness – but it’s not always the case:

Retention

An increase in retention numbers seems like a good indication that your customers are happy. After all, happier customers stay longer, right?

6 Reasons Users Hate Your New Feature

This post originally appeared on the Sliced Bread Design blog.

You spend months on a new feature for your existing product: researching it, designing and building it, launching it. Finally, it’s out in the world, and you sit back and wait for all those glowing comments to come in about how happy your users are that you’ve finally solved their biggest problems. Except, when the emails, forum posts, and adoption data actually come in, you realize that they hate it.

There is, sadly, no single reason why your new feature failed, but there are a number of possibilities. The failure of brand new products is its own complicated subject. To keep the scope narrow, I’m just going to concentrate on failed feature additions to current products with existing users.

Your Existing Product Needs Too Much Work

Ah, the allure of the shiny new feature! It’s so much more exciting to work on the next big thing than to fix bugs or improve the user experience of a boring old existing feature.

While working with one company, I spoke with and read forum posts written by thousands of users. I also used the product extensively myself. One of the recurring themes of the complaints I heard was that the main product was extremely buggy and slow. The problem was, fixing the bugs and the lagging was really, really hard. It involved a significant investment in infrastructure change and a serious rewrite of some very tricky code.

Instead of buckling down and making the necessary improvements, management spent a long time trying to build new features on top of the old, buggy product. Unfortunately, the response to each new, exciting feature tended to be, “Your product still crashes my computer. Why didn’t you make it stop doing that instead of adding this worthless thing that I can’t use?”

Now, you obviously don’t need to fix every last bug in your existing offering before you move on and add something new. You do, however, need to be sensitive to the actual quality of your product and the current experience of your users before adding something new. You wouldn’t build a second story on a house with a shaky foundation. Don’t tack brand new features onto a product that has an unacceptably high crash rate, severe usability problems, or that runs too slowly for a significant percentage of your users.

Before you add a new feature to a product, ask yourself, “Have I fixed the major bugs, crashes, and UX issues that are currently preventing my users from taking advantage of core features?”

Is Continuous Deployment Good for Users?

This post originally appeared on the Sliced Bread Design blog.

The recent release of Windows 7 got me thinking about development cycles. For those of us who suffered through the last 2+ years of Vista, Windows 7 has been a welcome relief from the lagging, bugs, and constant hassle of a failed operating system. Overall, as a customer, I’m pretty happy with Windows 7. But, at least on my part, there is still some latent anger - if Windows 7 hadn’t been quite as good as it seems to be, they would have lost me to Apple. They still might.

A big part of my unhappiness is the fact that I had to wait for more than two years before they fixed my problems. That’s a lot of crashes and frustration to forget about.

One approach that many software companies have been adopting to combat the huge lag time built into traditional software releases is something called continuous deployment. This sort of deployment means that, instead of having large, planned releases that go through a strict process and may take months or years, engineers release new code directly to users constantly, sometimes multiple times a day. A “release” could include almost anything: a whole new feature, a bug fix, or a text change on the landing page.

I worked with a software development organization that practiced continuous deployment on a very large, complicated code base, and I can definitely say, the engineers loved it. From the point of view of the employees, continuous deployment was a giant win.

But how was it for the users? The fact is, some decisions that seem like they only affect engineering (or marketing, business, PR, etc.) can actually have a huge impact on end users. So, whenever organizations make decisions, they should always be asking, “how might this affect my customers, and how can I make it work best for them?”

Is Continuous Deployment Good For Users?

As with so many decisions, the answer is yes and no. Continuous deployment has some natural pros and cons for the customer experience, but knowing about them can help you fix the cons and benefit even more from the pros.

Big Customer Wins

Fast Bug Fixes

Perhaps the biggest win for users is that bugs can get addressed immediately. Currently, even Microsoft releases patches for some of its worst security holes, but there is certainly a class of non-critical, but still important bugs that have to wait until the next major release to get addressed. That means weeks, months, or even years of your users dealing with something broken, even if the fix is simple. In continuous deployment, a fix can be shipped as soon as it's done.

A Faster Horse - When Not To Listen To Users

This post originally appeared on the Sliced Bread Design blog.

Henry Ford once said that, if he’d asked his customers what they wanted, they’d have asked for a faster horse. In the high tech industry, this quote is often used to justify not talking to users. After all, if customers don’t know what they want, why bother talking to them?

You need to talk to users because, if you ask the right questions, they will help you build a better product. The key is figuring out the right questions.

For starters, users are great at telling you when there’s something wrong with your product. They can tell you exactly which parts of the product are particularly confusing for them or are keeping them from being happy, repeat customers. Figuring out what to do about those problems is your job.

In general, users are not going to be able to answer the following types of questions:

• What new technical innovation is going to revolutionize a particular industry?
• What’s the next cool gadget that you’d like to buy?
• Do you think that people like you would buy this new cool gadget that you’ve just learned about?
• What new features would make this product more interesting/compelling/fun/easy to use? (although, this question becomes more answerable when the user is presented with some options for which features they might prefer.)
• How exactly should we change the product to make it easier for you to use?

They are fantastic at answering questions like these:

• What do you most love or hate about this product?
• Do you find anything about this product hard to use or confusing?
• Does this product solve your problem better or worse than what you’re currently doing?
• How are you currently solving a particular problem that may or may not be addressed by this product?
• What don’t you like about your current solutions for a particular problem?
• Why did you choose this particular solution as opposed to another solution?

Obviously, there are innumerable other questions that you might want to ask your users, so how do you decide which ones they’ll be able to answer with any degree of accuracy?