I very much like nearly all of Paul Graham's thinking. For his essay this time, I don't like his thinking. I believe that his essay here, and nearly all VCs a

I very much like nearly all of Paul Graham's thinking. For his essay this time, I don't like his thinking. I believe that his essay here, and nearly all VCs and media pundits, make the same, horrible mistake about planning successful startups: (1) We have to realize that successful startups are exceptional, one in a million or so. So, for the planning, we are likely planning something exceptional. (2) A successful startup is usually one of a kind, unique, quite different from the past. E.g., HP, Seagate, Intel, Microsoft, QUALCOMM, Apple, Cisco, Google, Facebook, Twitter, Applied Materials, Amazon, etc. So, from (1) and (2), in planning a successful startup, we are looking for something both exceptional and new. So, for our plan, we will have to dig enough to be exceptional (the common, ordinary need not apply) and also new (no sense in looking at and trying to build incrementally on the closely related past). E.g., for the A-bomb, don't go to a bunch of experts in WWI field artillery. Instead, need something both exceptional and new. E.g., many VCs claim to have "deep domain knowledge", but that has to mean that they spent a lot of time looking at poor business plans and what is in the market now -- not both exceptional and new. So, (1)-(2) is the horrible mistake. But, wait, there's more: (3) Given a candidate startup plan, how to heck to evaluate it accurately? All concerned very much need to know. Well, good planning of projects both exceptional and new really is possible: Examples include Hoover Dam, the Empire State Building, the Channel Tunnel, Ike's Overlord (invasion of Normandy), the Manhattan Project, turbojet engines, the H-bomb, the US SSBNs, the Boeing B-52 and 707, the engines for the SR-71, the SR-71 in total, GPS, Intel's step to 14 nm, Microsoft's Windows NT, RSA public key encryption, and much more. So, it is possible to evaluate projects; a project that passes a good evaluation becomes low risk, indeed, for both the technical risk and the market and economic risk. Then, on (3) PG's essay and VC work in general is short on how to evaluate projects. My startup is one of the ones on PG's list. I don't regard the project as risky. Okay, let's see how this goes: The project is a new Web site. The site is totally safe for work and squeaky clean and respectable. The site has only two main Web pages, and both are just dirt simple, so simple they will work fine on essentially any device with a Web browser up to date as of about 10 years ago -- mobile to high end workstation. The project is to solve a pressing problem so far solved at best poorly and shared by essentially every Internet user in the world, especially in the more advanced countries. The project seems to deserve on average at least 30 minutes of eyeball time a week for each of its users -- that's a lot of eyeball hours per year. The site is ad supported with some quite good, new opportunities for good ad targeting. So, sure, from the above, do some simple, back of the envelope estimation arithmetic and come up with the most valuable company in the world so far -- sure, > $1 T. Now do we need to look at this "obliquely"? Not really. Once explained, it's all plenty clear and obvious. Do we need to start on just a small part of the whole problem? Not really. Does such a big goal have to be a big project? Not really -- I'm a solo founder. Is the project risky? Now, not really; for me, never was. Is the project difficult to evaluate? Not really -- I had to evaluate the project and would not have proceeded unless I saw a solid project. But so far I'm the only person who has done any even a little serious evaluation of the project. Is the project a huge amount of work? Nope, not really. To date it's 24,000 Visual Basic .NET Framework 4.0 programming language statements in 100,000 lines of typing I entered into my favorite text editor KEdit on Windows XP SP3. Nope, didn't use an integrated development environment -- for me learning to use one of those was harder than just typing in the code! As of now, all the code is as I originally designed it and appears to run correctly. Debugging was no problem. The code is surprisingly fast and efficient (at one point, converting to a solid state disk drive would make the code fast beyond belief). The code is nicely documented. No refactoring needed. The code is fine. I want to do some more testing, tweak a few places, add some data, and then go live. The code as it is is ready for fairly serious production, and the architecture is easily scalable to serve the world. So, how can my project be so exceptional? And new? Well, it's new because I thought of it, and on first glance nearly no one would believe that the problem could have a good solution. Well, without some good original research in applied math (the users will never be aware of) with some advanced prerequisites, there is no good solution. So, without looking into the math, and nearly no one in business can, there is no way to believe in the project; so, I'm the only person who does believe in the project. Nothing "frightening" about it! So, my view is that the essay is poor on (1)-(3) and, with that poor foundation, makes lots of mistakes, e.g., that big results need a big project.