Case Study ( Entrepreneurship_Failure)

Learning from Failure: A Case Study in Entrepreneurship

“Success is simply a matter of luck. Ask any failure.” Earl Wilson

Introduction

Most entrepreneurs enjoy reading the success stories of technology companies and their leaders, both local and global. Depending on the entrepreneur's disposition, these stories can be motivational, such as when the entrepreneur can identify with the hero, or they can add pressure, such as when the hero sounds less capable than the entrepreneur perceives themselves to be. Stories of success are so captivating that we forget that most of what we do as a technology entrepreneurs will be classified as failure.

If an entrepreneur is in this game for the long haul, they will fail so many times that they will no longer differentiate failure from success, because like any human endeavor that improves with practice, the art of business building is a steady march of preparation, timing, execution, and aftermath. And while the current opportunity landscape lets us attempt more experiments than were possible in the past, this only means that we can fail faster and cheaper, ultimately failing more often.

While most of the stories we hear are written like victory speeches, this story is about failing. In this particular case, the story is not about failing particularly fast or cheaply; in fact, the story is perhaps even about failing at failing well. This article is not meant as a means of helping you avoid failure, but instead hopes to serve as a signpost. To quote J.S. Cournoyer, "this is who you're competing with." By sharing failure, we all stand to gain by the perspectives of similar people working towards similar goals. If we have no stories like these to tell, we might think our world is made of shining stars and obvious frauds, rather than the richer landscape of many talented, inspired individuals who are earning success one failure at a time. If we make that mistake, we might not even try.

Background

In the summer of 2009, I was finally coming to terms with a previous failure to build a business in the dating industry. I was a victim of something I like to call the "Frind Paradox", named after Markus Frind, the programmer that created the Plenty of Fish dating site that, despite its many technical, security, design, and character flaws, and much to the chagrin of a crowded marketplace with demonstrably better solutions, continues to generate more than ten million dollars in advertising revenue annually. The paradox is defined as the mistaken belief that a terribly executed plan plus perfect timing is always defeated by a well-executed plan after the fact. (Hint: it is not). Eager to start another chapter, and with the encouragement of new colleagues in a new city, I began development on Lunarbits, an e-commerce platform for selling digital goods.

I had a vision for a platform that gave absolute control to the content creator, whether they wanted a traditional "one URL equals one download" type of experience, or whether they wanted to stream video content within a browser to a subscriber base. In effect, Lunarbits was meant to possess all of the flexibility of Shopify, without the out-dated transactional approach to content purchasing of Fetch or Pulley, or countless other market participants.

Shortly after the initial flurry of excitement and imagination of what Lunarbits could be, I began product development. The Lunarbits brand was a happy stroke of luck, as I had found the logo (Figure 1), complete with its nerd-chic design, on BrandStack, an open marketplace for brand identities. In hindsight, the name Lunarbits is not a great brand name. It suffers from not having an obvious relationship with the proposed solution. This issue is especially problematic for products competing in the consumer Internet. I had chosen to focus my first marketing vertical on technical content producers - software developers like me that thrive on teaching others - and wanted to look like PeepCode, a popular screen-casting platform, while doing it. Using my own passion about a frustration I had, I replaced my own individual desire to solve the content delivery problem, with the intention of solving it for anyone.

The immediate next step was applying for, and being accepted into, Ottawa's Lead to Win program. Lead to Win is a six-day, intensive, business-building exercise put on by successful entrepreneurs in the region who are passionate about growing opportunities. Through a series of keynotes, peer evaluation, and private planning, culminating in a "big pitch" to a small group of successful CEOs and investors, business ideas are put through the ringer to determine if they, and the people behind them, have what it takes to become successful technology businesses. Each business that passes the evaluation is tasked with creating at least six jobs within three years. Lunarbits was put to the test, and came out the other side with the green light: "Go build this!".

Validation Is Not Enough

In many ways we are seeking permission, from people with experience, from informed business theory, and from ourselves, to invest a significant amount of time, effort, and money developing our vision. The thinking goes: if our plan is validated, it stands a much higher chance of succeeding, and the sacrifice is worth the risk. But validation is not enough. In many ways, the act of validation is a brilliant way to postpone the hard work, because it takes you out of the details of delivery and you become engaged in a socially acceptable form of pretending through financial forecasting, customer and market analysis, and partnership development. With Lunarbits, validation was never the problem; on paper, Lunarbits is still a viable business and its competitor landscape remains largely unchanged after two years. However, that does not mean it is a good idea. And that does not mean it will not fail for countless other reasons.

Mockups Are Not Enough

