From the course: Becoming a Product Manager: A Complete Guide

Getting to the real user needs

From the course: Becoming a Product Manager: A Complete Guide

Start my 1-month free trial

Getting to the real user needs

“

- Welcome back everyone. So in the last lecture, we talked about all of the places where you can receive user feedback and ideas. Once we have this list of ideas or feature requests, do we just go build them? Let's say that a user has given you some feedback and they want you to build a native mobile app for your website. So you get that feedback and you just go out and build it, right? No, being a Product Manager is about a lot more than just learning a few skills and applying those skills. One of the most important things about being product manager is having a product manager mindset, and a big component of that is being able to understand the core pain points, the real problems behind what people ask you to do. So in this lecture, that's what we're going to learn, how to get that essential skill. Let's start off with an example. Let's say that I have a friend and I don't really have any friends. So this is an unrealistic example, but let's say that I do, and they are standing outside in the rain and they're getting all wet and they're upset about being wet. And they say, "Cole, can you give me a towel?" And I give them a towel and they dry off and they get dry for a few minutes or maybe a few seconds, and it's still raining. So they keep getting wet, did I really solve the problem. Well, of course not. They asked for a towel, so that's what I gave them. That was a request to me. But is that the actual problem? No, the actual problem here is that they're in the rain. So the actual solution would be to get them out of the rain. So I know that example sounds pretty ridiculous, but this sort of thing happens all the time in the world of product management. People are always asking you to build things or add features and those things at first glance seem reasonable, but actually they're merely symptoms of a real problem the user is having behind the scenes. Being a product manager is all about finding a solution to a problem instead of trying to fit a problem to a solution that you or someone else has thought of in the first place. Given any request or a feature idea, the first thing I want you to do is think to yourself, is this solving an actual problem? The second thing I want you to do is ask yourself if we do this exactly as they ask without looking at any deeper, is it going to have any unintended side effects? I'll give you an example of an unintended side effect. Everyone's familiar with Twitter, right? They've got several hundred million users. The way Twitter works, is you can type some characters and send it out as a tweet, and that appears on your profile and it also appears in a newsfeed for everyone that follows you. On Twitter, you can also retweet, which is clicking a button on their tweet and it puts it on your profile. And all of that also feeds into the newsfeed. So if you are following a ton of people, then your newsfeed can understandably get pretty busy. One of the most common things people ask for on Twitter is the ability to just filter out retweets. So the idea is that if the product managers and developers at Twitter just made a button to where you wouldn't see retweets on your timeline anymore, it would make things a lot less messy. It sounds pretty reasonable, right? Now, Twitter as a business model is a company that really just tries to show everyone out there what is really popular right now. So what are people around the world talking about? Think about retweets for a moment. When I retweet something it's like saying, I really like this, I endorse it. I like it so much that I'm willing to put it on my own profile. So if we built this feature and it got pretty popular, then we could have say 20 to 40% of people not seeing retweets at all. What ends up happening here is less and less people retweet because there's not as large of an audience and then Twitter has less of an idea of what people really strongly like or really strongly endorse. This makes it even more difficult for them to separate out signals on what's globally super popular. This affects normal users as well. So with less people retweeting, it's more difficult for them to tell what is super popular or what people really, really like. So remember the request here was to allow us to filter out retweets on the Twitter timeline. And we've just covered, that might not be the best idea because it has some unintended consequences. I'll give you an example from my career of a feature requests that did not actually address the user problem. A while ago, I was a product manager at an eCommerce website and we were working on building a new content management system for the marketing team because they had outgrown the old one. This is basically a system by which they can go and edit the photos and the text and that sort of thing on the website while the website is live. So I'm meeting with the marketing team and I'm writing down requirements and they're saying, we need it to do these things. One of the things they mentioned was they said they needed the ability to put up a small message on a specific product web page to tell the user something. And they wanted to be able to put that up and take it down pretty quickly. At that point, I could have said, "Okay, I'll take that into account. "And I'll make sure that whatever we do, "we'll give you that feature." But instead, what I did was ask them, what's behind this request. What do they actually want it to do? So I asked why this was actually a requirement and for what reason do they need this? So it turns out that the merchandising department told the marketing department to tell me that this was a requirement. And the reason was, it turns out, that they would hold sales on particular product pages. And on this shorts page, in particular, the sizing and pictures were a little bit misleading. So when a lot of traffic went there, it ends up that a lot of people left because they were confused. So what they wanted was a little, basically a message where users would know to call our customer service line to better understand it. So after hearing all of this, it was pretty clear to me that the real problem wasn't that they needed an ability to put up a message really quickly for customers, the real problem was that the page was extremely misleading and causing problems in the first place. So after hearing this, I went back to the designers and developers and told them about this. And we went to the drawing board and talked about how we might make this a lot clearer for customers. Once we had solved this on the webpage, it was not really a problem anymore for the merchandising department and the customers didn't need to call into customer service anymore. So problem solved, but the real problem was solved, not the initial idea or requirement given to me by another team. I want to show you a really easy way to get to the core issue of a request and see what the actual problem is. And this is a technique that a lot of salespeople use and have for a really long time. So it's really easy. You just ask why, but then you ask it two more times, at least. So if someone asks you to do something, you say, why they'll tell you, you say why again, and they'll tell you a reason that's a little bit closer to the truth. And then you say why again, and by the end of it, they'll probably have illustrated to you what their real pain point is. It seems really obvious, but in fact, it's not. And there are so many people that just skip over this simple step. Ask why. I once took a sales class back after college. It was really, really good. And this guy that caught the course was in his early 50s. He had done some of the best sales jobs in the world. And his number one piece of advice was to do this. And this technique works with product management just as well. So in this lecture, we learn that the product manager's job is not only to listen to the request the person is giving us, but to find the real pain behind the request, what is the real reason they're asking for this? We also learned that the easiest way to get to that is to continually ask why.

Contents