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.
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.