Useful revenue model ambiguity

Michael Arrington of TechCrunch remarks on Twitter’s dilemma for starting its revenue model. To reword his points:

• Many firms are acquired pre-revenue and thus their valuation is made without proof of its revenue model.
• Before a startup has a revenue model, its revenues are anyone’s guess.
• Once a firm has revenues, the range of guesses will be much narrower — and often lower than the most optimistic predictions.

Of course, I’ve long been skeptical of Web 2.0 companies and their ability to create viable business models.

Cross-posted to Open IT Strategies.

A solution that found a problem

Several years ago, one of my students was involved in a business plan concept to use video board graphics processing units to provide extra processing power. The problem was this was a technology — or a solution — without a well-defined problem.

In this morning’s Merc, there was a story about TechniScan, a Salt Lake City company that is using GPU to enhance image processing of medical images (such as CAT scans). This is the targeted solution that my students lacked: a bounded technical problem (in terms of developing code and algorithms) with a well-defined group of customers with similar needs. If ever GPU processing is going to turn into a business, this would be it.

Ironically, the market they’re targeting is not a new one. Back in 1987, when my company was brand new, Peter Marx came down to Vista from Harbor-UCLA Medical Center to tell me how someday all medical imaging would be stored on computers. (At the time, the idea of images being stored on Sun workstations would have been considered technically challenging). He showed me all sorts of cool images that he’d processed on his Macintosh II.

Peter clearly had the right idea, but both the digital image generation and the host-based processing power were decades away.

So here we have examples of some of the factors that distinguish an incipient opportunity from a real one: a well-defined customer with a well-defined problem, and of course technical feasibility to do something about that problem.