Qasar is a founder and angel investor, and was formerly a product manager and a venture capitalist. Most recently, Qasar has been General Partner and Chief Operating Officer at Y Combinator.
Y Combinator is a premier early stage venture fund in Silicon Valley that has seed funded hundreds of companies including AirBnB, Dropbox, Reddit, Twitch, Stripe, Heroku, Wufoo and many others. The aggregate value of Y Combinator seed funded companies now exceeds $80 billion.
Prior to joining Y Combinator, Qasar was the founder and CEO of TalkBin, (also funded by Y Combinator) which was acquired by Google. At Google, Qasar integrated his startup into Google Maps and went on to be Group Product Manager for business facing products. Prior to startups, Qasar was an automotive engineer at General Motors and Bosch. He has a BSc in Mechanical Engineering from Kettering University and a MBA from Harvard.
[00:00:01] My name is Qasar. It's pronounced 'Casper', without the 'p'. If you ever fuck it up, I will hold it personally... Nah, I'm kidding. Almost everybody screws it up. Today we're going to talk about product. I would say my bread and butter is product, in my heart of hearts I'm a product manager, so I'm pretty excited to talk to you guys about it.
[00:00:20] 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 going to talk a little 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 has a very particular kind of way of practicing product and I'll talk a little bit about that. And then two, very right, 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 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.
[00:01:26] 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 poopoo 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 2010. That company was acquired by Google, and at Google I started kind of as a mid-grunt PM level 5 and when I left I was a GPM. Our product was and is, 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 you know when you search for the conference center and you see that one box on the side of Google that's the kind of stuff I managed and all the infrastructure below. What I think is that at the time there was a half a billion daily users. So a lot of people using it; about a dozen product managers, 120 engineers. And that's where I really felt I got my Ph.D. 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.
[00:02:57] 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, and you know not relevant to the talk here, but a really really great experience. At YC I spent a lot of time, I think that our group did 140 investments. If we have any investors in the audience, you realize this is a huge number. I work 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 in the autonomous vehicle space, you know, hopefully you'll hear about in the future. So takeaways, I'm old as fuck. That every time I do these slides there's another box and I just get further and further from 1999...
[00:03:49] Number two. I've spent a lot of years... My views are very very influenced by Google. So you know sometimes I talk to folks afterwards, and you know they're working on building a shoe company or something like that and the lessons are not directly applicable, but 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.
[00:04:13] So product, and a couple of things that I want to make sure you guys understand because it's the way I look at the world, product is really three skill sets; there'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 a great software engineer and a great designer, it 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.
[00:04:54] 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, I worked on that, obviously I am biased. I think it's a really fantastic product, purely in the sense that it's actually a very complicated product but fairly intuitive and we tried 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 and great product managers in 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. Sometimes you as consumers might be using products and you think, well why did they design it that way? The product manager probably thought it was a fantastic interaction, or the designers 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.
[00:06:25] So, let's talk about some of the product lessons from my startups. The first startup that I did was a company called Camisa which 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 2007 to 2010, is the product almost never changed. And so the smaller the team is, whether you're in an organization or as a startup, momentum is everything. And what I mean by momentum, it's not by like 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 independently can kind of see "am I actually making progress?", is do your customers feel like the product is moving? And I have some harsh opinions here. 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 5-7 years when you look back and when you look at a product like Facebook you can see Facebook changing almost on a quarterly basis. It changes enough towards moving forward but not so dramatically where it actually becomes a product that's difficult to use.
[00:07:42] 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 and I've spent a bunch of this presentation talking about testing, but it is absolutely true. You can almost see a successful company, you know I was just reading a Bloomberg article about Stripe, you know some folks who are local here from Dublin, a couple of founders; Patrick and John. And I've known Stripe from when they were very very young company, when they are 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 2010, 2011, 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 it move and change my organization in a way that we're actually shipping something notable every single week.
[00:09:03] Number two; talking to users is the 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 bullshit 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.
[00:09:41] One good rule of thumb I had from 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 as I'm 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 now I'm applying into my third company; it's not enough that people love your product. That's such a common thing we talk about, you know it's on YC's shirts "make something users want, make something people want". But we are now almost entering this more sophisticated phase of product development, and 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.
[00:10:40] So what does that mean? That just means you as product leaders have to recognize that these basic things not everybody gets. Everybody gets they should be talking to users. Some people are not executing it right but everybody gets you should have a, you know, a balanced team, et cetera. So I think the next level now of sophistication that's really existing within startup land and existing companies, but really in startup land, is it's not enough the products are loved. You have to think about how are you going to monetize it and more specifically what we broadly called technology strategy. Where do you have network effects, where do you have lock-in. So each of these are related to each company and it's pretty shocking that it's taken me 10 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. Through 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 2017 slightly be different, but certainly in the era of 2010 to 2014 that was not the case. And so, why that's important is you'll see a lot of products in Google are kind of built in a very weird way in where 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.
[00:12:05] With that being said, it kind of highlights the first thing which is; understand the mindset of your organization. Alot of times PMs look at their company, or they read kind of generic blogs, and they try to apply those lessons, or they like 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 be being a Google PM, but recognize that in each company that's going to be slightly different and also that you know that extends to "How do you work with design? How do you work with engineering?". At Google really the one-two punch was PM and Eng and as ugly as it was, almost everything was secondary and treated secondary. That includes marketing, sales, you know people, ops, et cetera. That's both good and bad, it's good because I think Google has really strong products, but it was bad because Google in some ways is a one-dimensional company.
[00:13:23] 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, and 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, and working in organization, and not the CEO, to sit down with the product lead, 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 multiheaded PM organizations. You have the designer fighting with a product manager, fighting with engineering, and it creates a real you know 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, is because you have one person who is 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 Google I really was just managing people. And sometimes you really see these gearshifts kind of being missed, where an individual contributor of a 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. We'll talk again about how to prioritize what to build.
[00:15:09] 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, 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, structured feedback, and recurring feedback, and this roughly can be mapped to new companies to mature and to 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 you know pick up the pace and 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 and that becomes absolutely critical here.
[00:16:29] 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 are fairly straightforward. I'll talk about that and then open-ended survey questions, so Wufoo forms, Google surveys. The best kind of strategic tips that are 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, it's just called 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 30 to 50 bucks, ask users to meet you and talk to them for 15 to 20 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 actually open the landing page and you show that person for 10 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 like 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, you can use things like Google consumer surveys, if you don't know it just google it, you'll understand what I mean.
[00:17:56] Structured feedback is stuff that almost everyone overemphasizes. This is stuff like Analytics, Mixed Panel, 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 the data can sometimes lead you along the 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 is not, you know 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.
[00:18:51] And then of course there's recurring feedback. Recurring feedback is feedback that we can measure 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 is 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.
[00:19:24] This type of recurring feedback can also be quite misleading, because these users have already now a part of your product and so sometimes users who are a 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 500 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.
[00:19:59] So, how to prioritize what to build? This is the heart of I think of 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. It's 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, you know, track back to when things fail because people sometimes need to be held accountable but also when things do really really well. Actually Daniel Graff was a person who did this, who now runs product at Uber, and follows a very similar methodology.
[00:21:07] Number two; define the behavior that you want. In the last presentation there was a discussion about 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 3000 engineers and 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.
[00:21:49] Number four; try to predict behavior. I think the most PMs don't do this enough, which is: before anything is launched, you should have a premortem and say, "when we launch, we this 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 something, and it kind of breaks apart the first three things you've been working on.
[00:21:55] And lastly, improve the organisation. Improving the organisation is improving yourself and improving the people you have on your team. I think, as you've probably noticed from the talk, I have a fairly high standard of what I expect the PMs in my organisation to do, and improving themselves and improving the way that we're measuring and the way that we're building product is pretty critical, especially when you're operating kind of 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, of 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, or the organisation or the market — and so to have some humbleness, to realise 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 the people who decide they’re going to 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. PM’ing is kind of weird, because you’ll see people come in and out of marketing or design or some other organisations into PM, but I would really highly encourage all of you not to do that. It is its own skill.
And be very careful who you take advice from. Generally speaking, I would say, stop reading the bullshit tech blogs. I think there’s so much garbage out there. It’s kind of like, if I told everyone 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?” There 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 shit that exists on the internet. And you have to remember, the shit that exists on the internet is just made for you to consume, it’s not actually to make you better. And so it’s really, really critical that you’re very, very careful on what content you absorb every single day. 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 in any sort of consistency, and even then, I’ve stopped going to comments — I literally only look at the articles and keep it there.
There are a couple of things I would read: there’s only two things I’ve found to be really, really good. They’re very short posts: Ben Horowitz’s ‘Good PM, Bad PM’, I’ve read that now probably a 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 10 years old… it’s kind of like, you know, 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 which has now 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.