A PM’s Guide To Nailing User Research With Zero UXR Training

Read The Transcript:

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

Hannah Clark: Anyone who’s worked with a really solid user research team can attest, great UXRs are worth their weight in gold. But let’s be honest, in this economy, gold is not so abundant. So I’m willing to bet that there are people listening right now who aren’t working with a well resourced team of UXRs. In fact, if you’re a product manager, there’s a good chance that you are the de facto user research lead in your organization. And if that’s the case, consider this episode our care package for you.

Our guest today is the amazing Michele Ronsen. She’s a CEO and Founder of Curiosity Tank and a seasoned and passionate user researcher. What I loved about talking to Michele was that all of her answers are so straightforward, so useful, and very actionable, even if you have no formal UXR training.

But my favorite part of the conversation was toward the end when she shares an awesome method for using storytelling to ensure that your research learnings inspire and motivate your stakeholders to take action. Let’s jump in.

Welcome back to the Product Manager podcast. I’m here with Michele Ronsen. She’s the CEO and Founder of Curiosity Tank.

Michele, thank you so much for joining us today. I’m super excited to talk to you.

Michele Ronsen: Thanks for having me. I’m glad to be here.

Hannah Clark: So can you tell us a little bit about your background and how you ended up as the founder of Curiosity Tank?

Michele Ronsen: Yes, I am a user researcher. I am an executive, a coach, a mentor, an educator. I both conduct design and user research and I teach people around the world how to ask better questions so that they can make more confident decisions. I have been a career educator in the design space and I’m formerly educated on the design side and I spent the first part of my career designing all sorts of experiences and products and services and transitioned into the research side about 12 years ago.

I absolutely love it. I completely won the career jackpot. It’s amazing to do what you love and to love what you do.

Hannah Clark: Absolutely. So today we’re going to be talking about research planning and particularly for product managers who are listening who are in the position where they’re performing the UX research role without any formal UXR training.

So can you start us off with just a little bit of context on why research planning is such an important step and why we should never skip it?

Michele Ronsen: Absolutely. And I see this a lot. So plans are the skeleton of all proper research and user research is definitely different than customer calls or sales calls.

User research has a rigor to it that will ensure or is intended to ensure that we’re gathering feedback from the right people in the right way and that we’re asking the right questions that ladder up to our business goals. So without a plan, one cannot be successful conducting any sorts of user research.

It’s that black and white. The process of authoring plans brings the stakeholders together, services different interpretations and perspectives around what we should be learning, why we should be learning about this and how the learnings will be applied. Basically, it sets the stage for the team to identify the goals, clarify the key questions, talk about who’s best suited to provide this sort of feedback, and much more.

So in the end, the core takeaways from the plan are to get the stakeholders on the same page in terms of what are we looking to learn, like specifically, how will the learnings be applied and when. And again, these really need to ladder up to broader business goals. I like to say, if you don’t have a few hours to draft a research plan, you probably shouldn’t be conducting research. It’s that important.

Hannah Clark: Absolutely. I’m wondering if you can share an anecdote of maybe something you worked with a client or a company that you’ve worked with that had a really strong research planning and what the outcome was of that?

Michele Ronsen: It’s black and white. I mean, I don’t have examples of teams I’ve worked with that don’t have plans because I wouldn’t work with that team.

It’s like oxygen, right? You need oxygen to breathe. You need a research plan in order to do any sort of successful research. The research plan identifies the research goals. In other words, like, why are we doing this research? It identifies the actions that will result from it. It identifies the key questions and prioritizes them.

It includes what we already know, and those might be in the form of some sort of hypotheses or assumptions or might come from existing research or feedback. It includes some details about the approach, like how we will achieve these goals, the recruiting criteria, the methods best suited. Any budget considerations or timeline considerations and budget might refer to either like hiring a researcher or a designer to either run the research or build the prototype that might include incentives for the participants, things like that.

So, unfortunately, I don’t have examples of research that have been run without plans because I wouldn’t be involved in something like that.

Hannah Clark: Yeah, it makes sense. So, let’s talk process. You’ve given us some really good starting points as far as some things that could be included in the plan, but when we’re thinking about a bare bones research planning process that can be adapted to any product team, can you walk me through how you get started on that and what are the ways to ascertain what the needs are for the research project?

Michele Ronsen: Yes, so the first thing I suggest is identifying what we already know about the people that we want to learn from or gather that feedback from in the question set. So I like to say somebody somewhere knows something, right? Let’s find the dead bodies. Let’s leverage learning to inform future learning. We almost never start research from scratch.

Something exists somewhere that will prevent us from having to reinvent the wheel and do research. So the first step would be to identify, like, what do we already know and how confident are we in those learnings? The second would be stakeholder kickoff meeting. And I have a document to share with you that walks through key questions for stakeholder kickoffs for research specifically.

And after we talk about what we’re looking to learn, how the learnings will be applied, why we want to learn about this question set, when the learnings need to be surfaced or delivered or shared in order to make the decisions that will impact the product. So that timing is really critical. And then how this research, how this study will also support those direct business objectives.

