Transcribe your podcast

Without any further delay, I'll introduce to you Michael Cybele, the CEO of Y Combinator, the founder of companies like Justin TV and Twitch and Social cam- to begin what is going to be a deep dive into product over the next several lectures. Michael.


So before we begin, it's kind of had a conversation with Jeff and I. And I wanted to say a couple of things, but my experience at Justin TV and. And twitch. So what I will say is that we broke many, if not all of the rules that I'm about to tell you at various points during our company. The things that allowed us to survive were, one, our founding team was extremely technical. Justin Emmit and Kyle all.


We're amazing to work with. And basically what I found amazing about them is they were not intimidated by any technical challenge. I think that I would not be standing here if I wasn't privileged to work with them. And so I think this is something that a lot of companies, a lot of startups, a lot of sort of founders don't truly understand. That fact allowed us to break a lot of rules. The second is we didn't spend a lot of money.


We moved out when we were twenty one, twenty two, twenty two and twenty three. We lived in a two bedroom apartment. That apartment cost twenty five hundred dollars a month. We were each given five hundred dollars a month walking around money, which technically is against the law because it was below minimum wage. But who cares about laws? And that was it. That that was the game. Emmitt got his own bedroom. Kyle and Justin slept in bunk beds.


I slept in the living room and sometimes on the balcony. We just didn't spend much money. That gave us a lot of ability to screw up and make mistakes. And this is the last thing that was kind of interesting I only realized later is that our ego was highly tied to our startup. We were not doing a startup to have a cool resume item. It was really the only thing we had done on our own. And so I think at various points during the company, when it looked like we would fail, basically our sort of failing was our life failing.


Right. I was like, well, this is the only thing you've done so far. And so if it fails, you get F on life. And I think that we all had that feeling very internally and therefore we just couldn't really conceive of giving up. So I think more than anything I want to say and the rest is presentation. Those were the three things that saved our company, made our company work. And strangely, I don't even think if you take one of those things away, any one of them, we would have died.


So this isn't one of those things where it's like, oh, you can grab for one or two. And that's pretty good. We need it all three or else game over. So as I get into product, I'm going to tell stories from Justin TV from really early days, a twitch when I was still there. And then also from a y'see company from a couple of ago named Poppy. It's a company that I've advised since I've invested in.


Did y see great founder name ofany? And weirdly, I just feel like I needed to do a case study outside of my own story somehow. It's going to help share these lessons a little better. So. I always like to start with what problem are you solving? Because when I'm pitched by founders, most often they just want to tell me what their idea is, what they're gonna do, what their product does. I think what's interesting is that like.


Oftentimes, they don't even know why, they don't know what's the problem that they expect to be solved at the end of what they're doing. Now, I think that for some businesses, it's totally fine, right? I think that especially if you're early on, especially if things are still in project phase, whatever. But I think at some point pretty early on, you have to figure out. What are we doing? And what do we expect the result to be?


So adjusting TV is the first thing. The problem we were solving was entertainment. We're making TV shows. Justin was the first one to broadcast his life 24/7, as was to be a TV show. It's actually pretty easy for us to understand whether that was working or not. Is anyone watching? Right. That's the problem solving. People watch TV shows. No one was watching. So it didn't solve the problem. Then when we pivoted to an open platform, the problem became can we let anyone broadcast live?


That was Palmer trying to solve. Anyone can broadcast live on the Internet. And once again, once we understood that it was very easy for us to judge whether or not someone could do it. We had this open platform, is anyone using it? But I think that like that was key to what we were doing. And sometimes when I talk to founders, there's something they want to do in the world. There's a problem that they're kind of vaguely interested in or there's an idea they're vaguely interested in, but they really haven't nailed down.


What's the actual problem solving if you don't know the problem? You can't know whether you saw it. The first thing I ask counter is can you state the problem clearly in two sentences? If you can't. You don't know the problem, right? In fact, it surely won't take you one sentence. So if someone asks you a problem, you're solving and you find yourself delivering an essay. You're doing it wrong. To have you experienced the problem yourself.


This is not always required, but is certainly helpful. I've met a lot of founders who are trying to solve a problem for someone else who they've never met, never talked to, and don't truly know whether that person exists in the world. And so all things being equal, this is a great hint that you're onto something. Well, at least one person has had this problem for.


The next one is can you define this problem narrowly? What's interesting is when you get started, you can't really solve this problem for everyone who has it. So when Justin TV first started, we couldn't let anyone broadcast live video. You had to have a laptop, you had to have good Internet connection. You had to have a webcam. There are all these kind of things you needed. And so could we actually now talk about. All right. We want to make live video for everyone, but let's talk about the people that we can address first.


Who can we help first? And I think oftentimes founders kind of want to skip that step. They want to solve the mega problem, like I want to cure cancer. I'm only talking about when everyone's cured as opposed to like what can we address immediately? How do we get the first indication this thing is working? And then the last one is the problem solvable. So here's what I'll bring up with Poppy. So Poppy is a company that's essentially Uber for babysitting.


They make it really easy for babysitters. I'm sorry for parents who need babysitters to get babysitters.


