Lessons Learned from a Failing Dot-Com
|
[next] |
Lessons Learned from a Failing Dot-Com
By Kathy Pendracky ( dhamu@access.hky.com ) For the past five years I have experienced one of the most interesting and exciting times of my career working for a start up Dot-Com. Our little company was wildly expanding and offering a full range of Web-related services from building storefronts to housing catalogs, with the option of even going so far as to provide procurement services for the goods. And, with our government procurement services expanding, we were pretty comfortable with where we were going. Even so, when the entire commercial end bellied up a few weeks ago and we found ourselves out on the street, many of us weren't completely surprised by the turn of events. As a company, we learned some critical lessons too late. If we had taken steps much earlier to just ensure that a few key points were part of our operating plan there is no doubt that our little company would be thriving:
- Define your niche in the marketplace and market it aggressively.
- Decide what your strategic goals are and stick to them. Be the first to grab the spotlight with a new idea and run with it. For too long and until it was too late, we continually shifted our priorities and game plan. We moved much too slowly after we built our initial storefront, before effectively and actively marketing an idea that was leading edge at the time. The IT group, and not marketing, produced the viable ideas and products in the early years and marketing struggled to catch up, initially understanding neither the technology nor the idea and its ability to succeed.
- Don't give away the store.
- It's easy to entice new customers or renew contracts by giving away or charging nominal fees for software and/or support, but somewhere a line has to be drawn when costs of production far exceed the return on investment. For several years we had too many clients with too high expectations of free services because of precedents that were set by eager sales staff.
- Define your underlying architecture carefully.
- Otherwise you risk losing customers and find yourself spending generously on conversions, internal training and outsourcing. One offering of our commercial area was to build storefronts and catalogs for customers. Within the time span of a few short years, our catalog architecture radically changed from a C-based non-parametrically searchable catalog to a packaged Oracle / DB2 based package that required expertise in C++ and several languages of its own. Finally we moved onto ASP / JScript / SQL server catalogs. Not only did our internal staffing have language and technology hurdles to overcome in the continual shifting, but our customers found themselves forced to accept catalog re-engineering from presentation, search tree structures and searching parameters and functionality. In some of the shifting, they lost some functionality that they relied heavily on. If the catalog was housed at a client site, every time we shifted our underlying database, we effectively forced the client to procure minimal DBA expertise in that particular database. In some cases, our UNIX based clients were miffed when we dropped support of earlier technologies and required them to switch operating systems and buy additional hardware or third party products.
- Define Responsibilities/Stress Good Communication.
- Having seen three CEOs within about the same number of years, the continuous managerial shifting spiraled downward and produced a chaotic state internally. If the company had already been stabilized in terms of defining site and group responsibilities early on, the management turnovers would have been less disastrous. As responsibilities continuously shifted, communications suffered. In many cases, other sites had no idea which group should be contacted at a given time for specifics. Interfaces were built between systems that often were lacking in key requirements because people weren't talking. At times, people weren't talking not only because of not knowing who to talk to, but often for fear of losing their little niche in the company to another site (which could happen at any time).
|
[next] |
Created: March 8, 2001
Revised: March 8, 2001
URL: http://webreference.com/new/lessons/

Find a programming school near you