I don't think you can just build a great piece of technology,
and hope along the way that you'll figure out how to make money
from it.
That's not at all the plan I'm suggesting. I'm simply suggesting
explicit non-determinism in both technology and business model
planning. Non-determinism is not the same thing as relying on just
"hope": it's just a more realistic, more robust, and ultimately lower
cost way to approach both problems.
More realistic because important contingencies in both business and
software planning are impossible to fully anticipate and plan for in
advance. In those few life-critical systems where people must make a
best effort to do such planning, costs are astronomical.
More robust because the effort becomes focused on building then
maintaining a potent set of degrees of freedom, rather than building a
Rube Goldberg contraption. Basis and span. Strategy and tactics.
Lower cost because with non-deterministic planning, you can always
work next on the option that is your current best bet of the least
expensive progressive step. Actually "right cost" would be a better
description -- you can also take better advantage of transient spikes
in available funding.
My most successful complex software projects have benefited greatly
from non-deterministic planning. My least successful projects have
been cut off in part because non-deterministic planning was wrongly
interpreted by the funding entities as: "he doesn't know what he's
doing".
You've got to have some idea of where you're going, and a
plausible path to get there.
In the ways that are logically important -- I do. In the ways that
fit the formula found in "How to write a business plan" books, it's
less clear.
But I'm not sure that is, in and of itself, the real obstacle.
That's where the venture capitalists come in.
VC's both in the sand-hill road sense, and the
exec-with-cash-in-the-bank sense. Sure. I agree.
Yet there seems to be both a class barrier and an understanding of
software barrier that is sharply enforced between me and them.
(I'm using "class" here in a generic sense -- a social function
distinction -- not in a marxist sense.)
The class barrier typically prevents bidirectional communication in
any form. When something leaks through that barrier, the
understanding of software barrier rears its ugly head -- the
representatives of capital frequently seem to have a very vague sense
of the software and engineering process design space and rely on
unreliable heuristics and advice from sources whose perspectives are
limited.
It doesn't help, either, that its a small and sometimes pointlessly
cut-throat industry.
-t