Poverty is a very interesting company because you need babysitters for a lot of different types of things. Some people need a babysitter five days a week. One parents at work. Right. That looks a little more like a nanny. Some people need a babysitter, whether it's an emergency. Oh, I have you know, I have a medical emergency and I need a babysitter right now because I need to go to the hospital. Some people need it because there was mis planning.


Oh, I thought it was gonna be at this time. And it wasn't. I thought I was gonna be at this time. It wasn't. I need a babysitter. Some people need a babysitter because they have an infant. Right. And so this baby students have a bunch of skills. Suddenly a babysitter to watch their fifteen year old to make sure they don't get out of the house. Different skills. And so what's interesting is that. If you just start with, oh, we're gonna help people get babysitters.


It's not really good enough to understand what you can address right away, right? Which one of those use cases you want to address? If you were to state the problem more narrowly, though, let's say we wanted to start out with infants. Right. We want to make it easy for parents to get babysitters for infants. Then we can really ask the question, is the problem solvable? I think one of the things that Poppy discovered when operating their business is that the level of skill that you need for a parent to trust you with their infant when they haven't met you is very, very high.


So the idea that you're going to have a rotating set of people you haven't met. Watch your little baby heart very, very hard. They have to be very skilled. And then on the flip side, the Uber model only works because there's a whole bunch of basically replaceable people with a common skill. Well, it turns out the people who've got the skills to watch infants and make parents comfortable with that tend to have nanny jobs where they work lots of hours and tend to be paid fairly well, especially in up-and-coming cities.


And so now we have this disconnect where it's like, well, we want to solve the problem of infant watching for four moms. But that talent pool, who can solve the problem, the supply of baby sitters. They might not exist. Problem might not be solvable. And so going through this exercise in real time, like with your products out in the world, you should be thinking about these things. You should be thinking how I narrowly defined the problem when itself first.


And you should be always asking yourself, is it actually solvable? I think a lot of founders just don't want to think about this because it's hard it's hard to think about who you want to talk to first. That's hard to understand. Oh, maybe I can't solve their problem. I have to move on. Abney was a mother of two kids and she was really pissed she couldn't solve this problem because it was her problem. But it's turned out to be very, very hard problem to solve.


You know, Young Infants On-Demand baby sitters. All right, the next question I always ask is who is your customer? And really, you don't understand the problem you're solving until you understand who you're solving it for. A lot of times people just want to say everyone, everyone's the customer. Right. And that seems like it makes sense in some cases, right, if you're building a social network or a search engine. Right. Everyone uses those things.


Now, what I will say is that in almost all of the products that everyone uses now, there was a time when almost no one used them. And the creators of those products had to figure out who is the ideal first customer. And so if you don't have a good answer to this question, you're gonna be lost. You have no idea who you should talk to, to ask them whether this problem has been solved and you have no idea who to talk to to figure out who this product is for.


And you'd be surprised the number of founders who are just building something as if they were writing a creative novel where it's just a product of their own brain and no interaction with anyone on the outside and inside of a problem that they're solved, that they've experienced themselves. Don't do that. Don't be one of those founders like you can talk to your users. You just have figure who they are. The next question I often ask is how often does your user have the problem?


What's so surprising is when you talk through startups with people, sometimes they choose problems without quite understanding who the user is or the frequency of the problem. So give me an example. A lot of people will come to Y, C and a popular idea back in the day was to build a car shopping Web site. Now, if you guys have been on car shopping websites, especially about five years ago, they all basically suck. They're they're hard to use.


They're not very transparent. You kind of want to have this almost Tesla experience of just buying a car, but they never actually work out that way. And what's interesting is that like a lot of founders come back to this problem over and over and over again and they always think that their customer is the person buying a car. Now, the reality is, is that when you go buy a car, assuming it's not a complete lemon, you typically keep that car for seven years.


So what happens if I told you I'm gonna create a startup and if I home-run with my customer, if my fucking customer loves me, they're gonna come back seven years from now. That's hard. It's very hard. It turns out a lot of the car buying Web sites are not built for the person who's shopping for car. Because that person doesn't have a problem very often, they're actually built for the person who's selling a car. That person has a problem every day, every day the dealership has to hit their numbers, and so you don't see as a customer how that product helps the real customer.


The person is trying to sell cars. And so by doing this analysis, I really try to push founders and understanding who is getting the most value out of this product. And it's really helpful if you're trying to help someone with a problem they have frequently. If you think about the products that you use on a daily basis, they tend to be on the front screen of your phone. You tend to use them without even thinking. They become almost extensions of you.


If you think about apps that you've installed and then they're kind of on the third page in the back or they're buried on the second page is some folder. Those tend to be the ones you don't use very often. Hopefully they don't need you to use them very often or else they're probably not very good businesses.


The next question I always ask is how intense is the problem? I find a lot of founders think they have a good idea, but they don't do this frequency and intensity analysis. And so if you have both an infrequent and low intensity problem that you're trying to solve. You're gonna have a problem getting a lot of customers even interested in talking to you. All things Mieko, a few grauwe problems. It's nicer for them to be higher intensity, higher frequency.


Let's think about a company like Uber, for example. Usually when you are somewhere and you need to go somewhere else, it's a pretty intense problem. I have to go to work. I have to go to the doctor. I have to go pick up my kids. They're so intense. You might have bought like a twenty thousand dollar car to help you do those things. Right. So it's an intense problem. And then when you think about frequency, how often do you move more than a mile more than walking distance every day?


