Unfortunately, at this point in time, I feel very strongly that these suggestions will lead you to do good science and end up without an Academic Research position...at least, not initially. Personally, I think we need a revival of Franklin/Jefferson/Priestley/Watt type science, where the science is pursued for fun and interest, instead of for profit. The current petty competition for publications and grant money is the worst thing to happen to science.
Maybe we should return university science to the Sputnik Golden Age style of funding: once you've shown that you know what you're talking about, you just get loads of funding and just publish papers to keep it coming. According to folks who were doing science back then, it was glorious; they could get work done so much faster!
And just think of the international consequences. If the US became the land of easy funding, it would definitely keep a lot of foreign talent around. This sort of thing is a competitive advantage, and probably pretty cheap.
> Franklin/Jefferson/Priestley/Watt type science, where the science is pursued for fun and interest
Entire fields are now off-limits to individuals (even wealthy ones) due to bureaucracy.
Even if you can afford to fork over, say, $25K for something as basic as an analytical balance, chemical supply houses are forbidden by US law to ship anything (even table salt) to a private residence. (Actually, the truth is more complicated - it is not prohibited per se, but most of them simply will not deal with a non-corporate/non-academic purchaser due to the required paperwork overhead not paying off.) Hobby electronics is still legal (for now - just wait until the War on Copyright Infringement approaches the scale of the War on Drugs.) But if your science requires professionally-manufactured precision equipment or even the simplest chemical feedstock, all bets are off.
4. If you do basic research, keep your eyes open for applications of your findings.
I'm always reminded of one of my grad school profs who said that the goal of any research should either be commercial or something which will end up in a text-book.
1. Establish an independent niche in the market as early in your startup as possible. Avoid the web2.0 startup trap of following hype implementing ideas that are already popular and profitable. Of course social networks are helpful, but just-another-social-network can't form the basis of your startup
2. Be problem-oriented, not technology-oriented. Use a variety of technology -- whichever are necessary to solve the problems in the market. As shown by twitter, back in the days of ruby&rails popularity and DIY-everything, it would take twitter considerable resources to assemble a new queueing queuing system which sucks, when existing better alternatives existed. lest the founder be seduced into implementing another overdone component/api in a brand new web2.0/meta-meta-programming language. It is also painful to hear one startup after another say that "we are based on ruby and rails", as if this makes them cooler. While this may interest potential non-technical investors who judge the value of startups by the amount of the lattest technology jargons founders put into their keynote/powerpoints, its simply a waste of resources for the company in the long run. Remember, technology comes and goes, but the underlying need of the market should be the focus of the startup. It is depressing to go to conferences where the same old market problems are tackled; more “cutting edge” techniques, presented by people enamored of the techniques rather than the market problems. If technology is so costly, in terms of equipment, learning time, and other resources, how does one avoid the trap of becoming technique oriented? The answer: use what is already out there, leverage open source and solve real problems in the market.
3. Think beyond the next hype, or even the next round of investing. Take the long view; look at the big picture. In other words, bite off a piece of question that may take a month, or even a year to answer. There is a major difference between the scientist that wonders how to break the question into appropriate sized grant proposals, and one who wonders how to expand the question into a grant proposal. Furthermore, commit yourself to your question; given the time and energy it takes to answer an appropriate sized research question, pursuing a series of unrelated research questions in parallel rather than in series is often a sign of dilettantism.
4. If you do developed a new technology in your startup, keep your eyes open for other applications of your findings. On the other hand, if you heavily leverage an existing technology, keep your eyes on underlying technology/framework. Often, the distinction between technology and application is arbitrary and fluid.
5. When conducting market resource, don’t accept data or results at their face value. Keep plugging away at the problem until the answers or results make sense or satisfy you in terms of an overall schema. Most importantly, don’t accept other company's solutions (37 signals?); every startup is different.
6. Expect the unexpected. Many great ideas are discarded because a startup initially “didn’t work”. However, good execution should provide positive results regardless of the idea involved. Often a "good idea" and a "bad idea" is only differentiated by the execution.
7. Don’t expect quick success in a startup; expect more hardship, sacrifices, sweat, blood and tears. Paul Graham used to tell us that a good startup often require years of work to build up. Perhaps non-entrepreneurs find this aspect of startups strangely frustrating. However, the lack of dedication and handwork differentiate the success and failures
8. Never stop asking for user feedback. User feedback are the stock-in-trade of startups. The corollary of this suggestion is “never make assumptions.” Of course, assumptions are a necessary part of application design, but on an everyday practical level, and in terms of application workflow, assumptions can be disastrous. Many times I’ve located workflow bugs and inefficiencies in a startup's application workflow, because unlike them, I did not assume that a user could not “go there” or “do that”.
9. Choose a problem that excites you. It should excite you so much that you can’t sleep. It should excite you so much that when someone asks you the time, you blurt out your 30 second elevator pitch.
10. Strive for elegance and cleanliness in yoru code. The elegance of a codebase is in the quality of the thinking and the cleverness of the approach to solving the market's problem, not in the complexity of the design or the sophistication of the technology. Often, the most elegant code are simple, short attacks at the heart of the problem. Study famous open source code in your application domain and appreciate the logic and thought that went into it. All too often startups nowadays ignore existing codebase because it isn’t available on github, or dismiss it for using old-fashioned techniques. There is much wisdom and cleverness in some of those old projects. Reading them, learning from them, and citing them, is what real programmers do.
