 Hi everyone, my name is Krzysztof Bielski and I'm a product manager at Google. I'm a geek at heart since ever and my adventure of computer science started since I was five years old and I saw my older brother playing a computer game called stunts and I discovered that you can build a program so to say your own racing tracks. Since then I finished my master's of science studies at the Warsaw University of Technology, founder of startup NGO and work in the tech industry for around 13 years. I currently work as a product manager at YouTube ads team in Zurich Switzerland where I am focusing on building products for the premium advertiser experiences. If you want to have any questions, if you don't have any questions, if you just want to say hi, please find me on Twitter or LinkedIn under the following anchors. And I will present to you today a talk that is called user empathy based product design. So let's start. This is me when I was six years old and I was asked by the photographer in the kindergarten to make sure that the balloon won't fall down from my hand. As you clearly see I took this very seriously. Somehow I forgot about the main goal of this exercise which was to make a nice picture. I found this picture a good analogy to what we sometimes tend to do as product managers. We define success metrics and for products and focus so much on measuring and improving them that sometimes along the way we forget about the most important thing which is doing what's right for the users. I will present today user empathy based product design framework that I was using when switching to a new product. You can equally use it when you're starting a new job and it helped me to better understand the users, their pain points, their needs, most important their motivation. So you see this quote from Albert Einstein. If I had an hour to solve a problem I would spend 55 minutes thinking about the problem and five minutes thinking about solution. As a product managers we love to find solutions. Ambiguity and lack of clarity is something we fight as part of our profession and we do have a natural tendency to jump into the solution design and brainstorming about options and that's kind of our natural tendency to spend most of our time there. That's not a bad habit per se but in particular when you're working on a new product or you're starting a new job it's actually better to spend more time on the listening. It's not your responsibility from the first day to start delivering tasks, building new products, producing things on the opposite. Your main responsibility at the beginning is to listen. Before you start designing your product spend a lot of time understanding the users, the user journeys and the pain points that they have. First thing when you start working on your product is hey, how much time can I spend to understand my users? What are the things that they're currently struggling with? What are their needs? What are they trying to achieve? And most important what is the motivation? What motivates them of doing the things that they're doing? Spend a lot of time defining the critical user journeys. Those should be used for everything from UX audits, accessibility reviews, launching or going or writing new test scenarios for user acceptance testing when you're launching a new feature. Everybody should know those and everybody should be brought into the value of those. UXR team is your best friend as a product manager. They are the experts to help you in understanding your users and to help you defining your critical user journeys if you don't have them yet. Remember that nobody expects from you as a product manager to immediately deliver solutions. First you have to understand and discover the pain points, the gaps in your products and it's actually very good to spend some time sitting on the problem space instead of immediately trying to find a solution for them. Make sure that you can put yourself into the shoes of your users and really understand what would help them to achieve their goals. I came up with this user empathy based product design framework that has seven steps and I want to walk you over those. First you have to define a list of user groups. Write them down, write their needs, write their pain points and write what would be their motivation. Second use qualitative user studies UXR to better understand how users interact with your product. Third use quantitative UXR to better understand in your products. It's the parts of functionality that you've launched but nobody's using and why is it so? What is the most frequently used use case? How many users are going over which path in your product? Those are important data to have to understand how users are in reality interacting with your product. Define core or critical user journeys for your product. This is a group exercise and you definitely want to involve the whole team into that. Form your product hypothesis, important hypothesis and not assumptions, write them down and write down how you're going to validate them. Six, introduce a confidence score for the major product deliverables before you implement it. Seven, last but not least, is measure success of your product feature by validating it with the users and ideally you want to do that by measuring CSAT or even better NETSAT which is defined as CSAT minus DSAT on a regular basis and compare the baseline values before and after launching a certain product improvement. You have to make sure that you as a team you're going to be celebrating landings which are proven impact of the launch rather than celebrating launches when you still don't know if it will bring value to the users. Let us spend some time going one by one on each of those steps understanding those a little bit better. So first you want to create a visual representation of your users and you want to make sure that you really understand the nuances between those groups and you have to make it stick. You have to involve the whole team and have the whole team understanding for whom are we actually building our product. Now this is a real life example from one of the products that we've been recently building and instead of just staying with a generic sales persona we as a team actually did put in the work in order to understand better what are the different groups. So you see there will be deal program designers accounting that our main goal is to reduce the financial risk. There will be compliance and legal that their main goal is to reduce compliance and legal risk of deal programs. There will be analysts and deal managers that will want to model the deal and track the return of investment and troubleshoot if something goes wrong. There will be sales finance that are setting up the guidance and financial terms for the deal programs making sure that everybody else afterwards is following this guidance when they're modeling a certain deal and you have market planners to manage the whole deal portfolio and to make sure that on the market level we are good. It actually does make sense to put in the work to understand the nuances and the differences between those groups and have the whole team understand for whom you're going to be building our product. Make it visual, make it detailed enough that people can understand the differences and most important make it stick meaning any presentation in your team and your partner teams should always refer to this shared understanding of the user groups and that should be the base for which we always start whenever we're discussing our product as a whole or we're discussing an idea of launching in your product feature. Second step use qualitative UXR studies to better understand how users are interacting with your product. There are a couple of points worth mentioning here. Ideas are cheap so you can have thousands of ideas but implementing all of them will be very very costly so validating hypothesis is always going to be cheaper than implementing those. That is why UXR studies and qualitative user studies can be very efficiently used to build quick prototypes on paper or mocks using modern tools like Figma and you can visually test those out with real users. Make sure that you really understand the why behind individual user wants and needs so just don't stay with the superficial knowledge of them but really make sure why do they ask the things that they ask and make sure that you go always in those UXR studies pick a good representation of your users and not over focus on one group at the cost of the other. I'm not going to be teaching you how to run UXR studies. There are better experts in that field but make sure that first of all you're going to be ending you're going to be asking open-ended questions and second of all as a product manager you should be joining those sessions as often as you can to learn daily query from the users. Now that you did your qualitative UXR studies it's also important that you're going to plan and execute on a regular basis the quantitative UXR studies. Those are the studies that help you to better understand your product in the early stages but also in the advanced stages. Those are studies that help you to discover and learn if a certain product feature that you launched is actually being used by the users. What are the most frequent paths that the users are picking? Where do they spend most of the time? Where do they get stuck most of the time? How much time overall it takes for them to finish the user journey? Is there anything we could do in order to improve that? Those are all the questions that a quantitative UXR study can help you to resolve and can help you to better understand your own product. If you have the opportunity to make sure that you hire data scientists in your team and that this person really understands the list of the users for which you're building your product the critical user journeys and the overall strategy and they will help you to design the right studies to either understand your product better at the initial phase or to make sure we validate certain ideas before implementing so that when we do launch them they're going to land really nicely. Next step is defining core critical user journeys for your product. So what is a critical user journey or even maybe even first let's answer a question of what is a user journey? So when we talk about user journeys we are referring to a series of interaction between the user and your product in order to achieve a certain goal or satisfy a certain need from a user and now a critical user journey is a user journey that is absolutely necessary. So think about it as like bringing the focus to the bare bone needs that your product. So everything that you're going to define within your critical user journeys should be later solved by the MVP minimal viable product that you're going to be building. And when you're going to be defining the critical user journeys those often represent either the paths that the majority of the users take in your product so the use cases that the majority of users are doing in your product or they can represent the most impactful for example financially wise set of use case that you built in your product. It turns out that deep diving into a critical user journey is nothing more complicated than doing a research research study or UXR. Hence my tip was that first you have to make the both qualitative and quantitative UXR and then using the results from your studies you are able together as a team to build the core critical user journeys for your product. This should be definitely a group exercise ideally all the engineering team whole UX team operations team they all should be involved in defining the critical user journeys so that at the end everybody is fully bought into but also fully understands what is the focus of our product and what is the thing that we're trying to solve. Okay so we go now to step number five which is forming a product hypothesis here first thing which I would like to spend some time on is distinguishing between assumption and hypothesis assumption is something that we assume and we don't plan nor account for verifying our assumption and that is not a good approach so we might take assumptions that are false and then build the product around it and it will be a wrong product it will be a fail because it won't deliver on the needs that the users actually had so in an ideal world we should be forming our product hypothesis first ideally we should be writing them down in a pretty formal form and we should in while forming our product hypothesis we should spend a lot of time thinking of how are we going to verify and prove if a certain hypothesis is true is valid or is invalid and ideally we should also be forming such a hypothesis write down the alternative scenarios of what's going to happen if our hypothesis turns out to be false as well as specify the amount of time we would like to take in order to verify a certain hypothesis now there is a lot to to unveil around writing precise and correct hypothesis and there'll be few books that I will recommend at the end of this talk where you can study in order to to learn more about this but if there is one thing I would like you to remember is that we should try to avoid this harsh reality where there are facts and on top of those facts we're building our hypothesis based on our awareness but we never plan to verify if they're right or wrong please make sure that whenever you're going to be stating our hypothesis there should be a sentence explicitly clarifying how are you planning to verify if a certain hypothesis is true or false by which time you are planning to do so and what is the thing you're planning to do if your hypothesis turns out to be invalid okay we go to the sixth point which is introducing a confidence score for a major product delivery base before you implement it there is a famous framework called ICE which stands for impact confidence and ease and it's a very relatively quickly and easy to do a framework where you assign a numerical value to different potential projects or product features ideas and you come up with a relative value for each of them using three basic parameters first is impact second is confidence and third is ease each of them is being evaluated against a ranking from one to ten for for each of their dimensions and those three numbers are later on multiplied and at the end we come up with the so-called ICE score so you see a simple table here on the on the left and by the way the slides are coming from Ita Markilat and his great book about it which I also recommend you to to read and you see that you have a project idea creating a community tab together by the team you can assess what will be the impact on your product or the success metrics that you define for your product then you have to define what is the confidence score meaning do you have any data actually proving that if you're going to implement this feature it's going to bring the impact that you're that you're assessing for this improvement product improvement to have and then ease of implementation how easy it is to implement it the easier it is to implement it the higher your score will be then you multiply all those things together and you end up with an IC score or ICE score this is a very simple framework and it looks like at which product features might move the needle and the key metrics being targeted confidence is certainly the one that needs the the biggest discussion among your team and there are many other different scoring models that that could be used I'm not saying this is the only one but ICE primarily is kind of it's very simple to use easy and basically gets the job done so I highly recommend it measuring success the last point measure success of your product feature by validating it with your users now Netsat or CSAT is often a secondary metric among the para teams as it is hard to prove causation between CSAT and things like net profit or incremental revenue or direct reduction of costs the most frequent pushbacks you're going to hear when proposing to setting up CSAT as the primary metric is how do I but how do I translate CSAT improvements to net profit how do I translate it to revenue increase how do I translate it to reduction of cost and the reality is it is very hard to prove that causation however using CSAT has a significant value that cannot be underestimated and it is the value of listening understanding and caring about your users I strongly believe in the following two hypotheses for the B2C products if your users are happy and satisfied they will be peaking your product over the other authorities available on the market and for the B2B products if your users are happy and satisfied they will be working more productive and that was in fact proven by many research studies which you can link in the description of this talk what I really wanted to say with this point is that you have you should have a central dashboard that is measuring CSAT and this is a dashboard that you should be looking at on a regular basis on a weekly basis with the whole team definitely you should be looking at this metric like before and after launching a certain product improvement and feature because this is the best way to quantify and to see if what you plan to launch for the users actually land it well and users actually appreciate the things that you're building perfectly those are a few takeaways that I would like you to take out from this talk before you design your products spend a lot of time understanding the user journeys the pain points their motivation their motivation their motivation pain points their motivation and how do they interact with your product use quantitative user studies to better understand your product in the early stages of your product design form your product hypothesis and use qualitative user studies or quick prototypes to validate those introduce a confidence score for major product deliverers before you implement them last and not least is make CSAT or even better NETSAT which is defined as CSAT minus DSAT as the first citizen metric for your product those are a few recommended books that I used in order to inspire myself to create this talk Marty Keegan inspired a book that I don't have to promote more and because everybody in product management board knows it already Ryan Singer shape up great book that allows you to know how to ship things and how to ship work that really matters ice prioritization done right by Ita Mark a lot goes quite deeply on the framework that we mentioned today and it's a very easy but very powerful framework that you can use in order to prioritize product features and the lean product playbook by Dan Olson is also a very highly recommend it's it thank you for your attention thank you for your time and looking forward to our future sessions thanks bye