Adventures in Product Development

With eight current software titles, thirteen years in business, plus several additional programs OEMed by other companies at one time or other, we thought it might be fun to talk about failed products. At Sagebrush, every project kick-off starts with a new notebook. The bookcase behind me has a shelf of notebooks with zero net sales, to serve as reminder/warning/inspiration/goad. In no particular order, here is a list of incompletions. Names are obfuscated, product descriptions are non-specific (in case we dust off a project and hit “Restart”), but perhaps we can convey an idea of the twists and turns of real-world product development.

Axxxxxx used sound in a novel way to control a computer. It was a cute idea, but not terribly practical. We marketed the title, but sold zero units, so the title was quietly withdrawn. Benefits/Lessons: Technology developed for this project was reused for our most successful title at that time, allowing us to stay in business.

Txxxxx used hardware currently on many computers to do a useful and novel task for which the hardware was not originally designed. The hardware was not a precise fit for the task, had buggy Windows drivers, and later the hardware became vestigial and started disappearing from new computers. We made a working prototype, but limitations were significant, and we judged most users would prefer a different solution. Recently this project restarted when improved hardware was discovered. We planned to sell a hardware-software bundle, but the price of hardware was too much to compete against alternate solutions, so we shelved it again, but not before burning a few additional man-months. Benefits/Lessons: A new sales strategy will spur development of several new products.

T2xxx used technology from Txxxxx to prevent numerous interruptions in a work week in a most satisfying manner. We got a prototype working, but federal regulations changed to remove the interruption just before we finished version 1.0 . Benefits/Lessons: Life is hard.

Ixxxxxx was a departure in our product line in being aimed at software developers and not audio/music related. Several similar products were available from competitors, but we could have a market advantage by producing much smaller file size than the competition. As Internet speeds and disk sizes increased, the potential market window closed before we could get very far with the large technology investment we needed to make a good tool. Benefits/Lessons: Stick with what you know, or be very fast.

Rxxxx used technology related to Ixxxxxx above, but was a different tool potentially useful to software developers and content providers. Someone else produced a similar freeware tool, later open source, that removed our incentive to complete. Benefits/Lessons: We killed this early enough to avoid much pain. If you must kill, kill early.

Mxxxxxxx re-used some of our existing code to improve upon an existing operating system function. Later improvements in sound card support made this obsolete before we could complete. Benefits/Lessons: Looking back, what were we thinking??? It was technically sweet, but no one would have paid good money.

Rxxxxxxx is similar to an existing product, but works on a different computing platform. We got a prototype working, but the many program features would require extensive testing. Soon after first prototype, sales of the target platform plummeted. Benefits/Lessons: We improved our method of partitioning code, used for several later products.

Axxxxxx used the computer to implement an expensive piece of dedicated audio hardware. We got an early prototype working, but sound device latency for most sound cards made the product unusable. Benefits/Lessons: We really should have done more latency testing before playing with a cool GUI front end. We were able to reuse some code on a project currently in development.

Mxxxx worked like an existing product, adding streaming over a network. Our atypical requirements forced us to create our own streaming method, instead of an off-the-shelf solution. Our solution was not reliable. Benefits/Lessons: Streaming is hard.

Rxxxxxx worked similar to an existing product, with Internet streaming instead of hardware. A working prototype was too slow for regular use, we weren’t certain about restrictions imposed by the Digital Millennium Copyright Act, and the industry went in a different direction, partly due to regulations issued by the Copyright Office. Benefits/Lessons: Cool GUI elements were reused in later projects. A method of interfacing to other programs was copied in two products.

Ixx was developed in parallel to Rxxxxxx, using video instead of audio. It worked, but was too slow to be pleasing to operate. Benefits/Lessons: Beware of doing projects in parallel. Switching back and forth may be fun and keep energy levels high, but the consequence of double-failure is huge.

Cxxxx combined video and real-time processing in a novel way (at least for general-purpose PCs). A working prototype worked, barely, but not reliably enough for deployment. Eventually we might revisit and solve the main technical issue. Benefits/Lessons: Code for text overlay was salvaged for our latest product.

And there you have it: more misfires than current products. I didn’t even realize before completing this post. Forget we said anything.