3 Questions That Kill Features

There are three questions that I ask over and over, throughout all of my projects. They often kill a potential idea or feature, and sometimes they make people work harder than they want to. And that’s a good thing.


Any real life UX project is going to include factors that have nothing to do with the actual project.

Company politics. Egos. Processes that never worked, even though we keep using them anyway. Trends. People who are distracted, because lunch time is in ten minutes. People who want to look smart but don’t want to learn anything new…

And so on.

All of that can add up to one moron who decides to tell a bullshit story and make a feature sound good, and then everybody agrees because they weren’t paying attention, and 6 months later the developers have stopped respecting you.

Don’t tell me you have never been in that meeting. You have. Maybe you weren’t paying attention, but you have.

These three questions look simple on the surface, but you’d be amazed how much (useful) trouble they can cause in a real conversation:

1) What are we trying to solve?

2) How do we know that is a problem?

3) Why are we trying to solve that?

Let’s take them apart and see what they are made of, shall we?


What are we trying to solve?

In other words, what is the problem or question that should have an answer when we’re done?

Have we found that users are confused by something? Does the data show that users leave the site on a certain page? Did the boss get an idea based on magic and unicorns?

By asking what we’re trying to solve, we are looking directly at the reason for the conversation. It might be an assumption. It might be a misunderstanding between developers and designers. It might be a problem that could happen in the future, but it isn’t real yet.

All of those are reasons to stop, and re-think: is this something that needs to be solved at all?

Or, if someone can state the problem or the question you’re trying to answer, that’s a good sign. It means someone did their job a little bit.

Keep going!


How do we know that is a problem?

Being able to point at a problem doesn’t always mean the problem is true. It is only a matter of time before someone goes into analytics and comes out with data that “proves” something they wanted to do anyway. 

In the meeting they will say, “the data shows that this is a problem,” or “user interviews show that this feature could be better,” or “marketing says conversion is low on this button.” You know: vague, unsupported requests.

That’s when you say, “how do we know that?”

What you’re really doing is asking about the source of the information.

Data can be interpreted in a lot of ways. If someone is good enough to find a problem, they are good enough to explain the data, specifically.

And if they’re not, they won’t be able to.

If users mentioned it in the interviews, ask what they said, or what they did instead, or how that changed their behavior. Don’t just accept a conclusion (hypothesis) without knowing where it came from.

And what does marketing mean by “low conversion”? Conversion is one of those words that can support anything you already wanted to do… but maybe the problem is the way marketing wrote the copy. Or maybe nobody actually wants the thing, so conversion is low because it sucks. Or maybe they are doing a banner campaign that brings in irrelevant traffic.

Or maybe this is the same smart person as before, and they can explain it to you. Great! Now you know the source of the information, and it sounds good. 

Keep going!


Why are we trying to solve that?

This one cuts deep, because it often becomes a question about business or strategy.

And people often have no idea why they’re working on a particular feature. They just are.

Often, it is a waste of time to improve something, because it doesn’t contribute to your bigger goals. If you spend time working on something that doesn’t move your users forward (and therefore your company), you might be wasting that time, which you could spend on something more valuable. 

The trick is knowing what your bigger goals are.

What you’re really asking is “what is the value of solving this problem, or understanding this question?”

If you’re just curious, the value is low. 

If it creates something that your competitors can’t do, the value is high.

If you want to do it because Twitter did it and it looks awesome, the value is low.

If it will make it much easier for customers to pay for your service, the value is high.

If your company serves a group of users that nobody else serves, then doing something nobody else is doing might be really valuable. And doing something that everybody else does might be worthless—it might even hurt your company— because it doesn’t serve your users.

If you are the intern and, seriously, this is like the coolest idea ever, and you worked, like, really, really hard on it, and you think people should take you a little more seriously, because your Tumblr blog is on fleek and old people don’t really know how the internet works anymore because if they did they would have read that article you found on Medium, ew, I mean Kik, which changes everything and proves that nobody is doing chat bots for Messenger anymore, because you need to make a Slack-integrated Reddit bot that pulls gifs from Instagram and questions from Telegram to make trivia content for your Periscope live stream, ASAP, otherwise you’re basically dead in the startup scene and if that happens you just won’t. The value is obviously off the charts. Do it. Definitely.

You get the idea. 

Ask “why?”

The big why. Not the “why” that will change after you’ve had your coffee.

And if it’s a smart person that understands how this feature/experiment/solution fits into the bigger picture, then they understand the value of building it. Maybe marketing was right, and the conversion is low, and the data clearly shows that the second page in the flow loses a lot of people, and this is how customers become customers!

Sounds like a concrete, verified problem worth fixing.

Keep going! And give that smart person a high-five for doing a good job. That makes your life, as the UX designer, better.


Cutting through bullshit is usually a matter of questioning the obvious. All you need is the patience to sit quietly while people realize they don’t know the answer.