In theory, designing a new product should be easy: interview your users, find out what they want, and make it. Unfortunately, in practice the process is never quite that straightforward. In fact, if you’re looking to make a product that gets high levels of adoption, saves companies time and money, and is loved by users, listening to what your customers say they want may not be the best place to begin.
What people say and what they do are often at odds. Think about your Netflix queue. Most people make an extensive list of movies they should watch, such as classics and educational documentaries. However, when it comes to actually watching a movie, these titles gather dust. Those movies are great but tonight — just tonight — wouldn’t a light comedy or an action flick see more appropriate? Ask users a question about a business process and you will inevitably find out about how the process is supposed to be, not how it is.
Don’t get me wrong — user interviews do produce a lot of valuable data, but data is not an end in itself. We use data to come up with meaningful insights. But data is often contradictory and fragmented. In practice it is difficult to assimilate large amounts of data and obtain clear insight. While users are very good at pointing out the potholes in their current environment, and excellent at trying to find workaround solutions, it’s difficult for them to imagine an entirely new and alternative environment — and good products often require that kind of a leap. To complicate matters more, in today’s turbulent business environment, the needs of the users may actually be evolving as you conduct the research. You are, in effect, chasing a moving target.
So it’s hopeless, right? Well, no. There is an alternative to listening to what users say: listening to what users do.
I still can’t believe this! All this hype for something so ridiculous! Who cares about an MP3 player? I want something new! I want them to think differently!
— from MacRumors comment board October 23, 2001
According to Steve Jobs, user interviews weren’t useful in developing the original iPod. Highsnobiety recounts some decidedly mixed user reactions to the initial release in 2001. Yet the iPod was immediate user adoption despite the lack of formal user input. So how do you know when you have a good product? Put it in front of your users — if they use it, it’s good. But new products and features often do not get user adoption. Jack Gordon, CEO of AcuPOLL Research, a market-research firm that specializes in new product launches, estimates 80–95% of new product launches fail. No company has enough resources to build complete products or features only to find out, after the fact, whether they will have adoption.
Luckily, there are two tried-and-true methods of learning what will be successful without spending a fortune: 1) build prototypes, and 2) build them small. Successful products have one core feature that builds loyalty and inspires passion — it is the “game changer,” and prototypes help us identify that feature. If the feature actually provides value, users will want to use it immediately. Better yet, they will be willing to pay for it up front, or invest their time in helping you make it better. Steven Cohn of Validately.com, a web app that helps companies validate insights, calls these features “needle movers.” He says “We spend zero time thinking about how to schedule the non-needle moving features.”
You can’t actually know what the needle-movers are without validating through testing — though we often deceive ourselves into thinking we can. Once the needle-mover is pinpointed, build a very, very, limited version of it — with zero bells and zero whistles — and put it in front of your users. It doesn’t have to be beautiful. It doesn’t even have to be 100% functional. The point is not to build an epic software application in one fell swoop but to simply test your assumption that this product or feature genuinely adds value. If you get adoption, build on it. If not, it’s back to the drawing board. In other words, never put all your eggs in one basket or bet your development budget on an untested assumption. It takes humility and discipline to test even what you think are the most basic assumptions, but in the end it may just save you from creating features and products that gather dust.