This article is the first of four in our Project Management blog series. Check back every week for the next four weeks to read the rest of the series.

There are a lot of failed products out there, but we never hear about them*. No one markets their failures; they only market their successes. But these failures do exist, and they’ve failed because they didn’t solve a real user problem. It’s not that the product wasn’t innovative or well built. Rather, it’s that earlier in the development process, no one asked enough questions, both of users and of themselves.

At the first sign of a problem, we have a tendency to jump right to finding a solution for it. The urge to fix what appears to be broken is prevalent throughout our lives.

Imagine this: You’re talking to a friend about some problem you have, and you get halfway through describing our problem when your friend pipes in with, “why don’t you just do X?” You start to explain to your friend that that won’t work because of Y. Your friend responds by telling you that you should instead do Z.

This cycle continues until you both get tired, and you leave the conversation unsatisfied, feeling as though you volleyed words back and forth but never really heard one other. You are left trying to figure out how to solve your problem on your own.

Users experience a similar feeling of dissatisfaction when we put products in front of them that might be lovely solutions to a problem, but don’t quite solve their problem. If we’re lucky, users will tell us how we got it wrong. In most cases, though, they’ll just stop using our product, and we’re stuck trying to figure out why.

But this doesn’t have to happen, so long as you approach your product with a clean slate and no pre-defined solution. Have no agenda other than to truly understand what problems are worthy of your efforts.

Re-thinking Product Management: A New Approach

Imagine the solutions that you could come up with if you knew that what Sally really wanted to do was save and share memories of her life, rather than focusing on the fact that she can’t take pictures. The first step in shifting toward this alternative method of product development is understanding the difference between a problem and a solution. A problem is a goal or objective that a user would like to achieve, but can’t. A solution is a product or process that can help a user achieve that goal or objective.

Oftentimes, when I ask a team which problems they’re solving, I hear them describe a solution that they want to build, but attempt to frame it as the problem: “Sally can’t take pictures.” “Michael wants to edit photos.” “Lucy needs more font options.” When this solution-focused work is taken to teams, it jeopardizes any alternative, innovative solutions the team could develop.

Imagine the solutions that you could come up with if you knew that what Sally really wanted to do was save and share memories of her life, rather than focusing on the fact that she can’t take pictures. What if you knew that the real reason that Michael wants to edit his photos is because he has an unsteady hand and always takes blurry pictures?

The second step in shifting toward this new methodology is to dig deeper when talking to users and collaborating with your team. Consider, for example, the issue that Sally can’t take pictures. If that “problem” is brought to your team, the conversation that follows might sound something like this:

A: Sally can’t take pictures.

B: Okay, so we need to put a camera in the app.

A: Well, she already has a camera in the OS. Do we really need to add a camera?

B: Okay, we’ll link out to the existing camera and build a way for her to see the shutter inside our app.

A: We shouldn’t need to link to existing software. That seems like a disjointed experience. Are there any other solutions?

B: Well, we could put a camera in the app.

But what if you found your inner two-year-old, and asked why?

A: Sally can’t take pictures.

B: Why does she need to?

A: Because she has kids.

B: Why does she want to take pictures of them?

A: She wants to remember what they looked like and did as children so that she can show them when they get older.

B: Why does she want pictures?

A: Because she wants to easily share these moments with her family members.

In that exchange, we learn so much more about our user. It’s then possible for us to stop focusing solely on adding a camera to our product and instead figure out a way for Sally to share her memories with family members.

It’s common in product development to get caught up in the solutions we love or the ideas we have. This method, unfortunately, leads to an abundance of features and products that users don’t want, can’t use, and/or don’t need. If we focus on understanding the underlying problems that people have, we can build stronger, more meaningful, and more successful products we feel good about.

Learn More: Product Management Webinar Series

For many people, this approach to product management is new, difficult, and takes practice. I’m passionate about helping product managers and others in product development learn how to think in this alternative way. That’s why I put together a four-part webinar series to give you a jump start. Check out the first installment, ‘Hey, What’s Your Problem?’ 

Facebooktwittergoogle_plusredditlinkedinby feather

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>