Happens a lot. And so if you think about that, even though you look at the taxi market and you say, oh, taxes in before Uber taxis, that's not that big of a market. If you just look at the customer, you say high intensity problem that happens very often. There's probably good business here. The last one is, are they willing to pay so many founders who come into y'see, their first thought is completely wrong on this front.


Their first thought is I to give it away for free because that's the only way I'm going to get users. One of the things that I always push them to do is think about it this way. If you want to know whether you have a good product, it's a lot easier to make it a little bit harder for your users to use it and then see if they use it anyways. Because if I am extremely intense problem and you say, well, it's gonna cost 100 bucks.


For the person with extremely intense problem, their mom, I think that's a deal. If you have extremely and if you don't have extremely tense product problem, you charge $0, you need a bunch of users who come in who don't really have the problem, but they're just trying something out. If you try to learn from them on how to improve your product, oftentimes they lead you astray. So strangely, starting with a higher price or a price is almost always better than starting free.


Almost always better. And if you have to start free, you need to do this analysis of how do you talk to the users where the problem is actually intense? I talk to the users who are using your product frequently in production for real-world purposes as opposed to the hobbyists. Talking your customers is good at talking to the wrong customers. Very, very, very bad. I've seen a lot of companies that are basically hijacked by bad customers, especially companies where there's real world costs.


So, for example, you know, if you have a company like Poppi, there's real world costs in recruiting, managing and working with all of these. Baby-Sitters And if you have a company, if you have customers trying to basically take advantage of that system being laid, being non-responsive, being rude to the babysitters, that's not going to help you run your business. And you'd be surprised at how many highjack customers there are out there. The last question I always ask people is how easy is it for your customers to find?


Because inevitably you're gonna need to reach them. And what's interesting, I look at the last batch there to be to be companies. One B2B company was here in America and it was very easy for them to find customers that could basically go to Linked-In, find the customers unlinked in Finding Nemo addresses, email them any more, a thousand customers a week. Another company doing B2B was in China. And interestingly enough. Reaching out over email in a B2B context in China just isn't a well done practice, getting access to people's e-mail addresses is actually not very hard.


Not very easy. And so strangely, they had this challenge of a relatively simple business to explain a real intense problem that happened often if they had no way to reach their customers and had to basically invent new ways to do it. And so I often want to ask this question, because if your customers are ridiculously hard to find, you better have a solution for that upfront. You can't build the whole thing and expect for them to find you. And so oftentimes you have a situation where someone's trying to build a product for either an imaginary customer or a customer who can't really hope to use the product.


I'm trying to get water to people in the middle of a desert in the Sahara. All they need to do is download my app and go online and then they can put their G.P.S. location and then we'll deliver water to them. That's not going to work. But you'd be surprised at how many people just don't think through those logical steps. All right. Next up, does your MVP actually solve the problem that you want to solve? This one is so hilarious how often it comes up because in the process of building an MVP, things just go weird and squirrelly.


So you have this problem and then you start building it and then you talk to other users and then before long you're launching something and then you realize that doesn't actually do the thing that you promise or even the thing that you want to do. So part of your process of building the MVP. It's really helpful to do these precepts first. It's really, really, really helpful because then you can always gut check yourself on. Am I actually solving the problem?


The other thing is that it's really helpful to build your MVP quickly. Typically, the longer it takes, the more you're gonna have MVP and problem drift or customer drift. If you decide to only build your MVP in two weeks, it's a lot easier to stay on task and make sure actually solving that problem for that customer. The way you test this, by the way, is you give your product to customers. Like you have to do that.


That is a required step. What I find interesting is that a lot of people think of their product as a painting, as something that could be appreciated as a piece of art, as something that, even if it's appreciated by one person, is special. That's not what you're making. Products are not paintings. They're not art. If users don't find products useful, then the products are by definition not useful and they're a waste of your time to build.


And I think a lot of people want to be artists. Startup world is very unforgiving to artists, and I think that interestingly, after the fact, a lot of people are painted as artists, right. Like Steve Jobs is painted as this like magical artist. Right. The other day, he had to figure out how to make a phone that millions of people would buy. If only one person bought the iPhone, he would be seen as a failure.


So the definition of art is it only has to be appreciated by one or maybe even none. That's not the appreciate. Maybe just the creator. That's not the definition of successful product. So this is what you should always be checking those every saw the problem. The number one problem with this question is that it hurts. The answer hurts. You can find that a lot in startups where the answer hurts, you know, doesn't solve the problem. But as long as we don't talk about it, maybe nobody knows.


It doesn't solve the problem. A lot of the answers inside of startups are a feel that way. Which customers should you go after first? A lot of founders are very confused by this question.


What I find interesting is just like the instinct is to go after customers by making the product free. For some reason, I find a lot of people think that their instincts should be to go after the hardest customers first, almost as if it's like a proof. Like if I can get this impossible person to use something, then like it'll be easier. I know that I've made something good. I'd like to start from a different point. It's an MVP.


You know, you've made something bad like that's the definition of. It's bad. So the real question is like, how do you find people who are willing to use a bad product?


