
The Science of Entrepreneurship - kyro
http://dustincurtis.com/the_science_of_entrepreneurship.html
======
RiderOfGiraffes
> _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!

------
swombat
Meh.

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.

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

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

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

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

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

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

------
tsally
_A true entrepreneur has to predict the future._

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.

------
k0k0k0k0
What the hell font is that? Is it available on UNIX?

"The Science of Entrepreneurship" text on the site.

------
c00p3r
It is also usefull to backport and apply all those TTD, XP and Agile concepts.

~~~
c00p3r
OK. I will try to explain.

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.

