Home About Eric Topics SourceGear

2003-12-19 17:00:07

Make More Mistakes

Summary: In an effort to encourage new entrepreneurs, Eric spills his guts about the mistakes he has made and the lessons he has learned.

Robert Scoble, weblogger extraordinaire, recently said, "I want to see more software companies, not fewer." I heartily agree.

At the risk of being too obvious, let us observe that every ISV is started by an entrepreneur who somehow overcomes fear of failure. The genesis of a new company usually involves hundreds of hours of study, deliberation, and conversation, most of which is focused on a single question: "Can I make this business work?"

That process is healthy and necessary. It involves market research and number crunching and presentations and conjecture and coffee, all of which are critical elements of business success.

Invariably, the process also involves a great deal of self-examination. The core question isn't just "Can this business work at all?" but rather, "Can I make this business work?" This, too, is healthy and necessary. I've seen research studies that show that self-awareness is the number one factor in success. There is no substitute for knowing your own abilities and limitations.

But the self-examination stuff usually includes some basic worrying as well. Entrepreneurs tend to worry about the mistakes they might make. Unlike all the other research and study and deliberation that happens in the formation of a new company, this worrying actually isn't all that helpful.

To continue quoting only from the giants of the technology industry, let me now cite a remark made by Thomas J. Watson, Sr., founder and former CEO of IBM:

Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure. You are thinking of failure as the enemy of success. But it isn't as all. You can be discouraged by failure -- or you can learn from it. So go ahead and make mistakes. Make all you can. Because, remember that's where you will find success.  
-- Thomas J. Watson, Sr.

I don't think Watson advocated courage to the point of recklessness. After all, I'm sure IBM did plenty of prudent market research and planning during his tenure.

But Watson makes a very important point for new entrepreneurs: Mistakes just don't need to be all that scary.

Endless Decision-Making

Life in a small ISV feels like a never-ending stream of decisions, many of which you were never trained to make:

None of my college classes taught me how to make these choices, so I had to learn by doing. Actually it would be more accurate to say that I learned this stuff by doing it badly. In the seven years since I started SourceGear, I have made lots and lots of mistakes. Although the memories of my failures sometimes sting, the lessons I have learned have been so valuable.

Through all these mistakes I have learned an important distinction. Whenever a decision yields bad results we call it a "mistake," but actually "clueless errors" are quite different from "bad bets."

Clueless Errors

In high school I once cost my math team a trophy by writing down "102/17" as my answer. I did all the calculations correctly, but I failed to realize that this fraction can be further reduced to "6". Leaving my answer in the incorrect form was not a calculated risk--I simply did not see the alternative. My math team coach was quick to observe what a knucklehead I was, and he was right. This was a clueless error.

If any kind of mistake is worth worrying about, I suppose clueless errors qualify. These are the ones where you can't see the bad result coming.

We can take some consolation in the fact that experience helps. Over time, we will tend to make fewer and fewer mistakes of this kind. However, that's not helpful now, when you're trying to decide whether your new company is going to make it.

To some extent, you can reduce the likelihood of clueless errors by reading. Almost every successful entrepreneur is a voracious reader. But take care: it is possible to learn about entrepreneurship by reading, but only if you approach it properly.

Reading is not a place to find the answers to your problems. On the other hand, reading is a way to learn the background which can help you figure out your own answers.

Bad Bets

Sometimes a so-called mistake is actually just a calculated risk that did not pay off. You were aware of the possibility of the bad outcome in advance. You placed a bet that the bad outcome wouldn't happen, and you were wrong.

This is basic risk-taking. Study all the outcomes that might happen, analyze the probabilities, and make a choice. Remember to account for the fact that the status quo is a choice. If you don't want to become an expert at choosing your risks, then don't become an entrepreneur. A lot of your bets just aren't going to work out, but you still have to go back to the table and try again. There is no business without risk.

You also have to be prepared to deal with those who are waiting to gloat when your bets don't work out. When you take a risk and get burned, there will be a chorus of "I-told-you-so's" from people who would never have taken that risk in the first place. Sometimes their feedback is part of the learning experience, but not always. Perhaps their posture toward risk is simply different than yours. You are an entrepreneur, so by definition, you are somewhat more of a risk-taker than most. In all likelihood, your personal sphere includes at least one person who would fold with four jacks when the opponent has a possible straight flush.

Sometimes you have to ignore the naysayers. If you know the odds are in your favor, you can go back and take the same risk again, even if people think you're crazy.

