Recently I had a meeting with an entrepreneur just getting his product off the ground. He has a functional app, a small but active user base, and has been pitching potential customers. He’s talking with his active users regularly and soliciting feedback. By all accounts, he’s doing the right things and moving in the right direction, then he said something important:
“I need to talk to them about [feature x] and show them how to use it.”
This is a warning flag.
From a product point of view, we want every feature to be loved, honored, and cherished but that’s the first problem: we’re married to our features. We spend
hours days weeks on our feature and we know that everyone finds it as valuable as we imagine which is the second problem: our imagination sucks.
Which problem are we solving?
When we build a feature and no one uses it, we assume it’s because they don’t know how but that one conclusion is built on a mountain of assumptions:
- The user has the same problem.
- The user experiences pain (physical, emotional, financial, stress, etc, etc) as a result of the problem.
- The feature solves enough of the user’s problem to be useful.
- The user is aware of the feature.
- The user found the feature.
- The user figured out how to use the feature.
- The user believes the feature will solve the problem.
- The pain of using the feature is less than the pain of the problem.
I use “enough” and “pain” here because they are not easily measurable and entirely up to the perspective of the user.
When you decide “if they just knew how to use it, they would” you’ve already made a ton of assumptions. If any one (or more!) of those is wrong, the later ones don’t matter.
How do we understand a user’s pain?
First, don’t assume your user has the same problem. Instead, ask them. It can be as simple as “Have you ever had to deal with X?”
Do not ask people to imagine they have the problem. If they don’t have it, talk to someone else. Any information you get from this person is made up at best.
Next, don’t assume your user’s pain is the same as your pain. Instead, follow up the first question with “Tell me about the last time it happened.” Open ended questions are ideal because you can watch their reaction. If they get angry, annoyed, swear, or cry, this problem is big. If they shrug their shoulders and mumble through a response, this isn’t important to them.
Further, you can estimate their pain by asking:
- How much did it cost before to prevent it? ..during to improve it? ..afterwards to fix it?
- How much time did it take to cleanup or fix the problem?
- Was anyone hurt?
- Did you lose time from friends, family, or work to fix it?
- Did anyone get fired or leave their job as a result?
These get at real, tangible impacts on someone’s life, finances, and health which helps you understand the size of the problem and the consequences of not fixing it.
Don’t ask them to imagine the impact. As a species, we are awful at predicting the future. Remember when you failed that quiz and thought you were going to fail the class? Or when you went out on that amazing first date and found your soul mate?
Next, don’t assume they know how the feature maps to their problem. Yes, you may have an “injection molded, mobile, extended reach excrement removal and packaging tool ideal for canines” but calling it a “pooper scooper” is simpler and speakers to the user’s problem.
Next, don’t assume your solution is good enough for everyone. The original iPod was the Nth mp3 player on the market and mercilessly mocked and ridiculed for not having enough storage. By the standards of the day, it was small but they iterated quickly, released/improved complementary products like the iTunes store, and now those other mp3 players are extinct. You can’t solve everyone’s problems on Day One but finding a small group of early adopters and iterating are key.
Finally, now we consider the feature. Can we solve enough of the problem to be meaningful? Is it less painful than their status quo? If you can do all that, fantastic! Get rolling! If you can’t, maybe you discovered a different, more important problem to solve. Dig and learn more!
When we jump to the last question first, we’ve assumed all the answers to our un-asked questions line up in the most favorable way possible. Then we dedicate time, money, and effort to it. If any one of those assumptions is wrong or collectively they’re all just a little off, we won’t build something useful. We won’t solve a real problem. We’ll make sacrifices for something no one cares about.
There is nothing more demoralizing than when you realize no one values your work. Don’t step into that trap.