[NY_Entrepreneur]

VCs have some VERY serious problems: Mark Suster has some graphs that show that on average over the past 10 years VC returns SUCK. Thus, a lot of venture partners won't be able to raise a new fund. Thus, a lot of venture partners will have to leave venture capital. And one of Suster's graphs shows just this: The 'unemployment' rate of VCs over the past 10 years has been, just from memory, something over 50%. For the VCs who still have jobs, their chances are no better.

My broad conclusion is that the VCs are without any doubt the biggest idiots in the room. They are nothing like the students I respected in mathematics and physics or in computing. One could count on two hands all the venture partners with significant technical backgrounds (in information technology). There is hardly a single VC in the country I would hire as COO, Chief Scientist, CTO, Chief Software Architect, software manager, software developer, server farm administrator, network administrator, new product designer, help desk staffer, etc.

Some VCs respond to 'cold, over the transom' e-mail messages, and some do not.

The VCs have a HUGE problem: They very much DO need 'home run hits' but have essentially nothing for good criteria for selecting such. Indeed, net, their view appears to be to go for 'base hits' with some 'face validity' according to some currently popular 'herd criteria', draw their 2%, and just let 'another Google' happen when and if it does.

If they get only 10% of their 'hits' from 'cold, over the transom' e-mail, then the reason might be not that the e-mail contacts are unpromising but just that the VCs have trouble (1) handling their e-mail (most do) and (2) actually evaluating a project based on just text in an e-mail message (most do).

In Silicon Valley the VCs have a special approach: They spend so much time in 'gossip' that they all learn about the same 'hot deals' at the same time, just from gossip.

Alas, the gossip is a very poor way to select home runs.

Here's part of the problem in selecting 'home runs': Look at the home runs, Apple, Twitter, GroupOn, Facebook, Google, Yahoo, Dell, Oracle, HP, Sun, Microsoft, Intel, etc. and now, your mission, should you decide to accept it, is to find the 'pattern' in that list. The list is short, and the list covers so many decades that the circumstances have changed a LOT over the decades. So, each decade, before the circumstances have changed, really have only one to a few such home runs. So, simplistic patterns don't work.

But there is something that does work. It has a GREAT batting average, FAR better than the VCs. It's worked GREAT for 70 years now. It still works. It gave us little things like the Internet, GPS, Silicon Valley, radar, atomic power, microwave ovens, microslectronics, and much more. Right: What actually works is the project evaluation process of the US DoD. And that is done nearly ALL on paper, with essentially always some quite technical material.

That process, nearly all on paper, is how I evaluated and executed projects in some of the world's best industrial research, some leading edge projects in business, various projects for the US DoD, my Ph.D. dissertation in engineering, and more. It WORKS. In comparison, the VCs are blind men throwing darts in the dark.

Some of the best VCs actually do realize that their 'networks' do not "overlap" with those of the most promising entrepreneurs. In particular, the 'network' of Lerer Ventures looks like it totally sucks for promising successes. Indeed, the very most promising sources of good deals for Lerer Ventures would be from 'cold, over the transom' contacts from people it does NOT know. If Lerer Ventures knows and likes an entrepreneur and immediately likes their project, then they should NOT invest! That is, unless they want to start another Huffington Post!

[rfrey]

Can you provide a pointer to the process you're talking about? Google turns up several candidates, none of which are stand-out obviously the process you mean.

[NY_Entrepreneur]

One "pointer" would be how a graduate student proposed their Ph.D. dissertation project. There is a lot of variety here. The way I did it was (1) pick my own practical problem I brought to graduate school, (2) in my first summer use some of the best material from my first year of course work to do some original research to get a solution, (3) write up the solution as a 50 page manuscript. That became my 'dissertation proposal'. The key to the 'process' here was that the manuscript had its core content in theorems and proofs. So, there wasn't a lot of doubt.

Later I finished my Ph.D. just as outlined in my manuscript.

Here's another example: I was working for a small company near DC on some DoD problems. At one point we had to bid on a software project for a major DoD lab. Part of the work was to provide data for a simulation of effects of ocean waves. Some of the input was actual ocean wave data. So, the goal was to generate simulated data with the same 'power spectrum' as observed. I got the famous book by Blackman and Tukey on measurement of power spectra and discovered that what the DoD lab wanted was poorly formulated; they were asking for too much 'resolution' from the data they had.. So, following the book, I wrote some software to illustrate what could and could not be done. The software, my references to Blackman and Tukey, and a technical paper I wrote formed the solid core of our proposal. We got the contact. The software I had written actually was essentially what was needed in the final deliverable.

I was in an industrial research group working on monitoring the health and wellness of server farms and networks. I had some new ideas and wrote out the ideas, with theorems and proofs, in a paper. Then I wrote some prototype software. On both simulated and real data, my software worked just as the math in my paper said it would. I wrote a paper for publication, and it was published. What's in the paper is solid and likely and apparently remains the best way to detect 'zero day' problems in server farms and networks. And for the "process", it is possible to be quite sure about the 'efficacy' of the work just from the paper.

The DoD accepts and reviews proposals for technical projects and research of wide variety. There is DARPA, ONR, Army Research at Durham, and more.

There is also design and planning in most of engineering, say, for tall buildings, long bridges, new airplane engines, new airplanes, etc.

In all such documents, the most serious question is, will the project as proposed yield the desired results? In nearly all cases, this question is answered just in the project proposal just on paper. Why such a paper is taken seriously is that, put briefly, 'it all hangs together logically from beginning to end'. Often the core of this logical connection is some math or math physics. That "process" of writing a paper that 'hangs together' is heavily from academic research. With this process, done well, it actually is quite possible to be fairly sure of the project results just from the project proposal just on paper before the project begins. The batting average of the DoD on such work, e.g., GPS, ARPANet, adaptive beam forming in passive sonar, inertial navagation, ultra low frequency radio communications, the SR-71, spread spectrum radar, infrared missile guidance, radar, the proximity fuse, the A-bomh, the H-bomb, the ICBMs, is nearly 100% and, thus, totally knocks the socks off venture capital.

Does this "process" have a role in information technology venture capital? At present, essentially never. Should it? Definitely, yes. How? Not for all projects but for the best ones, that is, the 'home runs': For an outline at 40,000 feet up, the standard steps in hitting an home run in business are (1) Pick a good problem, (2) Find a good solution to that good problem. (3) Sell the solution.

Part of being a 'good' problem is that a good solution will be valuable. Part of a good solution is that it is much more valuable as a solution than anything else and is difficult to duplicate or equal.

To ease the "process", pick a problem where it is obvious that a good solution would be valuable. Then for the solution, present that as a technical project proposal, say, much as for the US DoD, where all the proposal hangs together logically from beginning to end, likely with some math theorems and proofs and some math physics, etc.

Math? Information technology is to provide information by manipulating available data. Those manipulations are necessarily mathematical, understood or not, powerful or not. For manipulations that are solid and powerful, proceed mathematically.

Alas, US venture capital is nearly totally unable either to evaluate such work or even to direct the evaluation of such work. US citizens can be very glad for US national security that the US DoD is evaluating projects as they are and nothing like how VCs evaluate projects. Indeed, one could count on one hand all the VCs with qualifications to be technical problem sponsors in the NSF, DARPA, or the rest of the DoD. The IT VCs are trying to work in technical fields but nearly all are, in two words, technically incompetent.