My Stories

When I was interviewed after SourceGear won the Inc. 500 award in 2002, they asked me to share the biggest surprise of my experience as an entrepreneur. I told them my biggest surprise was that someone could make as many mistakes as I have and still end up on the Inc. 500 list. :-)

I often share the following advice with other entrepreneurs: "Make all the non-fatal mistakes that you can--don't make any of the fatal ones." Given that guideline, so far I'm rather happy with the mistakes I've chosen. As you are about to see, I've done some truly dumb things, but SourceGear is still in business today.

In the sections below I tell the stories behind some of my biggest failures at SourceGear. Some of these tales are really embarrassing, but they're still an important part of my history. I learned an important lesson from every one of them, and I have no regrets.

A Failed Project

SourceGear's first year of business was 1997. We started out by doing custom software development projects for companies bigger than us. In fact, one of our first deals was with one of the largest and most well-known accounting firms in the world. This project was a big opportunity for us to get a "banner name" client.

The project was to build a custom application to replace a very complex Microsoft Excel spreadsheet. The company we contracted with was stretching the limitations of Excel rather badly. We decided to build the application in Java. After determining the required features, we agreed to build the app for a fixed cost of $28,000 (USD). The project was a disaster.

We knew our bid was a little low, but we realized in hindsight that we might have underbid by an order of magnitude. When the project finally got killed, we had expended well over $100,000 in effort.

Lesson learned: Be careful about fixed-bid projects.

Circa 1998, betting on Java for a graphical user interface (GUI) application was suicidal. The platform simply didn't have the maturity necessary for building quality user interfaces. I chose Java because I was "head over heels" in love with it. I adored the concept of a cross-platform C-like language with garbage collection. We were hoping to build our Java expertise and make this exciting new technology our specialty.

But Java turned out to be a terrible frustration. The ScrollPane widget did a lousy job of scrolling. Printing support routinely crashed. The memory usage was unbelievably high.

I should have gotten over my religious devotion to semicolons and done this app in Visual Basic.

Lesson learned: Be careful about using bleeding-edge technologies.

Buying an Office Building

When I first started the company, I rented one room in an office building. As the company grew, we simply rented more rooms. Eventually we started talking about moving. After considering several alternatives, I ignored the advice of a wise friend and bought an office building. Within a year we outgrew the building and I sold it at a loss.

Lesson learned: Small ISVs should do software and stay out of real estate.

AbiWord

In early 1998, Netscape announced that the source code for its browser would be made publicly available. As a former participant in the browser wars, I found this news to be incredibly exciting. Somehow I knew that "open source" was going to become an important trend. I jumped on this bandwagon with both feet by launching AbiSource, an effort to build an open source office suite, starting with a word processor.

I had a big vision. I predicted that a wave of open source and Linux IPOs would happen and that AbiSource would be one of them. I began writing business plans and preparing to get funding. We wrote code like mad and unveiled the first public release of AbiWord at the O'Reilly Open Source Developer Day in August 1998.

AbiWord turned out to be a great way to get buzz. People really liked the story. Our tradeshow booths were packed. The press considered our idea a novelty and liked to write stories about us. In perhaps the strangest piece of attention we received, a Microsoft exec mentioned AbiWord in the antitrust trials (referred to on page 16 of the transcript) as evidence that Microsoft Office was facing viable competition.

But although AbiWord was fun, it was never much of a business. Our funding search didn't go very well. The buzz of AbiWord got us in the door, but we always walked out with no money. Tim O'Reilly said no. Bob Young said no. Frank Batten said no. Bill Kaiser said no. Hindsight confirmed these gentlemen to be as smart as we all know them to be.

Hadar Pedhazur also said no, but he said more than that. Hadar is probably the most "clueful" venture capital guy I've ever known. He spent a lot of time talking with me, and eventually convinced me that it would be extremely difficult to make the AbiSource business model work. The research and development costs of a word processor are simply too high to give it away. After my discussions with Hadar, I made the decision to abandon AbiWord as a business. (At the time of this writing, the AbiWord project continues to move forward as a community project.)

Lesson learned: Investors don't like low-margin business models.

RADish

After the death of AbiWord, the prevailing question in our company was "What now?" We still had a moderately successful developer tool product, but we wanted to do more, so we continued looking for new business ideas. We weren't ready to give up on the open source world, so we decided to get into developer tools with an open source twist. We designed a product which we code-named "RADish," intended to be "the Visual Basic of Linux." Suffice it to say that this idea didn't last long. Visual Basic is mostly about rapid development of desktop apps for the corporate environment. Linux didn't (and still doesn't) have any substantial penetration in that space. RADish was designed to solve a problem that almost nobody has.

