Minimum Viable Research: A 4-step framework to get executives, clients, stakeholders, and colleagues on board with user research
“I think I can relate to the user because I want to be one.”
The other day I got an email from someone who wanted advice on how to convince the founder of the company they’re at that they should do more user research. The founder repeatedly justified not doing research with the argument, “I think I can relate to the user because I want to be one.”
For context, the startup had to do with smart devices for parents and their babies.
And…yes, you guessed it. The founder did not even have children.
At least once a week, someone emails me asking me to tell them how they can convince their boss or stakeholders to do more user research.
Here’s the truth…When people are so vehemently opposed to doing research, it’ll be hard to get anyone to change their mind.
So what should you do? How can you approach trying to get your boss, stakeholders, team, or client to buy into doing more user research?
In the article, Why I can’t convince executives to invest in UX, Jared M. Spool writes about how you’ll never be able to convince an executive that UX matters. Instead, you have to show them, and then let them decide when they are ready. He writes:
Have you ever met a smoker? Of course you have. Have you ever met a smoker who didn’t know the harmful effects of smoking? I bet not. Every smoker I know is well aware of what smoking does to their bodies, yet they continue to smoke. There are physical, cultural, and behavioral forces that make it hard to quit.
You can’t convince a smoker to quit smoking. They need to just decide they’ll do it. On their own. When they are ready.
It’s the same with executives. Neither I, you, nor anybody else can convince an executive to invest in user experience.
The same approach applies to doing user research.
I suggest that you treat the problem of people not wanting to do research like a UX problem you’re solving.
Here are the four steps you should consider when trying to get a stakeholder or boss to buy into doing user research:
- Know your audience
- Know your product
- Identify the Minimum Viable Research (MVR)
- Make changes and measure impact
Step 1: Know your audience
First, you have to do some research to figure out why they are opposed to research. Chances are you’ve heard at least one of these oppositions for doing research:
- I’m the user, so I know what they want.
- Research will slow us down.
- We can’t afford to do user research.
- No one on our team has done it before.
- Users don’t know what they want.
Don’t let these statements be the end of the conversation. Just as you would do in a user research interview, you have to ask follow-up questions to understand why the founder, boss, stakeholder, or client has these beliefs.
These statements are just symptoms of an underlying problem or belief. If you can identify the root issue, then you will have something to work with. Then and only then will you be able to design a research plan that truly addresses the fears and concerns of your stakeholders.
So when you hear the common pushback as to why someone doesn’t want to do user research, try asking some of these follow up questions:
- When was the last time you did research?
- What type of research did you do?
- Who did the research and how did it go?
- What was the outcome? What did you learn?
- How did the team apply the research?
- Why do you believe that research is expensive?
- How do you think research will slow us down?
By asking follow-up questions, you’ll start to have an actual conversation with the stakeholder. Use smart, open-ended follow-up questions to help dig deeper and avoid asking yes or no questions that will quickly dead end the conversation.
If you don’t have a question in mind beyond “can we do some user research?”…then guess what, you probably won’t!
The outcome of your discussion should help you answer the following questions:
- Why does this person oppose user research?
- What is their past experience with user research?
- How involved have they been with research in the past?
- What is their underlying fear or concern about user research — what side effects do they think it will cause?
- What internal assumptions is the team operating with?
- What parts of the product are they most concerned about?
- How is success of the product being measured?
Until you can answer these questions, don’t move on to step two. Commit to understanding your audience. Or, as the great designer Hillman Curtis said, “eat the audience.”
For more tips on how to talk to executives and stakeholders, check out this free workbook I created to help you have smarter conversations to get buy-in and belief in user research.
Step 2: Understand the product & team
The next step is to do a bit of digging to understand the product and the team.
In addition to talking to the stakeholder, you should talk to the people making the product. You want to understand their role and influence in doing research. Maybe these are your colleagues or even you.
I always try to pinpoint what the impact of not doing research is on the team. For example:
- Is the team constantly building features and then users aren’t using them?
- Is the team stuck in the weeds and in a cycle of conversations that sound like “I think” or “My cousin uses it this way” — instead of conversations that are focused around users?
- Is the team constantly over budget and delivering late because they can’t narrow down and prioritize scope because they can’t agree on what to build, or because what to build is changing due to stakeholders changing their minds?
Figure out the impact that not doing research has on the team.
In addition, take some time to look at any existing analytics you have so that you have a general idea of where there may be problem areas in the product. Also, use this as an opportunity to install any analytics tools that you may not be using including:
- Google Analytics
- Crazy Egg & Kiss Metrics (by Neil Patel),
- Sumo (by noah kagan)
- Chartbeat (by betaworks)
- ClickTale (by Dr. Tal Schwartz)
This is a good time to remind you that we cannot just rely on data.
We can’t just rely on data. We can’t only look at analytics. We can’t just sit behind dashboards and gloss over the data.
Data only tells us the what. People tell us the why. And we can’t begin to address the underlying issues until we truly understand the why.
Ok, now that you understand your audience and your product, it’s time to plan the actual research you will do.
Step 3: Identify the MVR (Minimum Viable Research)
Two of the predominant oppositions to user research are time and money.
There’s a misconception that doing research will to take $35K and 6 weeks to do. Now it could be that expensive and take that long if you were doing a large multi-city in-person research project. But if you’re just starting out with research, this shouldn’t be your goal.
When dealing with people who are opposed to research, you cannot expect them to buy into a big research project or approve budget to open up research positions on your team. It’s not going to happen.
In the same way that you wouldn’t launch a full version of your product in the first release, you can’t expect to do a huge research project the first time around.
Your first research project should focus on providing maximum insights, undeniable evidence, and tangible next steps.
Most of all, when trying to convince people about the value of user research, your first research project should be about proving the concept just enough so they can validate the idea that user research is valuable.
Once they see the value, chances are they’ll be the one to suggest to you that the team should do more research. Because that’s the way the world works. Make them think research is their idea and then you’ll be able to do more research.
So how do you identify what your Minimum Viable Research should be?
You have to figure out what the major pain points are the for the decision makers right now — the people who will need to be convinced that research is of value.
Based on your conversations that you had in the previous steps, this should be fairly clear by now.
Some examples of major pain points should be:
- Key business metrics and success metrics are not going met.
- The team is wasting a lot of time disagreeing on what to build.
- The team is releasing features that don’t get used, and then the team needs to go back and fix them or deal with UX debt.
- The team is constantly over budget or late with product releases.
Once you know the major pain points, you have to figure out what specifically in the product (assuming you have a prototype or it’s in market) you can test.
Identify a specific screen or user flow that you can focus on. For example, if you’re working on an e-commerce product it might be the checkout process, or the product search and filtering user flow, or the behaviors people have around wish-listing or saving products, or something as narrow as adding and editing new payment methods.
The goal is that you go narrow so that your research can focus on something very specific. Why? So that when the research is over, you can actually make changes to the product and the measure the impact of those changes. Then and only then will you be able to get stubborn stakeholders to see the value of research.
Side note – it’s also important to note the method of research that you should use in your plan for Minimum Viable Research and how you will share your findings.
Let’s be honest, no one wants to read a 30-page Word doc of research findings. What’s the most powerful way to share your research findings? Stories.
Why stories? Because people remember stories. Our brains are naturally wired to remember stories.
In the New York Times article, Your Brain on Fiction, author Annie Murphy Paul writes about the impact that narratives have on our brain. When our brains encounter fiction, more areas of the brain are stimulated, and this impacts our recall. When our brain encounters fiction, parts of the brain responsible for emotion, movement, smell and touch all light up. Together, these create a story that’s more memorable than a bullet list of facts.
The very best stories come from talking to users one-on-one, preferably in person. Why? Talking to people in person helps establish more of a connection and trust with the participant which elicits more honest and raw feedback.
In-person interviews, especially at the person’s own home or office, allows you to gather a better holistic picture of the person — what type of computer do they use, what browser are they on, how many tabs do they have open, what’s the state of their home or office, do they have physical artifacts that they bring up during the conversation (eg. a notebook full of their Internet passwords, spreadsheet of online coupon codes that they keep … both of which I’ve encountered in research).
At minimum, you’ll record user sessions so that you have evidence that you can take back to your stakeholders. The audio and video artifacts you get from the research is critical to getting buy-in.
Imagine you’re doing research around the behavior of users when they shop online. You’re trying to determine the value of the wish list feature. You believe that if you can get people to add things to a wish list, then you’ll be able to email them later with follow up offers for those products. The problem is that right now, no one is adding things to the wish list. So, you go do some research about it…
Now it’s one thing for you to say to a stakeholder (after the research is over) that “In the usability tests we saw that no one used, let alone saw, the add to wish list button for products.”
But, it’s a completely different thing another thing for a stakeholder to see a video of someone perusing a screen and completely missing the big “add to wish list” button, complete with a cute heart icon.
Seeing this video evidence provides the “ah-ha” moment that is crucial to getting stakeholder buy in for research. Seeing the user struggle puts the stakeholder in the users shoes.
The stakeholder now feels like they are a part of the story. They are possibly even yelling at the video “The wish list button is right there, how are they missing it????”
Bonus points if you can get your stakeholder to actually participate in the interview, but that’s a conversation for another day!
When planning your Minimum Viable Research, you must figure out the perfect combination of what pain point or problem can we easily research and what method can we use that will provide the best “ah-ha” moment for stakeholders?
Creating these “ah-ha” moments will help the stakeholder get out of their own head and into the head of the users. And that’s exactly what you want.
Step 4: Make changes and measure impact
Once you’ve done the research, you should have some actionable insights that you can plan some A/B tests around.
Back to the e-commerce example, if you were researching the problem of a store having a huge cart abandonment rate, then the research should have helped uncover why this is happening.
This is when you can work with the team to use what you learned in the research to design some solutions that you can tangibly A/B test.
The goal here is that you can go back to the stakeholder and say, “Here’s what we learned in the research and here’s what we’re going to do in the product experience to address these problems. And, here is how we’ll measure the success of the feature changes.”
What you don’t want to do, for example, is try and change the entire checkout. That would be a disaster.
Instead, change small things that you can easily measure. Take baby steps, don’t try to do an entire checkout process re-design.
Build, release, and then assess. Figure out if the changes you made impacted the checkout cart abandonment rate. If so, this is when the stakeholder should finally buy into research.
Why does this work? A few reasons.
First, you involved the stakeholder in the entire research process, so they should feel bought into it. And we all know that when people are a participant in something they’re more likely to believe in or support it. Next, you have quantitative data from these small incremental changes you’ve made to show that the changes you made impacted the checkout process.
It’s hard to ignore this combination of qualitative insights from users and quantitive results from making small changes to the product.
Ok, but what if this doesn’t work?
It’s true. Some people will just be resistant to research. You can only do so much. It’s not going to work with everyone. And nothing you say will change their mind. Nothing an expert says will change their mind. It’s just won’t happen!
The Bottom Line: Start small, iterate, and don’t give up!
Just like any smart approach to product development, you figure out the features of impact and build those. You don’t build the entire product roadmap and launch that as the first version. You start small. You launch. You learn. Then, you change course and move on.
The same applies to research. Don’t embark on a massive research project at the onset. Start small. Show value along the way. Build trust. And eventually your executives and stakeholders will see the value that it has not just for users, but for the business metrics and team productivity.
Good luck and don’t give up!