 Hi, I'm Anton Guinovsky, and I want to talk to you about a really important topic in product management about understanding customer problems. Now, why should you watch this video? Well, it's about saving you time and building impactful products. Here's a quick example. I've launched two startups. In the first startup, I had this MVP solution for real estate, and I was really focused on the payment flow. What's the cheapest, fastest, simplest way to transfer funds? And I ended up using building this MVP solution for ACH, solution powered by Duola. And I started talking to agents about it, like, isn't this cool? Don't you want to use this? How would you sign up? And my head was already all about payment processing, left and right, connecting the dots, thinking of edge cases. And then I started talking to these agents, and then like Anton, I can't touch payments within a mile. I don't care if you beam it to me from space. I don't care if you use Stripe, Duola, prepaid credit cards. I can't touch payments. My broker needs to handle payments. He is legally the only one who can do it. I can't do it. I can't touch it. So you're not even talking to the right people in the right room. And then I was listening to his conversation. I was thinking to myself, wow, I jumped a gun here. I spent a lot of time thinking and building cool solutions for a thing which is fundamentally not the right approach. I need to be talking to an entirely different persona than who I'm talking to right now. And boy, would I have saved some time and money by just doing that upfront work instead of googling and building out all these cool solutions? And that is why this talk is important, because this is how you create products that have impact and last. And for folks of you who are listening, who are trying to break into product management or interviewing, you will likely face some sort of case study question. And very often success here starts by understanding the customer's context and problem space first before jumping into the cool thinking about features, solutions, and forecasting and growth metrics. For the same reason, this applies to anyone in product at any level. There's a long list of startups, solutions, companies built initiatives within companies, which sound great at the time or funded, get built, and then realize they don't quite have a great fit. They kind of fall apart and die. So this is about how do you build to have an impact on others sustainably? It really starts by as a necessary first condition to really get your problem space, really clear understanding of who and why and what you're building before you're actually building out those things. Now, back in 2016, I was interviewing, pitching my startup, Y Combinator. And there's four words which appeared on their website and inside of the interview room, which are extremely simple, but they're loaded with a lot of meaning. Make something people want. And a lot of companies don't do this. A lot of startups don't do this. And we're going to focus on the last three words, because make is all about execution. Incredibly important, you have a problem, you have a solution, you bridge the gap to and learn between what you're doing and how it connects the two. Crucial, lots of failure points there, but we're going to focus on the last three words, something people want. Because that is really important. And think about who is it that wants what are we thinking doing? Is it just you? Is it an imaginary person who has this imaginary problem that you think is very crucial? Or do you have specific names you can write down and people like them and you know how to reach those people who have this need? And it's a big need because those three cases are very different. Now, before we jump into building a clear understanding of the problem space, we have to pause, just take a breath. And I love this cartoon because there's often a need for bias to action, some tangible outcome from your work. And as this cartoon says, just listening and talking to people without building is action. It helps you understand the context of everything that's going on. And ultimately, it will save you time in the long run and help you build the right things faster. Now, what I really like to do is you have a big sense of what you're trying to build, this big problem statement. Write it down. Write it down because writing forces you to go from nebulous thoughts in your head to something specific and concrete on paper. And that will show you two things. One, it will likely show you how confident or unconfident you are about what it is you're writing down. And two, it will force you to think about what things you don't know. Like what assumptions are you making? How concrete is it what you're thinking? And this is just a starting place because then the next step is we'll add specificity to this. So for example, in the previous thing, maybe you have a problem statement from your boss that says we need to increase registrations by 25%. And that is your problem statement. Okay. We'll try to get that more specific. For example, as a customer who is A, I need B in the context of C. And we'll build out some specific problem statement we can use to then increase the registrations by that amount. And I also really like using the first person voice when I write these things down because that forces me to think about as that person, as that kind of perspective, first person point of view, rather than maybe a little bit more distant hypothetical case. There's a really common code which is often overused, but I think it's really it's powerful. It's customers don't want to drill. They want to hold them all. I love it. And it's all about thinking about the customer's outcome. What is the customer trying to get done? Not necessarily what they're saying right now is a problem or maybe they're even coming up solutions for you. But what is it they're trying to get done? Why are they trying to get it done? When are they trying to get it done? This framework is called jobs to be done and it really forces you to think about the outcome. And you want to write these things down again. I think that's a common pattern throughout this whole process is trying to write things down. And then you want to get more context on the problem. So you have something, you wrote down some initial thing. We're trying to get this framework of jobs to be done. What is the outcome for the customer to focus on? And get more context. I have this example of I built this startup in the restaurant space and I get a call from a customer. Nothing's working. The tablet which is supposed to receive updated order information. Nothing's working. He's trying to log in, pressing the button. Nothing's happening. Getting irate, upset, about to cancel the whole deal. I'm on the call with my engineering team trying to debug what is going on with this customer. Is there a server up? Is there some weird edge case logic we didn't think about? And then I hop on a cab and basically drive over to his restaurant. Only to find out the following situation after more clicking around. There's no Wi-Fi. The whole thing is not working because it's not in our area. It's not working. The tablet is fine. It says Wi-Fi that's off. You didn't realize that was the case. Our tablet did not show that update. There's no data. There's no Wi-Fi signal. And that is a really good thing to extrapolate from. You want to get more context on the problem. The customer says, or this person says, they have a problem, A, and you need to fix it. Dig deeper. What is really the problem going on? When is it happening? What is happening? Put yourself in their shoes as much as possible. And we'll focus on two tactics here. One is qualitative and quantitative methods to try to get at this deeper level of understanding of what is going on here. So quantitative. Again, for the purpose of this talk, we'll focus a bit more on existing companies rather than early stage companies in large part because you have much easier access to quantitative data to analyze. And if you have quantitative data to review, it's silly to not look at that. It's absolutely, it's right there. Dig in. Segment it out. Look at users by type, channel of acquisition, channel of every kind of channel. Geography, trends, mobile, desktop, segment to users. Trying to look at what is sticking out here. Where is there some pattern of weird behavior which jumps out? Because that can really help you focus on your attention. Going back to the original hypothetical problem statement, your boss says increased registrations by 25%. You do this, maybe you're lucky and you see that mobile doesn't work. And 100% of that drop off is explained by your mobile and not working. And you just save a lot of time. Now, think about also just don't rely only on quantitative data because often the answer is not as trivial as your mobile app is just not working. Users are real people. And data often mixes a lot of correlations. For example, if you look at your channel SEO, search engine optimized channel, not every iPhone mobile user is the same. It's a lot of different people there. And if you just look at data and see that cohort is standing out for some reason, that's an indication, but that's not the explanation that there might be something else going on. And maybe these people, they're correlated to some other behavior. And maybe it's that other behavior which is a root cause of what's going on. For example, mobile apps, iPhone users on SEO, maybe they're primarily using Safari and Safari has some bug that's going on. And maybe that's the real issues there. It's maybe not necessarily quite with just a cohort itself. Now, then we want to get qualitative. It's all about real people the other day. What are they trying to get done? You want to try again going back to understanding the problem space. There's a couple of tools here. Try if you have access to online recordings and full story or something like that where you can really see the person's behaviors, use it, see how they're using your site. Surveys and interviews are also really important to try to get at what is the hidden motive and understand what's going on here. In essence, you want to talk to real people, not just sit behind your desk unless the answer is already obvious or some bug or something. Now, you take your statement you wrote down, you take what we just learned from your qualitative deep dive research from a qualitative interview and reviewing, talking, and monitoring real user data. And you want to refine and rank your problem statements. What is really a customer's jobs to be done? What are they trying to get done? What is the problem statement? And going back and editing that. This might take a couple of rounds going back and forth. But the idea is you went from something rough to something a bit more refined as a process. And then ideally, you want to find a group of people who can kind of talk about what you're finding as a problem statement. In my experience, what I always try to do in my startup is have a beta group of early adopters who are not my family, we're not my friends, who I can bounce off these ideas and what I'm seeing off with. That helps me get some outside perspective of, am I basically building my own bubble of understanding? Or is my understanding resonating with what they're seeing and their intuition about the situation? The thing to watch out here is the easy yes. And that especially so if you're talking to friends and family. Because they want you to succeed. They want you to say yes. They want you to pursue this thing. And as good as an intention as that is, that is also dangerous. I had another example going back to a real estate startup. I had, I was able to sign up a lot of agents and they all expressed interest. They said things were going well for that thing we're building. And then it came time to sign a contract. You're saying you're interested, you're saying yes. Here's the contract. Let's sign it. Let's get your name on the dotted line. And boy, did I see a lot of new things come up when that happened. The difference between someone saying yes to actually committing to a yes, which potentially in that case you're pending money or some sort of obligation and if something's really on the line. Boy, those are different things. And you want to make sure when you're assessing the situation and you're talking and verifying the problem that they're not just saying yes, just for the sake of saying yes and being nice to you. But there's a real commitment here. Ideally they're paying money. Ideally they're product cost money and they're able to subscribe and say some definitive, some definitive resoluteness that they are actually truly understanding you're on the right track. Anything short of that, you do need to be a little suspicious and just be a little skeptical over the whole thing. And lastly, and this is going down to the make something people want, the making part, you've got to ship as much as you want to stay and analyze and understand the context of the problem. As important as all that is, you need to ship to get to that verification of are you shipping something to solve a real problem? Because for that easy yes, for that early data, there's a lot of room for misunderstanding. But when you're shipping something, you have something concrete to show someone and have real signups, real commitment going into it, that is how you can really start verifying. The thing you built, does it solve the intended problem? Does it solve anything? Does it solve some other problem you're not even aware of? What is it like? Are you on the right track? And that is really a great final way of measuring feedback and getting an assessment of here's my problem understanding, here's my solution. I shipped the solution. Did it solve what I thought it solved? Which really is not. Is it the problem solution or both? So we have spent all the time thinking about the problem. You started off, you wrote something down, then you thought about it some more, got more context, qualitative, quantitative. You thought about the customer's outcome in mind. You shipped it. What happened? Are you on the right track? So this is a short talk. I hope this was helpful. It's really just to reiterate, it's about saving you time to bank something which makes an impact. It's all too easy to build stuff for the sake of building things only to realize they don't solve a clear specific problem you can write down succinctly and that is backed up by data. Thank you. I will note final shout out. I'm hiring two senior growth PMs at Upwork along with other roles. Reach out, ping me, apply to our site. And that is all. Thank you so much.