Startup Advice from Michael Hartl
Friday at App Academy we had a surprise visit from Michael Hartl, author of the now-famous Ruby on Rails Tutorial. Interestingly, the conversation tracked a wide range of topics that leaned more to the entrepreneurial than the development side of things. Michael himself admitted that he’s probably not the right person to ask many beginner questions to, since he has very little personal experience being a beginner or dealing directly with their issues.
Instead, we tried to get a better sense of the steps that led to the tutorial’s creation and his advice for the day when we might put our newfound skills to use in startups of our own. Michael, after a narrow miss with a lifetime in academia, got into programming and landed in Y Combinator working on an open-source social network called Insoshi. As he put it, they just kind of pulled it together at the last minute to get something ready for Demo Day and it was surprisingly well received before the financial world ground to a halt in fall of 2008 and they couldn’t secure funding to continue.
After that, he treaded water with some consulting gigs while putting the tutorial together. He’d co-written a Rails book years earlier and had the utmost confidence that his tutorial would take over the Rails world and blow away any potential competitors. Still, it took nine months to get it all working properly. His business model, giving away the tutorial but selling the e-books and accompanying screencasts, has proven surprisingly successful.
Some of his more interesting points:
>> Being a sole founder these days isn’t the same impediment to success as it used to be due to advances in the ease of launching and maintaining websites. It can make you more streamlined and efficient. VCs (or Paul Graham for that matter) haven’t really come around to that mindset, though…
>> Corollary: Just because it’s easier now doesn’t mean you should be a sole founder and just because PG says you should have N > 1 teammates doesn’t mean you should either. You must *right size* your team. Some problems require 4 devs, others a dev and a designer, some can be done alone.
>> Just because an idea is a good idea doesn’t mean it’s a good idea for YOU.
>> Why? Because you must make sure to have an unfair advantage. You need to absolutely crush your competition with authority or you’re just fighting the pack. If you don’t have an unfair advantage, it’s not the right idea for you or your team.
>> Development skills are turbocharged by design knowledge. Embrace the unicorn inside you.
>> Shipping is HARD so PRACTICE before you enter the game, even if that just means taking some throwaway sites live first. You need to experience both the difficulty of shipping and the strange plethora of real-world bugs that arise in a production environment.
>> Only create the expectation of continued involvement in something (e.g. a blog or support for a product) if you can follow through. That expectation can quickly become a burden.
Of the things he said, the one that stood out most to me was about having an unfair advantage. It ties everything else together. We may be learning a set of valuable skills right now at App Academy but they do not represent an unfair advantage in the marketplace. Locating and cultivating that will be true education.