We often hear abstract lessons about failure, but there are plenty of concrete reasons for projects to falter. One of them, which applies more specifically to software but has broader applications, is designing without mockups. This approach assumes that the vision of your business has its own natural metaphor that can express itself in software without disciplined work. With Lunarbits, I paid up front for quality graphic design of the website (i.e., the brochure), admin portal (i.e., the back end), and default store theme (i.e., the marketplace). When I met with the designer, I had an idea of how the application should "feel", but I only brought feelings to the table. I thought that my vision was obvious and that the design would be self-evident. It was not. I was surprised to find myself tongue-tied when asked simple questions, such as: "What happens next?" with respect to customer workflow.

By the time I realized my mistake, I was already too stretched financially and emotionally to turn the corner; I would need to rewrite Lunarbits to fit the metaphors I learned building it, which I could have learned if I had "built it out of paper" first.

The lesson is that you cannot know the generic without attempting the specific. I now recommend to everyone that there are two very specific stages that you should go through before you spend a cent on graphic design. The first is using a mockup tool (or a good pencil and pad of graph paper) to outline every screen of your application, even those that seem obvious to you. Make copies, and then assemble them into "decks" that represent tasks your customers need to perform, such a "sign up for an account" and "upload a new video". When you can see all of these interactions clearly, the next step is to throw them away.

Going Alone May Not Be Enough

I have always been an advocate of solo entrepreneurship. I consider myself a "code soloist", someone who has the imagination to solve a problem and the broad base of technical and communication skills needed to build it with their bare hands, with the exception of graphic design, which should never be left to software developers or other mere mortals. Yet, over time, I have learned that certain categories of problems need teams, no matter how ambitious or capable the soloist. It is more a question of simple human dynamics than it is about the character of the person. People are energetic beings, and we cannot sustain a high degree of intensity or capacity for work indefinitely without encouragement and consistent feedback, which are impossible to provide for yourself.

Building a technology business is a grind. Like any stressful, all-consuming journey, you need supporters, both for accountability and momentum.

With Lunarbits, I made the mistake of continuing despite an inability to form a team. Left alone long enough with the massive task of architecting a platform that could be used by anyone, I lost interest. I attempted to manufacture a technical support team by extracting components of the underlying infrastructure and offering these components to others under an open source license, hoping that releasing them would attract other developers to my cause. Do not do this.

Scratching Your Own Itch May Not Be Enough

A compounding problem of "scratching your own itch" is that wanting something for yourself is not the same as wanting something for everyone. While it is easy to make imaginative justifications for how others will benefit from the solution to a problem you have, and while you may even represent a large market of solution seekers, it is a mistake to think that a solution that solves your problem is generally useful as-is. Entrepreneurs grossly underestimate the amount of time and effort it takes to take a working concept and make it widely available, stable, scalable, and supported. From a design perspective, interactions that make sense for a prototype are rarely well received by the general population without refinement. An additional problem is that once the solution works, the entrepreneur's problem is solved. This takes away the motivational leverage, but leaves a large body of work that seldom resembles the original problem and has more to do with maintenance than creation.

Big Ideas May Not Be Enough

Sometimes the big vision we have cannot be solved well for all of the people, all of the time. This is a curious property of big ideas: they all start with an optimistic burst of energy that seeks to topple the status quo, but their proponents forget that the existing solutions did not spring up out of a lazy person's mind, and it is a mistake to take any of them lightly, no matter the apparent gap between a new idea and their reality. To maximize your chance of success, when faced with a big vision that cannot be solved well for all of the people, all of the time, the correct response is to shrink the vision, or get a new one.

Conclusion

In the end, Lunarbits failed not because it was a bad idea, because nobody believed it would work, or because its team was not capable of creating it. It failed for regular, human reasons. I simply could not sustain the effort long enough. I did not spend enough time up front getting the experience nailed down before spending my budget on a designer. I did not find a co-founder even though the scope and effort required to execute a full-scale platform clearly demanded it. I spent too much time generalizing infrastructure details hoping for external collaboration through open source efforts. I kept pursuing a huge problem I could not solve alone in an acceptable amount of time, for the widest possible audience. I did not interpret the lack of market movement as a possible warning sign that there was not a strong market to begin with. I mistook my own problem of needing a flexible content commerce application to warrant a common and widely desired solution. I scratched my itch for so long I forgot what I was scratching. After two years of hard work, I could not access any of the original inspiration I used to feel. The problem was, and is, "dead to me".

I do not have a success story to tell today, but I will in the future. I will because I recognize that success and failure are identical experiences of effort and learning, but have different outcomes depending on whether a lesson is truly learned, rather than merely witnessed. It would be easy for me to postpone telling my failure stories, choosing instead to reminisce on them fondly and cite them in victory speeches, but the truth is that these painful experiences are most of what we do every day as technology entrepreneurs. These stories are important. The more we share them, and the data behind failing, the better chance we all have of understanding where we fit, and learning what we need to take the next step.

Questions

1. Identify 5 mistakes made by this entrepreneur during the start-up of the business

2. Develop an action plan that could be followed to avoid unnecessary mistakes