Right. There have to be the most desperate, the most desperate. And so a lot of times I talk to founders, I really push them towards. Who are the most desperate customers and how do you talk to them first? That's what I define as easy. Desperate. If you're having like a you know, if you're trying to sell a simple piece of software to someone thousand dollars a month and you're engaged in a six month conversation with a company that's not a desperate company, move on.


In fact, when you're doing enterprise sales early as a startup, like you're looking for even more desperate customers just because literally takes so long to sell them. So if you don't feel like you're dealing with desperate people, if you feel like you've dealt you are trying to get impressive customers who aren't desperate, you're probably doing it wrong. Literally, the number one thing I often tell founders, just like whose business is going to go out of business without using you?


Which people out there are not going to be able to get to work or to watch their kids? How do you find the people who are just literally are screaming for something like this? And then how do you talk to them and not talk to your friends? Had a whole bunch of friends who were using social cam-, right? My company was doing video for for sharing with friends. And they weren't really using it. They were using it because it was like my app and they were friends with me.


I would only add one friend. It was like super on us about this Steve. Sea of red it. When we sold Socialcam, he literally said, Thank God. Now I can delete this app from my phone.


So the perfect definition of someone you should not be trying to get product feedback from. Right. And so he didn't have the problem we were solving. Many of your friends won't have the problem that you're solving. Make sure you find the. And by the way, the kind of community of startup people and or investors usually don't have the problem that you're solving. So if you're using investors as a as a trigger for am I solving the right problem? Or like, do do they find this useful?


It's almost never the case. I'm almost never the user of a product that comes into yrc. And so ignore your investors, ignore your friends like they will lead you 100 percent astray out of good intentions. They'll try to be helpful. Well, I you know, I've never lived in the Sahara. I've never been thirsty. But maybe it should work like this. Right. Horrible. Runaway. Runaway. Once you start having customers, I think it's a very helpful exercise to try early to identify bad customers.


These are people who are blasting your support. These are people who are constantly, constantly complaining. My co-founder, Justin, he had a company that was basically on demand, personal assistant. And he was the first one who I met who actively fired a customer is basically Uber for personal Pursell systems called exac and literally a customer would have the exact do something like like crazy, like something you couldn't do. I like we organize my house the way I want things organized.


And I'm I can tell you I want them organized or go shopping for me. But I'm going to critique every single like piece of fruit and vegetable that you picked out. Is it completely unrealistic aspirations? And so after refunding the person four times for four different tasks. The person did a fifth task on the product, right? Because he's getting much of value for free. And Justin Kosmo says you're fired. You can't ever use product again. Like look for those people, because if you are delivering anything of value, there will be people trying to exploit that value and some might be doing it not out of the goodness of their heart.


So don't let these people lead you astray. We talked about this. Don't discount. Now, here's a caveat on discounting. Parker from Xenia Fitz came to y'see, a couple years ago and he gave this great talk about enterprise sales and Xenophon's his product that's given away for free. So it's actually kind of a interesting enterprise sell. And one of the things he said that really got to me was that there are ways to convince organizations, basically you can structure discounts and incentives into your sales pitch if you basically understand what value you're getting back.


So his example was he would try to sell to a company to switch on his own efforts for their health care.


And he would say, look, because of this third party, let's just say E.W. us has given us a discount. Who knows why, right? We just bought dedicate instances. So now we have 40 percent lower A.W. US bills so we can actually pass on some benefit to you, but only for the next 30 days. Now, I feel horrible even telling you this because I want you to take as much time as you need to buy my product.


I would just hate if you bought it on the thirty first day and I couldn't give you this discount. Now this isn't a let me give this away for free. Like because I'm afraid people will use it. This is a very structured process that he did. He basically incorporated a deadline based on some third party providing a benefit to the customer. And he knew that when he said this to the customer. Every time that this was talked about internally, the deadline would be brought up and the discount would be brought up.


And suddenly this is now become not a way to be afraid. Right. Too much of your customers vendors make it free come a way to speed up the process. And his discount was just baked in like he just price the product 50 percent higher. So it's like literally like. That is the way to do it, the way not to do it is I'm afraid no one's going to use it. So I have to talk, not charge any money.


OK, the next is how to set up metrics. How many of you are using Google Analytics as your primary metrics products? Raise your hands. OK, you are doing it wrong. Yes. So. Setting a metrics is something that's like super important very early in your company because it's how you know whether your product is being used or not, and it's one of the number one sources of new product ideas and inspiration. So Google Analytics, I would say, is a great product for knowing how many people came to your website today and how many pages they viewed which used to be relevant.


And it's not really relevant anymore. And where they came from, what it's not a great part for is identifying what people's actions were when they were using your product. Did they click this button? Did they see this screen? How long were they on the page for before they did something else? Did they leave something in their cart for all of those things you want and events based metrics, product mix panel amplitude heap. I think we've funded like 50 of them.


They're like 100 of them out there. You should be using one of them. If you're not, you can't be sophisticated at building your product. Is just kind of a prerequisite. So get on it. And this goes back to the early thing that I mentioned, which is technical teams for a technical team implementing mix panel is ridiculously easy for non typical team. It's basically impossible. This is just one of the many advantages of having a highly technical team.


