Login

If It's Not Validated, It's Not Real

You have an idea; it’s a great idea! Who wouldn’t want this feature you came up with? I mean, you know you want it, therefore anyone similar to you would want it, too. Right?

Maybe.

It’s a fallacy we tend to easily fall into: we like an idea, so everyone else must want it too (this also works in reverse, if you don’t want a certain feature).

Let’s take it a step further.

You like the feature you came up with. After talking with other developers, product managers, etc., you start to think/believe that this is a bona fide good idea that users will love.

You begin to decompose the feature, you discuss it with the team, you build it, and you launch.

But the feedback is not what you expected. The comments on iTunes and Google Play stores come back with, “what a waste of an update” or “I would have rather have had them fix the bugs than add this feature.”

What went wrong?

Assumed empathy. You assumed that you are a representative of the end user, the buyer, the customer. You assumed what you wanted was exactly what your audience wanted.

There is a real world example from the 1980s, when a town in Sweden was chosen as a nuclear waste site. A research firm wanted to poll its residents on their approval of the plans. 51% of the residents approved of the measure when first polled. When asked again, with an incentive of receiving $8,000/per resident, the approval rating plummeted.

Why?

Well, the initial thought was that the monetary incentive increased the perceived risk of having the nuclear waste disposed of in their town. Seems natural enough; however, when they polled if the monetary incentive increased perceived risk, the research came back that it was not the case at all.

So what was it?

The town residents initially felt that having the nuclear waste was a civic duty, but with the monetary incentive, it became a bribe.

What does this have to do with empathy?

The research firm assumed the money would increase approvals. It did not. They assumed it was due to perceived risk. It was not. It was something else entirely--something they never even considered.

When ideating and building features, functionality, and/or products, remember that you are not the target audience. Your audience is your target audience.

So how do you go about finding out if your idea is valid?

  • Interviews: 5-10 actual buyers/users of the product or potential product market. Have a loose script to follow and allow for deep dives in a particular area during the interview if you think it may lead to something. Be sure not to use leading questions (i.e., “would the swipe down feature allow you to bring up your notifications easier?”). Leading questions result in voided data.
  • Prototypes: Nothing fancy, but a clickable prototype (could be wireframes with embedded links to another wireframe) can go a long way into seeing the interaction from a true end user's perspective. Followed up with questions (i.e., “Why did you want to click there?”), prototypes are very powerful.
  • Surveys: In a perfect world, I would steer away from surveys. They tend to not bring in quality data. Surveys should be used as a last resort or a supplement to the prior two validation efforts.

You may have a bona fide idea and the support of your team. But until you present it to the true audience, it’s not validated. User feedback will help keep your focus fine-tuned to what people really want, preventing you from wasting time and money on a feature that won’t be positively received.

Recent Lessons