How to make sure you’re dealing with the real problem and not just a problem manifestation

In his article Outside-In User Story Example, my favorite product management expert, Scott Sehlhorst, describes how users “almost always fixate on problem manifestations, versus underlying problems”:


Problem manifestation Problem
My contact list is missing this person I need to know the identity of this person
My phone does not ring loudly enough I am not noticing incoming phone calls
I need a faster horse I need to get to my destination faster

To explain what it means to switch a product team’s role from “do these things” to “solve these problems”, Scott uses a personal experience of being a part of a messaging conversation on his phone with three other people (a group MMS) and seeing two names and one phone number because one of the participants was not on his Contact List.

A reader asked in the comment section:

Do you have any personal criteria that help you determine whether you are working with a design or intent? The example of “faster horse” vs “get somewhere faster” is good but I am not sure the difference is always going to be that visible. Do you have any personal recommendations on how to determine whether you are dealing with a design?

I’m sure Scott and other successful innovators have powerful approaches to deal with this issue. Here I’m going to share mine.

The secret to going from a “problem manifestation” to the real problem to be solved is to have a process that supports these key principles (the actual steps may vary from company to company, product to product, and team to team):

  • All product and feature ideas are based on customer insights, and address an important need they have.
  • Customer insights are gained not only from interviewing customers, but also observing end-users in action. (If you just listen to what people tell you, you’ll miss important insights.)
  • Feedback from customers is sought all along the way: when you have the idea, a concept, a low-fidelity wireframe, the high-fidelity wireframe, after launch.

To give an example of how this works in practice, I’ll reuse Scott’s example of group text messaging.

Imagine that the experience Scott describes happened to a customer of your messaging app, and this person submitted a request for an enhancement to be able to add people in a group conversation to their contact list. How do you know they’re focusing on a problem manifestation and not the real problem?

1) Have “problem interviews” with your customers

Instead of taking the request at face value, first you’d ask the user to explain the context in which they realized they needed this feature. They may say something like, “well, from time to time I find myself in a text conversation with a group of people, and instead of seeing all their names, some people are displayed as phone numbers, which makes it difficult to know who is participating on the exchange. That’s why I wish I could add these people to my Contact List and start seeing their names instead of numbers.”

You could then reply, “Oh, I see. It looks like your end goal is to have the names of all participants of an group conversation listed on the screen as the exchange happens, so you know who is participating on it–is that right?”

(Customer) “Yes, that’s it!”

(You) “OK. Let’s say the app automatically identified the person for you, and displayed their name instead of their phone number, even if they aren’t on your contact list. Would that solve your problem?”

(Customer) “Yes, as a matter of fact, it would.”

(You) “Got it. And let’s say this person’s name was displayed every time they are part of a group conversation with you, despite the fact they’re not on your Contact List. Would you still want them added there?”

(Customer) “Well, not automatically. If I have the intention of contacting the person directly in the future, then yes. But it’s possible that the person is someone I don’t have a relationship with, and adding them to my Contact List would just clutter it.”

(You) “I see… It sounds like it would be useful for you to, besides seeing the name of everybody who is in the group conversation, know when someone in that conversation is not on your Contact List, and then decide whether to add the person to the list or not. Is that true?”.

(Customer) “Yes! Once the conversation is over, the app could ask me whether I want to add the person to my Contact List, and only do so if I confirm I want it done.”

Note how at the end of this conversation the user is back to thinking in terms of a solution (“the app can ask me if I want to add the person to my Contact List”). Accept the reality that it’s human nature to focus on problem manifestations and candidate solutions, and that it’s your job to redirect the conversation back to the underlying intent.

Even if the customer suggestion ended up being ideal, they’re not going to be thinking of all details, so we’re not trying to design the final solution at this point. It’s quite possible that the same customer who suggested the solution above would become annoyed if the app started asking each time they were on a group conversation with the same person, “Roy Miller is not on your Contact List. Would you Like him to be Added?” without an option to say “No (and don’t ask me again)”.

Every time the customer attempts to describe a solution (“I want to add people from a group conversation to my Contact List”, or “I want to be asked at the end of an group conversation whether I want to add to my Contact List the participants who aren’t there yet”),  you can steer them back to a conversation about their desired outcomes (e.g., know who is in a group conversation, selectively add people on a group conversation to my Contact List when I want to be able to reach out to them), as opposed to how (and when) these outcomes would be achieved.