You actually know what users are doing without this. You're just missing a huge part of what you need to know the next thing. And Sue Suhail from X panel gave a great talk about how do you set up mics, panel? One of the challenges of setting up a mixed panel is the second that you're sitting there saying, I want to track what my users are doing. You can come up with like 150 things users can do with your product and you can track all of them.


That's often a mistake. If your analytics product is got too many analytics in it in the beginning, it will be hard to use. And part of what you're doing if you've never used product like Misspend before, is learning how to use it. And most importantly, teaching your employees and your co-founders how to use it. Because this product should be a product that everyone in your company understands how to use. Everyone your company should understand how the product is functioning.


This is not something that like the CTO uses and creates reports from. This is interactive product that everyone can use. So to start pick five to 10 simple stats. Let's take Instagram as an example. Right. If I were to pick 5 to 10 simple stats for Instagram, let's say open the app trading and account, took a photo, applied any effects, share the photo. That's probably all I need in the beginning. Right. I mean, the number one mechanism for Instagram is taking a photo and sharing it.


I can track that. I'm pretty happy. The other thing that I will warn you about is that if your product is good, the naming conventions for these stats are going to become very important because one day there will be 100 or even a thousand stats you track. So think a little bit ahead of time and don't name something, something that only you'll understand. Make sure that you if your company is good. Many, many people have to look at these stats, make measurement a part of your product spec.


Oftentimes when I talk to founders, they say we built it on this release and we'll add the measurements some point the future. I don't understand how that works. You build something you want people to use, but you're not incorporating the measurement that tells you whether people are using it. That doesn't work. Building measurement is part of a product spec. So when you spec out a product, you better spec the stats you expect to be tracking and you should also spec the stats that you think are going to improve.


When you're building that product, that should be part of the spec. It should be part of the first release. Otherwise, you're flying blind. This is just countless times it just on TV. This is screwed us OK. Part of element cycle. So Justin, TV was Twitch was three Yale kids and one of my ticket at Yale. Probably the most productive skill you're taught is how to argue with other Yale kids. And so the number one way to get products developed at Justin TV was to win an argument with the three Yankees.


Kyle disliked this so much that he actually switched his sleeping schedule so that he wouldn't have to involved in these arguments. So we were awake from about 8 a.m. to about 12:00 midnight. He would wake up around 11:00 midnight and write code all night and then go to sleep in the morning. So he wouldn't have to argue with us on what stupid thing they built. One of the classic arguments suggest in TV that lasted approximately three months was the background color for the original sites.


The original site is just one page. Justin wanted a black background. I wanted a wood grained background. Three months debate, we settled on changeable backgrounds, so there were five background options, clearly idiotic. Like I said, we made many of these mistakes. We didn't actually really learn how to do a product development cycle until we failed at it for about five or so years. And during that time, this is what bad product Volman cycle looks like, one we would release every three months for a web only product.


That is horrible. Second, we would have a product meeting and we wouldn't write anything down. Right. It was just four of us. Can't you remember you're an idiot if you can't remember a conversation four people had. Right. And if you forget something, just ask one of the other four people in the room. Right. No. So as a result, during the first month of the devil cycle, we'd all go off working on slightly different versions of the thing we wanted to build because we didn't write down the spec.


Then at the end of that month, we'd come together and we'd be like, Oh, wait. This isn't we're not really building all the same thing. And we have another product meeting where we didn't write anything down and go off and build again for another month. At this point, right, two months in, we probably have about three weeks of productivity and about five weeks of just stuff that's going to be thrown away. At this point in, we kind of come back together and realize that we're not two thirds of the way done through the sprint.


We're less than one third of the way done. And we're starting to get sick and tired of this feature that we're building. So then we basically say, all right, slash-and-burn, let's just make a shitty version of it and we take another month to do that. Now we've worked on this product for three months. If you had any good or new or interesting ideas during that three months at a time, you were told we're already working on something else.


So your ideas are worthless. Just write down somewhere. Whatever. We're working on this thing right now. At the end of the three months, instead of wanting to iterate, we were sick of the dot damn feature. We just spent three months building poorly so we would launch it. And if it wasn't used right away, we would come up with some new brainstorm on some brand new feature that would rescue the company. This is the wrong way to run a company.


It was absolutely horrible. Second to Jeff earlier, the major product decisions that Justin TV made that carried through to Twitch today was chat on the right, video on the left. We decided that in 2006 it is the same way 2018. The vast majority of the party decisions we made were horrible and never saw the light of day because they went through a process like this.


So if your process revolves around arguing, revolves around not writing spec, revolves around long dev cycles, you are doing it wrong. You are 100 percent doing it wrong. What I'm going to give you is a model of how we figured out how to solve the problem. Steal as much or as little of this as you want, but understand that if you have any of the symptoms I'm talking about, you need to solve them or else your company is just going to be much less productive than it could be.


First, you need to actually have a number that you track that reflects how good your company is doing. Almost always, if you ever are going to charge money to your customers, this number should be revenue. Almost always. If you are never going to charge your customers money like Facebook, then maybe it should be a usage based metric. Like half into your customers come back every day like d.a.'s. It is almost always one of those two usage.


If you will never charge the customers money, if you will charge your customers. Many people will invent reasons why these two metrics don't apply to their business. 1 percent of them might be right. 99 percent of them are probably wrong. Whatever this KPI goal is, make sure you're measuring it. Make sure that everyone in your company knows what this goal is every day. Helpful to put it on some screen somewhere. If an investor asks you what your KPI is, you're not all qrio to say what it is.


