 Hi, welcome to the webinar, Translate Customer Feedback to Product Features. I'm Priyanshi Mithil, I'm a senior product manager at Microsoft, part of the cloud and AI group, and part of commercial acceleration team. Customer feedback is very important and crucial for your product at every given state. Today in the webinar, we are going to talk about why it is important and how we can translate and take that feedback to actual product features. We are going to start with why do we really need customer feedback? We will then cover a lot of different aspects of going through the flow of translating the feedback that we can collect from different channels to actually derivative the product, starting with how to sort feedback from different channels, understanding specific use cases, categorizing and prioritizing the feedback that we get from the customers, creating wireframes and prototypes, feedback to with customers, implementation and launch, and how do we measure success over time? But first, let's start with a meme. And I believe you might have already seen various versions of this meme, but I edited this to fit this topic. You see how the information and implementation gets changed in every step, and in fact, even the customer is not fully aware of what they really want. So if you look at the first picture, that is how customer actually explained what they want, then how product manager understood it, then based on the product manager, how the designer designed it, how the engineer actually implemented it, and what actually customer really wanted. And there's a huge difference if you see what customer actually explained and what the customer really wanted. We are going to cover in this webinar about what customer really wants and how we can decipher it. Why customer feedback is important for product element. First of all, identifying the features and functionality of customers concern. Feedback is also essential to the iteration phase of product design. Customer feedback is an insight into what is working well about your product or service and what should be done to make the experience better. Secondly, you are able to discover customer's pain point. Customer feedback is the fuel that will help you connect the dots between design, technology, business to create amazing products, amazing products that your customers would love. Once you understand your customers, you will be far effective in communicating their needs to your engineering team, design, and business teams. Thirdly, it provides useful ideas for product improvements. If you are constantly asking customers to provide you with feedback, you are establishing a continuous improvement for your product. You are able to highlight product innovation investments. When you are involving customer in this process, you are communicating that their attitudes and opinions matter. You can identify what's working and what's not to ensure your product adheres to their needs. Not only does this create a positive user experience for the customer, but it also boosts loyalty for you, your product, and your organization. Can give you a competitive advantage by ensuring customers are satisfied with your product, listening and responding to their requests and need. Taking these steps to solicit feedback throughout each phase actually results in your best product going to market and hence will give you that competitive advantage. Now let's look at different channels to get the customer feedback from. Firstly, field and sales. They are a great way to get feedback. They work with customers day and night and know them and their pain points much better. Similarly, customer support and success teams would have a great database of issues, feedback that they hear from customers on a day to day basis. You can also leverage this by going through the support tickets and the incidents that the customer create to understand what pain points were problems to their face. During the product lifecycle, it is also very beneficial to get feedback on an ongoing feature through usability studies that you can conduct with your customers while you are actually designing and we will go through that as well. As an enterprise product manager, you spend a lot of time weekly talking to your customers and understanding their issues and problems. This is a great way to interact and get details one-on-one. You can also set routine processes that work for your organization. So for example, different feedback channels like voice of customers to get consolidated feedback on your product by chosen set of customers. At Microsoft, we have something called unified voice of customer where we collect a lot of different feedbacks from our set of customers for our products. Lastly, asking NPS and feedback on the product interface itself is a great way to get direct and filtered feedback. Let's move forward and now see how do you actually understand the use case? You've got a lot of different feedback from different channels. Now it is important to once-ordered all of that and find the most meaningful and actionable feedback. Filter out generic positives. Oh, I love your product. Generic negatives. I totally hate that product. Junk, this is useful for nonsense feedback like blah, blah, blah, which you cannot actually use in any way. So let's go on to why do you want to understand the feedback and what it takes to understand that? Generally, customers will only give you what? It is also important to understand the how and why to make sure that the actions from the feedback is scalable and you are not just solving pain point for just one customer and not relying on the face value of the feedback to implement the features. Let's take the example here that we see on the screen. So let's say one customer is saying that I need to download data in CSP. Another is saying I need to integrate this tool with a specific analytics tool out there. Third would say I need to download data via API. How do you scale? The first step is understand what they actually do to get things done. So for example, if they are saying they need data in CSP, let's take talk about how they would say, oh, today I copy paste data from a table online to a CSP. Okay, why do they need that? Why do they need to actually download data in CSP? They need to upload it to a third party tool. So essentially what they're saying is though they just need data in CSP, the actual pain point or the problem that you may want to solve is uploading data in a third party tool, which is essentially integration with any third party tool. Categorizing the feedback. After finding most crucial feedback, now comes to categorizing the feedback. You've already seen how you can actually get the most useful and inside put feedback from the last slide. And then the different categories that you can identify are usability issues. Issues mostly due to experience could be any experience. APIs, UI, CLI, et cetera. For example, oh, this is not a detailed error message. Obviously, now you know, a very specific problem is that the error message that you are giving to your customer when the error occurs is not clear to them and how they can solve it. Secondly, new feature request. Something that is completely new. In the last example, integration with third party analytics tool was one such example of a new feature request, bugs. I'm not taking into consideration P0 and P1 bugs because they should be solved on priority anyway. I'm talking about the bugs that don't affect customer workflows or do not break the experience but still cause bad customer experience. User education issue. Identifying if it is something that can be resolved by product experience improvement or how product handles the feature or is there a gap in documentation and support guidance. Example, let's say that a customer wants to change the password and they cannot find option on the UI. Do you feel like it's an education issue or do you feel it can be actually resolved in experience changes in UI? Ideally, changing a password is very common scenario where they would not need a lot of documentation steps, et cetera. So if we can make it very visible on the UI itself, they won't have to go and chase support for that issue. Lastly, others. There will be some feedback that's hard to categorize. So you can go back and recat categorize it later as patterns emerge in the rest of the data. Now that we've categorized and we've understood the most important actionable feedback, it's time to prioritize the feedback. It is difficult to quantify every feedback that you get from the customers. So you can use a easier version of Rice Framework to prioritize the feedback and request. First of all, reach. What exactly reach? How many customers would are asking for this customer, sorry, feedback? Or how many customers are actually affected if it's a bug? Impact. So what exactly, how can you say that impact is higher? So if it is giving higher revenue or if it is adhering to customers that have a lot of revenue impact on your product? Cost of work, obviously. What is the cost of works in maybe dev weeks or dev months based on engineering feedback? Alignment with business goals. This is also important to understand that some of the things that you get from the feedback may not align with business goals or the vision of your product. So you may also want to see how it aligns with the business goal. So for each of these, you assign high, medium, and low. You can start with requests that are high in reach, impact and alignment with business goals and low in cost of work. Sometimes you would also have to look at top customer requests. Even they have higher costs. So for example, though they might not have like a higher reach because only a set of customers are impacted. They would, they might have a higher impact because large customers may have higher revenue but the cost of work may also be higher. So you may also want to adhere to that feedback because those are your top customers. Now let's move on to next step. Now that you've gotten the feedback, you've categorized, you've prioritized. Now it comes to creating US wireframes and prototypes. Work with the design team to understand the flow. Start with what, why, and how that we've already seen. Make low-fidelity wireframes to visualize. Even on paper and whiteboard is very, very helpful for your design team to actually see what your vision is about that feature. Designers are definitely the SMEs. So based on what is discussed in first and second steps, they can now go and create designs. This step is crucial to get on early feedback by conducting usability studies from the customers. Next, it's always a good idea to walk through these designs with engineering just to look at the feasibility and call out if something is not feasible. It can be either handled by adjusting the designs or maybe thinking about what are some other feasibility needs. Based on the engineering feasibility, feedback from the customers, you would have the final set of mockups and prototypes ready with your requirements. Next, coming to implementation launch. I'm not covering details on processes, agile, sprints, et cetera. I'm going to focus on high-level process and action items when you launch a new feature or a new proofant. First of all, make a plan of launch. When to launch? Will it be available to all customers? Do you plan to roll out two set of customers first? How will the flighting be done? How are you planning to get feedback in that process? And so on. If it's a multi-print effort, go with the phased approach. Plan to get feedback on regular basis, even for each phase. Once implementation is done, make sure to update any documentation so that customers do not end up creating support tickets. Make announcements. Whatever is set up in your organization, you want to make announcements maybe on the product or website or send emails, et cetera. Also make sure that the support guides are updated so that support can help customers in efficient way. Lastly, record any feedback via different channels that we've already discussed in the past because feedback is a continuous process and you want to collect as much feedback as possible in every step. Now let's move on to what are some of the metrics that you may want to measure to actually measure your success or failure for the product? And this step is very important to enable continuous improvement of the product. First of all, define metrics and how these can be measured. These metrics can be, okay, number of customers using the feature. What is the retention? Is there any revenue impact? Then what is the revenue impact? What was my daily active users, monthly active users and now has it improved? And so on. Secondly, you can record funnel. At what point does the customer drop in your, using your product? It is a good indication on what step would need some improvement in your product. Has the NPS or CSAT changed? Has it improved? Has it not improved? That is a good indication of whether the feature was successful or not as well. Recording, if there is any change in support tickets and incidents, it can be increased or decreased again. That is a good indication of if you're actually solving for improving the CSAT or you're resolving a bug. Lastly, any qualitative feedback through different channels is also very important on an ongoing basis. So what have we covered? Definitely, feedback is a continuous journey. You want to collect feedback at every step to make sure that you are improving your product on an ongoing basis. It is crucial to understand why and how to fully understand the customer pain point. Feedback is the key to improve the product on an ongoing basis. Feedback does not only improve customer satisfaction, but it can also result in increased revenue and competitive advantage. Thank you.