Qasar Younis has worked in product and engineering roles in both big companies and his own startups. Along with that, he spent 3 years at Y Combinator as partner and COO. In this session we’ll dive into what it really means to make something people want and why that’s easier said than done.
← All talks 
Build Product Turing Fest 2017
Prioritising Features and Talking to Users
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
My name is Kassar. It's pronounced Kasper without the p. If you ever **** it up, will hold it personally. No, I'm kidding. Almost everybody screws it up. Today we're gonna talk about product. I would say my bread and butter is product. In my heart of heart, I'm a product manager.
So I'm pretty excited to talk to you guys about it. A few seconds before I walked up, I thought, I hope that photo in the background is the right photo and it's not Dublin. I did a good Google search and it was right.
So let's talk about what we'll talk about. First of all, I will give you a little bit of my background so you have some context of the recommendations and the advice that I give. I'm gonna talk a little bit about product lessons from my startups.
I'm actually doing my third company now. I have three lessons. Then we'll talk about some of my work at Google and some of the things I learned there. Google is a very particular kind of way of practicing product and I'll talk a little bit about that.
And then two very, very everything is pretty tactical here. So it's really for PMs who are practicing as PMs. For everybody else, I'm sorry. We'll talk about how to talk to users. And then that's more for startups and then how to prioritize what to build.
And that's more for folks in organizations. Though both sections are pretty fairly applicable. And then lastly, getting better. Just kind of how to become a great product manager over time. With that being said, let's jump in. So my background. I originally started as an engineer.
My first actually PM role was in a non traditional, non software PM role for airbags. And then I became an engineer again because I was pretty terrible at it. And then I went and got an MBA. A lot of people poo poo on MBAs, especially in the Valley.
I had a phenomenal experience. I'm happy to try to convince you to do one. Especially, I went to Harvard, especially at Harvard I really learned a lot. And for a couple of years I did finance, which was terrible. I went back and started my second company in twenty ten.
That company was acquired by Google. And at Google, I started kind of as a mid grunt PM, level five. And when I left, I was a GPM. Our product was and if you're using Google Search or Google Maps, anytime you search for a business, our team touched some aspect of that infrastructure or any of those pixels.
So when you search for the conference center, see that one box on the side of Google. That's the kind of stuff I managed and all the infrastructure below it. I think at the time it was a half a billion daily users. So a lot of people using it.
About a dozen product managers, one hundred and twenty engineers. And that's where I really felt I got my PhD in product management. Google is a pretty intense place, specifically for PMs. Every company, Snapchat, Twitter, Uber, down the road, the PM role is slightly different.
Google views PMs as the CEOs of products. And therefore, you get the most kind of risk and reward in that role. I was recruited at YC at a phenomenal time. I was actually at YC for three years. I did fairly straightforward venture stuff, picking and advising startups.
Not relevant to the talk here, really a really, really great experience. At YC, I spent a lot of time. I think our group did one hundred and forty investments. If you have any investors in the audience, realize it's a huge number. Worked with a lot of startups and we talked a lot about what startups struggle with and some of that we'll talk about today.
And today I'm doing my third startup. Just started a few months ago. It's an autonomous vehicle space. You know, hopefully you'll hear about it in the future. So takeaways, I'm old as **** that every time I do these these slides, there's another box and I just I'm getting further and further from nineteen ninety nine.
Number two, it's been a lot of years. My views are very, very influenced by Google. So sometimes I talk to folks afterwards and they're working on they're building a shoe company or something like that. And the lessons that are not directly applicable. So that's why I want to say I'm really a software person.
And most of my views are influenced by software. Even though by trade, I'm actually a mechanical engineer. So product a couple of things that I want to make sure you guys understand, because this is the way I look at the Product is really three skill sets.
It's design, engineering, and marketing. If you're a PM, you should be world class in one of those three things. And I think if you're really, really great, maybe two of those things. I've rarely met any PMs who are really great at all three things.
I think to be great, great software engineer, a great designer, usually is not in the same person. This talk is for PMs and all of my viewpoints are just mine. So try to generalize to your own views, but remember everything I'm advising is based on my own experiences.
And I think sometimes people don't realize that. So what makes a great product? There's three things. It accomplishes a specific task elegantly. It returns more value than it takes. And you as the user feels the interaction is true without even conscious reasoning. And so Google Maps, if you're using the Maps app to get here, worked on that.
Obviously, I'm biased. I think it's a really fantastic product purely in the sense of it's actually a very complicated product but fairly intuitive. And we try to explicitly hit all of these things. But really all of this can be summarized in one word.
A good product is empathetic to the user. You as the lead, and I think great leaders in organizations, great product managers organizations hold true, something that I really hold true, which is I don't know what's going on. If you start looking at products and saying, well, I want to use it this way, it can really lead you paths to bizarre interactions.
And sometimes you as consumers might be using products and you think, why did they design that way? The product manager probably thought it was a fantastic interaction or the designer thought it was a fantastic interaction. And the reason that we get into these kind of weird interactions is almost pride in thinking that you actually understand what's going on.
And if you have the humbleness to recognize almost always your product is failing, you'll actually move towards a product that people actually want. So empathy is kind of the most important thing, I think, in making a great product. So let's talk about some of the product lessons from my startups.
The first startup that I did was a company called Kamesa, which was we ran for three years a consumer company. It ultimately went absolutely nowhere. And the biggest failure that we had in the company, and as I look back from two thousand and seven to twenty ten, is the product almost never changed.
And so the smaller the team is, whether in an organization or as a startup, momentum is everything. And what I mean by momentum, it's not by feeling busy. A lot of times people feel like I'm making progress because I'm very busy at work.
And that's just not true. So the best kind of proxy in the way you as independently can kind of see am I actually making progress is do your customers feel like the product is moving. And I'll have some harsh opinions here. And I don't mean to be too rude here, but there are products like Twitter, like Yelp that have not seen a lot of progress in the five, seven years when you look back.
And when you look at a product like Facebook, you can see Facebook changing almost in a quarterly basis. It changes enough to where it's moving forward but not so dramatically where it actually becomes a product that's difficult to use. And so when you're small, momentum is everything.
And so as a PM or as a founder, if you have to make a decision, I almost always favor towards actually making pushing and shipping rather than testing. And that doesn't sound completely kosher because I think a lot of times we'll get feedback that and I spend a bunch of the presentation talking about testing.
But it is absolutely true. You can almost see a successful company. I was just reading this Bloomberg article about Stripe. Some folks who are local here, I sit from Dublin, a couple of founders, Patrick and John. And I've known Stripe from when they were a very, very young company, when they were just a handful of people.
And the kind of startling difference between Stripe and every other payment company that I saw in that same vintage, twenty ten, twenty eleven, is Stripe moved very, very fast. And so when you're small, momentum is everything. And we never got that in our first company.
And I think it's a key reason we failed. And that's it, it's not deeper than that. I wish it was, I could give you guys some like deep insight into how to make a great company. But if at the end of the week, your product, your team hasn't shipped something forward, It's something that you should be very concerned about as the product manager.
And you should figure out how can I move and change my organization in a way that we're actually shipping something notable every single week? Number two, talking to users is lifeblood of the company. This goes back to empathy. I think it's shocking when you're in a company the size of Google and the resources of Google, how rarely actually users are talked to.
And this basically happens because you get busy dealing with the ******** of working in a company. Your manager and your employees and all the other crap promotions and all that other nonsense that happens. And you very easily forget you're actually building these products for a group of people who are out there.
And so it's almost universal. I really mean from Google all the way down to the smallest startup product managers do not talk enough to their users. One good rule of thumb I had for my PMs at Google was if you're not talking to a person, for us as business owners, every single week we are making some fundamental mistakes.
And a lot of times people talk about successful and unsuccessful products. And it really comes down to this very, very basic thing of saying, I don't know what is actually right or wrong, and going spend a lot of time in the field. And probably the third thing, which is something I've learned the most in YC and especially applying it to my third company, which it's not enough that people love your product.
That's such a common thing we talk about. It's on YC shirts, make something users want, make something people want. But we are now almost entering this more sophisticated phase of product development. I mean last night I was watching some of the commercials that are local here and one of the most striking things is how similar companies here locally are actually to the Valley.
And so what does that mean? That just means you as product leaders have to recognize that these basic things not everybody gets. Everybody gets that you should be talking to users. Some people are not executing it right, but everybody gets you should have a balanced team, etcetera.
So I think the next level now of sophistication that's really existing within startup land and existing companies, really in startup land is it's not enough that products are loved. You have to think about how are you going to monetize, more specifically, what we broadly called technology strategy.
Where do you have network effects? Where do have lock in? So each of these are related to each company. And it's pretty shocking that it's taken me ten years to learn three very, very simple lessons. But it's definitely true. I'm going to dive a little bit into talking users a bit later here.
Three product lessons from Google. As I said, Google is a very unique organization. One very, very important thing that I should mention is every product manager at Google previously had to be an engineer. I think that might now, in twenty seventeen, slightly be different.
But certainly in the era of twenty ten to twenty fourteen, that was not the case. And so why that's important is you'll see a lot of products in Google are built in a very weird way, in a way infrastructure is built actually before the products.
And that's both good and bad. But it's important because I think it changes the way the products are built. With that being said, it kind of highlights the first thing, which is understand the mindset of your organization. A lot of times PMs look at their company or they read kind of generic blogs and they try to apply those lessons.
Or they come to a talk and they apply these lessons. This is actually really, really bad. If there's one thing I can tell you, if you're within your company, figure out what the senior leadership or what the founder or the CEO expects the PM to do.
Sometimes PMs are required to be project managers, But the CEO really doesn't understand the difference between a product manager and a project manager. And it is your job to actually fulfill the role that the company needs. Like I said, at Google, there was this view that the PM is the CEO.
And I found myself that transition was easier from being a startup CEO to being a Google PM. But recognize that in each company, that's going to be slightly different. And also that extends to how do you work with design? How do you work with engineering?
At Google, really the one two punch was PM an inch. And as ugly as it was, almost everything was secondary and treated secondary. That includes marketing, sales, people ops, etcetera. That's both good and bad. It's good because I think Google has really strong products, but it's bad because Google in some ways is a one dimensional company.
Number two, how you prioritize what to build is critical. In an organization, this is kind of one of the key debates, is almost everybody has a different view on what to do next. And we'll talk a little bit about this in detail. I just have even more tactical ways to how to actually solve these problems.
But at Google, that ultimately came down to the PM. My tactical recommendation to you would be if you're a PM or working in an organization, you're not the CEO, to sit down with the organization leadership and push for a view which says the PM should be the CEO.
The worst kind of organization I've seen in startups is you have multi headed PM organization. You have the designer fighting with a product manager, fighting with engineering, and it creates a real, real significant mess. One of the reasons you see real clarity in Google products and it's not always the case.
But if you look at maps, if you look at search, it's because you have one person who's ultimately responsible. And they are the ones who are prioritizing what to build. And that teeth mashing happens within the organization and doesn't manifest itself in the actual product.
Lastly, I think a lot of PMs don't really understand this balance of shifting from product to shifting to a manager. The larger your organization becomes recognizing now the product decisions have to be pushed down to the actual PMs. And as I said, I had a dozen PMs on my team.
And near the end of my career at Google, I really was just managing people. And sometimes you really see these gear shifts kind of being missed, where an individual contributor of PM is very good. But when they become a PM leader, it becomes a real problem in the company.
And so these are kind of the three biggest, I would say, mistakes we consistently saw. And we'll talk again about how to prioritize what to build. Okay, let's talk about how to talk to users. We're going to get even more tactical than we have been so far.
So number one, there's three types of feedbacks as a now this is both with being a founder or being a PM within a company, but this is more for founders. It's unstructured feedback, it's structured feedback, and recurring feedback. And this roughly can be mapped to new companies to maturing companies or new products to maturing products.
And we're just going to walk through each of these and how to do each of these effectively. Fairly boring stuff, but this is where good founders and good PMs, and I don't mean just okay, I'm really talking about the best in the world, Really do each of these really, really well.
And are very conscious about each of them. And so when you think about your product or your company, explicitly when you're getting feedback, they should fall into these individual buckets so you understand the pros and cons of each of these methodologies. So when you're talking about unstructured feedback, what we're really talking about is feedback that can be interpreted subjectively.
So I'm building an autonomous vehicle infrastructure company right now. I'm going to customers like Toyota and Honda and General Motors. And we're asking, what are the things you need in order to pick up the pace in development. That is a very open ended question.
And so examples of this is founding team experience. I was an automotive engineer for seven years, so was my co founder. That becomes absolutely critical here. So sometimes you'll hear investors say that the best CEOs or the best PMs are folks who've actually done it before.
What they're really talking about is they've kind of intuitively built unstructured feedback into the product. User interviews, fairly straightforward. I'll talk about that. And then open ended survey questions, so Wufu forms, Google surveys. The best kind of strategic tips that I or the best ways that I've actually done this myself is we actually document specifically the assumptions that we have going into a product build.
The Craigslist example is I'll call it CL here. But Craigslist example is good. It's fairly common now for early stage companies in Silicon Valley. But I'd use it here. If you have a blank sheet of paper and you're trying to figure out what to build, the best thing you can do is go on Craigslist for thirty dollars to fifty dollars ask users to meet you and talk to them for fifteen or twenty minutes.
Don't tell them you're a founder. Tell them you're from a marketing agency and say, hey, I'm trying to build a blank. And the second version of that is once you have a landing page, you open the landing page and you show that person for ten seconds.
You have them look at the landing page and you close the laptop and you say, what do you think that company does? This level of very, very basic product iteration is almost required at the beginning of a company. When you get to places like Google, this kind of work almost doesn't happen, but it's still pretty critical.
And then of course, can use things like Google consumer surveys. If you don't know it, just Google it. You'll understand what I mean. Structured feedback is stuff that almost everyone overemphasizes. This is stuff like Analytics Mixpanel Optimizely. You just sign up for these things.
I'm a little skeptical that the answer is in Google Analytics. We would see this all the time in maps where data can sometimes lead you along a wrong ways. And when you have tons and tons of data, you have politics within the organization or within the company actually start driving product decisions by pointing at things in the data which actually might not be true.
And so my view on structured feedback and for the products we had is we really required hundreds of thousands, if not millions, of users before we started taking structured feedback seriously. And that's sometimes off putting because most startups will not have millions of users.
But I think it's really important because, again, it's just your brain rationalizing what you want to see within data. And then, of course, there's recurring feedback. Recurring feedback is feedback that measures lots of aspects of the business and the product. And the best example of this are CSAT Net Promoter Scores and things like Intercom.
You guys can Google all these things. How you do it, you sign up for these things. Homemade CSATs are kind of the best thing. CSAT is a customer satisfaction score. It's something like, for instance, this festival. As soon as this festival finishes, Brian should send every single person in this room a survey about every single talk and what works and what doesn't work.
This type of recurring feedback can also be quite misleading because these users are already now a part of your product. And so sometimes users who are already part of your product will actually not tell you the biggest holes that you have, which is understanding basics.
So we focused a lot on Google Maps on figuring out first user experience, even when we had five hundred million daily active users. And then when you really are getting to a product that's that large, you're really going, we're doing Indonesia user specific tests.
We're doing India user specific tests. Brazil user specific tests. And we find maps are being used different ways in different communities. So how to prioritize what to build. This is the heart of, I think, a lot of politics that happens in companies. It certainly happened at Google, which is why should we build what we're building?
Within organizations, there's lots of debate of what should be being built because consumers and users are telling you lots of different things. Conflicting. And of course, you have limited resources. No team, even a company like Google, does not have infinite resources. And so I have very specific points.
And we literally came up with these at Google of how to do this. Tactical steps on how to prioritize what to build. Number one, we had a clear product leader. We literally assigned one person in the company lead. And so there is a person at Google who's responsible for the iOS app.
And that person, he or she, will exactly make every decision. And that's really important because then we can track back to when things fail. Because people sometimes need to be held accountable, but also when things do really, really well. Actually Daniel Graf was a person who did this, who now runs product at Uber and follows a very similar methodology.
Number two, define the behavior that you want. In the last presentation, there was discussion about this. The smaller the increment, the better. So what we mean by define the user that you want is when you open the Google Maps app, what do you want people to do?
That sounds like a very simple question, but that is actually a very, very complex question when you have a half a billion people opening that app every single day. Build and test one assumption at a time. Difficult to do when you have three thousand engineers, dozens and dozens of product managers.
But the team always needs to know, this week we're knocking this out. And so we get back to that momentum. Every single week, large groups of people understand what are we trying to knock out. Number four, try to predict behavior. I think most PMs don't do this enough, which is before anything is launched, you should have a pre mortem.
And say, when we launch, we think this is what's going to happen. We expect our user actives to fall here. We expect this to be a problem. If you don't do that, you don't know why you're building and shipping some of And it kind of breaks apart the first three things that you've worked on.
And lastly, improve the organization. Improving the organization is improving yourself and improving the people you have on your team. I think, as you probably noticed from the talk, I have a fairly high standard of what I expect the PMs in my organization to do.
And improving themselves and improving the way that we're measuring and the way that we're building product is something that's pretty critical, especially when you're operating really within the best in the world. So the last kind of stuff that I'll talk about is getting better.
The first thing here is the things I've learned is everyone thinks they're a good product person. I've never met a PM who says, I'm notably terrible. I'd love to talk about how I can get better. Almost everyone feels that they're really good at one of those three circles design, engineering, the organization or the market.
And so to have some humbleness, to realize you probably don't know a lot of what you should probably still learn, it takes years and years for a lot of this stuff to become intuitive. And so recognize that. I think the best PMs are people who decide they're going be a PM at the beginning of their career and fifteen years later they're still practicing being a PM.
The same goes for the best engineers, the same goes for the best designers. PMing is kind of weird because you'll see people come in and out of marketing or design or some other organizations in a PM. But I would really highly encourage all of you not to do that.
It is its own skill. And be very, very careful who you take advice from. Generally speaking, would say stop reading ******** tech blogs. I think there's so much garbage out there. It's kind of like if all of us if I told everybody to stop eating McDonald's, no one would debate me.
But I feel like when I say stop reading these blogs, everyone's like, well, how do I stay up with the industry? Is no industry to stay up with. Do your damn job. You'll get better. And these lessons will be something that you'll learn from practicing the art, not actually just reading random **** that exists on the internet.
And you have to remember the **** that exists in the internet is just made for you to consume. It's not actually to make you better. And so it's really, really critical. I think it's critical that you are very, very careful on what content you absorb every single day.
And I've gotten to the point where I'm so suspicious of what I consume, I don't consume anything. I think Hacker News is probably the only thing I read in any set of consistency. And even then, I've stopped going to comments. I literally only look at the articles and keep it there.
So there are a couple of things I would read. There's only two things that I've found to be really, really good. They're very short posts. Ben Horowitz is good PM, bad PM. I've read that now probably one hundred times. Almost before every interview, I read that.
And then how to hire a product manager. Ken was a group product manager at Google. It's a fantastic post. Both these posts are probably now probably ten years old. It's kind of like a good advice for product managers is kind of like good music or good films, the older the better because it's kind of sifted through many, many years of garbage, may have been forgotten.
And lastly, ship, ship, ship. The more you can build, the more you can ship, the better you are. So that's it. That's my super tactical, practical advice on product management. Thank you.