Show to say what the metric is. You say where the metric is now, where it was three months ago, where it was when you started. This is kind of table stakes. The next thing that we would do is as this kind of product person, I would come into the meeting and I would say this is the KPI we're looking to improve this this cycle at Socialcam, the top level KPI was the use and the three ways that we thought we contributed to d._a use was either new users retention of users and new content created those three things.


So every cycle we ran one of those three numbers moving that number so that the right direction was the goal and we'd want an open brainstorm. Brainstorm for us would take a couple hours and it was a real brainstorm. It wasn't a brainstorm where like you say, what about this? And your co-founder says, that's a dumb idea. That's not a brainstorm. Real brainstorm is that any idea that stated is written on the board. The cool thing about these brainstorms is that everyone's computers were always open to mixed panel.


So if you had an idea or you had a thought, you could always just go in and check the metrics and see like, oh, is that right or is not wrong. You'd be surprised at how much value there is and seeing your idea on the board. Not everyone is going to get to have built what they want to have built. But the fact that your idea was considered and added to the board actually makes people feel a lot better than otherwise.


People feel horrible when their ideas are shot down. CEOs. Their job is to make their employees not feel horrible all the time. Sometimes I think CEOs think their job is to shoot down ideas. It's not it's not gonna help you at all. And everyone, by the way, in our company participated in this brainstorm. At that point, that was for people so easy to do. The next thing was we did what's called easy, medium, hard.


So our brainstorm was actually typically split up into three categories, new features or iterations on existing ones, bug fixes and or other maintenance and tests, a/b tests. We want to run. We have a whole board filled out with ideas on these three categories. And then we go through and do what's called easy, medium, hard for us. Hard meant it would take one engineer most of the dev cycle to build medium. Typically Mannatech day two days easy means we could do multiple in a day.


This is extremely important. How many of you in this room do not know how to write code? Raise your hands. There we go. I am one of you. It's extremely hard if you don't know how to write code to figure out whether your idea is easy to build or hard to build. That's something that you actually learn as a skill over time. And this process basically is the process that can help educate you. It turns out that easy ideas get built way faster, way more quickly than hard ideas, and turns out that most hard ideas can be restated as an easy idea.


If you just understand what bits of your hard idea are both useless and hard, and most of the time there are useless and hard bits and hard ideas that can just be removed. And so for us, this was educating everyone. The team and for us made a cross-functional team. So someone might not realize that this is really hard in the video system, might be an easy web feature, but hard in the video system or vice versa. So this is basic educating everyone the team wants easy, medium, hard.


It also created an objective standard by which to start thinking about these ideas instead of just based on the arguments ability of the person delivering them. It was like, well, your idea is like really frickin hard and seems like it wouldn't move the numbers that much based on mixed panel. Whereas like this other person's idea is super easy and probably can move the numbers a lot. The next thing we would do is we decide hard first, so we'd look at all the horrors and you say which hard is going to impact the KPI the most?


And then we move to eases and then we move to then we've moved mediums and then we move to eases. What was interesting is that like just with the ideas on the board and with easy, medium, hard. A lot of the ego was removed from the debate because one, you knew your ideas being considered. And two, you'd set some objective measure about how hard it was. And three, because the board has a bunch of ideas on it.


Now, it's probably pretty easy for you to find an easy idea that you really like. And so you're just going to be excited that that's probably going to get in and you're really hard idea. That's fine if it doesn't. The next step is you have to write the spec. This is where everyone fucks up. The meeting might be going on for four hours now. And this is the step no one likes you actually go through and you actually write down, what do we mean by we're adding video filters to social calm?


What do we mean by were allowing people and Justin TV twitch to chat with one another? What does that actually mean? How is it gonna work? This is really important. And once this is done, you can then distribute tasks to the team. Now, we would run these cycles every two weeks at Socialcam because back then something to the app store took longer. If you're doing a pure web product, you can run these cycles once a week.


The rule that we had to make the team not hate these really long meetings. This was the only meeting we had. Does it only heating and so it might take two hours, it might take six. But for that two year period of time, there were no other meetings. In fact, for me, being a non coder, my number one job was to shut the fuck up. Because I could create a problem. Right. We're busy working, we have this re-inspect.


Everyone knows what they're doing. If I have some brilliant idea during that two weeks. Right, that'll throw the whole thing into chaos. Suddenly they're inspects. Not important. We're back to the drawing boards. We're changing things. Yada, yada, yada. What I had to realize is that every two weeks we do this over again. So that burning idea. Just fucking wait two weeks and we don't have the meeting. And then we can get it in.


And turns out you're burning ideas probably wrong. So it's totally fine the way two weeks to try to chemistry will do something wrong. Is totally fine. As opposed to like having this cadence met every two weeks. We had success every two weeks. If we built what we said we were gonna build, we felt good. And then that cadence meant that we'd go into the next cycle and do even more. This cadence is extremely important because it's going to take you guys a long time to find product market fit.