2) Observe end-users in action

Talking to customers is not enough. It’s also critical to observe the end-user doing the tasks that your product is going to support. If you just listen to what the people tell you, you’ll miss important insights.

In our example, you could observe someone having an group conversation that includes people that aren’t in their Contact List and therefore have their number displayed instead of a name, to see how the interaction happens.

3) Check-in with customer in all stages from problem definition to solution implementation

Drawing a parallel with past real-life projects, first I’d have checked back to customer to see if they agree that these are the two problems they are trying to solve:

  • Know the identity of the people in my group conversation. As a participant in a group conversation, I want to see the names of all identifiable people who are part of the conversation, even when they’re not part of my Contact List.
  • Selectively add people from the conversation to my Contact List. As a participant in a group conversation with people who are not in my Contact List, I want to be given the option to selectively add them to my contact list.

After validating that I had identified the correct problems to solve, and determined that these problems represent high-value market opportunities to pursue, I would develop a concept for how to solve these problems, and check back with the customer to validate that concept. Then I’d check in again when there was a low-fidelity wireframe to show, a high-fidelity wireframe, and after launch.

Throughout the process, we’d be looking at candidate solutions. For the second user story, is it better to update the Contact List and later ask the customer if he wants to keep or discard the new contact? Highlight the names at the end of the conversation and ask whether to add them as a contact? Create a workflow where the users can press names to add them to the Contact List during the conversation? These decisions should be made ahead of implementation as part of the user experience design, taking into account usability, value, feasibility, and costs.

Do you have a different approach to go from “problem manifestation” to “problem” before working on a solution?

If so, share your thoughts (or link to a blog post that fits this topic) in the comments section, so more people can learn from your successes.


Photo credit: Chris Devers (Creative Commons)

7 Replies to “How to make sure you’re dealing with the real problem and not just a problem manifestation”

  1. Hi Adriana,
    I like to learn how the others deal with their problems.
    Very often It helps me to understand how to define and resolve mine.

    Thanks again

  2. One of the ways I like to think about design versus problem is through the question why. When a stakeholder requests something, I try to answer the question why. I don’t recommend asking that question directly since it can be seen as combative, dismissive, and/or confrontational. Instead, ask questions around their request. How do you imagine yourself using the faster horse? Help me get a sense of what the faster horse should change for you. See also the five whys.

    1. Hi, Peter,

      I agree, asking “why” is a powerful tool. Like you, I typically use the indirect methods of asking for the reason you describe. Another question I like to use to get to the underlying problem is, “if you had a faster horse, what would you be able to do then that you can’t do now?”

      Thanks for stopping by!

  3. Hi Adriana,

    Great article, thanks for sharing. If the ‘real problem’ is not obvious, I always do a root cause analysis. What is it what the user really wants? If the user asks for a bridge, what would his goal be? Crossing the river? If so, how often? If it’s a one time thing, he could just be satisfied with a inflatable rubber boat :-).

    Anyway, there are several helpful tools/methods to perform root cause analysis (5x why, fishbone, etc)

  4. Hi Adriana,

    Long time no speak, I hope you are well!

    This is a great article, and such an important point. I sometimes imagine that as BAs part of our job is to help stakeholders climb (and descend) a ‘logical ladder of abstraction’. For example, they might come to us with an explanation of a problem (from their perspective) and a solution that that problem. Yet, we need to help them climb up the ladder of abstraction to help articluate *why* the problem is important… and also to understand the boundaries of the problem. By better understanding the problem and the desired *outcomes* we can then help them imagine multiple different solutions/possible future options.

    I love your idea of separating out problem and problem manifestation, and I really like the idea of running specific ‘problem interviews’.

    Incidentally, I ran a webinar a few years ago which is archived on my blog, on a very similar topic. I hope you don’t mind me sharing it here, in case readers might be interested? Here is the link:

    Thanks again for a very interesting and practical article!

    1. Adrian, my apologies for the delay having your comment approved and replying to it! I just realized that WordPress wasn’t notifying me of comments in moderation.

      Of course I don’t mind you sharing the link — what a great resource, thank you for sharing. I’ll make sure to forward the URL for BAs whenever it’s pertinent.

      Thanks for stopping by. It’s always great to know that someone with your experience agrees with my view :-).

Comments are closed.