Learn User Research: Build Products People Actually Want

1. Welcome to the class!: Hello, and welcome to this class on user research for product managers, startup founders, solo builders, product designers or anyone creating something new. I'm Anna, product manager and startup founder. Over the past 15 years, I've built digital products across a wide range of industries, finance, logistics, commodity trading, and education, and for diverse markets from Europe and Southeast Asia to Australia. Whether you are a product manager or an entrepreneur, if you are working on building a product that people will actually want, you're in the right place. If you don't deeply understand your users, your product decisions are just guesses. In this class, I'll walk you through a simple practical process to run your own user research, even if you don't have a research team, or if it's your first time talking to users in a structured way. We'll go step by step through how to define your user research goals and hypothesis. Pick the right user research method, find and recruit the right users, collect and analyze insights that guide your product decisions. By the end of the class, you will know how to confidently run a user research process and get clarity on whether the problem you are solving is even real and who you are really solving it for. No prior user research experience is needed. You just need curiosity and product idea or challenge to explore, and that brings us to your class project. You will pick a product problem real or fictional and run through the early stages of the user research process. That includes defining your goals, selecting research method, recruiting users, and starting to gather insights. It's a hands on project that helps you apply what you are learning right away. So by then, you haven't just watched videos. You've actually done the work. Alright, if you are ready to stop building in the dark and start learning from your users, let's get into it. See you in the next class. 2. User research: the foundation of every great product: Everyone, and welcome back, regardless of what your role is product manager, product designer, startup founder or product builder, staying close to your customers is non negotiable. You need to understand their needs, their pinpoints, what motivates them, how they make decisions. What gets them to try your product, and what could drive them away. This understanding is what helps you build something people actually want that's feasible to create and viable for the business. This is where user research comes in, and just a quick note before we dive into the process. I'll be using the terms customer and user interchangeably. But in many cases, especially in business to business, these aren't the same people. For example, a sales director might decide to purchase a CRM system, but it's the sales team who actually uses it day to day. Okay, back to the definition of user research. User research is the practice of uncovering your user's goals, motivations and behaviors using such human centric methods as, for example, design thinking. You rely on user research throughout the product development life cycle. First, during the discovery phase, before you've started building anything, you use user research to figure out what the real problem is. You might have assumptions or gut feelings, but until you talk to real users, those are just guesses. At this stage you are asking, is there actually a problem here? If so, what is it? Who exactly is experiencing the problem and what do they believe or feel about it? Second, when you have got a potential solution or design, user research helps you validate whether it solves the problem effectively. Our users getting value from it is the experience intuitive. Does it actually work for them? Third, after launch, user research helps you evaluate how people are engaging with your product. You can track whether behaviors are changing, identify emergent needs, and find opportunities for further improvement or even innovation? In short, user research supports every stage of the product journey whether you are discovering a problem, validating a solution or optimizing what's already out in the world. What does the process look like? Here are the seven core steps of the user research process. For this class, we will be doing research on a problem, not a solution, as that's key. Many teams jump straight into validating their idea. But if you don't even know if the problem is real, you're skipping a critical step. So in the next lecture, we'll choose a problem and go through a user research process to better understand it. But before we continue, let's briefly recap what we've covered here. You will have to stay close to your customers throughout the end to end product development process. To create products that are desirable for customers and business viable, you will need to know customers' needs and wants, how they make the purchasing decisions. What makes them buy your product? And what will drive them away? A discipline called user research helps determine the user's goals, needs, motivations, and other insights. The user research consists of the following seven steps. We will be covering each step of the process in the videos of this class. All right. And Sa in the next lecture. 3. Find a problem worth solving: Everyone, and welcome back. Before we dive into user research methods, we need something important, a problem to research. This will be the foundation of your course project, so it's worth spending a bit of time to get it right. Now let's talk about how you pick up a problem to explore. From my experience, the best ideas usually sit at the intersection of three areas. Number one, your passion. This is something you really enjoy doing, even if you don't make money from it right now. For example, one of my students build an app around breathing exercises, something that helped your stay fit and manage stress. Number two, your daily life. Often the best ideas come from everyday annoyances. Something that slows you down, frustrates you or feel unnecessary, complicated. That's how my first product idea was born. I was working as a consultant, constantly on the road, and I could not stick to any kind of fitness routine. So I decided to build an app for live group workouts with instructors. These days, that sounds obvious, but back then it felt like magic. Number three, your future. Maybe there is a new industry or topic you want to dive into. For example, if you are interested in working in Adiotech you could explore how students struggle to land their first job after college. That is a real researchable problem, and it could also help you break into this space you want to work in. So think about what inspires you, what bugs you, and what you would love to learn more about. Once you've picked a general area, the next step is to frame it using the how might we method. This is a brainstorming technique that helps you describe the problem in an open, optimistic way without jumping straight to solutions. Here are some examples based on ideas we just talked about, how might we help people stay calm and energized with daily breathwork. How might we help busy professionals keep a consistent fitness routine while traveling? How might we support students who feel lost figuring out their career path after graduation? Keep your questions focused, but not too narrow. How might we solve inequality? That is too broad. How might we increase the profitability of a car sharing service? That's too narrow and too solution driven. Start with the challenge. Ask yourself, what's frustrating, confusing or just plain broken? Then write it as how might we question? Write down as many ideas as you can. Don't worry if they seem silly. No ideas dump at this stage. You can always refine later. Once you've got a bunch of ideas, pick two, 23 that excite you most. We will validate and refine them through user research later on. And here is a super important reminder before we wrap up. Fall in love with the problem, not the solution. It's natural to think of an app or product right away, but try to resist that. If you already have a solution in mind, pause and ask yourself. What's the problem I'm really trying to solve here? For example, if your idea is an app to connect working professionals with mentors, what's the core problem? Maybe it's that people don't know how to prepare for a promotion. Or they want to change careers but don't know where to start. Your job in this phase is to explore the challenge, not design the product yet. All right, cool in the next lesson, I'll share what problem I picked up for this class. But before this, let's sum up what we've just learned. Pick a problem space from your passion, your daily life, or something new, you want to explore. Frame it as a how might we question focused but flexible. Don't rush to solutions. Fall in love with the problem first. Write down your ideas, pick a couple to explore, and we will validate them in the next steps. I'll see you in the next video. 4. Step 1: Defining goals, objectives, and hypothesis: Everyone, and welcome to the lecture, we will start talking about the first step of the user research process, defining research goals, objectives, and research hypothesis. The goal of the user research at this early stage of the product development is to understand how and why the problem occurs, who the target users are and how they are affected by the problem. Also, we need to know what the users need, desire, and value from a solution, and why. However, this initial user research won't involve testing any solution yet. We'll do it at the later stage of the product development. Don't know much about problems that users might have. We have only assumptions about the problems. So let's quickly write down all our assumptions for the do follow loon project. To recap, the project aims to help those who want to kick off an educational project to learn new skills, but they don't know where to start, which idea to focus on or how to move things forward. So let me list down all the assumptions I currently have regarding problems that the JustDo project can address. First, there could be a problem with searching for project participants. It's not clear where and how to find those people that present a good match in terms of skill level or desire to work on a similar product idea. So let's write this down. What else? When I started my side project, I had a problem selecting an idea. I felt like I had quite a few to choose from, and I was unsure which one to focus on. I'm pretty sure that I'm not the only one with similar struggles. So let's write down this as an assumption. Yeah, I think that can be a real problem for many people, and force them to put the whole project on hold. Anyways, we will validate this assumption later during the research phase. Next, I think that many of those inspired to start the side project might have some commitment issues. For example, it may be challenging to allocate enough time to work on the project, since it is perceived as a non priority task. This is especially challenging if you have a full time job and family. I have another assumption regarding a problem. Often to move forward with the project, one needs an opportunity to brainstorm with someone or have a thinking body. Otherwise, you feel stuck with your thoughts and cannot make meaningful progress. So let's keep this assumption on the list. Okay, that's what I have for now. Maybe these assumptions feel like wild guesses for now. That's fine, since we don't need to be right at this point. However, moving forward with designing a solution just based on our assumptions about problems is way too risky. We may very likely find ourselves in this situation when we create a product no one needs. So the next step we have to do after we formulate all of our assumptions is to transform them into hypothesis. Think of the hypothesis is an assumption in a testable form. Write down the problem hypothesis, we can use one of the following templates. I believe type of people experience type of problem when doing type of task, or I believe type of people experience type of problem because of limit or constraint. Please pay attention that this is the template for a problem hypothesis. We will also formulate a solution hypothesis later in the program using slightly different template. Oki dooki, let's rewrite our assumptions in the form of hypothesis using the templates. Here is our first assumption. It's not clear where and how find those people that make a good match for a site project. For example, in terms of a skill level or a desire to work on a similar product idea. So I'll use this template to create a hypothesis. I believe type of people experience type of problem because of limit or constraint. Can you see that we need to define who we'd like to talk to. Since we are building a new product, we don't have existing user base yet. So we'll need to think about who can be potential users of our product. In other words, we need to find those who might have the problem we believe exist. For now, let's define our audience very broadly, like people who want to acquire new skills. In the following videos, I'll explain how you can do user segmentation and find those people you want to speak with first. So coming back to our first assumption, after transforming into the hypothesis, that's what I. I believe that people who want to acquire new skills experience struggles when finding participants for the educational project because of multiple factors they need to account for to find a good match. These numerous factors could be skill level, willingness to work on the same project idea, and maybe such factors as being located in the same geographical zone for the ease of communication or having a similar work schedule, et cetera, et cetera. We'll figure out all these during the research. Let's transform our second assumption. Some people may struggle to come up with side project ideas or have too many ideas to choose from. And here is our hypothesis. I believe that people who want to acquire new skills struggle to choose a project idea because they don't have enough ideas to select from or have too many ideas. As a result, this holds them back from starting a project. Here I mean the word experience from the hypothesis template, since otherwise the hypothesis may sound a bit wordy, but that's okay. You don't need to stick to the exact template all the time. Our third assumption is, I think that many of those inspired to start the side project may have issues with allocating enough time to work on a project, since they think of it as a non priority task. And this is our hypothesis. I believe that people who want to acquire new skills experience issues of allocating enough time to work on the side project because they perceive it as a non priority task. And finally, here's our last assumption. Often to move forward with a project, one needs an opportunity to brainstorm with someone. I transformed this assumption to the following hypothesis. I believe that people who want to acquire new skills may stuck in their thoughts and ideas when working on a project alone. Okay, we are done with formulating the problem hypothesis, and now we can proceed with defining the goal for the research project. The goal is the central question that has to be answered by the research findings to test your hypothesis. It needs to be specific enough, so you'll know when you've reached an answer actionable and that you could act on your findings once you've completed the research. When formulating a goal, always start with a verb such as understand, learn, find, identify, et cetera. Limit the number of goals you define per project to one or two as a maximum. Doing so will help you with a clear understanding of a particular aspect of user behavior. To define research goals for the project, let's look at our hypothesis list once again. We see that part of them are related to the site project planning process, while others highlight issues with the project execution side of things. With this in mind, let's formulate the goal of our research as to understand how people plan and execute their site hassles. From the research, we'll see whether the planning or execution site has the most burning issues that we could try to address. Let's also specify several objectives we want to achieve within this goal. You might feel a bit confused now. We just define the research goal. So why do we need the objectives as well? And how do the goals and objectives fit together? Here is the chart that shows that relationship between the goal, objectives, and questions that you will ask to validate or invalidate the problem hypothesis. As you can see from the chart, the objectives help us to specify the research goal and define questions we want to ask the research participants. Here's what I came up with for the JustDo project. First, identify ways people start planning their site hustles and tools they use. Second, identify what makes it easier for people to plan site projects and what makes it difficult. Third, identify ways people execute their site hustles and the tools they use. And fourth, understand what elements make it easier for people to execute site projects and what elements make it difficult. As you can see from these objectives, we are not only focused on validating the problem hypothesis we have so far, but we want to explore the bigger context around these problems. Doing so help us discover what might trigger a problem or additional challenges that users have and that we are not aware of yet. And lastly, let me give you quick tips and tricks on how to define the objectives for the user research project. Create no more than four objectives for one research. If you try to achieve more than four objectives at once, you are planning too much, since each objective will represent up to ten questions you need to ask research participants. Also, your research objectives need to be high level, but specific enough to get clear and concise answers for each. And now let's do a recap. The first step of the user research process is defining research goals, objectives, and hypothesis. Problem hypothesis are assumptions written in a testable form. To write down the problem hypothesis, we first create a list of our assumptions about the problem and then transform every assumption in the hypothesis using one of the following templates. We formulate the research goal using action verbs such as learn, understand, define, and we aim to have one or two research goals per project. And lastly, we define up to four research objectives within every research goal. Objectives help us specify the research goal and develop questions to validate or invalidate the problem hypothesis. Okay, that's it for this lecture. In the next video, we'll talk about the second step of the user research process, and I'll see you there. 5. Step 2: Selecting a research method - research methods overview: Everyone, and welcome back. Before we start doing user research for problems we've identified earlier, let's go through the most popular methods to conduct the research. Specifically, we'll explore ten of the following research methods, in depth interviews with existing or perspective customers or the company's internal stakeholders, contextual interviews, diary studies, participatory design, user journey mapping, usability study, card sorting, event tracking, AB testing, and customer survey. Go over every method one by one. An in depth interview is a method that doesn't require a detailed introduction, since all of us know what an interview is. During the in depth one on one interview, an interviewer, for the case of user research, a researcher meets with, research participants to discuss what the participant thinks about a specific topic in question. Example, maybe I do a series of interviews to figure out why a product feature isn't used as I initially expected. During the interviews, I could learn that users don't understand the purpose of the feature and how they're supposed to use it. Having this information, I could think of how to change the feature to make it more explicit and clear, or I could decide to get rid of it. Knowing how to do interviews is a powerful skill you'll definitely need as a PM. Next is a contextual interview. The contextual interview is another research method that is somewhat close to the in depth interviews. During the contextual interview, you watch and listen as the user works and you ask questions as the user navigates through your product. The benefit of the contextual interview is that you see the user's environment and the existing technology they work with. The next method is diary studies. It implies that participants are asked to keep a diary and log specific information about activities being studied. Diary studies help understand long term user behaviors such as habits, perceptions or motivations. For example, you can use a diary study to determine what motivates someone to act. Why did someone order an Uber rather than taking a bus? How did they feel when they decided to stop in for a cup of coffee? Depending on the length of a diary study, you can get closer to the nuanced thoughts and attitudes impact the decision making process. A fourth research method is participatory design. Participants are given special tools like paper, sticky notes, pen and pencils, and other basic suppliers, or even Llega blogs to demonstrate their ideal experience that reveals what matters to them the most. For example, to understand how a user values certain product features, you can plan a simple buy feature game where participants are given a limited budget of artificial money and ask to buy feature based on that budget. I love this type of interactive research since as you move beyond conversation into collaboration, you could uncover valuable insights that you wouldn't have gained in other types of research. Next is user journey mapping. This is a widespread research technique that implies a visualization of a process that a person go through to achieve a goal. Let's come back to my previous example with the real estate industry in Singapore. Imagine that you are a product manager of a real estate portal and you want to find some new opportunities to make a difference for potential renters and home buyers. By creating a journey map for the property selection process, you can discover challenges users have in the process and subsequently come up with product improvement ideas. Another research method is usability study. Usability studies are sessions where participants actually use the product or a prototype to achieve a goal. The usability test helps the product team assess the product's effectiveness and efficiency and the satisfaction of its users. Think of usability study as a way to tell you where you are with product development process from the user's point of view. Let's move on to the following research method. It's card sourcing. Card sourcing is a technique that involves asking users to organize information into logical groups. The process looks like this. Users receive a series of labeled cards. Their task is to organize and sort them into groups that they think are appropriate. To conduct the card sourcing, you can use actual cards, pieces of paper or one of several online card sourcing software tools. Card sourcing is an effective technique that helps design workflows, menu structures, or website navigation paths. The next method is event tracking. It's always helpful to understand how people are using your product. To do so, you can observe how they interact with the product and what actions they take. We call these actions events and the process of recording these events event tracking. For example, sign ups, logins, downloads, form submissions, clicks, scrolls. These are just some of the events you can make sense of. Event tracking is a common way of analyzing user's behavior and sourcing product opportunities for many companies, especially those in BTC or b2b SAS business. This is because they have a large user base to make these observations statistically significant and valuable. Okay, two more methods to go AB testing. It is a popular method of testing different product designs by randomly assigning groups of users to interact with each design and measuring the effect of these assignments on user behavior. Let's go over an example. Sometime ago, visitors to amazon.com noticed a slight difference in the product detail pages. Some saw the familiar two button experience where they could either add an item to their card or click by now to skip the shopping cart and move directly to the checkout experience. Other customers, however, saw just one call to action, the add to Cart button. The IkamrsGiant was doing a NAB test, experimenting with the number of buttons on the product pages to see which version resulted in more sales. The two buttons layout was deemed the winner and continues to be the standard experience on the site. And finally, customer surveys. Customer surveys are effective methods of finding a priority or scale of a problem, especially for those companies with a large user base that they have access to. For example, by doing a survey, we can answer what proportion of our users are impacted by a particular problem. We can do surveys in many forms. For instance, email survey when participants are recruited from an email message or intercept surveys when a service triggered during the use of a website or application. And that's it. We just covered ten of the most popular research methods you should be familiar with SAPM. Let's briefly recap what they are. Contextual interviews, diary studies, participatory design, user journey mapping, usability study, card sourcing, event tracking, AB testing, and customer surveys. In the next lecture, we'll continue talking about the research methods, and I'll explain how you can decide when to use each of these methods. I'll see you in the next video. 6. Step 2: Selecting a research method - how to choose one for your research: Everyone. Welcome back. In the previous lecture, we talked about ten research methods available for you to discover new product opportunities, get feedback on existing products, and find insights on the next product improvements. Now let's talk about how you can select which method to choose. To better understand when to use each method, we will view them into two dimensions, qualitative versus quantitative methods and the phase of the product development process you are in at the moment. Start with the first group qualitative versus quantitative methods. With qualitative research, our goal is often to answer questions that call for personal interpretations or when we want to investigate whether a problem exists, why something is happening and how a problem can be fixed. Such methods as in depth interviews, contextual interviews, diary studies, participatory design, usability study, and card sourcing are classified as qualitative research methods. When conducting quantitative research, we gather numbers that describe some aspects of user experience instead of gathering insights. Quantitative research methods will come in handy to determine the priority or scale of a problem, like the proportion of users impacted by a problem. In other words, quantitative research helps us to answer how many and how much types of questions. Quantitative studies are also helpful when you want to compare alternative design options and need data to support your decisions. Already recognize some of the quantitative research methods we've covered in the previous lecture, right? They include such methods as customer surveys, AB testing, or even tracking. We need a large user base to perform this research as opposed to qualitative methods. Otherwise, we won't be able to rely on the research results since they won't be statistically significant. Okay, now let's move to the second approach of selecting the research methods based on the stage of product development. Remember, at our first lecture on user research, we said that we need to understand different things at different stages of the product development process. So let's see how this applies to selecting the research method. At first, very early stage of product development, even before we start brainstorming about possible solutions, we'd like to understand what a customer problem is. We also focus on uncovering product opportunities as well as opportunities for innovations. At this stage, we can use both qualitative and quantitative methods, such as in depth interviews, contextual interviews, diary studies, and surveys. At the next stage of designing a solution, we focus on ensuring that it solves the customer's problem and is easier and enjoyable to use. In other words, we do solution ideation and validation. As product managers, we also need to validate if our customers see value in the product and are ready to pay for it. To answer the research questions at this stage, we'll mostly rely on qualitative methods like card sourcing, participatory design, including paper prototyping, interviews, and usability studies. We also use some quantitative methods such as EB testing to complement the insights we get from qualitative research. And lastly, we use user research after the product launch to evaluate changes in user behaviors and needs. We also want to assess what improvements or innovations could be introduced to the product. Since our product has hopefully gained a large enough user base at this stage, we can rely a lot on the quantitative research methods, and be tasting surveys and event tracking. However, we are not only limited to the quantitative research here and still use qualitative research like in depth interviews. If we want to get into the root cause of a problem and need to ask detailed questions and follow up on users answers. So in depth interviews will likely be preferable in this case, rather than a survey or other methods where you have a fixed set of questions and no ability to follow. Please note that we can combine the research methods. For example, we can start our problem research by conducting one on one interviews to nail down the problem statement and then run a survey to understand how prevalent this problem is among O target users. Okay, now let's recap. When deciding on the most appropriate research method, we must consider multiple factors. The first is the type of questions we want to answer. For example, do we want to know why and how or how many and how much types of questions? Second, we need to consider where we stand in the product development process to get a clue on which research methods will be more beneficial for us. And now I suggest that you go back to your course project and think of the research methods that you can use. And in the following lecture, I'll share the research method I've selected for the JustDo project problem discovery. I'll see you there. 7. Follow along: Selecting a research method: Everyone. Welcome back. In this lecture, we'll select research methods that we'll be using at the problem discovery stage for the course project. I'll illustrate the selection process with the JustDo project. Our research goal is to understand how people plan and execute their site hustles. Our research objectives are the following. First, identify ways people start playing the site hustles and tools they use. Second, understand what makes it easier for people to plan site projects and what makes it difficult. Third, identify how people execute their site hassles and their tools. And finally, understand what elements make it easier for people to execute site projects and what factors make it difficult. We already know that we need to consider two factors when deciding on what research method to choose. The first is the type of question we want to answer. For instance, do we want to answer why and how, how many and how much kinds of questions? Second, we need to consider where we are at the product development process at early stage in the solution design and development phase or at the post launch stage. From our research goal and objectives, we can clearly see that we look for how and why questions, since we discover if a problem exists. And consequently, we are at the earlier stage of the product development process. So from the previous lecture, we know that the qualitative research methods will be the most effective for us in this case, in depth interviews, contextual interviews, diary studies, participatory design. From this list, I'll choose the in depth interviews as our primary discovery method for now. Those interviews are relatively easier to set up from the logistics perspective than other methods we see in the list. Also, in depth interviews are among the most effective and popular methods for user research. So I'd like you to be aware of how to plan, conduct, and analyze user interviews. Excellent. We are making progress in planning the problem research process. In the next lecture, we'll continue with the third step of the planning process, selecting your target audience, and I'll see it there. 8. Step 3: Selecting a target audience: Everyone, and welcome to this lecture, we will continue discussing the user research process. So far, we have talked about defining research goals, objectives, and hypothesis, and how to select the research method. Now it's time to think about the profile of your target users with whom you can speak to. Your first PAM job will most likely be for an existing product. So in this case, you will have a pretty good idea of who your users are and how you can approach them. However, you will be in a more tricky situation in the case when you are creating a new product from scratch. Since you don't have an existing user base yet, you have to brainstorm who could be your potential users and customers in the case of b2b products. There are many approaches to do the user segmentation, depending on factors such as your target industry or whether you are creating a product for b2b or b2c spaces. Let's take an example of the JustDo project to illustrate how to find target user segments. So far, we have defined our audience very broadly as people who want to acquire new skills. The current definition is really broad and vague. There are so many reasons why people need to get a new skill. What can help us define the audience more precisely is asking this question. What's the goal or motivation of people who want to acquire new skills? My initial research shows that there could be several incentives for people to get new skills, and they use a side project to achieve the following goals. Transition into a new career, getting a promotion to a more senior compliance with employees' requirements, being up to date with the latest strengths in their profession or field. There could be other reasons behind learning new skills. Still, I think you get an idea of how we can start narrowing down the audience by answering the question about problems, goals, and motivations our target audience might have. Can do this audience license several times and ask the same questions for every group. For example, what's the motivation behind transitioning to a new career? Well, for some people, it might be that they want to have a chance to travel around the world and experience working with people from different cultures and mindsets. Yeah, that's a real example, by the way. It was my intention behind selecting the management and consulting industry before I discovered product management. What else? There could be reasons people want to shift from their current profession that's becoming redundant to something with long term future potential for growth and development. There can be many more reasons people want to transition to a new career. Now let's discuss how broad or detailed you should go with specifying the target audience. Since at this stage, we don't know much about a problem yet, perhaps you think that it's good to start with something generic and broad. After all, you don't want to rule out target users just because you go with two specific profiles. However, if you kick off your research with a vast user base, you face several problems. First, you will be overwhelmed by different views and opinions. You may end up doing 30 or more interviews and still don't know where to start. As a direct consequence of this, you will have diverse and mixed feedback. That's hard to interpret. Also, you will be progressing in your research, but at the same time, you won't be able to disprove your hypothesis. So to sum up, the more narrow your focus, the faster you progress. Here is the picture that illustrates this idea pretty well. So we start with a very niche market and focus our efforts on that specific narrow market first. And once we nail this market, we can expand the definition of the market to continue growing. Okay, now that we have several segments grouped by similar problems, goals, and motivations, let's add another layer to those segments and narrow them down based on the demographics. It includes age, gender, background, family status, et cetera. You don't need to slice the audience for each of these dimension. Use just those relevant to your problem area and industry. For the JustDo project, let's take the first segment, people who want to transition to a new career and slice it first based on the occupation. So who could wish to transition to a new career? Apparently, these are working professionals who want to change career, for instance, by moving from a sales manager in an insurance company to a product manager in insured tech startup. Also, we can think about students. So first, we can divide students by fresh graduates who want to get their first job. And the second group will be students of postgraduate programs like MBAs who want to start a new career just after graduation. This is a very common scenario for MBA students, by the way. Now we have the following groups, working professionals who want to transition to a new career, fresh graduates who want to get their first job, and MBAs who want to transition to a new career after graduation. We can narrow down these three segments even further based on the career they want to move to. Since we are now at the product management program, and you're probably already working or planning to work at tech companies, let's focus on the tech industry. What are the roles in tech where having a side project will help get relevant work experience? Well, these three immediately come to mind product management, UX design, and software engineering. Of course, there are other roles as well, but let's focus on this for the D project. So now we have the following groups, working professionals who want to transition to product management, working professionals who want to transition to UX design, and also to software engineering. Also we have fresh graduates who want to find their first job in product management, fresh graduates who want to find their first job in UX, as well as in software engineering. And lastly, we have MBAs who want to transition to product management. So for MBAs, I've included the product management group only since students go to business school to transition to business oriented roles like product manager roles, rather than to technical roles such as software engineers. As a next step, let's look at the behaviors of every segment and think about where we can find these people. To help you thinking, ask yourself the following questions. What, if anything, are these people doing to try and solve the problem? Where can we find people of the same demographics who demonstrate this behavior? Let's take the first group, working professionals who want to transition to product management. Answer the questions. I'm a member and mentor of different product management communities. I regularly see posts from aspiring product managers asking for advice on what they can do to transition to the role successfully. From time to time, I also come across posts when people ask for recommendations regarding projects they can do to gain product manager skills. It's common to see these questions every week in product management communities on Facebook, telegram, and slack. I have access to all of these groups, so I can reach out to people interested in transition into product management and ask them for interviews. What else can people do to gain skills relevant to new career? Well, they can also sign up for courses or programs through different online platforms and try to build up skills and product portfolio there. It would be pretty challenging for me to get to these groups. Usually these communities are not open to the public. However, I have a community that I'm building around my educational project, future diversity, and people like you are joining to gain skills by building up a real life project. So I definitely can talk to this audience and ask them for an interview. Let's think if there are any other ways to grow skills. Of course, it's also possible to build up relevant skills at the current workplace and make an internal transition to a new role. However, this group of people is not my target audience, since they already use different solutions for the problems. Also, it's nearly impossible for me to find these people unless they are members of the product management communities I mentioned before, and they do ask questions on how to make career shift. I can continue working with other segments and explore what they currently do to solve a problem and where I can find them. Now, when we identify where to find the people from our target segments, let's figure out what segments we can reach and what the most profitable segments are. Let's look at our groups once again. From the accessibility perspective, I see that all segments use the same work arounds to solve the problems of getting relevant expertise and skills. Of the channels are more accessible, some are not. If you don't have any idea on how to access a particular user segment, excluded from your list. Regarding the prefitability criteria, I'd say that working professionals and MBAs seem to be a sweet spot for now. Fresh graduates probably don't yet have enough resources and willingness to pay for specific solutions. However, it doesn't mean that we won't be targeting students in the future. Just decided to start with more promising segments for now. So finally, here are the groups I want to speak with theorist that I have prioritized based on two criteria, reach out isinss and profitability. Working professionals who want to transition to product management, working professionals who want to transition to UX design, and working professionals who want to transition to software engineering. I also have MBAs who want to transition to product management. Right, it was a rather long lecture, but we've covered a lot. So let's recap on what we've learned. If you don't have an existing user base for a product, you have to define what are the segments you want to target first. To find a user segment, start with the questions. What is the problem or goal? What's the motivation? Narrow down the segment further by applying demographic criteria. Repeat these two steps until you eliminate broad segments. Try to narrow down your target audience to maximize your progress with validating or invalidating problem hypothesis. Next, ask yourself questions about people's behavior in these groups you've identified so far. What, if anything, are these people doing to try and solve the problem? Where can we find people of the same demographics who demonstrate this behavior? And lastly, ask yourself what segments are unreachable to you and rule them out. And then prioritize the remaining segments based on their potential profitability. And finally, let me reiterate once again, all the segments that we've defined so far are based on our current understanding of our prospective users problems, needs, and behaviors. Most likely that after we start talking to these people, we find other segments or criteria that will define each segment. We will have user interviews to figure this out. But before we start preparing for user interviews, we have one more lecture where we will speak a bit more about our target audience. I'll see you there. 9. Building up a Customer (User) Persona: Everyone. Welcome back. In the previous lecture, we talked about how to identify target users. This step is critical, since it clarifies who you are building the product for. In many cases, a problem will be solved differently for different user types. That's why defining the target user makes us focus on addressing the needs of that specific segment of users. Instance, imagine that you are building a graphic design platform for casual users who has nothing to do with the design industry and who need to put together a quick presentation or social media graphics. This design platform would look very different than if you were building it for professional designers. This is because the professional designers have very different needs and goals, such as creating crisp professional designs and icons. A product would need to help them accomplish these goals. We have a user personas tool to encourage the product and other teams to build empathy around target users and focus on their needs, problems, and motivations. User persona is a fictional person made up based on information about real people who might use your product. Let's go through the main segments that make up a user persona. Actually, we already started discussing these segments in the previous lecture. When we talked about how we could slice the audience, we said that we could use the following parameters to define a customer segment, problems, goals, motivations, as well as demographics. We will use all the segments to describe the persona. We start with personal details such as short biography, photograph, and name. It's also good to incorporate a real quote from users you've met during user research. In addition, you can include the description of the user. Together with the quote, it can add more colors to the overall picture of that user, and as a result, help us empathize with the user more deeply. At the same time, you don't need to include a thorough description of the imaginary individual's life here. Focus on highlighting key details relevant to your product. Please avoid including extra information that doesn't affect your product. Next, I demographic details such as age, marital status, gender, income, et cetera. Next, we include goals and motivations that the user is facing and that relate to your product. We also want to describe frustrations, challenges, or pain points that the user is facing now. And lastly, it's important to include behavioral details about how the persona tends to act when using the product. Please note that the information about the goals, motivations, frustrations, challenges, and behaviors is crucial for the persona's description. Without this information, you won't be able to create a product that will resonate with your customers and help to solve their problems. That's why we empathize discovering what user problems are and what motivates them to perform certain tasks. Let me illustrate this idea by showing you this image. These are two people who have similar profiles based on demographic criteria. Can barely look at these pictures to understand how the needs and wants of these two personas are different. So please remember that personas shouldn't be about demographics in the first place. Instead, they must be about the problems and challenges people face. And on that note, please also remember that personas are not user groups or segments. A persona is a singular user derived from the bigger user group who has specific details and important features of that group. Don't forget that we use personas in product development as a tool that helps the product team build up empathy for real people who will be using a product. A group of users is too impersonal and challenging to keep in mind when creating a product. Now let's speak a bit about the logistics of creating a user persona and discuss when and how to make them and how many personas you should create for a product. When to create personas. In short, as soon as possible, I like to create a draft of the persona even before I've started user research just based on my initial assumptions about a target user of a product I'm working on. Later on, when I have insights about users from the user research, I come back to persona profile and make changes. That's what we will be doing here in the program. I'll ask you to create a persona based on your current assumptions and online research you did about a problem you will be solving with your course project. And later on, once you have insights from the customer interviews, you will make changes in the persona's file. Next question is where do we create the persona? You can use different software for this. One example is Mirror, which I've already mentioned when we talked about tools you can use to organize brainstorming sessions to find an idea for the course project. Miro has a pre built template for describing new personas. You can use this template or make modifications as you see in fit. Another software you can use is Expressia. It provides a set of online tools for visualizing customer experience, including designing user personas. It is straightforward to create a persona there. You will get a personas template, which you can modify and add new sections from a catalog. It's up to you which one of these tools you want to use for creating personas for the project. For the JustDo project, I've decided to use Expressia. I'll include my user personas file in the resources section of this video. And final question, how many personas to create? Of course, my answer here will be it depends on your product and industry. Every product will likely have several personas to cover parts of product functionality. For example, when I was developing a trading platform, we had the following three primary personas, trader responsible for deal capture processes, operator who was in charge of deals execution activities like planning and scheduling of the vessels to transport cargo from a seller to buyer. And finally, we had a back office manager. Whose main responsibilities were to process goods, receipts and goods issue operations, invoices, and other documents. Okay, now let's recap. A user persona is a tool we use in product management to encourage product and other teams to build empathy around target users and focus on their needs, problems, and motivations. A user persona is a fictional person made up based on information about real people who might use your product. It's not a user group or a segment of users. Every persona description includes personal details, demographic details, goals, motivations, frustrations, challenges, pinpoints, and behaviors of users when dealing with your product. We can create the persona based on our assumptions about the target user and then refine the description after conducting user research. We can use different tools to create a persona. Such software as Miro or Du Express will do the job. And finally, every product will likely have several personas to cover parts of product functionality. That's it for this lecture, and I'll see you in the next video. 10. Step 4: Recruiting research participants: Everyone. Welcome back. Now let's look at how to recruit participants for your research project. The process consists of the several steps. First, you define whom you want to invite and where you can find these people. Second, you create an interview screener that helps you select the right audience. And finally, you send out invitations to participate in your research. In this lecture, let's talk about deciding whom to invite and where to find them. The first choice you have to make is whether you want to talk with your products users or with external users or non users of your product. In many cases, you will be gathering feedback from your existing users. For instance, when you want to explore where the next big product improvement belongs, or how happy the users are with your recent product update. This case, you can access your target users by inviting them through emails or posting requests for participants on your website or social media. Alternatively, you can rely on your product stakeholders like sales or customer service teams to make direct requests to participate in the research. Of course, avoid being too pushy with your research requests and clarify the benefits of participating in the research. For example, you can emphasize how much the feedback will enhance the product they already using. Or you can offer early access to the new product functionality. Can also explore other ways of connecting with your customers, depending on how your company's customer engagement process is organized. For instance, you can have a daily or weekly customer office hours where your customers can show up and ask product team questions and share feedback. Or you can have customer discovery workshops to bring storm product improvement ideas, or you can have user testing sessions at different stages of product development. For example, when you test solution ideas or the earlier releases of your product to market. The bottom line here is that customer engagement isn't just about conducting interviews or running surveys here and there. It's a mindset. Your customers are one of your closest partners in product development work. So you have to nurture and develop your product's most passionate and loyal customer base, whom you know how to approach and who would be eager to help make the product better. However, there are also cases when you may want to speak with non users. Example, when you are developing a new product from scratch, so you don't have an existing user base yet, or when you want to get feedback from Nubis non experience with your product or when you want to test potential new user groups, or when you need to understand your competitors users. There are many ways to find non users or potential users, including online and offline channels. We've already covered this topic briefly when we spoke about how to do user segmentation. Said it makes sense to focus only on those segments we know how to reach. So in case you don't have an idea about the user segments you want to approach for the problem discovery part of your course project, please pause this video and do the homework first. Yes, I'm waiting for you to close this lecture and start thinking about your user segments. Okay, I hope that now we have only those students who did the user segmentation exercise. Let's look at the most common channels for recruiting prospective users. First, you can approach your colleagues, friends, or family members and ask for the intros if they are connected to your target segments. The second is different social media platforms, Twitter, Instagram, Facebook, link IDN, or even relevant slack groups. The third is events. For example, you can connect with prospective customers at an industry conference or during a MITA this method will be especially relevant for b2b segments. Fourth is your company's website. It's pretty standard practice to look for participants for the research programs. For example, here is the Landing page of GitLab's First Look initiative. They call for everyone visiting their website to sign up for the research programs to participate in usability tests, user interviews, surveys, and other types of research. Another way you can find your target segments is by dropping by a place where your customers are. It can be physical store if you are developing a product for frequent shoppers or working spaces if you are developing software for startups. Another channel that you can rely on is recruiting users through specific user research platforms. These platforms offer a large pool of participants and let you target users by many criteria, depending on your research goals. Here is a list of some of the platforms you can rely on. User interview.com, respondent Io, hellpenpunk maze.co, and usertesting.com. You don't have to start recruiting users through these platforms right away. Instead, try to explore other channels first and refer to the platforms in case you run out of ideas on where to find the ideal candidate for your research when you need to target a massive user group. And by the way, you can use these platforms not only as a researcher, but as a participant. Doing so will allow you to see the entire research process and to end from how companies screen and select candidates they want to speak with to how the feedback is collected, whether it is an online interview, survey, product testing, or other research method. It's an excellent way to learn and practice your user research skills. And as an extra benefit, you can even earn some side money for your participation in the research. I'm sure there are other channels where you can look for your target audience. Be creative and spend some time brainstorming where you want to focus your efforts. Now let's briefly talk about what channels I'll use to find prospective users for the JustDo project. To Remind you, here is the list of the user segments I want to approach. I've decided to rely mainly on social media channels and post my inquiry to meet with people for an interview in the product management, UX Design and software engineering groups on Facebook, Telegram, LinkIDn and Slack communities. By the way, if you want to explore what Slack communities to approach, you can use Slow file platform. This is an online database of Slack communities where you can find those that align with your target audience. I leave a list of all the communities I plan to talk to for the JustDo project in the resources section of the video. Okay, that's it for the lecture, and as always, let's do a recap. The first step in recruiting the participants for your research project is to determine whom you want to invite and where you can find these people. You have two options. Invite your products existing users or non users. You want to speak with your current users if you are looking for the next big product improvement when you want to get feedback on your product update. Please remember that engagement of your existing customers isn't just about conducting interviews or running surveys from time to time. It's a mindset. Throughout the end to end product development process, you have to invest your time in customer development. You will be talking with non users if you are developing a new product or you want to get feedback from people non experienced with your product or when you want to test potential new user groups, or if you need to understand your competitors users, you can use offline and online channels to approach your current and potential users. In the following lecture, we will cover why you need an interview screener and how to create one. I'll see you there. 11. Creating an interview screener: One and welcome back. In this video, let's talk about how to craft an interview screener. The purpose of the interview screener is to filter out those interview candidates that don't qualify for the interview process. The screener is a survey that consists of several qualifying and disqualifying questions. To come up with the screening questions, think about common characteristics of your target audience, like the needs, goals, tasks, motivations, demographics. Then structure your equations like a funnel. Start with the broad questions and narrow them down until you can say if the participant qualifies or not. I hope you notice that this process resembles what we used to define target segments. So if you followed along with the lecture on user segmentation, you should have a pretty good understanding of what questions to put into the screener. If you did not do the user segmentation for your project yet, please stop watching this lecture and finish with the segmentation first. Now let's take an example and define the screener questions for the do project. All people from our target segment have a common behavior. They have already started or planning to start their side project to achieve some of the goals. So let's use the first screener equation to qualify candidates based on this criteria. I'll write down the equation this way. What are the reasons you have started or are planning to start a side project? And I'll have the following options, supplementing of primary income, enjoyment, transition into entrepreneurship full time, new skills development. According to the online research I did, those are the most common reasons people start their side projects. However, I'm not interested in talking with all site hustlers out there. Instead, I want to speak with those interested in developing new skills by working on the site hustle. Also, we need to add the option I did not start or plan to start the side project anytime soon. Trull out candidates who don't have the behavior we are looking for. Our next question has to clarify why people want to develop new skills. As you remember, we want to find those who wish to transition to a new career. So let's ask the following question. What motivates you to develop new skills? And our answer options will be, I want to transition to a new career. I want to get promoted to a more senior role. I need to comply with my employer's requirements. I want to stay up to date with the latest trends in my profession or field and other. So as you see, I structure my question so that every answer helps me get closer to my target candidate or disqualify those who are not applicable. I'll add two more questions to my screener. Which of the following most closely matches your current job title? Please mark more than one if you are responsible for multiple jobs. I've included this question since I want to understand whether I'm talking to working professionals, planning to make a career change or a recent graduate of such programs as an MBA. I also want to exclude students from my interview list for now. Here is an example of the answer options that I'll have. And last question. What new career are you looking to transition to? Again, remember that for now, my goal is to speak with people who want to transition to one of three domains, product management, UX design, or software engineering. And here is the answer options. Product management, UX design, software engineering, project management, other please specify. Also, if you plan to record your conversations for future reference, don't forget to ask the participants permission for the session recording. And lastly, in case a survey tool doesn't collect emails automatically, you have to ask for the email or other contact information to send an invitation to those who qualify the criteria. And speaking about the tools where you can create a screener, Google Forms will be one of the most accessible tools to use, and it's available free of charge. You can also explore a software called Survey Monkey, which as we see from its name is dedicated to developing service that you can create from scratch, from templates or by working with a virtual assistant. Unfortunately, however, not all of these functionality is available in the products free plan. So you'll have to upgrade to one of the payment options to explore the breadth of the functionality. Another software is qualtrics. They have free online tool to create, distribute, and analyze surveys. Again, you can choose from the more than 50 online survey templates or start from scratch. Lastly, if you're using one of the user research platforms we talked about in the previous lecture, most likely that they will provide you with tools to create a screener survey as part of their product functionality. I recommend beginning with the most accessible tool such as Google Forms and crafting your screener there. I'll be using the Google Forms for the JustDo project screener as well. And later on, you can come back to the lecture and test and experience other tools. Please don't focus too much on selecting one tool or another. Any software that has a survey creation functionality will do the job. However, it's really important to think about the equations you want to ask to rule out the candidates that don't fit within your research goals. So concentrate on the content rather than a. All right, let's recap. An interview screener is a survey used to filter out candidates who don't fit into the research goals. To come up with the screening questions, think about common characteristics of your target audience needs, goals, tasks, motivations, demographics. Then structure your questions like a funnel, start with broad questions and narrow them down until you can say if the participant qualifies or not. Any online survey tool will work for creating the screener. I leave a link to the tools we've discussed in the lecture and other alternatives in the resources section of the video. Okay, that's it for the video, and I'll see you in the next one. Bye. 12. How to invite interviewees: Everyone and welcome back. In this video, let's cover the process of inviting shortlisted candidates to participate in your problem discovery interview, a product test, or a survey, depending on your research goals and what research methods you plan to use. Email is the best way to communicate with short listed research participants. First, you need to confirm that a person is interested in meeting with you and your team. Share what the process will look like. For instance, if you'll be asking questions only or ask to test and give product feedback. You can use Calendly to schedule sessions with users. Usually the user interview or product testing session runs 30-60 minutes. So plan this time slot in your calendar invitations. In terms of the team members whom you want to invite, at minimum, it should be you and someone else from the product team so that you can both listen, take notes, and exchange your impressions after the meeting. Usually, the second person will be UX designer or UX researcher. A company has dedicated user researchers in the team. I also like to include software engineers as optional participants so that they can join the session in case they have some spare time. Participation in the meeting with users and listening to their problems, needs and expectations is an excellent way how engineers can develop user empathy and become more user focused instead of focusing solely on the technical aspects of product development. Now let's talk about how many interviews you need. Unfortunately, I cannot give you an exact number of interviews you have to go through to validate or invalidate your hypothesis or receive product feedback. And also, there is no industry consensus on this. Sometimes five interviews are enough, and sometimes you have to do around 15 to 20 interviews before seeing any emergent patterns. After all, after you conduct the first two to five interviews, should review your interview questions and notes and adjust the interview. Then after ten conversations, you should start to see patterns in the answers you are receiving. In case after having more than ten interviews, you still get answers that are all over the place and cannot give you any clues on your research questions. I'd say that your target segment is too broad and you have to try to narrow it down further. You stop the interview process when you don't hear new things from people you are talking to. Recommendation for you will be to start with five to ten interviews and see what the outcomes are. Lastly, let's discuss if you should offer some incentives to interviewees. Similar to the questions of the number of interviews you have to do, there is no consensus on this matter. Some experts say that you shouldn't offer any incentives whatsoever, since if a customer has a big enough problem to solve, they will be willing to meet with someone who is working on solving that problem. On the other hand, others believe that offering incentives is a great way to build participants' interest and engagement in user research. I belong to the last category of people, and I like to offer incentives for my research projects. However, I prefer non monetary incentives like providing early access to the product I'm developing or offering 30 minutes of my time and the opportunity to ask any product management related question in exchange for my interviewees thoughts. This is especially relevant when I want to speak with people interested in joining or growing in product management. In the case of the users of the JustDo project, you can also offer monetary incentives. As the rule of thumb, the more specific your target audience is, the higher their incentives should be. For example, senior level managers need to have high incentives to join your session than entry level employees. And of course, when deciding on your incentive plans, please don't forget to check your company's policies, and if there is a budget allocated to set monetary incentives, the research projects. Okay, that's it for this short lecture. And let's recap. Email is the best way to communicate with shortlisted research participants and invite them to the interviews. Invite some of your colleagues to participate in the interview with you. For example, user researchers or UX designers. It's good to include software engineers as optional participants to help build up their user empathy. There is no standard recommendation on how many interviews you have to make. Start with five to ten interviews and see what the outcomes will be. Consider offering incentives for your research participants if your company's policy allows this. You can choose from providing monetary incentives and non monetary perks. All right, that's it for the lecture, and I'll see you at the next one. 13. Creating a discussion guide: Everyone. Welcome back. So we are almost ready to begin interviewing users and start getting the first insights regarding the problem we want to solve. I said almost because there is one last but not the least task we have to take care of before we are all set to meet with users, creating an interview discussion guide. Discussion guide or interview script is a set of questions and topics you would like to discuss with an interview participant. Scripts are critical for conducting effective user interviews, since otherwise, they often turn into conversations that wander and rarely extract the learning. Typically, it consists of an introduction, warm up questions, questions about problems or solutions you want to discover or validate and debrief. So let me walk you through how to create a discussion guide. At the introduction, introduce yourself and let the participant know what to expect during the interview. Clarify that this is not a test and that there are no wrong answers here. Give them a chance to ask questions. If you need to record the conversation for future reference, get the consent from the participants before the interview. However, it's good to double check verbally that the participant is still happy with the conversation to be recorded. After you've finished with an introduction, start by asking the participant a few warm up questions about themselves and what they do. This will help the participant get used to answering questions, making them more relaxed and open to your further questions. In addition, these answers may help provide context for any later responses they give, so listen carefully. Then you ask you key questions regarding the problem or solution. You can brainstorm interview questions using the same technique we use to brainstorm product ideas for the course project. Before you start, review your research goals and objectives. Your task will be to brainstorm questions for every objective of your research, while brainstorming questions identify themes or subject areas into which most questions fall. Once you've identified the themes of your question pool, define the order that would allow the conversation to flow most naturally. As you begin to structure your equations, allocate time for each theme. This will help keep your interview on track. Next, move from general questions to more specific questions. For example, from how do you currently do this task to what's the most challenging part about a task to what could be improved in how you currently do a task. Take a few moments to review the script and make sure that you leave room for plenty of Y equations. That will help you go deeper in the discussion and understand the root cause of a problem. The last part of the interview is a debrief. Thank the participant for their time and explain what happens next with the feedback they have given you today. Also allow the participant to ask any questions. Don't forget to leave your contact details if they have any follow up thoughts they want to share with you. Okay, that's it for the interview guide structure. To help you come up with the questions, I leave a link to the list of questions you can consider asking to discover a problem or product idea or receive feedback on your product. Please don't use all of the questions. They and modify those most relevant for your research goal. And before we finish the lecture, let me give you several tips on creating the discussion guide. Please don't forget that your discussion guide is just that a guide to help drive the conversation. Feel free to deviate from the initial script if you need to. Also, expect to change your script after going through your first interviews. You're making the first version of the script based on your existing understanding and assumptions about users and problems. All the insights you learned during the ears interviews will help you revise and amend the initial version of the script. If a participant say something interesting, that is not included in the discussion guide, listen and explore what they're saying. You might uncover something you had not previously considered. Avoid including questions about the future. It's hardly possible for all of us to predict it. So if you ask something like, would you use this product or feature, you won't get accurate responses. Most likely, some people will say no, simply because they cannot visualize how the final product would look. Others may reply, Yes, just because they don't want to be rude to you or because they don't want to rule out the possibility that the product or feature might be helpful for them at some point in the future. And lastly, be aware of our memory limitations and avoid asking questions about the past behavior that happened more than two to three months from now. Instead, concentrate on asking questions about the present. Okay, that's it for the lecture. And now I'm asking you to review the examples of the questions I've prepared for you. You'll find them in the resources section of the video, and I'll see you in the next lecture. Bye. 14. Step 5: Collecting insights: Everyone. Welcome back. If you followed along with the previous lectures and did your homework, you are ready to start your problem discovery interviews. But before you begin, let me give you the final recommendations on making the most out of your interviews. First, try to connect with your interviews so that they feel relaxed and open to the conversation. I know that it might sound obvious, but let me remind you that you should greet participants by their name. Smile to them, be friendly and initiate small talk before transitioning into your interview. Second, begin the interview with more straightforward questions and then get into the specifics. Use the five is technique to get more details about a topic and motivate a person to share more information. And even when you think you know the answer, ask people why they do or say things. The answers will sometimes surprise you. Third, ask questions neutral. For example, a question like, what do you think about purchasing groceries online is better than, don't you think online shopping is great? Because the first question doesn't imply a right answer. Fourth, shut up and listen. Please don't be afraid of the awkward silence. Interviewers often feel they need to ask another question when there is a pause or they want to start a small talk. Instead, bite your tongue and wait for interviewee to continue. If you allow for silence, a person can reflect on what they've just said and may reveal something deeper. Five, don't ask binary or leading questions that require a simple yes or no answer. Remember that your goal is to encourage a discussion build on your interviews stories, thoughts and feelings. Sometimes you can also unintentionally lead your participants response when you want to follow up on what they say or when they say something unclear to you. A simple technique here will be to repeat what the participant has said with some intonation. For example, if you interview set, this boarding flow is not user friendly. Then to clarify, you can ask, is it not user friendly? You encourage the participant to continue talking and explain what they mean without influencing their answers. Six, be present in the conversation. If you're doing online interviews, it might be tempting to check your email or slack messages simultaneously while listening to your interviewee since they cannot see what you do. Please avoid doing this. Close down the tones of tabs you have opened and leave your phone in another room. You must be fully concentrated during an interview. Seven, look for inconsistencies. Sometimes what people say and what they do or think are different. These inconsistencies often hide interesting insights. Pay attention to non verbal clues such as body language and emotions that can signal these inconsistencies. Eight, be mindful of time. Time goes by very quickly during interviews. Respect the timing that was agreed before the interview, and if you feel that you need more time to finish all questions, kindly ask your participants if they are okay with staying with you a bit longer. Nine, do an interview in pairs with your colleagues. For example, UX designer or UX researcher or other product team members. Try to capture exact quotes when possible without paraphrasing. If you can bring someone to the interview, ask your participant if you can record the session to refer to it and adjust your notes after the interview. Lastly, do a 15 to 30 minutes debrief just after the interview with your interview partner. Use this time to recap what you learned. Also discuss if there is anything that needs to be changed in the discussion guide. Make sure that you capture the following main themes or learnings that stood out from the interview. Things that mattered the most for the interview participant and things the participant said that surprised you. Okay, these were my main recommendations for you before you use your interviews. Now you're completely ready, and I wish you good luck meeting and talking with users. But before you go, let me briefly recap the ten user research recommendations we've just covered. Connect with your interviews so that they feel relaxed and open to the conversation. Begin the interview with more straightforward questions and then get into the specifics. Ask questions neutrally. Shut up and listen. Don't ask binary or leading questions. Be present in the conversation. Look for inconsistencies. Be mindful of time. Do an interview in pair with your colleagues or record the session. And finally, do it debrief just after the interview. 15. Step 6. Analyzing research findings. What is a validated hypothesis?: Everyone, and welcome back. In this video, I want to share how you can analyze the research findings and uncover insights that will inform your next steps of solution ideation and design. The outcome of your analysis will depend on the quality of the interview notes you made during your interviews, either yourself or with your interview partner. For every interview, you need to capture the following. Min themes or learnings that stood out from the interview, things that mattered the most for the participant. Here you can also include topics where your interviewee showed strong emotions and things the participant said that surprised you. I like to capture my notes in one file, for example, in Google Docs. You can also use conference, a software famous and product community for creating meeting notes and capturing many additional things related to your product or project. For example, stakeholders requirements and expectations, product technical and functional documentation, information about new product releases. So pretty much everything that can be captured and shared about your project. Another software you can check is notion. It's also becoming increasingly popular among product teams who choose to use it for different tasks from creating roadmaps to organizing product related documents. Let me share with you how I organize my interview notes. Right before my next interview, I add a person's name, role, and interview date to the file. I also copy and paste questions from the discussion guide right after the interview, I review my notes and look if there is anything that I should change in the discussion guide. It's important to do this debrief after every interview, even if you did the interview on your own. And if you interviewed with the partner, exchange your thoughts, share what went well in that interview, and what you can learn from the interviews, emotions or body language. After doing several interviews, you can also rely on special techniques to analyze interview findings. But before we start learning about these techniques, let's come back to the main goal of our research project. As you remember, we developed problem hypothesis and wanted to validate or invalidate them with the help of user interviews. But what does validated hypothesis mean? Well, validating a hypothesis means you're confident enough to continue investing time and effort in solving a particular problem or research question. We can go further with this definition and list out criteria that when fulfilled, can give you the confidence to continue working in that direction. First, a customer confirms that there is a pinpoint or a problem. Second, a customer is actively looking for a solution to that problem. Third, a customer invested something, for instance, time, money, effort to solve the problem. And fourth, nothing prevents the customer from finding a solution to the problem. After you've conducted about five of your first interviews, you should expect to meet at least someone who can relate to the problem you are discovering. After around ten conversations, you should start seeing patterns in the answers you receive. In case if after having more than ten interviews, you still get answers that are all over the place and cannot give you any clue on your research questions. The reasons are most likely one of the following. Your target user segment is too broad, or problem you're discovering is not as real as you thought at the beginning of your research. So if one or more of these four validation criteria falls, you can conclude that you've invalidated your hypothesis. So in other words, you couldn't find a user segment with a specific problem you think exists. As the next step, you can do the following. Look at your target segment and consider how you can narrow it down further to find more niche and targeted group of people who might resonate with problem. Or reframe the problem. You often have to admit that your initial assumptions about the problem were incorrect and that users don't think about this problem the same way as you do. In that case, reconvene with your product team members and brainstorm the next opportunity space you can work on. It can be something adjacent to a problem you've discovered before. It can be a completely new problem you didn't think exist before you started interviewing users. But it turned out that nearly every user you spoke with mentioned this problem. If that's the case, you can formulate a new problem hypothesis and continue your research in the new direction. Okay, that's it for this lecture, and as always, let's do a recap. Your interviewing sites will very much depend on the quality of the interview notes. So don't forget to take notes during the interviews and do it debrief with your interview partner. You can rely on different software, including Google Docs, conference on Notion to keep your notes in one place. When analyzing interview notes, you look for insights that help you to either validate or invalidate your problem hypothesis. Validating a hypothesis means you're confident enough to continue investing time and effort in solving a particular problem. If after more than ten interviews with your target audience, you still don't have clues about your research question. This is most likely a sign that your user segment is too broad. But that problem you are discovering is not real problem for users, and you have to reframe it. All right, that's it for now. And let's get to the next videos to talk about techniques you can use to analyze user interviews. I'll see you there. 16. Formulating a Problem Statement: Everyone. Welcome back. Our lecture about the customer journey mapping technique was long one, but this will be much easier, I promise. So after you've analyzed interview findings using one or several techniques we covered in the previous videos, it's time to formulate a problem statement or point of view statement. A problem statement helps us frame the problem in a way that's actionable for ideating and designing solution alternatives. Think of the problem statement as your guidance statement that you put together based on all the insights uncovered during the emphathize phase and that focused on specific users what they need and why. Let's look at template you can use to write down the problem statement. Type of people experience, type of problem because of limit or constrain. Alternatively, you can formulate a problem statement in a slightly different form. Type of people needs a way too, users needs because but or surprisingly, interview insight. Please remember that needs should be verbs. The insight usually shouldn't be just the reason for the need, but rather more of a synthesized statement that you can leverage in designing a solution. Let's go over some examples of the problem statements. Here is how we can formulate a problem statement for a car sharing service. When people rent cars for short periods, often by the hour. Alex is a 30-years-old working professional who lives in the city. He needs a way to do a quick, 30 to 60 minutes commute to and from his office two to four times a week at his own convenience. He really enjoys driving himself. However, he is not ready to invest money in purchasing his own car, since it involves high upfront expenses and maintenance costs. So here you see, first of all, that we defined our target user who resonate with the problem we uncovered. Next, we specify the needs. These are the key insights about the problem. Finally, we include other important details that might support the next step of ideating the solution. In our example, we clearly say that purchasing a car is not an option for solving the problem since it involves high upfront and maintenance costs that our target users cannot afford. At the same time, we point out that our target audience does love to drive. This extra detail is essential, since it gives us a clue that such solutions as taxi rights, shared rights or public transport won't work for our target audience, and we have to brainstorm other alternatives. Let's look at another problem statement this time for Linkedin Sales Navigator that helps sales professionals to find the most relevant prospects and increase the quantity, size, and speed of closed deals. Here is what the problem statement could look like. B to B sales professionals from the tech industry in the way to make successful social sales. However, they realize it's challenging to find the right warm contact, figure out who the company decision maker is, and understand what social context that they can rely on to personalize their first contact. Again, we started by defining the type of people who experience the problem. Next, we formulate what the needs of these people are. And finally, we included insights about the current challenges of these people that prevent them from satisfying their needs. Okay, let's take a third example of formulating a problem statement. This time for an on demand video streaming service. Helen is a 29-year-old and based student who loves documentaries. She needs a way to relax after her studies and access new and engaging content she's excited about and that she can share with her friends. As always, we start the problem statement by specifying the type of people we want to focus on. Next, we talk about the core needs or problems of those people and interview insights that will inform and support us during solution ideation and design. For instance, in this problem statement, we've included important insight about Helen. She wants to share the content she's excited about with your friends. This insight may prompt us to consider the community aspect we can introduce into our streaming platform. For instance, we can allow users to share links to their favorite movies with friends or invite friends to watch a movie together online. Okay, I hope that by now you have a pretty good understanding of how to create a good problem statement, and you are ready to practice making a problem statement for your project. If you need more examples of how to formulate the problem statement, please watch my follow alone lecture at the end of this section where I'll share my interview findings for the JustDo project and the problem statement I came up with as a result. And I'll see you in the next video. 17. Follow along: Analyzing findings from JustDo problem discovery: Everybody, welcome back. In this video, I'd like to walk you through the problem discovery interviews I did for the follow on project, the interview findings, and the decision I made on if I want to continue working on the same idea or pivot to something different. Let me remind you of the context behind the problem I decided to explore. After working with Aspiring product managers over the past years and helping them to transition to a product role, I concluded that there is one thing that they struggle with the most and that prevents them from making a move. Experience. To be more precise, lack of relevant experience in building and launching products. One of the best solutions to that problem is to actually build something and to end as a site educational project. I know many examples of people, myself included, who made the transition with the help of site projects. However, when I offer this option to people, I often get puzzled stairs followed by many questions from what idea to choose to how to execute a project. Given this, I put together a list of hypothesis about problems I think people are usually facing when starting or executing a side project. With this hypothesis in mind, I've decided to dig deeper into the problems and research if there is a product opportunity for me here. I formulated my research goals to understand how people plan and execute the side hassles. I defined these four objectives to narrow down the goal to something I can work on straightaway. Regarding my target audience, I've decided to begin with the following groups that I believe can relate to my problem hypothesis. I've decided to start my research with the first segment, working professionals who want to transition to product management. These are the people I'm connected with the most, so I wanted to talk to them first and leave other groups for later. Okay, the first thing I did after setting up the goals was to create a list of channels where I could find my target audience. I decided to rely solely on the online channels and groups dedicated to product management related topics, including how to make a transition to product. Here is a list of groups I chose to use for inviting people to participate in problem discovery interviews. Here I have Facebook groups, slack channels, two channels and telegram, and one linkIn group with a big audience of over 60,000 members. I've experimented with several invitation messages that I posted to the groups. First, I posted this message to the Facebook communities and asked people to respond if they were keen to participate. Next, I modified the text a bit and offered an incentive for people to participate in the research. I wrote. As a compliment for your effort, I'd be happy to include you in the list of early users of the first version of a product. It will be created with no code tools based on findings from this discovery research. Also included an interview screener to ensure I'm speaking to the right audience. In my case, these are the people who have started or are planning to start the side project to learn new skills they need to transition to a new career. I created the interview screener using Google Forms. Here is what it looks like. The screener questions are structured to help me find my target audience by looking at the responses. The only problem I see with the screener is that it shows all questions on front. And it doesn't include any logic that lets me offer the following questions based on the responses user gave in the previous step. For example, I need to show the question what motivates you to develop new skills only to those respondents who answered new skills development on the previous question. However, this option is not available in Google forms. So I checked other survey tools and found a functionality called skip logic provided by Survey Monkey, which can deliver exactly this logic. But unfortunately, it's available in the paid plan only. The main risk of showing all questions in advance without implementing any skip logic is that respondents could guess whom you are looking for and provide incorrect responses to participate in the research. It can happen when, for example, you offer monetary incentives for the research, and participants want to make aside income by participating in many such projects. So in this case, it's better to upgrade your software and use the skip logic function to ensure that you qualify the right people. For this educational project, I'll proceed with the current version of the screener, since I'll be advertising the project in very closed communities of people motivated to develop and grow their product management skills. Also, I don't plan to offer any monetary incentives for participating, but only early access to the JustDo application. So I estimate that I have a high chance of receiving genuine responses from this community. Okay, let's move next. After finding relevant interview candidates, I wrote them a message confirming their participation. I also asked them to select an interview slot in my Calendly schedule. Now let's look at the interview statistics. In total, I got about 100 responses from all of the channels. Out of these hundred people, 40 belonged to the target audience I wanted to speak with. So I invited all of them, but got replies only from 30 people. And I ended up talking with 15 people since others didn't show up or asked me to reschedule the interview to a later date, but didn't confirm the attendance. This behavior is expected. Remember how many times have you registered for an online event or webinar, but never showed up since your plans have changed or simply because you forgot about it. The same can and will happen with your scheduled interviews. Some participants will never show up, but please don't be discouraged and continue working with those who made it to the interview. Let me show you the discussion guide I've prepared for the interviews. As you can see, I first asked about the project planning site, focusing on the two most problematic areas, selecting a project idea, and finding team members for the project. Next, I proceeded with the second part of the list and asked about the project execution site. After all, I got the impression that I put together too many es to be covered during the 30 minutes time slot. Usually, every interview took me about 45 minutes to cover all the questions. And with some participants who were highly interested in the topic, we even spend around an hour talking and discussing the questions. So during your first three to five interviews, see how the process goes and how much you can cover, and consider reducing the number of questions in case you cannot go over everything in the time slot you have. I leave a link to this discussion guide, so you can use it as reference for your interviews, but you have to create a copy of the file to be able to modify it and add your questions and comments. Okay, now let me share my interview findings with you. Many interviewees said that they experience challenges finding participants through online channels such as product management groups on Facebook or LinkDI. They admitted that the response rate is generally very low. Those who eventually replied could have different motivations for starting a project. For instance, not necessarily related to growing a skill, but rather to creating an aside income or moving into entrepreneurship full time. As a result, aligning on the project idea, timeline, and commitment expected from every team member takes a lot of time and effort. Another common issue people mentioned was the challenges they experienced selecting an idea for a project or finding a good enough problem to solve. From the interviews, I noticed that this challenge has been especially relevant for people with non tech backgrounds and those who have never worked in tech companies before. They shared that they struggled to find an idea for a project that can give them required learnings, but at the same time, that they can execute. As a result, they would prefer to join other teams rather than start a project independently. Also some people shared with me that they would love to start a learning project, but they believe this option is available for people who can build things such as software engineers, they weren't aware of or never tried no code tools for building software or thought that these tools also require tech skills, which they don't have. Now let's speak about the project execution side. Unfortunately, I could not research this topic in detail since many of my interviews were still on the project planning side. But those who started working on the project admitted that there was a commitment issue. So it was difficult for them to stay on track with the project, and they tended to postpone and delay. Also, they mentioned a lack of opportunity to talk to mentors and get advice regarding open questions or uncertainties about going ahead with a project. Okay, these are major findings that I got so far. Now let's return to our hypothesis and see which of them have been validated or invalidated. Here is once again the list of hypothesis as well as validation criteria. Okay, let's go one by one. For the first hypothesis, I got clear feedback from people that they experienced challenges finding project participants. They admitted that they were actively looking for a solution and invested their time in finding a good match. I didn't hear about things that prevent them from finding a solution to this problem. So the criteria are also fulfilled. Very at this point, I'm very confident that there is a problem here. Let's mark this hypothesis as validated. The second hypothesis is also validated since I can check all the criteria boxes here. I got users with a non tech background who either believe they need to have tech skills to start a project or who rack their brains to find an idea they can work on. Okay, our remaining two hypotheses belong to the project execution site. Several participants confirmed the commitment issues and mentioned that they lack a mentor or study body who can help them advance with the project. However, since I got only several participants who made it to the execution side, I feel that my overall findings are inconclusive. I need to do more research on this before making a final decision. To sum up, I'm confident in proceeding with solution ideation related to the first two problem hypothesis. With this in mind, I formulated a problem statement or my point of view for the solution ideation and design. Joy is a working professional who wants to make a career transition to product management, but struggles with getting relevant skills. She needs to find a good match by skills availability allocation to work on an educational site project and grow her skills. She has your ideas for a project, but also doesn't mind joining a project of others if she can relate to the ideas. You see here that I've started the statement by specifying a user who has the problem. And I also highlighted the core motivation of the user related to the need that I defined in the second sentence. I described the core user needs as finding a good relevant match for an educational site project. It may include finding an idea for a project or finding project participants or study bodies. I also included interview insights important for designing a solution that every user can play both roles, project owner and participant as long as they can find a good relevant match. Okay, that's about it. My main conclusion after the problem discovery work is that I'm confident to continue working on ideating and designing a solution, given the problem statement I put together as a result of the research. Let me briefly recap the main points you must pay attention to when approaching your problem discovery project. Planning is key to fruitful insights. Before talking to users, define your goals, objectives, research, hypothesis, and target audience. Select wisely people with whom to speak. Use interview screener to narrow down the audience. Come to the interview prepared and have a discussion guide with you. But remember, this is just a guide, so be ready to go with the flow if you hear something interesting. Don't be discouraged by no shows. It's expected behavior, and it doesn't mean that the problem you discover is non important. Adjust the number of questions you can ask to fit into the interviews. People will appreciate that you respect their time and will be willing to work with you further. Okay, now you're fully equipped for your research project. So please go ahead with talking to users, validating the problem hypothesis, and deciding on what your problem statement is going to look like.