Lesson learned: A market with no competition ain't.

A Weasel

It seems like ancient history now, but during my AbiWord and RADish days I really wanted to get some outside capital funding. I was watching the dotcom bubble produce ridiculous valuations and I wanted my company to play, too. I pitched my business ideas to all kinds of investors. When that didn't work, I decided to hire someone to do the fundraising. This turned out to be a big mistake.

I should have heeded the advice of Doug Colbeth. Prior to starting my own company, I worked as a programmer for Spyglass, where Doug was the CEO. Around the time of the Spyglass IPO, Doug humorously explained to us the hierarchy of the world's true scumbags:

Of course, not all investment bankers are bad eggs. Still, there is some irony in the fact that Doug's joke turned out to have a grain of truth in it in my experience. When I was in my "funded company" funk, a guy whose firm specialized in raising private placement capital for small companies contacted me. I ended up signing an investment banking agreement with this guy who promised to connect us to some investors who had a whole bunch of capital. As you can already guess, this guy's help gained us no investors.

Lesson learned: The negative connotations of the word "middleman" are often deserved.

Believe it or not, this tale gets even worse. I failed to have an attorney review this agreement, and it had a big problem in it. We ended up paying this guy $40,000 cash to cancel the agreement.

Lesson learned: All contracts must be reviewed by an attorney. No exceptions.

Investing Outside Our Field

I wish working with the investment-banking weasel was my worst financial decision. Unfortunately, it doesn't even come close.

In the fall of 2000, we were hoping to get more involved in building high-end websites. Somebody introduced us to a newly formed print magazine that had big plans for expansion. The people producing the magazine were looking for seed capital as well as for a technology partner to help them get their magazine onto the Web. We decided to jump in with both feet.

In the end, this deal turned out to be a financial nightmare. They never found any other investors. They never paid us for phase 1. Phase 2 obviously never happened.

Lesson learned: Cash is supposed to flow from your customers to you, never the other way around.

Building the Platform Under the Application

Not all of my boneheaded moves have been financial. I've somehow found time to work in a few truly ridiculous technology choices as well.

After failing at word processors and magazine publishing, we decided perhaps it was time to refocus on our core competency: developer tools. Through it all, SourceOffSite had continued to be our flagship product. In late 2000 we decided to build another edition of SourceOffSite with some more collaborative features built in. This product (which we do still sell) is called SourceOffSite Collaborative Edition, or "Collab" for short.

Actually, Collab has thousands of customers and they generally like it very much. It's not a bad product at all. The biggest problem with Collab is that we spent far too long building it. We built too much of the underlying platform instead of building on the platforms which were already available.

Everything crystallized for us at the 2001 Professional Developers Conference. Listening to all the presentations about the new Microsoft .NET, we realized that we had created from scratch our own implementation of Web services, completely incompatible with any other.

Lesson learned: Small ISVs should build apps, not platforms.

Summary

As I write this, it has been just over two years since the 2001 PDC. In hindsight, that event was the time when many of the lessons I had been learning really started to get put to use. Just after that PDC, we made a lot of tough decisions about our company direction. We got ourselves out of the contracting business, which allowed us to focus exclusively on our own products. We decided to build Vault, which has been very popular. Since then, SourceGear has hit its stride and found its identity. In the future, we will face new challenges, and once again we'll try to figure out which are the best risks for us to take on.

As you can see, I've made some clueless errors and I've taken some risks that didn't work out at all. These mistakes dovetail with my successes and form my history. Truth be told, every CEO has similar tales to tell. If everybody told their stories, we would almost certainly see that success and failure are as strongly correlated as Watson said.

I hope you have read these stories and said to yourself, "I can do better than that!" These stories are my contribution to stamping out the fear of failure. As Scoble said, we need more small ISVs, not fewer.

Eric Sink is the non-legendary founder of SourceGear, a developer tools ISV located in Illinois, which offers the worst weather patterns of any inhabited region on earth (or so he claims). His weblog is at https://ericsink.com/.

This article originally appeared on the MSDN website.

Copyright 2001-2023 Eric Sink. All Rights Reserved

If you are in need of contract software development services, I would appreciate your consideration of SourceGear.