The Science of Entrepreneurship
dustincurtis.com
dustincurtis.com
This is a mis-charaterisation. Most likely the author knows, but scientists don't build experiments to support their theory or hypothesis. They use their theory to make a prediction, and then design an experiment to test that prediction. If the prediction is vindicated/validated by the experiment then the theory is supported.
Of course, this is the theoretical progress of science. In practice it's not as clean cut, but it's a good goal for our aspirations.
Having said that, I think it's an interesting article. Being specific about your model, being specific about your business theory, being specific about testing your model by performing experiments, and being specific about adapting your business model to take account of the results of said experiments, might be worth making explicit, rather than leaving implicit, haphazard, or even nonexistent.
If you want to make money, why not use (the theory of) science to help!
It's a nice theory, but it's not particularly useful to someone who wants to start a business, or who is already starting a business. We make and test theories about the future in all our human endeavours - not just entrepreneurship. Even going on a date is testing a hypothesis about the future.
So, in summary, this article is correct about the human decision process, but incorrect in the implicit assumption that this is something specific to entrepreneurship.
And if you develop a powerful enough theory for your market, and then build toward that theory rather than arbitrarily building a website with a function, you'll have a higher probably of eventual success.
I've seen a lot of companies just fail because there was real driving force behind the product more than "hey, that'd be cool, I think." That approach might work sometimes, but I think you can vastly improve your chances by having an underlying prediction for the market you're entering.
If you're trying to start a company that changes an industry, like Hulu or Tesla, your predictions need to be quite a bit wider in scope. I'm referring in the article to the latter kinds of companies.
Mitch Kapor also did not have a theory.. he had an 'idea' an 'hunch'.. but not a theory.. theories have been proven by rigorous reproducible testing.. it would been hard for him to have done that; because lotus 1 2 3 .. was a completely new revolutionary idea. If he had spent the time to come up with a true theory based on years of testing with consumers.. diffrent types of UI's etc.. well someone else would have beat him to market..
there is nothing wrong with working off of hunches.. and in fact probably the fastest way to market.. and if your hunch doesn't work then come up with another idea..
companies that work off of proven ideas, and theory.. are large companies looking to make steady growth..
you wanna make millions.. fly by the seat of your pants.
I think this is a horrible misconception. If you want to build the next billion dollar company, perhaps. But if your satisfied with building a multi million dollar company, all you need to be able to do is take a reasonably critical look at the past. What sort of products have people characteristically paid for, despite the quality of available options being low? Answering that question doesn't require prediction at all.
"The Science of Entrepreneurship" text on the site.
There are big problems with software development - complexity and requirement of the special state of the mind. This is why there are still no programming factories. There are already data-indexing and query processing factories, but you still should think and write.
All those methods, form Booch's RUP, Beck's XP, Fowler's Refactoring are an attempts to adapt scientific methods, psychological and human behavior models, and even religious concepts to the process of the writing software.
The point is that these common ideas can be also adapted to a business processes.
For example, RUP is about planning and circles of iterations - scientific approach. XP is about reuse human behavior - little steps, being sure you hadn't broke anything, look (run tests) at your beloved code 10 times a day. Refactoring is about continuous improvements, little changes, that makes your code easier to understand, which means easier to modify and support. This is, probably, from dictionary and guide-books writing. You're writing the code is for humans, not for compilers.
Of course, not one of these methods fits all, but you can make a mix by yourself. Some from there, some from there. It is like cooking. All sources and ingredients available - just try, learn on failures and try again.