So that’s where I would start before ever drafting a plan. And then when it comes to drafting a plan, I never spend more than two hours on that first draft. I want to get feedback on that like kind of bare bones, rough version. And I want to get those stakeholders into my plan documents. So literally I’ll create a Google doc.

I have a template actually. And I will highlight specific areas in the draft and tag my stakeholders and I’ll say Sam, is this framed in the right way? Does this capture the intent properly? Or Mary, I’m struggling a little bit with understanding how A relates to B. Could you clarify this? So I’m literally pulling them into my document and we’re iterating on the plan until there is agreement to begin the next stage, which is the recruiting aspect.

But the planning process and the plan itself is iterative and the plan should get updated at every point where there is a decision made or where new learning comes into our ecosystem. I mean, the learning might come in from customer service. The learning might come in from another stakeholder or input or some secondary research.

So these plans are really, really iterative and they’re living, breathing documents that should be updated throughout the entire process. But I’d start with what do we already know?

Hannah Clark: That’s a really good call out. So when we talk about the planning process as an iterative process, what are some of the variables that we should be preparing for during that stage?

Michele Ronsen: I think cultural relevance is really important. Different teams have different cultural norms. Some teams and some projects are going to be fine with really scrappy research. How scrappy is defined is also going to vary. What separates scrappy from crappy? Other teams and projects are going to seek more rigorous research, so understanding what the cultural preference is in regard to that specific project would be really, really helpful.

Also discussing what level of confidence is desired. Are we looking for a smoke signal about whether or not we’re moving in the right direction? Or are we looking to be supremely confident because we’re going to make a huge update to, say, the primary navigation to our website? Also, I think access to participants is a really important consideration that can be really variable.

When doing B2B research, it can be much more difficult to recruit other businesses. And there’s also some legal and ethical considerations there that aren’t always well thought out or understood and ensuring the learning can be completed in time to impact the decisions, that the team is looking to make.

We don’t want to conduct research for research sake, right? We want to conduct research that will help us make more informed decisions with confidence.

Hannah Clark: So I think this has been a good sum of a lot of the do’s in the planning process. I think we should talk a little bit about some of the don’ts. So what are some of the rookie mistakes that you’ve observed that product teams should be mindful of before they begin engaging with users for research purposes?

Michele Ronsen: This is such a great question. I love it. I think commonly, newer researchers and non researchers don’t necessarily understand that there are two sets of stakeholders, at least for every study, right? There’s the internal team who will be expected to act on the learnings. And then there’s the end user that we’re designing for.

So when I’m designing my studies, I’m always designing the studies for these two sets or two segments, if you will, of consumers of the research or beneficiaries of the research. And within there, there might be multiple other segments, right? There might be like the core team who will implement on the learnings.

And then there might be like the C-suite who wants to understand what happened, at a high level. For the end users, there might be, several different tiers of users that will be impacted. Another aspect is not brainstorming with your stakeholders to identify and formulate hypotheses that we want to test.

And the goal of these formulations isn’t to be right or wrong, but it’s to provide us with a distinct perspective from which we can frame our question set. And of course, not having a documented plan. This is something that people really don’t realize the importance of. And without having a documented plan, you are basically not documenting your success criteria.

And what happens, unfortunately, is that if we don’t have that success criteria documented, it will trail and move and take on a life of its own. And we will forget, why we are doing this research in the first place. And when those goals aren’t documented, we can’t be successful because we have nothing to measure them against.

Hannah Clark: So when you talk about some of these more proactive ways of making sure that things are documented correctly, I also think about organizing the research data and some of the outcomes that we get from our research projects, which I think for some folks is a challenge. It’s a good problem to have to have too much insight, but also it’s something to manage and to be able to synthesize effectively, you need to have a good system in place.

So do you have any tips for proactively organizing research data as it accumulates?

Michele Ronsen: Yeah, I’m super passionate about this topic. I teach entire workshops on, we call this note taking. And there’s numerous strategies. The most appropriate strategy, taking these notes and organizing, these are findings, not insights, which are completely different terms, often confused.

But the most appropriate approach will be determined by whether you’re doing generative or evaluative research, what level of UX research maturity the primary researcher has, and or like the immediate core stakeholder team, the study specific goals, and the time frame to turn around the results. But for newer and untrained researchers, I strongly suggest not taking notes during live sessions.

And instead taking notes from the recordings, whether they be audio or video or transcripts of those recordings, and then using frameworks to organize those notes. Another consideration is whether we are learning about attitudes or behaviors or both. And that will also inform which frameworks might be best to organize these notes.

I have a frameworks document to share with you, and I’ll put those in the resources as well.

Hannah Clark: Yeah, that sounds great. I know that a lot of folks are going to be getting a lot of use out of that. So I’d love to chat a little bit about getting stakeholder buy in. We talked a little bit about stakeholders being an important part of that research planning process.

What are some ways that product teams can use their research plan to get stakeholders on board for a very costly or time consuming UXR initiative?

