Dropbox and why you should invest in people
cdixon.posterous.com
cdixon.posterous.com
From the essay:
"The hallmark of an architecture astronaut is that they don't solve an actual problem ... they solve something that appears to be the template of a lot of problems. Or at least, they try. Since 1988 many prominent architecture astronauts have been convinced that the biggest problem to solve is synchronization.
...
Jeez, we've had that forever. When did the first sync web sites start coming out? 1999? There were a million versions. xdrive, mydrive, idrive, youdrive, wealldrive for ice cream. Nobody cared then and nobody cares now, because synchronizing files is just not a killer application. I'm sorry. It seems like it should be. But it's not."
I immediately thought of dropbox. It appears, to some degree, it is a problem and some people do care. Like Chris said, its the execution and people that made the difference.
He was right because there are architecture-astronauts who overdesign things that they don't understand yet.
He was wrong, because the mistake of architecture astronauts is not that they want to solve a template to a lots of problems. Solving a template to a lots of problems can be a huge business. Think of the personal computer. Think of MS Excel. Think of Oracle. It is just very hard to get these things right, because it is very hard to see the market for these generic products in advance. Also generic things are very technology heavy usually, so hard to convince investors. (Maybe I am just defending myself here, because I am also working on a generic application which is about helping businesspeople to access/maintain/query their data intuitively. (Like Excel just with a bit more constraints (with relational db. server backing))).
YES.
This idea has always bothered me: "don't solve a template of a lot of problems, solve one problem."
Isn't that the essence of innovation? To kill lots of birds with one stone?
The problem with "architecture astronauts" is that they over-think their problem, and they spend too much time over-thinking and over-developing before they really understand the problem space. It's a problem of over-engineering and isolation, not wanting to kill more than one bird.
So what you end up with is a framework that solves nothing that requires a bunch of configuration, or unnatural calls to its API(s) to get your one problem solved.
If your 1 problem took, say, 100 "units" of coding; often the framework will take 400 since it's generic. Then you have to code another 50-75 for your one problem.
Sure, the next guy also has only 50-75 to do, but too often these astronauts have no idea of the ROI of the 400, they just assume that "REUSE IS GOOD!" since that's all they've ever been taught. The ROI may never breakeven, much less get profitable.
Also, astronauts VERY often never have to dogfood what they've written, and have no idea if what they've done is actually any good, or usable.
"Before you design for reuse, make sure you've designed it for use." I'm convinced "reuse" has caused more unnecessary code than anyone imagines.
An example of something that solves lots of problems at once well: a language and its compiler/interpreter.
A framework makes a lot of sense for internal applications and large companies. You're often repeating a very similar application over and over (same style, same database, same replace-unwieldy-Excel/Access power user DB problem.)
A framework makes a lot of sense for consulting-ware. Deploying 20 versions of a highly customized application with a lot of reuse. As I see it, this is the use case for Spring. I can't think of another way to easily test such a system.
Frameworks make sense when you need to assemble a team together quickly to solve a problem. You are inheriting a set of best practices that allow a quicker norming phase. Frameworks make sense when you have average and junior programmers as the primary workhorses on a project. (Note: we don't have enough A-listers to solve all of the world's computing problems.)
Frameworks aren't for every problem. That doesn't make them useless.
I heard "high-level program translation framework".
If something actually is the template to a lot of problems then obviously it's going to be successful.
Have you looked at QlikView? Sounds similar.
Do you mind saying what your product is?
- helping agile 'database evolution' by providing schema refactoring, and automatic schema refactoring advice by detecting redundancies.
- automatically creating indexes using query statisitcs.
- presenting a data maintenance GUI based on the relational schema, which is very similar to modern CRUD applications directly developed with the given schema in mind. (for example intelligent automatic generation of form layouts)
- semi-natural query language support. (actually I've extended the SQL Select command's syntax with quite a lot of intuitive and comfortable constructs.)
In other words, they are trying to find an overly wide and generic solution while all they have is a specific instance of a problem in a particular implementation they need to design for.
Architecture astronauts tried to build generic diffs and merges, on top of rich documents. Think SVN for Word docs. Then they though about metadata, like bug-reports and other actions. Then you can host the bug report (and the project management system, and the wiki) on top of the synchronization architecture.
Dropbox, at its core, just keeps your files and 30 days of history.
Sorry about the semantics ... I should have been clearer.
There was no single solution that was both convenient, compatible across devices and platforms, and useful for all the usecases. Dropbox nailed that.
she should use dropbox, google docs or have a mailing list, but i don't know how to say that. she knows only web mail as it's around for decades...
So yes, you should invest into people, but the trick is to recognize brilliance in advance. Which is brutally hard. For example recognizing technical brilliance if someone is not technical is almost impossible. I think where YC shines is not only that they try to invest into people but that they are actually quite good at recognizing brilliance. (I doubt they are perfect in this, but probably the best in the market.)
Entrepreneurs should always ask themselves “why will I succeed where others failed?” If the answer is simply “I’m doing it right” or “I’m smarter,” you are probably underestimating your antecedents, which were probably run by competent or even great entrepreneurs who did everything possible to succeed. Instead your answer should include an explanation about why the timing is right – about some fundamental changes in the world that enable the idea you are pursuing to finally succeed.
http://cdixon.org/2010/11/07/timing-your-startup/
Here Chris argues that even if he is able to recognize brilliance in advance, he wouldn't necessarily bet on them because of other external factors. So has he changed his mind in the last 5 months?
The more I read about startups, the more I feel like ignoring all advice and jfdi.
If that's the case, wasn't your error not thinking dropbox would be a big winner?
A new generation of killer startups were created: Facebook, Zynga, GroupOn etc. and KP just watched it all go by. It would be difficult to just quantify how much $ they missed out on, but at least now they are sorta admitting their mistake and getting back into tech investing (greentech didn't really turn out to be the second coming that many thought it would be)
Unfortunately people like 'symantec middle manager' are still around.
Frankly, I was turned off by the distraction and skimmed the rest of the article.
I guess we can now expect to see many more blog posts about missed opportunities, and lessons learned.
That being said, thanks for the post Chris.
Makes for good reading :)
Wait for it in 4....3....2....
because there may be the negative: i passed dropbox, i passed airbnb, i passed mysql and google, and see, i'm fine. what do you want? ;)
(it's not about chris or fred)
But I don't pay for it. I'm somewhere around 5+ free gigs of which I might use around 30%. Normally if I loved a product this much which I wasn't paying for, but ought to, then I would. But I'm not stealing my account, so I don't really feel like I should pay.
On top of that, I use a different paid service for storing large amounts of files. It ends up being cheaper and I feel both solutions work best how I have them - dropbox for sharing/working and the other for offsite backups that just transparently syncs every night or something.
I guess all that to ask a question...how the heck is dropbox making money? Between the amount of free storage they give and the fact that there are much cheaper remote backup solutions, I just feel like I'm missing something.
How they make money is fairly simple: use you as a customer acquisition channel to get people who have money using the service. Charge those people many, many times what servicing them actually costs. Does it matter if there are cheaper options? Pfft, no. There are cheaper caffeine delivery vehicles than Starbucks coffee, but since people don't choose coffee primarily based on price, if they hook one more weekday latte drinker that gets them a LTV of several thousand bucks at a margin of ZOINKS%. Dropbox isn't Starbucks, but their unit economics can be reasonably assumed to be "quite favorable indeed."
Since many large files are saved by a lot of people individually (movies, mp3 files, pdf manuals, etc) this saves them a lot of space. As they get more users this advantage grows.
What if I wanted to use Dropbox for piracy purposes (I don't, just using an easy to understand model). Could I upload a copy of Avatar.mp4, compute or find the checksum for it, and then distribute just that checksum to other users? Or distribute a file that wasn't Avatar.mp4, but looked like it to the Dropbox client? Would this effectively trick the Dropbox servers into distributing the file for more, so that I could legitimately claim to not be distributing copyrighted material, but just distributing a "magic" file that caused Dropbox to give me a copyrighted file that someone else had uploaded?
Modern hashing algorithms make this practically impossible, sorry.
Just because you have a hash string that's not technically a copyrighted film, you could still be guilty of copyright infringement. cf. http://ansuz.sooke.bc.ca/entry/23
I don't see how it shouldn't be good practice. The only information you're potentially giving away is that someone else that has a dropbox is in possession of the same file as you.
If dropbox client were to still force the upload to happen, and only discard the object afterwards, this "duplicate file exists" information wouldn't be leaked. Presumably, they want to detect duplicates within an account and avoid the transfer in that case in the interest of user experience, but if I've told dropbox to upload avatar, I'm presumably OK with the transfer happening, even if it's not strictly needed because someone else has already uploaded it.
Seems to me that that would be a bad investment.
Also:
Be careful about your metric of great. The metric of great must be "this person is a genius with lots of energy and creativity," not "this person graduated from the right school, knows the right people, comes from the right part of the country, lives in the right zip code, etc." It must be first-hand meritocratic, not based on second-hand derivative indicators.
DropBox's founder went to MIT, but that's not what made him great. MIT is just a good school. The guy may well have been just as great if he'd gone to Ohio State or some other less-prestigious school.
There's also the "ambitious and gets shit done" angle. IMO, like it or not, getting into and graduating from a "named" school is one indicator of precisely those two qualities.
There was a study recently that found there was a higher correlation between life outcome and where one APPLIED to college than there was to where one WENT to college. The takeaway for me was that people ambitious enough (and presumably confident enough) to apply to MIT would get similar results in aggregate to those who actually attended. I googled for a few minutes to try to find the study, but failed, so I apologize if I've mis-remembered or mis-stated the conclusions.
Disclaimer: 1993 MIT grad here, but while I greatly value my experience there, I give basically zero "extra credit" for MIT on a candidate's resume over any other school and I'd take "built dropbox" over any schooling, 8 days a week.
That is very interesting. Thanks.
Excerpt: "Once the two economists added these new variables, the earnings difference disappeared. In fact, it went away merely by including the colleges that students had applied to - and not taking into account whether they were accepted. A student with a 1,400 SAT score who went to Penn State but applied to Penn earned as much, on average, as a student with a 1,400 who went to Penn.
“Even applying to a school, even if you get rejected, says a lot about you,""
Instead, I prefer Mark Suster's "invest in lines, not dots" strategy. You really have to spend more time to have a better idea on whether you should invest.
In hindsight, of course Drew Houston would be a good investment.
I was fortunate to get to know Dropbox a bit more than most (and less than many). We were in the same YC class and shared an office for a little while. They was voted top of our class in YC - I don't think anyone doubted they'd be the most successful company.
I don't think anyone felt that even if they were overtaken by Google Platypus or similar that they would fail either - they were doing such hard stuff and had such dedicated users it would still be a great technology acquisition. The company was a really great investment and in fact after Clickpass was acquired I asked Drew if I could invest but unluckily for me they weren't taking on any more (very) small angels.
The interesting thing was that in those very early days (post YC), the investors still weren't fighting their way into it or making the hullabaloo that you see around some of the other valley companies. Drew and Arash were never big-talking sales people, they never focussed on bells and whistles and instead just concentrated on building great product. Day in, day out they just came in, built amazing software and, starting with Aston, they slowly added other amazing developers around them. That relentless progress seemed to be something that most investors really weren't tuned into.
Investors almost never take the time to actually hang out in a company and instead rely on consecutive and very similar meetings. They never actually watch a company work (although Mike Moritz did interestingly come and hung out in their apartment in the Y-Scraper before making his investment). I always therefore feel that statements such as you should invest "in the team", "in the market" or "purely in any other one thing" are all slightly trite because what you really want to invest in is the relentless march of a product towards a market.
You can't learn that in a pitch though or from a founder's personality or even their CV - all of these are single data points and you want to measure the product trajectory. You can however get a very real feel for that by spending real time with a company, in their office. I'm sure you would get some false positives from it but in the long run it would be hard to avoid the true negatives.
Dropbox's office was calm, intelligent, very productive and full of debate and fiercely intelligent employees who believed without hesitation in the product. The developers were constantly interacting with their customers through their forums and they hung out as a team after work. It was totally and utterly different to many other offices I have observed and made it very hard to imagine an outcome that would not be good. They knew the market for their product, they knew it was big and they marched relentlessly towards it.
I know lots of smart, driven, successful people whom I still wouldn't invest in but I would be very interested to know how many such teams with the kernel of a product people like, in a market that is significant and who march relentlessly towards it do not constitute a good investment.
I have heard it said before that some of the best ideas are those that take complicated things and make them simple or easily understandable, and their success goes a long way to proving that point.
Dropbox is a great lesson in how ideas don't matter and how execution is king. They had the guts to compete with a dozen other players who were trying to solve the same problem, solely based on the confidence in their execution. Investing in people having the skills to execute, the guts to compete, and the resilience to persist, clearly makes better sense than investing in just ideas.