We've been trying a lot of things, iterating a lot, and if that process doesn't feel fun, you're gonna be very frustrated. This made the process feel fun because we had goals and we accomplish them. Period versus iterate. A lot of why C companies, a lot of founders in general will tell me. Our thing isn't working. It's been two months. It's time to pivot. When I think about that statement, it blows my mind. Right.


You're building a new product for a customer who might not have ever used a product before. You're oftentimes exploring a problem that you only know to some degree or you've only experience it personally. What makes you think two months is enough time to know whether you figured something out? What impressive thing only took two months to build. So if you're not thinking that the process of coming up with a solution to this problem is probably a lot more like a two year process, you're doing it wrong.


If you're unsatisfied with significant progress in under two years, you're probably doing it wrong. It's going to take time. You're doing something hard. If it was really easy, someone else would have done it. So. I define pivot as changing the customer or changing the problem. This should be rare, this should happen infrequently. Many times this means you should start a new company. I defined iterate. As changing the solution, it turns out you had the right customer, you had the right problem.


You're MVP was shitty and it didn't work. We need a new solution. It turns out maybe the MVP was great, but it didn't solve the problem. We a new solution. It turns out you showed the product to your customers and they don't want to use it, even though they have burning problems with a new solution. Oftentimes I see this in reverse. People think solution first and when cut the customers they thought didn't like their product. They try to find some other random customer who does.


He might even have a complete different problem and then try to shopping around their solution because they think their solution is the genius part. I think the problem is the genius part. I think identifying a problem that other people haven't figured out is worth working on is the genius part, right? Facebook wasn't first a social networking and Google wasn't first a search engines. Their genius was understanding that the people who came before them hadn't solved the problem, and if they could solve the problem better, they'd build huge companies.


Their genius wasn't, oh, we built this cool thing. Let's just figure out who might want to use it. Wrapping up a little bit here. I tell the story about fake Steve Jobs vs. real Steve Jobs. A lot of people think that Steve Jobs is this person they should emulate, but they have a false picture in their heads of when Steve Jobs was. They think that like he dreamed perfect ideas out of his head and into the world.


And what's funny is that I think oftentimes people look at the iPhone as a perfect example of this, but they look at their iPhone today. Your iPhone today is fucking magical. The first iPhone sucked in almost every way, and they don't realize that Steve Jobs wasn't somebody who was just not iterating, who just Imagineer perfection minute one. Steve Jobs was iterating at every step. So I like to remind people what the first iPhone did. First iPhone, no 3G back when 3G was a standard feature.


So you have this great Internet browser, but you can only use it on edge, which means it fucking sucks, right? One carrier. Oh, you don't have this carrier. Sorry. Switch carriers. Figure that out. Horrible battery life. Screen cracked all the time. No app store. You can't even download other apps. That was the first iPhone. Everyone forgets that iPhone. So if you are the person in your company who is being fake, Steve Jobs is saying the product has to be this way.


Because what I said, fuck the customers, fuck everyone else, fuck you. Make the product the way I want it to be. You're being fake. Steve Jobs. Real Steve Jobs released a shitty MVP that was revolutionary, but still fairly shitty and every year iterated it. Until you have a thing in your pocket right now, which is pretty damn good. Real Steve Jobs. Iterates and talks to customers fix Steve Jobs just dreams and creates art.


Don't be fixed. Jobs. OK. So with all of this, I want to go back to the beginning when I said the beginning still holds. Justin TV, the only reason my actually even know any of these rules is because we broke all of them. The one thing that Justin TV and Twitch had. Was a really strong technical team with high ego in the product and low burden. When we started figuring things out with Twitch, it was very interesting.


Gamers had been on our product the whole time. Gamers have been streaming on Justin TV since almost the beginning. At any given time, there were 20 percent of our traffic for years. We ignored them. We ignored them. We ignored them. We ignored them. Ignored them. They still use the product. We didn't build features for them. They still use the product. They must be been pretty fucking desperate because they still use the product. Year after year, the number one thing that changed when we started working on Twitch was we start talking to them.


And what's weird was it's not like we were talking to other users and they know it is us. We can talk to any users. We had this like crazy part Volman cycles. We couldn't do that with talking users too. So what we did in the beginning was we literally just sat down with these gamers and we said, what did you want? And what's funny is we didn't build them anything very special. They were like, oh, like L&G socks.


They wanted like little things. What was great about it was they realized we were now going to build something for them. And no one on the Internet was building things for these gamers, and they realized that when we said we're gonna build something. It came out. When was the last time that you talked to someone building a product that you like? And you said, can you do this? And they did. It was last time you suggested a feature to market Facebook.


And then the feature came out. Never like it's one of the magical things you can deliver as a startup is you can talk to a passionate user and then you can go to what they want and then you can say, here it is and they will fall in love with you, even if those features are relatively mundane. Because let's quit Twitch today, chat on the right, video on the left, the same product. What was great about this process was by talking to them, they realized that we were on their side lies.


They were building something for them, so they told their friends. That was the major change. If we didn't have a technical team, if we weren't sheep, if our ego wasn't involved, never would've gotten to that point. And if you look at the history of Justin TV in the first five years, it went from being worth nothing to being worth about twenty four million dollars. And the next three years weren't being worth twenty four million dollars to win with a billion.


That's what software can do when you when you hit the right customer.


So a couple questions in the back of your body.