Michele Ronsen: Great question. Costly or not, you should always include your stakeholders in research. They’re the people that are going to be acting on the learnings. And if they’re not brought into the research from the onset, the chances that they’re going to implement on the outcomes are like slim to none, right?

So no one wants to do research for research sake. Researchers don’t even want to do research for research sake. So I strongly suggest getting your stakeholders like physically into the plan into the actual document and asking for specific feedback. Because the last thing you want is for any core stakeholder to say you didn’t ask the right questions to the right people in the right way, thereby challenging the research approach or the research outcomes, right?

If they don’t believe in the research, they will be implementing on the learning that resulted from it. I see a completely 100% clear connection between stakeholder engagement in the research planning process and the likelihood of implementation. Another reason you want to bring your stakeholders into the process is because they have more institutional knowledge about how we got to this point and what the challenges and opportunities are.

They have very specific, design, product management, engineering, and other types of knowledge that the researcher likely does not bring to the table. And those perspectives are super important not only the researcher to understand, but all of the other core stakeholders understand as well.

So no or little engagement from the stakeholders is very likely 99% of the time going to result in no or little implementation, right? And our goal as researchers or non researchers conducting research is to move our teams into action. So, without that, I mean, we’re really setting ourselves up for failure, for make work, if you will.

Hannah Clark: Yeah. And speaking of implementation, I’m a little curious about how you would approach advocating for the implementation of findings. I know that there’s some of that process happens at the stakeholder level early on where you’re getting some buy in, but then there’s a matter of actually making sure that some of the findings, even if people have said that they’re on board with them, they actually get followed through on.

So do you have any tips for product managers who are looking to implement some pretty significant changes across functional team?

Michele Ronsen: Yeah. So one great tip is to organize the learnings by functional area. So you might have 20 action items to come out of one study, and that might seem very overwhelming. But really three are for the content team, four for the design team, three are for the dev team.

So I like to organize the learnings according to functional teams so it’s more digestible. I also find it’s really helpful to work with my PM very closely to identify what are short term recommendations versus long term strategic considerations that really warrant either more conversation or discussion or warrant more research.

Those might be some sort of inflection points. So organizing the findings according to cross functional area for implementation, as well as short term kind of just do it versus long term let’s consider it is really, really helpful. And it helps to organize that information into more digestible bite size pieces, including things like video highlight reels and key quotes really helps to substantiate the results that we are learning on and bring this data to life.

So I’m working on a study right now and I brought up a key theme in an initial top line report and the PM said, I really don’t understand what you mean by XYZ. No problem. Let me substantiate that. And I pulled together like 10 examples of how this theme manifested across the study. And he was like, Oh.

So it really, really helps to substantiate and bring that data to life when we can reinforce it with actual quotes or videos or other types of artifacts as well.

Hannah Clark: I like the use of storytelling in order to connect people with the findings so that it’s not so abstract and it’s not as murky and how I can actually, why it matters and how it could actually implement.

So you’ve mentioned a few resources that we’ll include in the show notes as well, but I’m wondering if there’s any other essential resources that you haven’t mentioned yet that you really recommend for product managers who want to get better at user research, want to be really efficient, but just don’t really know where to start?

Michele Ronsen: Great question. Curiositytank.com has a plethora of free user research sources, tools, templates, webinars, podcasts, and more. I also offer the Ask Like a Pro program, which a lot of user researchers take those workshops are available individually and as part of a series. And I do spotlight workshops often.

We’re going to have one for product managers on April 9th. It’s a special two part workshop on user research specifically for non researchers, just really like a condensed kind of version. I’m also really active on LinkedIn and I invite all of you to connect with me on LinkedIn, mention this podcast. If there’s a specific question or resource that you’re looking for, send me a quick note.

I’m happy to do my best to support you. We all win and our organizations are all in, such a better state when we know how to ask the right questions to the right people in the right way. The risks of conducting poor user research unknowingly, of course, are huge, right? And they can impact, not only your immediate team, but your users.

And my goal is to really, really help you learn how to do this better. It’s akin to learning a new language or learning how to play a musical instrument. User research is something that is learned over an extended period of time and after someone has a plethora of different experiences and different domains and recruiting challenges, etc.

So I don’t expect any PM to be super proficient, especially at the gate, it’s just not setting them up for success. So I want to help.

Hannah Clark: Of course. Yeah. And thank you so much for being such an advocate for user research and for being a resource for folks to learn from your wealth of knowledge. I think it’s such an important thing. And I’m glad that we’re talking about user research in a lot more tactical way. It’ll be really helpful for those listening.

Thank you so much, Michele, for joining us. It’s been such an honor to chat with you today.

Michele Ronsen: Thanks, everyone. Bye-bye. Hannah Clark: Thanks for listening in. For more great insights, how-to guides, and tool reviews, subscribe to our newsletter at theproductmanager.com/subscribe. You can hear more conversations like this by subscribing to The CPO Club, wherever you get your podcasts.