Print this page
by Harley Zipori
The Analogy
I like analogies. I especially like those that are vivid and graphic and speak to large numbers of us. Building a technology company, startup or otherwise, is a complicated, dynamic and, I hesitate to say, even chaotic, activity. I tried to think of another human activity that parallels this at least in some ways and I think I've come up with one: sailing the oceans. Actually … sailing in the good old days at the time of Columbus in wooden sailing vessels. Let's look at the parallels:
- Both are done in vessels made by a group of people. Startup companies are like smaller sailing vessels. Big corporations are more like clipper ships. Columbus was a startup.
- Navigating the ocean (or the ocean of business) is a tricky business, subject to winds and tides and other elements beyond our control.
- Our ability to navigate these aided by only the most primitive tools. In Columbus's case he had primitive maps and perhaps a crude sextant. We have marketing surveys and the media, the modern maps for navigating our technology companies. Columbus's maps only went so far, and showed the edge of the Earth with notes like "Monsters be here". There is, of course, a big difference between these maps and a marketing survey. The warnings on the maps of monsters and the edge of the Earth were myths, while the oceans were quite real. In a marketing analysis, the description of the market and its potential (the analog to the ocean) are myths, while the very real dangers of falling off the edge or getting eaten by monsters are unmentioned, unmarked and undreamed of, but quite real.
- You may be sailing along smoothly, but at any moment the environment can turn quite nasty, develop into a big, nasty storm … and sink you.
- Pirates could appear at any time, shooting your ships to bits, capturing your crew and plundering your assets.
- When you get somewhere, you may think you know where you are, but in actuality, you may not have a clue as to where you truly are.
- When you have finished your voyage of exploration and returned to your homeport, people will have trouble understanding where you've been and what you found, even if you bring a captive or two to show off.
- The actual results of your voyage will not be apparent, even if you think they are. It may take quite of bit of time to see the real results, and you may not be the one to profit from them.
- If you don't bring back the gold and jewels the sponsors of your voyage expected, you might lose your head.
Gee, this is fun … and I'd like to go on, but the parallels get weaker and I think the point was made.
Apart from being fun, these analogies can be quite helpful in providing perspective on our activities in technology companies.
The Voyage
Let's say you are living in the times of wooden sailing vessels and crude maps. You hear of a huge hoard of gold in a far-away land, guarded by a primitive tribe of people. This information is from a reliable source and you do not doubt its veracity. You do some quick calculations and figure that even a small hoard of gold and jewels will cover the cost of mounting an expedition and provide a handsome profit. You create a business plan that reflects the realities of carrying out such a venture. OK, so you minimize the risks, lowball the cost of building the ship and hiring the crew, and slightly (but only slightly) exaggerate the size of the treasure as reported to you.
Armed with this beautiful parchment document, containing elaborate illustrations, and written by the best scribe you could find, you make the rounds of the local moneyed crowd and manage to round up the necessary cash to get the expedition off the ground, in exchange for a percentage of the haul.
You start out building the beautiful ship you designed, but after you get the shell built, you realize that it cost quite a bit more than you estimated and now you have to start cutting back. So you outfit the ship with less of everything, but at least you leave lots of room for the treasure. You also don't have enough money left to get the large, top flight crew you want, so you get a couple of stars and a few regular sailors to raise the sails and swab the deck. You yourself will be pilot and navigator.
You also need a few soldiers, but instead of the large, professional and experienced team, you have to settle for a smaller, scruffier and less disciplined group of mercenaries. You promise them a share of the loot in exchange for coming along.
Still, all in all, you are quite pleased with the venture you have created and with the highest hopes and enthusiasm, you sail off into uncharted seas. Needless to say, the voyage is longer and harder than expected. There are fierce storms and days of doldrums. The crew gets edgy. The mercenaries are complaining that the sailors can't move the ship fast enough. The sailors are convinced that the soldiers won't be able to fight a band of street ruffians, much less a group of savage natives guarding their holiest treasures, but they keep it to themselves. After a while the crew is hungry, thirsty and disenchanted.
Finally, you sight land and find a sheltered bay to go ashore. There you are greeted by the natives, who tell you that the tribe you seek is large and fierce and live on the far side of a rugged range of mountains and thick jungle. The mercenaries claim that they didn't sign up for a trek across mountains and jungle. It's not in their contract. If your information about where the tribe was and its size was wrong, it's your problem. The natives are not willing to provide you with enough porters and guides anyway. The sailors complain that they can't wait around for months while the mercenaries try to liberate the treasure, and demand more money on the spot if you want them to wait for you. You realize that you must go along, leaving the natives and scruffy sailors guarding your ship.
You are disheartened and reach the conclusion that for now, at least, the treasure is out of reach. You start planning the next voyage with a trustworthy partner who can stay with the ship and a larger, more reliable band of mercenaries with a lot more supplies. You have to raise more money.
However, these natives have a few things of interest. Let's say they have an exotic hardwood that you can make beautiful furniture out of. You don't have much to trade, but you have some tools they don't have, so you put the crew to work felling trees and building houses for the natives. After a few months of toiling in the tropical heat, you get your hardwood trees and sail for home. You figure that if you make a few more trips like this, you can cover the cost of building the ship and hiring the crew and maybe even see a small profit for you and your investors.
Back to the Future
Now, let's jump forward to today. As we look at this story we, as modern, creative thinkers might find the assumptions of our fictional entrepreneur rather weakly based and his optimism out of place. However, the story allows us to step back and maybe see where the parallels are and maybe, just maybe, learn a couple of lessons.
Everybody knows that in high tech, and in startups in particular, you must be agile. Fast on your feet. If the market demands a change in your product, then you have to make the product suitable to the market. It's one of the basics of any business.
Your original goal was to develop the technology, turn it into a product and sell the product, allowing you to recoup your investment and realize a good profit. Maybe you want to sell it as shrink-wrap software or a large system involving installation and training so that other people can use your technology to set up services for end users.
There is a trap here, though. You go out trying to sell you technology. It's really just a technology at the early stage, not a finished product. It requires testing. You call it an alpha or beta or whatever. You have a demo and travel around showing it to what you consider prospective customers. These prospects are those people who you figure will benefit directly from using your technology.
It's a tough sale. though. The people you talk to are not just unsure that the technology you show them in the demo is good enough for a production system; they are not even sure that they will benefit monetarily or otherwise from what you are trying to sell. After all, it's a new technology and not just a better version of something else. Who knows if it is useful? How will it generate income? You may have a revenue model or ROI analysis, but are you right? You have no income generating installation. How can you prove it to them?
The logical answer to that question is obvious. You agree to a 'pilot' project. You will set up a working system for them at no cost, and they will see for themselves that the promised benefits will be there.
It's easy for managers of startups to be seduced into adapting their technology to a live pilot, early in the game. This has two immediate, apparent benefits:
1. It forces the development team to take the path of least resistance to a workable system, and
2. It allows you to test your vision of the product against an actual 'customer'.
Doing an early pilot is an idea that's easy to get infatuated with, but there are some obvious and not-so-obvious drawbacks. However, one of the immediate effects is not desirable at all: the company changes from a technology developer/provider to a service provider.
Let's think for a moment what that really means. Web hosting services are an excellent example. For a fee, they will design a set of web pages and place them on their server. They charge money for the site design and from that, they pay their graphics designers, HTML writers, Java coders, and overhead, and maybe have a few dollars left as profit. Maybe. For the hosting, they get a fee every month from which they pay for the fast Internet pipe, hardware, system managers and overhead. Again, maybe a few bucks a month for profit. Today, you can get a site designed for a few hundred dollars and hosting for less than a hundred a year. Do some math here and you will see that you will be hard-pressed to take a business like this to the NASDAQ. Even in the height of the high tech hysteria, nobody built a business plan on a commodity service model.
But I'm not talking about companies with commodity technology. Their technology is supposed to be unique or, at least, head and shoulders above anything similar. The problem here is that the people offering the services provided by the technology aren't enamored of technology itself, but tend to see things from their customers' point of view; their customers being the end users. Sure, somebody else can do it without the quality, features and bells and whistles, but you have to be very careful in justifying your providing the service at a cost at an order of magnitude or more than the lesser technology.
OK, so you agree to do the pilot for free or for some delayed payment based on some mutually recognized formula for a successful implementation. Now, the technology is not quite ready for prime time, so the entire development team concentrates all its efforts on making things work right and look good. After all, it's not a product. The people who are building the service intimately know the inner workings of the technology. No manuals necessary. No tech support. What a deal!
So, you start tailoring the product to the pilot. You cut a few corners. Dumb it down a bit. The customer starts coming up with ideas and you start implementing them quickly. Your people are concentrating on content. You have to solve immediate problems of deployment and upkeep. In short, all your technical efforts are now oriented to providing a service to the customer. You are focused on getting the service up and forget about getting the product to the market.
Of course, the CEO will still talk about long range goals and the need for a phased approach and the importance of people seeing your technology at work.
However, one thing for certain has happened: technology development has stopped. Fixing bugs and creating patches for adding requested features does not replace the development of the core technology. The team loses its development focus. People are disenchanted. In a good job market, some will leave.
What happened?
- The core technology may not be solid enough to use. We are not talking alpha here, we're talking demo plus.
- Not enough money was raised for the development, which advanced at a slower than expected rate.
- The investors wanted to see results. Maybe they were promised too much in the first place. When the promises aren't fulfilled, they understandably get nervous.
- Progress on the technology stops. All effort is focused on bugs, aesthetics, deployment and molding the demo to the customer's wishes.
- The customer wasn't impressed by the limited capabilities, especially considering the proposed price tag associated with the service.
So what can be done?
Well, armchair football coaches are a dime a dozen and it's easy to be wise when it's not my company and my you-know-what on the line. Nonetheless, a few carefully phrased conclusions may help those companies that are facing similar situations.
Be aware that a situation like the one I described is possible. Especially for a software technology company. Hardware is much less forgiving and it's less likely to be possible to do that early pilot.
Discuss the issue with the investors and clearly state the commitments and importance of developing the technology to the desired level of quality and reliability.
In our post high tech crash world, getting your technology out into the real world is not a luxury, it is a necessity. Nevertheless, you must realize what the long-term implications are.
The most important method for avoiding these problems is one used by larger, established companies. Set up two separate development teams. One works just on the technology and the 'product' and the other works on 'projects'. This does not mean doubling the development budget, but it is important to properly fund both activities or else nothing will get done right.
It really boils down to one thing not to forget: The company you are creating builds technology and products. It does not provide fee-based services.
Harley Zipori has been developing software and engineering systems for a number of years. More than he cares to remember or admit to, actually. He has been involved with the development of new technologies and products since the early 80's. The first project he worked on as an engineering professional just crashed into Jupiter in September, but he would like to stress that it wasn't his fault.