So the question is, put it more generally. Should you be going free if your final idea for a product is to be free? What I would say is this if your users are users who you never plan to charge, then it's totally fine for you to be free. But if you do plan to charge them in some way, it's really helpful to charge them as soon as possible because you want to know whether or not they're willing to pay. And certainly if their business depends on it, it's especially helpful to charge them.


So that's the measure that I would use. And there are all kinds of little tweaks and so and so forth. But at a high level, do you ever plan to charge them? I charge them. If you never planned, charge them. You can plan them Monitise based on ads, which really is usually the way that you never plan charges. You amortize it. That's if you're not going to monetize with ads, you probably start charging them.


All right. Next question from sharehouse.


You mentioned that the almost always the best revenue are the best Kategaya. Right. Yeah. Let's say I watch that first. I know for you we hardly get to go to Europe. I'd still be riding revenue down or something.


Revenue. If you're metric if your KPI is metric, you do that. If you're KPI is revenue and the number is zero, should you still be tracking that as your top line KPI? The short answer is yes. You should be depressed looking at that number every week too. But that's that's the answer. Now, let's be clear. Like I said, with social camera. There are contributing numbers to that. Right. And so whereas like dieser use was our top line metric.


Right. We also the things we thought contribute to that new content, new users, retained users, those numbers we can move. So if you're in a sales type business, you're KPI number one revenue. If it's zero, that should fuck you in face. 0 0 0. Horrible. But then you should ask yourself, maybe your three other metrics are how many conversations did we have this week? How many people are in contracting? How people are in onboarding?


Right. And those can be your three numbers that will if those numbers move, you expect the revenue number to move and they can keep you motivated. But you're your top line KPI. No bullshit like absolute no bullshit.


You know, we're a hardware company. Prelaunch. And so our users are our target market experience or problem five to nine hundred times a day. And the intensity is can we pay our rent or not? But we'd like to offer pre-sales as a way of getting the product to market. Do you guys have any tips on doing that?


Do we have any tips on pre-sales where I would say is that there are many, many tips on pre-sales. I would email some founders who've done it before. That's what my best tip is to email them and ask them what they did. The number one s- mistake I see with pre-sales is discounting. The number one mistake is that basically especially hardware founders will miss understand how much they need to charge so they don't lose money and so their pre-sale becomes their death.


So I'd avoid that. All right. Two more quickly and we're back.


What was the hardest part of having a slow burn?


Well, we were young, so it wasn't hard at all. We were living like we lived in dorms. I think it's a lot harder now. Right. I've got a kid, I've got a wife, got an apartment, got a car. It be really hard now. And so I think really the hard part about slow burn is can you adjust your lifestyle if you've already leveled it up? And if you haven't leveled up your lifestyle yet and you're still working, you know, if you're young and just working at a company is paying you well, not leveling up your lifestyle is a big way to stay ready to do a startup.


Adding on the mortgages and the cars and the vacations makes it a lot harder. I just know a lot of people who never could come back from that. Absolutely. Never.


And that going from beta. How do you go from beta to early MVP? I don't really know what those distinctions are like. All I know is, are people using your product? Yes. No. Like if people are not using your product, get to the point where people are using your product extremely quickly. Once people are using your product, there's all different labels for it. Beta prelaunch, alpha bulbul. Who cares? Right. It's just that's the dividing line.


Like a people using it. The next question is, are you actually solving their problem? That's the next question. Not like are we following this line of launching things, most y'see, companies will launch many, many, many, many times. So that progression isn't really that important.


Are people using your product? Great. Bam, you're launched.


Congratulations. Call whatever you want. All right. One more.


Yeah, I was regarding this link Xpecial. You already mentioned it. I am sure that we should follow directions, but that you have to agree that each one wants something different. So we. But we need to ensure we found the body.


So this is a great question.


And I have I have an unsatisfying answer, so the question is basically how do we figure out what to build next? Here's my answer. The reason why you have apart development cycle is that you can work on multiple things. Usually there isn't a right answer. Usually all of the things that you want to build won't work. So what you need to do is need to create a process in your company to build things quickly so that you can actually see whether they're work or not.


And then you can iterate them from there. So it's far more important to have a tech, tactically talented team that can build them v.p.'s quickly in a non frustrating way and then measure the results than it is to be a super genius who can imagine what's going to happen in the future without actually knowing. Now, in the big picture, you have to have that imagination for your vision for where it's gonna be 10 years. Now you have to have that imagination for the little technical like tactical move in the next three months.


Like, it's really hard to nail those. You have a process that can rip out things quickly and then only iterate the things that are working. They'll serve you far better. Our mistake was that adjusting TV, it was thinking every time we've got the run. Let's only swing for home runs. And of course it would take three months to do it because we had to make a perfect right and then the whole spike spiral of death. All right.


The last thing I'll say is my email address is Michael at Y Combinator dot com. Strangely, I tell people that I answer every email and people mostly don't believe me. And the ones who do e-mail me and I reply. And so everyone I talked to and everyone online, there's really only two categories of people, the people who don't believe me, in which case. Great. Continue your lives and the people who will believe me. And if you need help, they'll email and I will try to help you the best I can.


It's really that simple. You don't need to have networked with me. Y Combinator is fairly easy to spell. And so as Michael. So you should be able to figure that out. Thank you.