 So, given the estimate time and you can build the perfect product, so a little about me. Right now, I'm working in the Goal School and I'm the founder of Goal School. We teach Ruby on Rails and I'm also the organizer of Rails Taiwan and the last Pacific, I'm also the organizer. Right now, my full-time job is the kind of software development coach and also my primary language is also Ruby on Rails. I started using Ruby on Rails since 2007 and I am also a hacker. Speaking to a hacker, so you may think, why can I call myself a hacker? I may not like a hacker, but I used to work at Hexon in 2012 and I am the world champion. This is real, this is Mark Zuckerberg, not a Photoshop picture. This is tech in the Hex square. So, that makes me kind of qualified to talk about this topic, how to build a product in very limited time. So, first, speaking to Rails, what can cross your mind? So, what would you want to enter the Rails world? I think the main reason is like, you think Rails is fast, so you want to run Rails so you can work all over time. But when you finally enter the Rails world, you find out you still work overtime. So, too many jobs and burnouts, so why? Because Rails only guarantee you can build things very fast, but it didn't guarantee you can get the right project direction. So, today's topic, so it's not about like how exactly about building Rails with agile approach. Instead, I will talk about how to win a Hexon, for example, to teach you how to do the right project management and how to make you a better Rails developer to deliver the project on time. So, speaking of how to win a Hexon, so how do we think how to win a Hexon? So, the answer is probably very, the answer probably is you build the great PowerPoint and then you can win. So, many people are very angry about this, but this is true. So, typically, a Hexon winner will come out with following results. The number one is like you have the great pitch deck. The second one is you have a right product and the product's purpose is good for press release because like if a bank throw out a Hexon, you may probably the first place will probably be like a mobile Hexon and can pay something easily, so the product must make their expectation. And also, you should finish the product, even with the prototype. So, it's kind of like when you want to build a product, what is the great product? It's like you also need to like a great pitch take, so you can tell your customer, your scenario is your value and the project must meet MVP definition, minimal viable product. So, this product must like can quickly success and deliver the future on time where the market needs it. So, fighting a Hexon is kind of like you're building a great product in less than 10 hours. So, that's why I will choose today's topic, like building how to win a Hexon. For example, technical example to explain how to exactly manage your project. So, how do we win in 2012? So, the product we built in 2012 is we built a service called paperclip.io. This is the FBE share links bookmark service. So, we usually save a lot of links on our Facebook, we would like. But in the old Facebook, so after two weeks and three weeks, you will forget how, which amazing article you browse in several weeks ago. So, I think this is terrible. So, that day I built this topic to become our top project. So, this feature later becomes the built-in feature in 2014. So, if you use the Facebook now, they already have this feature. So, why we will win in four years ago? Because in late day, we have the perfect pitch deck and with perfect product and we built it and perfect in seven hours. So, how do we manage to do this? So, what we use rest of course, because if you want to win a Hexon, you need to build things first, things very fast. But I think why we will win is more about time management. Before this Hexon, I like bigger stuff. So, I tend a lot Hexon, but I always lose. Why I lose? Because number one, I didn't have the perfect deck. I built a perfect deck. So, every time I lose. Second is, every time I run out of time, so I have a crappy demo. And the final reason is like I have a crappy idea. I always build something. I think it's very cool, but the strategy is it sucks. So, how will we do in 2000 at Hexon? So, this time I really want to win because I think at that time I'm building the consultancy. I think if I win the price, then I can get more business. So, I must win this year. So, I realize every time I lose is because for this reason, crappy idea, crappy pitch deck and crappy idea. So, I think what can we build this time? So, I find out the number one reason for me to lose is I didn't have time to build everything at all in the given timetable. So, I find out. So, why should I check how many resources before I start? So, the timetable is, this is a seven-hour Hexon. So, start at night and end at 6 p.m. So, we only have seven hours to build this product. This time, the seven hours also includes lunchtime and bathroom time. But this is not really we have. So, I want to win this time. So, the important thing is I need to give a very great presentation. So, in order to do this, I must finish my pitch deck. This takes one hours and the practice. And before that, I need to build a great product. So, I must take some screenshot. So, it only left me five hours. So, you might think this is not possible. Five hours. How many things you can build in five hours? I will think probably I can build five features in five hours. But, turn out, we only build one major feature. Because, like in Hexon, if you are too greedy, it will be more low cost. When you think you only have one buck, actually you will get 10 bucks. And then you will die. Like, buck song. So, because I always, like, run out of time in the previous Hexon. So, this time I run something smart. We should only focus on one feature and the graffiti is perfect. So, I start thinking, what topic should I build? So, I think I want this feature very bad in Facebook. So, probably I should build this. And in order to build this idea, I need to build several infrastructure. Like, we need to save our links. So, the features we want to build, we need to build is like URL feature and background job to crawl out of all of the links and with a simple design. So, we finally build this service. And the second is, we start to plan our power schedule. And at the beginning, we spend 30 minutes to discuss this idea. We decide to only build one idea and one feature. Then we spend the next 30 minutes to set up the developer workflow like Git and the Capstrano deployment for the continuous deployment. The reason we do this is because you always fail at the final moment. You cannot deploy your website. So, this time we take smarter approach. So, I set up the continuous deployment at the first place. So, then we will like fail at the final moment. Then third is like build a major feature. So, I split the time. Like before lunch, we build the major feature because our core feature is too simple. So, we can finish all the feature before the 12 o'clock. And the reason we need to finish it all before lunch is because I will do something very evil. So, at lunch, I do something very evil. At lunch, we already have this demo. So, at lunchtime, instead I am not eating lunch. I take my laptop to show off people and make them demonstrate. So, you will lose. I win. Okay. And the fourth stage, after lunch, I started to do this because I always fail at the last moment. When the judge plays the website, you always fail. So, I spend a lot of time giving this demo to my Facebook friends, to help me to test. Then I find a lot of bugs. For example, we need to save a lot of links on the Facebook, but our background job is not fast enough. So, I build a parallel algorithm to make it faster. So, when you import your links, the result will show instantly. Instead of, like, dun, dun, dun, dun. And we also take some time to, like, have built some several minor details and building the landing page. And the step five is, like, finalize the product. And after I implement the minor features, my Facebook friends tell me, I don't know what stuff you are building. So, I realize we not only need to do a presentation deck, we also build our landing page. So, I spend some time to build our landing page then make our presentation and pitch, and then pitch at the final. So, why we want eventually? Because, like, we spend a lot of time practicing our pitch deck and the demo. In the hack zone, it's not what you build is not the first reason. It's like, if you want to want, like, programmers head to list, but the presentation, the pitch, the demo is the mostly important. And the second level, we only build one product, one product, one feature. And this product must be meaningful. What I picked this topic is because I think this I want to leave this feature. And also, I think Facebook needed this feature so I built it. And we spend three hours, like I say, we spend three hours to practice this project. So, by the presentation, presentation time, our product is already 100 production ready. But what others do? This is typical, programmers will do. If you want other, what people will do in hack zone? First, when they arrive the menu, they spend one hour discussion. Then they will see, and then we'll spend another hour to discuss for 10 ideas. Then they will decide to nail down to six major features. And then they will start coding. Then after discussion, they will spend all the time to build all the stuff. Then after like five o'clock or like the end, they will realize they can build and all. So they decide to drop to only two major features because they cannot complete all. If they want to complete all, they will run out of time. So I just pick the two major features. So they will, after coding, they also will save time for the pitch take. But since they don't finish all the features, they also didn't finish most of the takes. So when they come out of the stage, the first thing they will say is, sorry, I run out of time. Apology for their unfinished work. Then when the judge presses their website, pun 500 zero. So that's what typical people do. The difference between me and them is I spend only half of the time to develop a feature. But they spend most of the time to develop a feature but also include unnecessary features. But I save a lot of time to practice and craft my product to the perfect state. So by the end, my progress is 100, but their progress probably like 60. So let's find people, other people didn't win. So they spend the last time of unnecessary features. So that's not the only technique, that's not the only take, I only use the Hexel. Usually I manage all my projects in the same method. The way I manage my projects is like typical pitfall. I always do the same method. Like first, I will count how many resources do I have. For example, if a client dedicated a project to me like say I have like three months to build a project. So I will estimate how many resources do I have. Then the first thing I will do is like save the next month of assessment testing because if we didn't have save this time for practice or assessment testing finally, as the final, I probably will be get sued. Something like this. Because like the project fail is not like we run outside, it's probably like because you build something completely wrong or like over time, over project. So I think the last month for assessment testing is extremely important. And then I will split the other eight weeks for two, three milestone. The first milestone is like do the groundwork and find out what the risk in my project and set up the continuous deployment. And in the meantime, I can like go through the user story and to prioritize the user story. Then the second phase, I will build implement the major function and the project's major workflow to find out what the risks we have and what features we need to dump to complete the major goal of this project. And the third phase, then I will implement the major functions like improve usability and style the project to make it like much beautiful or much useful. In this week, I can continue to figure out where the risks and where the architecture we can improve all have. So then by the last month, we can make the product to do the perfect. So you will not, over time, you have plenty of time to make the project succeed and meet the expectation. So what do I do? Hexon is simply adapt these techniques. So I list my timetable. If I want to present in six o'clock, so I must finish the presentation at five o'clock. So if I want to give a pitch taker, if I want to do a pitch taker, I must finalize my product in four o'clock. So then before that, I don't need one hour to debug. So I must finish all my product before the three o'clock. So I use 12 o'clock to become the middle line. So I must complete most of the major feature at 12 o'clock. Then I can have a major demo to my stakeholder to make sure it looks good and gives them confidence. And after that I can go through the user story detail to make things right. So if you want to build a successful story, I think this talk I want to tell is instead of you building your product in waterfall way, first is you should define what is the success of your project. For example, if this is a Hexon, you must find out what is the success for the judge. For example, judge don't have time to go through your project or your presentation. So you must make them feel good. So you can have a very beautiful pitch taker, just make sure your project didn't fail at the demo time. So this is the success. It's not matter how your project is cool or something. The judge of Hexon won't give the first place to cool but useless or cool but not good for put on the newspaper. So you must want to win the Hexon or complete the project goal. You must find out what stakeholders care about and based on the definition to prioritize your story's priority. And the second is find out what is your major features. The major feature means the features you must have. Did it all could have and nice to have. Typically, if you do overtime in your project, probably the number one reason is you do too much could have and nice to have project in the first place, then you run out of time. And for my approach is like I will save the first one-third for the September for the final assembly testing and split the rest of the two-third to another three milestones. The first milestone is for ground works. The second one is for major feature and the third one is for minor features. Then I can make my available and the rehearsal so this approach can this approach can make sure you have plenty of time to think about and do the detail without over promise or like over two opponents. So the reason I'm doing this because the project fail is normal developers will do. If you have 90 days to do 90 days product, you probably won't build the product at all because if you have like 90 days or like 180 days it probably will spend all the time for planning. The typical internet company always like this kind of tragedy. So we have six months and the PMs spend five months for planning. Then after five months they give a proposal to the designer. They say we only have one month and the designer spends three weeks to build all the mock-up. Tell engineers you only have one week to implement all the features. So why I'm doing this because there are too much times so people are too optimized about the milestone. The way I'm doing this because I can use these techniques, I can cut down I can make the available looks very little. In this method I only have 60 days to build the features. Then I will think the time is very urgent. So I will dump all the features that are unnecessary. So if you do this your timetable and the quality will change it very significantly. So you will delete all nice to have and could have features to focus on actually MVP. When you finish the MVP you have plenty of time to implement that instead of spending too much time on wrong direction. So people always say Rails is fast but in my opinion the truth is if you didn't deliver something right nobody will think Rails is fast so that's the thing I learned in my software career. This is my talk thanks everyone. This is a little sale promotion. I have a new book called Crosshaker. Now it's the top seller. So if you want to buy this book we also have like sweet 30 copies in the front desk. You can grab one and give me to sign. Thank you.