 Hello, and welcome to the session titled Converting User Problems into Solutions. My name is Kevin and I'll be your host for this session. A few words about me. I'm originally from Australia and I now live in Norway. I've been lucky enough to work all over the world throughout my career and that really helped shape both the person and the product manager that I became as I was exposed to many different cultures. Day-to-day, I had a small product team within Microsoft that sets direction for our data platforms and they're dedicated to people and how they're represented in Microsoft products. Outside of work, I spend a lot of my spare time coaching and in particular goalkeepers for football or soccer, depending on which part of the world you're listening in from. I also mentor and invest in a handful of companies to keep touch with the tech world outside of Microsoft. So even though this session will really only scratch the surface on these topics, I hope it will equip you with some new insights and ideas that you can use in your own work as product managers. We'll cover the problem with the problem and why the biggest challenge is often not the one you think you're solving. We'll discuss some tips and tricks for keeping focus on human needs, including a quick introduction to what we mean by that term. And then we'll round out the discussion with some tips, tricks, and advice when it comes to delivering solutions that will make you proud of your product. So what is the problem with problems? Hopefully, most of you have seen or heard of the Galaxy Note phone or Fabulate as it was originally named. It was one of the first, if not the first, large screen mobile devices that was released maybe seven or eight years ago. And it got a lot of attention at the time for the form factor in particular. But can you guess the problem the largest screen was actually solving? Perhaps a very non-obvious answer, but the key driver for the largest screen wasn't because it was trendy or cool to have the largest screen, nor was it a practical thing like looking at content on YouTube or one of these other streaming services. Rather, the problem itself that it addressed was users who had long fingernails found it very difficult to type on smaller touchscreen keyboards. By increasing the screen size, the keys could be spaced further apart, making it easier for those users to use the device. Now let's look at another example. This one is perhaps a little more obvious to everyone, but let's see. One of the most coveted seats on an airplane historically is a window seat, especially when you're flying over some terrain like the Swiss Alps or the French Alps. Using the same approach as the last question, what is the problem that putting a bunch of windows into planes was trying to address? OK, so this one was probably quite a bit easier. The reason we have windows on planes isn't because it makes the plane lighter to carry more people, or that it becomes cheaper to build, even though those might actually be true statements. The real problem it was solving was helping people in the plane feel at ease so they could see what was happening outside when in flight, taxiing, and at the gate. OK, so why did I take you through what were some pretty out there examples in a session about product management and converting user problems into solutions? I wanted to focus us on identifying the human need you're addressing whenever you see or are solving a problem. The two problems we had are great examples of aha-type moments, those moments when you figure out what the need actually being addressed is, and then it feels painfully obvious afterwards. So the problem with problems is actually breaking it down until you locate the human need you need to be addressing to solve it. Now, consider how the foundational or fundamental needs like competence, connection, and autonomy impact how your users are interacting with your products. Seek to fulfill your own needs rather than try to deeply understand others and theirs. And once you've solved your own needs, figure out how to extrapolate that out to meet the needs of a much broader audience. So I talked a lot about focusing on human needs in that last slide, but what are human needs? Now, I don't want to turn this session into a Psychology 101-type session, but anytime we start talking about human needs, it's important for us to set some context and framing about what they actually are. So here you see Maslow's hierarchy of needs, which I suspect many of you have seen or heard of before. And I'm not going to focus on the five levels of the pyramid that you see here, but rather I want to draw your attention towards the concept of growth needs and deficiency needs, both of which are important inputs for how you go about addressing the needs of your users. Deficiency needs stem from a person's desire to get rid of deficiencies to obtain things they're lacking. As a person obtains the things they lack, their motivation to obtain these things decreases. So a great example of that is the longer a person goes without food, the more hunger you get. Once you eat, that need is fulfilled until you're hungry again in a couple of hours, and then that cycle begins again. Whereas growth needs, they're not present due to a lack of something, but rather a desire to grow as a person. And interestingly, as a person fulfills growth needs, their motivation increases and their desire to become better just increases as well. A great example of this is your lingo, where you go through and you do the exercises they have and then you get to the end and the owl pops up and gives you a pat on the back, and then you're motivated to attempt to do more. So being very conscious of the needs and the type of needs that you're meeting really helps you figure out the behaviors you can expect from your users when you're building your product. Okay, so how do we go about identifying the human need you're addressing with your product? I've listed a couple of things here. I've always found very useful when working with products that I've managed over the years. First is actually maybe very non-obvious, but become a new and really put yourself into the mindset of being a first-time user coming to your product. Use it, consider the things you miss when first using it, other things you expect to be there that aren't, that you can't do, for example. And then immerse yourself in how people talk about your product and what they're saying about it if it's possible for you to do so. And then seek to identify commonalities or trends in what you're hearing and seeing, and then go off to the underlying cause. And this isn't just useful for fixing problems, but it's also useful for identifying new features based on unmet user needs. And then I think lastly, don't forget to consider the needs of groups of people. As humans, we have a natural predisposition to form groups as humans. And many of the individual needs can be equally applied in a group context as well. That's why you see social networks be so popular. So along the same lines, here are some things I've learned to avoid over the years as well. The first is perhaps common advice or maybe even common sense. Don't go and implement a feature just because a user is asked for it. If you have a hundred different users, you're going to have a hundred different feature asks in many cases. So take the feedback and use it as an import and especially into some of the feedback loops that I talked about a few moments ago and see if you can identify some trends in it. You should not use it as your roadmap in most cases. Another thing is just copying your competitor's feature set or focusing too much on what they are doing or have done. Sure, getting an understanding of what the underlying needs they are meeting is possible to achieve, but it's really, really hard without context to understand who their users are and what they're targeting. I think lastly, listening to other product managers. Let's face it, we all believe we're the smartest person in the room and that we have some sort of unique insight into our users that all of the other product managers don't. Now, in reality, we have a tendency to be very overly analytical or rational in our approach and we miss some of the obvious things in the process. So by all means, talk to other product managers, but treat that feedback in much the same way that you're taking user feedback and look for trends and themes in the data. So let's talk about getting to some creative solutions. So there's a few things here. Creative, one of the things that really strikes me is creative solution just not necessarily equal a beautiful design. It is perfectly possible to meet a need or solve a need in an ugly manner and be very successful. And there's tons of examples of very early product mockups and MVPs through services like Uber and Amazon and probably a ton of our Microsoft products that were very ugly early on, but did what they said on the box. Another thing is to really think about designing for the future. Constraints that exist today might not exist 10, 12, 18 months from now. How does that impact how you're thinking about addressing the need? Also, consider whether or not you're excited about the feature or solution that you're proposing. If you're not excited about it, maybe you shouldn't actually be building it. And it's okay to, in that vein, come back to a problem. If no good solution exists, it's not the right time, come back to it later. And then think about your weaknesses as potential strengths. A good example is people with social phobia. They might actually have a knack for developing great social network products. So always look for the positive in any weakness. So I think another key theme here is simple tweets exhaustive. Provide one general mode with no alternate design. There's no need to have skins or anything like that. You should be able to offer one version of your product and offer it really well. Make your features stupid simple. Find a solution that a user can pick up and start using in a matter of seconds. Take away explanations and focus on ensuring the feature is clear enough that it doesn't need explaining. Not a free solution or feature needs to be obviously or immediately visible in the product. It should be where the user needs it when they need it. And then finally, I think asking users to manage things is unnatural. For most users, management is a chore. It's not a need that they have. Contacts, calendars, great example of things that should just automatically update and be magical and easy to use. So if we think about some of the key takeaways here that I wanna leave you with. So a couple of things to iterate. When it comes to problems, again, focus on getting to the need that isn't being addressed. You can't find the need. And it's really worth digging in and checking whether or not it's a real need or whether it's something that's being manufactured or is an artificial need. When it comes to focusing on human needs, keep in mind that you're a human too to put yourself in the user's shoes. Use your intuition when you're seeking out the need to be addressed. Often you're gonna know what that is innately. And then finally, for getting the creative solutions, stay future oriented and laser focused on addressing needs in a very simple, effective manner. And then remember that it's okay to park scenarios and come back to them later too. Timing is everything. So with that, thank you very much for attending and listening to the session and I hope it was enjoyable.