3.2: Define Customer Research Techniques - Video Tutorials & Practice Problems

<v ->Now let's talk about</v> defining customer research techniques. If the key to building the right product is to understand customer needs, we need to rely on customer research. However, in many instances, our understanding of what the customers need, or even who the customers are is not accurate. No matter how well we know those customers, our understanding of what they need is just an assumption unless we create the right data. This is a hypothesis and we need data to have it validated. As Henry Ford is said to have stated once, "If I had asked people what they wanted, they'd have said a faster horse." This way a car would never be invented. A true product visionary frequently comes with the ideas that others have not yet suggested or tested. And yet there is a need to validate those ideas before implementing them commercially. User research focusing on understanding user behaviors, needs, and observations through a number of techniques is really important. Those techniques range from the observation of users in their natural surroundings to interviewing them about the experience with a specific working product and everything in between. It's an iterative and cyclical process. In lesson two, we discussed the lean startup framework that provides ways to validate customer hypothesis. And we spoke about design thinking models that are used to design and prototype products. However, this is not sufficient to define the right product. In order to achieve validated learning from customers, four steps as regards to user research are most important. The first one is to identify the right customers that represent the target personas for your product. The second one is to define the way of collecting this feedback. Could be customer interviews, observation of customer interaction with prototypes or existing products, surveys, web analytics, and so forth. Third one is to actually conduct this research and use measurable results to validate your hypothesis. And finally, you have to aggregate and interpret all the data from the research and compare it against the hypothesis in a non ambiguous, data-driven way and do your validation and the final decision. So once the problem is identified it is very important to define how to measure it and how many respondents are required for your research. For example, if the user research method involves comprehensive interviews, then the number of customers who participates in the research is fairly low. And if you do web analytics research, then the number is in hundreds. Finally, it is helpful to identify success criteria. Whether your hypothesis will be validated by a simple majority of respondents or you need a specific percentage of users that will confirm your assumption. And the most important rule and the mistake that frequently is being done is to never ask a question that starts with, would you, would you buy it? Would you use it? Those responses do not validate customer behavior. And actually most customers would confirm that they're interested in using the tool or software or product because there is no obligation on their part yet. In addition, these types of questions cause respondents to guess about behavior rather than share facts about their actual behavior. You can show your customers a prototype of your product followed by a set of questions, or simply observe the interaction with the prototype. That's much more impactful. And finally, you can always conduct interviews. A simple and yet very powerful interviewing approach is called a three point interview. It consists of three questions. Question number one, have you ever had like this specific problem? If they say no at this point, assumption is invalidated and you have to pivot. Start with something totally different. Second question. Tell me more about the last time you had this specific problem. What did you do? Here you look for them to actually do something about it. And third question for you. What is the ideal solution in that situation? So third question is not perfect, and yet it gives you the direction for your solution that you can at least start with. So now let's talk a little bit about conducting the research itself. Customers have to be available first and in agreement with the research. Sometimes they have to sign an agreement. No matter whether they're internal or external they need to be recruited. And there are multiple ways of reaching out to customers and giving them different sorts of incentives so that they participate in your research. For example, in case of external customers you can offer them participation in a better product or discount on your product for a specific period of time. I give them a gift card. In case of internal customers, you can incentivize them by supporting them and solving the actual problem that they're facing. Also, researchers have to have an interview script. They have to allocate sufficient time for interviews. Never rush an interview. If you are absolutely time boxed, just cut it short, don't try to rush through answers. You have to make your participants comfortable and very clear about the expectations. And if there are any legal aspects and other constraints, you have to take care of them in advance. For example, if you may want to have your external participants to sign a nondisclosure agreement or NDA before showing them any prototypes of your future product. And all the results are accurately documented by interviews in a predefined format. Tips for conducting user interviews are as follows. The most effective interviews are with one person at a time because groupthink, when one answer influences others, is misleading and happens frequently. Also when there are multiple researchers the respondents may feel uncomfortable so try to do it one on one. It is important to know the goals and questions ahead of time. So give this courtesy to your interviewees if it is possible. A prioritized list of assumptions is used to generate a list of questions. You don't share this list but it's helpful to have those with among interviewers. It's also advisable to clarify and adjust the questions based on the respondents. But again, there always has to be a clear script to start with. Now you have to define what interview type it is. Try to separate behavior interviews from feedback interviews. If the goal for the research is to understand customer needs, then ask about the gaps between their needs and the available functionality. If the goal is to get the feedback on features of a specific product, use your prototype and ask about usability aspects. Also you have to stay open minded and get excited about hearing hard truth. Don't try to hide or to avoid any negative feedback. If you're really invested in your product, project, or service, it's very easy to overlook negative feedback and start selling your product to respondents or cause them to be unnecessary polite with you. So encourage and embrace negative feedback because it'll save you effort going forward. Remember we said in lean startup, fail early and often. We want to prevent the mistake so negative feedback is the most helpful. Active listening is also the key. It is important to help customers to provide their unbiased feedback to you. Open ended questions are most effective and definitely significantly more effective than yes-no questions. Try to avoid binary answers by opening your questions. So if a customer pauses, do not try to fill the gap. Give them time to think. The goal is for you to learn, not to market your product. And finally, we need to aggregate and interpret the data. This step is extremely important because of the way the data is aggregated and presented. This way will influence your final decision. This is one of the reasons why the metrics and success criteria are defined in advance. Based on the result, the decision is made whether to pivot or change the business model or one of the most fundamental assumptions, or persevere and proceed as originally intended. It's important to base decisions on data rather than speculations and your interpretation of answers. Even if this is coming from the customers. As both Henry Ford and Steve Jobs have shown, the features that customers ask for are never as interesting as why they really want them.