My short response would be:<p>How to Jerk the Chain of a Seed/Early Stage Venture
Partner.<p>Consider US <i>information technology</i> (IT) venture
capital (VC): It is easy to understand that the
author of the original post (OP) is frustrated,
etc., but my guess is that with reasonably high
probability can get a response from a seed/early
stage VC partner if (1) have a product/service
developed, about ready to get users/customers and
revenue, and that a VC partner can "play with" and
(2) send the VC partner some e-mail with a short
description of the project together with an easy
way, say, just a URL, the VC partner can use to
"play with" the product/service.<p>Then the VC partner may evaluate the potential of
the project by pretending that they are a
user/customer, that is, evaluate how well many
users/customers will like the product/service. If
the partner likes what they see, then more
communications are reasonably likely.<p>For a little more, since most VC firms do publish
their phone numbers on their Web sites, can call
and, give name, say are an entrepreneur, and ask for
"office of" a VC partner are interested in. Then
may get a person, often a really sweet, young woman,
and explain a little of the work and ask how can
send e-mail. Often can send e-mail to the woman.
Also, often, if call the VC firm after closing hours
can leave a message on the phone of the VC partner.<p>Should, of course, check the interests of the VC
partner to see if those interests do cover the
project. And likely should pick a VC partner
without very many current investments or board
seats.<p>For a little more, once the results of a project
have obtained some publicity and traction, VC
partners may notice and call the entrepreneur.<p>The key in all this is just (1) above, that is, have
the project that far along.<p>But, more generally, for such contacting a VC
partner, my view is that an entrepreneur with a
project about to get users/customers should try hard
not to accept equity funding and, instead, just
continue to own 100% of the business. I explained
more in<p><a href="https://news.ycombinator.com/item?id=8640126" rel="nofollow">https://news.ycombinator.com/item?id=8640126</a><p>Whatever VCs are doing, tough to expect them to
change if they are getting good returns on
investment (RoI), but as in<p><a href="http://www.avc.com/a_vc/2013/02/venture-capital-returns.html#disqus_thread" rel="nofollow">http://www.avc.com/a_vc/2013/02/venture-capital-returns.html...</a><p>actually on average VC RoI is poor.<p>My view is that US IT VC is missing out big time on
much bigger RoI. The main reason is that VCs just
will not fund the work before there is a
product/service ready to "play with". Much of the
reason here is that VCs can't/won't evaluate plans
for such work, and likely the main reason here is
that they do not believe that such evaluations could
be at all accurate in predicting financial success.<p>So, essentially all the work in IT the VCs see is
what could be done by 1-3 guys in a garage before
equity funding, and this situation is for high RoI
just devastating. Moreover, about all the VCs can
do when evaluating such projects is to look just
superficially, at only the cover and not really the
book, and the superficial look hurts evaluation
accuracy and, thus, average RoI.<p>Part of the extreme tragedy of this situation is
that quite broadly in our applications of the fields
of science, technology, engineering, and mathematics
(STEM), we know quite well, thank you, how to plan
projects, present the plans just on paper, and
evaluate the projects, just from the paper, with
high accuracy, much higher than that of IT VC. Or,
we can do such evaluations for the largest engine,
ship, or airplane ever built, the tallest building
or dam ever built, the longest bridge, tunnel,
canal, or pipeline ever built, etc. Heck, the
ancient Egyptians planned the pyramids, and we don't
see a lot of evidence of a lot of partially
completed, failed pyramid projects.<p>Here's an outline of something IT VCs could do that
huge evidence from history clearly shows would yield
much higher Roi; the outline is in steps (a)-(d):<p>(a) Problem.<p>Pick a good problem, one where the first good or a
much better solution will be a <i>must have</i>, not just
a <i>nice to have</i> for many users/customers, so that
in total, from number of users/customers and revenue
per each, can build a business worth $1+ billion.<p>Here is an example of such a problem: Find a safe,
effective, cheap one pill cure for any cancer.<p>For this <i>must have</i>, there should be very little
doubt; if there is much doubt, then pick another
problem. In particular, we do not want to struggle
over <i>product-market fit</i>.<p>(b) Solution.<p>For the needed solution, do some STEM research.
We're talking real research here, of quality that
would qualify as a Ph.D. dissertation in a good
research university, a paper in a good journal,
maybe a grant from NSF, DARPA, etc. Yes, there is
training for such research, the Ph.D. degree.
Right, mostly here we're talking a good research
university STEM field Ph.D. prerequisite.<p>With the research, want to create some <i>proprietary
intellectual property</i>, <i>secret sauce</i>, STEM
technology difficult to duplicate or equal, that is
the crucial, core of the solution and the business
and, for competitors, a severe barrier to entry.
Protect the work as a trade secret (with
corresponding software securely locked up inside a
server farm) or patents.<p>For this solution, there should be very little doubt
that it is the first good or a much better solution
to the problem. If can't find such a solution, then
return to (a) and pick another problem.<p>It should be possible to give a quite accurate
evaluation of the solution and, thus, the project
from the research for the solution presented just on
paper.<p>(c) Software.<p>Since we're considering IT, with Moore's law, etc.,
to provide the product/service to users/customers,
write the software for servers and user devices.
Given the solution, the software should be routine.<p>(d) Launch.<p>Now we are sure we have the first good or a much
better solution for a problem where such a solution
is a must have.<p>Get publicity, users/customers, revenue, earnings,
and a company worth $1+ billion.<p>For (a)-(c) here, there are some great examples from
medicine and US national security.<p>For the second, there was the SR-71: The problem
was to do surveillance of the USSR. The intended
solution was an airplane that could fly at 80,000+
feet, at 3.0+ Mach, for 2000+ miles without
refueling. Kelly Johnson of the Lockheed Skunk
Works showed up with an armload of papers showing
the plan for the solution. The project was
approved, and for years the SR-71s flew as designed.<p>Another example was Keyhole, basically a Hubble but
before Hubble and aimed at the surface of the earth.
Another example was GPS.<p>Technology? Nearly beyond belief. Value? World
changing. Batting average? Very high, much higher
than VC.<p>Gee, if the US DoD had wanted to sell the results of
Hubble or GPS, wonder if they could have gotten any
revenue? Are we talking <i>must have</i> here? How
'bout that?<p>Of course, the work in (b) and (c) needs accurate
evaluation, but the US is just awash in people that
can do that in the best research universities, via
editors of appropriate peer-reviewed journals, via
problem sponsors in NSF and DARPA, etc.<p>After (a) and (b), it really is possible to know
with quite high accuracy VC firms should look to
fund projects just after success with these two
steps.<p>That's how to do (a)-(c) of projects. To be sure
the launch in (d) works, do the work as outlined in
(a)-(c).