> In scientific research, an experimenter develops a hypothesis with a suspected theory and then builds an experiment to support the hypothesis.
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.
Thanks. The point I was trying to make was that developing a philosophy behind building a company is not generally considered a strong requirement for most web companies.
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.
Sure, and I never criticise the noble aim of trying to figure out ways to increase our chances of success (we need all the help we can get). However, I think you'll find a stronger correlation between "being aware of a very pressing and important unmet need that people are willing to pay to resolve" and success than between "making a philosophical gamble on the future" and success...
I think in many ways those are the same thing. It depends on how wide of a market you want to capture. If you're just solving a single problem, like web forms (wufoo), then it's easy as long as the problem is real.
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.
Treating your product as a hypothesis encourages you to challenge your assumptions and rapidly iterate with new experiments, I think it's critical to starting a business.
It can prevent the failure loop of "looking for smarter prospects" who will appreciate your invention.
I think the parallel to scientific hypothesis is an accurate description of entrepreneurship. It is the process that I teach in my undergraduate course, without identifying it. My only caution is that focusing on the future of the market can lead one to focus on product features and not customer needs. Customer need drives the market and gives one the basis for the evolving market.
you are misusing the word 'theory'.
and you are completely butchering the scientific method in the idea you propose(what you propose is not a theory.. nor close).
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.
growing a company that's specifically built to rapidly experiment and learn is a powerful idea. I'd say that the initial problem or market insight - the "hypothesis - can sometimes matter less.
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.
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.
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!