There are times when I get super excited about solving business problems for an organization. After speaking with a data analyst or looking into Google Analytics, I find a spot in our product that isn't performing well. For instance, there's a considerable drop-off rate during our check-out flow or a high bounce rate on the homepage, or people sit on a particular page for a long time (what are they looking for?!?).

Utilizing user research to understand why these things may be happening helps us connect our value as researchers to the business. I can go straight to a product manager and say, "Hey, we're having these issues in our analytics; let's look into this with research." Likely figuring out those metrics is a shared goal with the product manager, leading to easier buy-in.

Instead of always talking to users to find out more problems to tackle, it is also interesting to start from the other way around. Look at Google Analytics or data you have collected to see where they might be in the product.

Starting with a business problem

As I have mentioned before, whenever a research request comes my way, I always have the requester fill out an intake document. In this, I ask them what the business problem is and, separately, what the customer problem is. Frequently, the business problem is copied and pasted into the customer problem. Trust me, I've tried varying the order to ask about the customer problem first, but the same result ensues.

What's wrong with this? I just mentioned how great an opportunity to start a project from a business perspective, so what is the problem?

A business problem is NOT necessarily a user problem. However, a user problem is almost always a business problem.

So, when a research request comes in saying, "Not enough people are signing up" or "People aren't using our product across their teams like they are supposed to" or "Users are dropping off during our funnel," I have to say:

"So what? That isn't a user problem."

Why do we start with customer/user problems?

I am in no way saying that figuring out why these business problems are happening isn't essential. Approaching user research from the business side can be an excellent way to start a project; however, we have to be very careful as researchers. In an ideal world, it would go like this:

The problem is, that's not how research works. We can highlight business problems, but we can't ask our users to fix them. Users and customers don't care about our metrics or business problems; they care about whether or not the product works for them. If we aren't asking the right questions to users about their issues (not the ones we are), we aren't helping them. And, if we aren't helping them, those metrics won't change.

If we start by understanding what the user/customer cares about, we will solve the correct issues rather than business metrics. And, most likely, if we solve user/customer problems, the metrics will become more favorable and improve.

However, since many colleagues we work with come from the business perspective, it is not always easy for them to automatically convert a business problem into a potential user problem. As user researchers, we have to help them translate business needs and issues into user problems to focus on finding out the most critical information and doing the most impactful research study.

Business perspective → user perspective

Whenever I see a potential business problem in analytics or through speaking with colleagues, I automatically figure out a potential user problem in my head. Keep in mind, by coming up with a user problem, we don't delete the business problem. That is why I ask those two separate questions: business problem and user problem. After we brainstorm and test solutions, the business problems and metrics should indicate if we chose the best solution.

Generally, whenever I get a research request with a business problem highlighted as a user problem, I work together with my colleagues to pull apart a user problem. I could easily do this on my own, but this is a great time to educate your stakeholders on the differences and help them cultivate a user-centric mindset.

To understand the potential customer problem behind the business issue, I ask the following questions:

1. "Is this a customer problem?" First, I start with this question, whereas the answer is usually a silent room before someone hesitantly explains the problem's logic. I explain why this is a business perspective rather than a user problem and the importance of splitting the two.
2. "Are there technical issues that could be causing this problem?" This question has nothing to do with the user necessarily but is vital to ask. Has the product manager looked into bugs or technical issues that could be impacting this metric? If we don't understand this first, we could do an entire study to determine a critical bug keeping users from continuing to the next step.
3. "Why would the customers care about this?" We then dive into why customers might care about this particular business problem. In this section, I try to get colleagues to discuss the business issue from the user's perspective. Often, the answer comes to "they wouldn't care." And that is true. Again, users/customers don't care about our business metrics; they care how effective, efficient, and satisfactory our product is for them.
4. "How could this be impacting our customers?" Now we get into more fun stuff. We take the business problem and figure out how it might be impacting our customers. Based on the metric, what are the things that could be going wrong with our customers that cause this? What problems could users have to create this business problem? Again, here we are looking at this from the user/customer perspective instead of the business.
5. "Would solving this help out customers? If so, how?" Again, this is taking the business problem and flipping it toward the user. If we solved this business problem, how would it help our customers, if at all? Asking this question can help colleagues understand that we might not get meaningful information if we don't start from a user problem for a research study.
6. "Have we heard this problem in previous research?" Once we translate the business issue into a customer problem, I always ask if we've heard of this problem in previous research. If it has come up repeatedly in an earlier research project, it is something worth looking into. That doesn't mean we can't work on it if it hasn't, but it can simply help you prioritize requests.

After this exercise, we brainstorm some user problems that are associated with the original business problem. This part is a fun way to include and educate your colleagues even further. If they understand the differences, they may approach you next time with a business problem and a user problem!

An example

Let's say a product manager approached you with a joint business and user problem in an intake document.

Business/user problem: Not enough people are signing up for our subscription. We see a decline in subscription revenue by 5%.

Now going through the steps, you would ask:

1. Is this a customer problem? No, this is purely a business issue. People are not signing up for a subscription, and we see a decline in revenue because of that. There isn't any user perspective or indication of how to help user's through their problems.
2. "Are there technical issues that could be causing this problem?" The product manager checked the technicalities, and there are no critical bugs or technical issues.
3. "Why would the customers care about this?" Customers don't necessarily care that the subscription revenue is declining or that your organization isn't getting more subscriptions. They care that something may not be working during the subscription process or that the subscription is not what they need or expect.
4. "How could this be impacting our customers?" The fun begins! If people aren't signing up for the subscription, there may be a few issues:
   1. They are not getting the information they need
   2. They are not able to finish the subscription funnel to sign up
   3. The subscription is not solving a problem for them
   4. They have questions that aren't getting answered

If the subscription revenue is declining, you might have a problem with people canceling their subscriptions. However, I would focus on one question at a time.

1. "Would solving this help out customers? If so, how?" Based on the above brainstorm, would fixing these issues help customers? Likely, yes. And it may very well impact subscription sign-ups and revenue.
2. "Have we heard this problem in previous research?" You have heard that users struggle with filling out all the information to sign-up and are unclear about certain aspects of the subscription. With this in mind, you would prioritize these as the focus of the research. If you have not, you brainstorm with the product manager how many and which user problems to focus on.
3. Brainstorm. Based on the above information, you can now choose which problem to focus on for your research session and create the projects' goals. For example, if you decide to go with the funnel issue, you can ask, "What are the pain points people are encountering during our subscription sign-up?" Or, if you go for the lack of information issue, you can ask, "What information is missing or confusing from the crucial pages?"

Overall, it is fantastic to walk the line between business and the user as a user researcher. With these skills, you can speak to both colleagues and the user and solve the most critical problems for both.