There has been a bit of buzz in the last couple of weeks about a conceptual new type of transport that Elon Musk has developed called the 'Hyperloop'. While he hasn't shared specific details, he has mentioned the concept in a few recent interviews e.g. here and here.
I find this exciting because I've been thinking about new types of high speed transport for a while now. I don't think we've solved the 'moving people around' problem as well as we may have predicted 50 years ago (alas still no Star Trek transporters). My best guess about what this Hyperloop might be, is an implementation of a vacuum train. The basic idea being that that you construct a tube, suck out all of the air so there is very little friction/drag, and then whisk people around in very high-speed capsules (just like the jetsons). Think NY to LA in 45 minutes. It's not a new idea - Robert Goddard first proposed a similar concept in 1910, but it wasn't economically feasible. Perhaps Elon's spin on it makes use of more recent technology advances and cost savings.
This is all speculation of course, but it would be incredibly exciting to see something like this developed. In fact, commercialization efforts are already under way with ET3 selling licenses to a patentent Evacuated Tube Transport system. More than 60 have been sold including 12 to China. Someone with the credibility and resources of Elon Musk jumping into the fray would greatly help the cause.
I've even fantasized about trying to do something like this myself, but where would one even start? I was brainstorming with a friend in LA recently about a market entry strategy for something like this and he proposed an interesting idea: the first deployment could be a high speed train between LA and Las Vegas, funded by one of the large Casinos (hello Steve Wynn) to bring gamblers in for a quick day trip. Alternatively, if US regulations make building it here too difficult the same concept could apply (albeit undersea) linking the casinos in Macau to Hong Kong.
Since California is already considering spending up to $98B to build a (relatively slow) high-speed rail between San Francisco and LA, the time is certainly right to consider alternatives that may end up being cheaper as well as advancing technology that will be of significant benefit to society.
We frequently hear non-technical entrepreneurs lament how hard it is to find technical co-founders (especially in the current environment). It's a commonly held belief that it is better to be technical yourself if you are starting a tech company. This is probably true, but I've been thinking about the other side of the coin and I want to present the downside of being a technical founder.
I'm mostly reflecting on my own experience. I have a masters degree in engineering from Stanford and I love to code, but I'm also attracted to all areas of running a business and wouldn't be happy as a pure software engineer. This has always been the case–I did both an engineering and a business degree for undergrad. So my ideal role in the companies I have started is Founder/CEO.
The crux of the problem is this: writing code creates a feeling of very tangible progress, whereas other business tasks like meetings and planning and recruiting etc don't. If I spend a week taking meetings, and then look back at my progress at the end of the week, I find it difficult to point to anything concrete that I have achieved (even though these meetings often yield important results in the future). However, if I spend a week coding, I can very easily point to features that I've built and shipped. It is therefore very tempting to spend time writing code even though it is probably not the highest leverage thing for a CEO to be working on. For this reason, being a founder who can't code may be a blessing in disguise. Such founders are forced to hire/outsource coding tasks and thus better leverage themselves, since they don't have the option to just fall back on writing code themselves.
I often observe friends who are non-technical entrepreneurs, and who treat coding as just another task that needs to be done for the business. The best of these entrepreneurs seem to have a 'hustle' about them and just seem to get stuff done. They are free from the diversion and distraction of “oh I'll just code that up myself” and so they are able to operate at a higher level and apply their time to all areas of the business that need it. I sometimes wish I had the discipline to do this, but then I oscillate to another conflicting mindset where I'm glad I have the ability to quickly prototype new ideas and don't need to rely on anyone outside of myself. I fantasize about coding up dozens of prototypes of all the ideas in my head, eventually finding one that resonates with customers and becomes a business.
I guess my conclusion is that I'm glad that I can code, but I need to have the discipline not to code when I will gain greater leverage by applying my time to other areas of the business. As much as I envy those who can't code because they don't need to consciously make this decision, they probably envy me just as much when they need to spend hours, days or weeks working with an engineering team to get something built that I could just do myself.
When do you get to stop calling it a startup and start calling it a
company? Is there some kind of threshold you need to cross - employees, revenues, profits?
I wonder if 'startup' has become too much of a loaded word, especially in the valley. It seems like every idea or side project can be called a startup.
Language can be powerful - I wonder if it would change things to refer to it as a company from day one? Would it change our thinking as entrepreneurs? Maybe it would motivate us to take things more seriously. To get to revenues, profitability, or some other measure of success that much more quickly.
One trick I've found when starting a company (and it's particularly useful at the very start, before you've launched a product) is to create external deadlines.
It's hard to be sufficiently motivated by internal deadlines and plans. When there's no clear negative consequences, it's all too tempting to slip a deadline by a few weeks in order to add an extra feature or to fix a few bugs. However the most important advantage a startup has is speed, and in most cases the best thing you can do is to get your product out there and in front of real users and customers as quickly as possible. This means you start getting feedback sooner, you start learning earlier, and you can iterate more quickly.
For me at least, I've discovered that setting external deadlines means I'm much less likely to slip. I think most of us don't like disappointing people or failing to live up to our promises. I'll illustrate with two examples of my product launches.
It was late 2007. I had recently left my full-time job and my two co-founders and I were holed up in a makeshift office in my living room working on Omnisio, a new tool for sharing educational videos online. We had grand plans and the whiteboard was filled with sketches of all the amazing features we were going to build. But we needed to get something out there. The concept of a 'launch' doesn't really mean much when you think about it. The company is still the same the day after as it was the day before, except you hopefully have a few more people using your product. Furthermore it's common these days to have alpha and beta and 'soft launches', and rare to have a big bang PR launch. So what is a launch then? I think it's actually a very important psychological point in the early development of a startup, where the team switches from a “*we're building this cool new thing*” mode of thinking, to “*we've built something and now we need to grow our user/customer base*”. I think it's important to get to this point as quickly as possible.
Anyway back to my story. We knew we had to launch something, and we figured an external deadline would be a great forcing function. The first technology we were working on enabled us to synchronize powerpoint slides with videos, and we realized conferences might benefit from this. Often times you want to watch a recording of a speaker at a conference, but you either end up squinting at a grainy video trying to read what's on the slides next to the speaker, or you somehow manage to obtain the slides separately and try to follow along with the video. This is easy to fix with technology.
I learned that a friend of mine was organizing a conference on social network platforms - a hot topic that was sure to draw a lot of interest. Perfect. I contacted him and told him about a cool new product we had built for showcasing conference videos, and asked if we could put videos of his conference online. He loved the idea. The only problem was that we didn't have a product yet, and the conference was a week away. This is the kind of external deadline I'm talking about that provides the motivation to work at the speed of a startup.
I vividly remember the scene a week later at the conference. I sat there with my video camera filming each speaker, while my co-founder Julian ran around with a USB drive asking speakers for a copy of their powerpoint slides, and my co-founder Simon sat there on his laptop writing the code that would glue it all together. Needless to say we got it done, although I think it wasn't all working until a few days after the conference. We set up a private page with all the videos in our new video player, and the conference organizer sent out a link to all the participants. We had our first live users and our first real feedback! It would be quite some time before we did a public PR launch of the feature (we launched some other components first), but the important thing was that we had passed the first key psychological barrier and we now had actual users to please.
I'll finish up with a second story about the launch of Kaleidoscope, which is a mobile fashion app that I'm working on at my current company, Inporia. We conceived of the idea in early January, and decided it would be best to launch during the spring fashion season, - New York Fashion Week in particular. The problem was it was only 6 weeks away and we didn't have a product yet (do you see a pattern here?) We reached out to various media partners as soon as we had created screenshot mockups with the hopes of securing a launch partner to help promote the app. We ended up building an embeddable web widget version of the app, alongside our Android and iPhone apps, so that we could piggyback off the traffic of our launch partner.
We officially launched on February 14 to great press coverage, and had our widget embedded on modelinia.com. The outside world never saw the fact that Simon was still fixing critical javascript bugs the night before (yes the same Simon), and Sarah pulled an all-nighter making sure all the content was loaded and everything was working (side note: this is why you need an awesome team when building a startup). We repeated this again for Paris Fashion Week a few weeks later, this time securing a partnership with AOL's stylelist.com. That brought a crushing level of traffic and took down our servers almost immediately, but with Simon on hand working to fix things combined with the elastic scaling capability of today's cloud services (thanks Heroku) we were up again in no time and the partnership was a great success.
I hope those stories give a little insight into what life is like in the very early days of an embryonic startup, and serve illustrate how important external deadlines can be in getting past the first critical hurdle - launch.
