 Hello and welcome everyone. I am really glad to be here again at product school talking to you about a topic that's another topic that's actually pretty close to my heart. And I think it's really important and passionate about it. A few months back I talked about how to use understanding as storytelling as two core skills in the product management career and how to form your narrative as someone who's getting into product. But today I brought a topic that's getting more into the weeds of product, the product craft. I'm here to talk to you about how to develop a good amount of user understanding very early in the product development process actually before you start building that's pretty important and how to do that in a lower resource and a higher resource way. So I brought you a graph about the double diamond framework and I'm not sure how many of you have heard about the double diamond framework before it's pretty largely adopted by design teams in the product development process. It's a really useful frame of thinking about how to approach solving problems through this like that this represented by the diamonds, the divergence in the convergence model that's actually originally set up by a linguist where the widening and the diverging parts of the diamond represent a process of exploring an issue more widely and more deeply and the converging part then represents taking focused action. So today we'll dive a little bit deeper into the first half of the first diamond. This piece of the process is called the discover phase and it's all about understanding rather than assuming what's the problem that you're trying to solve and I want to talk to you about tools that you can use in the process of discovery and then they actually discover phase the first half of the first diamond. I'll walk you through the methods I've been using for years to improve user understanding. These worked for me at my time at a series A startup and as well as building products currently in Spotify. It's an especially important distinction between a startup or a more established company because I've experienced this crappy kind of like low budgetcy way of doing things and I've also experienced like having more resources to dedicate into this process and having a dedicated research team. So every method that I'll show you I'll talk about a low resource and a higher resource alternative as you can see next to the diamond. So I mean it's important to ask why is it important that we approach it this way? Why do I think it's important to approach user research or user understanding from a resource standpoint? But actually because what I really want you to take away from this presentation is that you don't need to have a long time to dedicate to this you know user research process or and or a huge budget of dedicated researchers to do it. Especially at startups and early growth stage there tends to be kind of like a misbelief that user research is a luxurious thing and I actually firmly believe that the exact opposite is true of this. It's a luxury not to do it. So why do I say that? Because investing time into research will help you to understand whether you're building the right thing and this process even if it's lengthy will be so much cheaper than building the wrong thing and having to throw out weeks and months of hard work just because you were kind of convinced in the beginning that your that your solution or your you know that you're building the right thing and your solution is going to work. You need to test your hypothesis, you need to look at your ideas from different angles, and you need to probably need to do a lot of user research in order to build the right thing for the right people addressing real user needs. So I hope I will be able to show you how to discover in in a low resource point as well be able to convince you to do this. But before we jump in let me just quickly introduce myself. My name is Kinga Oshbot. I've been working as a private manager at Spotify for the last near the two years. Before that I worked at the B2B SaaS startup. I got into product there and that is called Impraved and before I transitioned into a PM role I worked in a in the customer relations team actually and worked with in the customer supporting customer success teams. I studied psychology and I had a brief kind of adventure as an entrepreneur as well. And these two I actually consider like kind of key transforming me into someone who is really focused and and passionate about delivering user value and to be honest I'm also kind of strict about this too. If I you know if I think that if that ever happens that I think that we don't have like their right user needs like narrowed down and properly mapped out and understood I'll always push back building a solution. So let's talk a little bit about what user understanding is. So simply put it's understanding the different needs pains annoyances desires because trains etc of the people that you're trying to build your product for. This is especially important to do before you start building and base your decisions on assumptions and potential biases that you might have about your users. So not that we have this the definition I know many of you are thinking you know especially that I talk about like a design framework double diamond you know you might think wait a minute why am I who's the responsibility is this like isn't this design team and that's a very fair question and there still tends to be a concept that in-depth user understanding is only the design team's responsibility and to be honest I just couldn't disagree a bit more. As a product manager you'll ultimately account for your product success and your product success is firmly grounded and how well it can deliver user value and how could it deliver user value without you understanding your user's needs their circumstances their behavioral patterns who they are and what jobs they're considering hiring your product or solution for. So I'm here to make a case that developing user understanding is best done with you as a product manager involved if not actually driving it. Usually your design folks will be very involved in the process too and they bring on expertise that will be really helpful really really helpful in doing user discovery and structuring information that you collect by your users. But you know that the PM should always be involved and in some situations where the company doesn't really have like resources or you know a lot of budget to found user research you as the PM can very much pick this up and you can actually drive this. So with that said let's drive into the methods that I brought to you today to begin this process. The first one is interviews and it's always a great idea to start with conducting interviews. If you have already a good business problem that you want to solve and if you just want to validate it or if you're searching for like you know very wide discovery just searching for meaningful problems to solve in your potential user lives. Interviews are a great goal to to kick this process off. So yeah let's talk about stakeholder interviews first. So this is the process when you schedule calls with your business and customer stakeholders and try to unlock their knowledge their perspective their insights and I dare to say yes even ideas. I'm 100% sure that they will be kind of thrilled to talk to you about their opinion and they will grab every chance that you give to them to share their insight knowledge as as well as possible. After all these are the people we interact with your customers or your potential customers actually regularly they feel the customer's needs and pains and they interact with them and they see you know how your product is being used and and and they kind of use your product sometimes rather similarly as an external user would. So they usually have like very well informed feedback and good ideas and what usually these needs to be like filtered and refined and you know to get to the root problem it's a great resource of information to start the expiration of potential problems to solve. But stakeholder interviews are more of process of a one interviewer and one or a few interviewees there's another tool I love to use that's very similar to this but it's kind of a little bit different and it's called lightning or expert interviews. During the lightning interviews you invite an expert and ask them questions about their area of knowledge. For instance you can invite a customer support representative and ask about what they see the biggest bottlenecks of the process processes that the product that users go through. You can invite marketing or sales team members your business and data insights team anyone and everyone basically who might have a unique perspective on your users and the space that you're working in. What I actually really love about this process is that it's very fast and it's very concentrated that's why it's called lightning interviews actually. Also instead of like you asking questions you can invite and you're actually encouraged to invite the entire product team and have them ask questions while you're kind of just in the background moderating the conversation. Your product team will write down how might be questions of the insights that they're gathering. So for example when the expert mentions I often see people reaching out to us asking us to send them their invoices. Your product team might note down how much we make it easier for users to download their invoices in a sub-survey. I actually lifted this exercise form from the Design Sprint or Google's Design Sprint. If you haven't heard about the Design Sprint I highly recommend you to check it out. It's a few days long process to drive from problems to solution. It's a brilliant class-based tool for all product teams to use to test their ideas. Lightning interviews and how might be questions are part of the understand phase of the design interview and that might sound a little bit familiar. Thinking back of the double diamond and the part that we're talking about this cover phase. It's part of the Design Sprint but as I said I use it on its own too and I really believe that it's a great tool on its own as well. And obviously this is a really lower resource way of learning about your user problems and all you need is to block some time out and invite people who might actually be very enthusiastic and happy to talk to you about their experience and knowledge. So let's talk about another very obvious method or interview method which is conducting user interviews. I don't really want to get super deep into this. User interviews is kind of like an art on its own but the point here is to urge you to go ahead read about it and I really encourage you to try it out. You can start these interviews like really wide and not focused on any topic. You can talk to your potential existing users. It's a good method to talk to a variety of users. It's actually good to keep in mind to talk to different users from like in terms of like their background and demographic age etc etc. So here I brought you some examples. So I don't know let's just assume that you want to conduct some interviews about shopping habits and you kind of suspect that there might be a pain with grocery shopping. So you can start really wide and ask the question how do you feel when you think about having to be grocery shopping? What do you typically do before you leave or you know what do you find pain for and annoying when you do and when you're doing your shopping? Walk with through your time when you are faced with not having enough time or you know etc etc. So kind of like keeping it wide and as you can see these questions are also like very broad and it's great to start off this way especially if you don't have a firm idea already what to work on and it's also a good place to be when you don't have a firm idea. You can later narrow your questions down further to understand a more specific problem. I'd like to urge you to be curious and keep an open mind in this process. Follow up with clarifying questions when necessary and yeah I actually use interviewing a lot in my career. We do this as Spotify a lot too. It's actually invaluable I think to talk to real-life people facing search and problems or you know people who actually use your product and you can scope your interview phase to be as big or small as you want it to be. You can make it like kind of you know scrappy and do it yourself or you can hire user researchers too. It's actually really up to you and you know I've actually done both. I went out to talk to like potential users on the streets before. I said I have tons of emails like begging for a chance to talk on the call but I've also worked with like user researchers who felt like I'm in like sitting the most question sofa while digesting user insights. So really no matter your resources I really encourage you to talk to experts, your stakeholders and your users and maybe another thing to add here and this is something that I've actually taken from my experience working as a psychologist is that people actually love talking about themselves. So let them let them they will share a lot of their ideas problems concerns all you need to do is to listen and you organize your findings and you'll have so many ideas so many they can spark so many good ideas how to solve problems of what problems to solve. I really encourage you to do this and listen to people. Cool. I just thought about like organizing these findings and you know a great way to organize findings and once you actually gathered a lot of great insights through these interviews you'll I think you'll start noticing that they already kind of naturally fall into distinguishable categories when it comes to your users. So the next logical step is to group them and create representations of your user groups. The high resource approach to creating representations of your user groups are creating archetypes and or personas without your design scheme. But what are archetypes and how are they different from personas? Well archetypes are behavioral perspectives of a user towards a specific product. These representations contain user needs and behavioral patterns and other important vectors that align a group of users together. And then on the other hand personas are fictionalized and hypothetical characters that represent segments of the user base and are built around more about like the demographic demographic details such as age, occupation, education etc. You might have seen these before actually. They sometimes even have a name or often they even have a name and a gender attached to them as opposed to archetypes that are really like wide and don't have these demographic details attached to them. And then as I mentioned archetypes are more behavioral constructs and they're more task oriented as well. So obviously the question is which one you would set up and I would say that really depends on what you need. Behavioral patterns show how people are using your product and what personas give insight into the people who are using your product. So behavioral versus characteristic is really the takeaway from this one. I've used personas in the past and they were really great to think about delivering user value for like more personal user needs. But I also really really love archetypes and I find them to really to be really easy to work with. I think they're prompting great problem thinking without the personal touch. At Spotify they actually use both archetypes and personas which backs up my statement about you know it really depends on what you need it for. Currently I'm working more with archetypes actually and it's really helpful to kind of constantly incur the way the first thinking about problems to solve to the people that we're solving for. And so it's a great method I really recommend that but if there's one thing that I learned about using both personas and archetypes is that you need to constantly work on them. So yeah whether you choose archetypes or personas, setting them up and perfecting them are a lot of work. You probably need a lot of like help from your design or insight theme. You're probably gonna spend a lot of time doing research as well which is actually great if you have a lot of time and resources before you can actually use these things. But what if you don't, what if you need something kind of right away? Well then I recommend you the lower resource alternative of this, the proto personas. You remember what I said about the lower resource interview methods to talk to your stakeholders? Well proto personas are descriptions of your target users and the customers of your product based on these assumptions from stakeholders. This is a very useful method to build alignment in the early discovery phase between teams and you know it allows like the product team to start designing and building without feeling kind of paralyzed by not really understanding who the users are and I've actually seen that happen a lot of times and this is a really, really useful little method to like unlock that feeling of being paralyzed. And it's important to keep refining proto personas as well. Some definitely not saying that you should stick with them you know later on when you will have like some more occasions but you'll do user research, user interviews, you can build this and you can iterate these into archetypes and personas. So yeah in that sense proto personas also require constant refinement and it is a lot of work but with proto personas you can just get started kind of right away. And also it's important to keep in mind that this process of iterating that's also what makes them useful. In the beginning you might have a lot of assumptions and you might you know work these assumptions into a persona or an archetype and later you can refine or swap these like assumptions out with the knowledge that you gathered during your user discovery. So these are the tools that are brought to you today to develop early user understanding and making sure that when you start building you're actually solving a key problem of pain point for searching group of users. And I hope that you were able to get this message out of this presentation that you don't need to have a lot of time or a huge budget to bring your user understanding to the next level. And before I say goodbye to you today I just wanted to mention one more thing about this you know low resource, high resource topic. It might be a little bit unusual but I actually believe that sometimes it's much better to do things this crappy way. It brings you as the product manager much closer to the problem than when you have these insights delivered to you. You know you can actually take this chance to interact with your users and develop a much better connection to the problems itself. It also makes you and the team more invested in the success. It makes it easier to empathize with your users because you're interacting with them face to face. It reinforces the team feeling or working for something impact for a meaningful if you involve your product team in the process which sometimes you have to do when you do things crappy. So there are a lot of great takeaways from doing it this crappy way and obviously this can be done with the right ways of distributing research insights. So even if you have like you know dedicated research findings and you're having like an executive brief of the research findings you can still distribute these insights in your team and this basically it has to be done but it's maybe it's a bit more natural when you and your team is also part of the user discovery process. So that's what I wanted to talk to you about today. Thank you so much for your attention. I hope you enjoyed this quick talk and I really really hope that inspires you to do more user discovery to build the right thing even if you don't have the budget to do something fancy. Thank you so much.