You are on page 1of 7

Learning from Failure: A Case Study in

Entrepreneurship

June 2011

Daniel Crenna

Success is simply a matter of luck. Ask any failure.

Earl Wilson

Abstract

Business ventures often fail even when market demand is demonstrated and evaluated by
peers, and when the project team is capable of producing the work. In this informal case
study based on the author's own experiences, the topics of market size and fit, team size,
human dynamics, business validation, and interaction design are explored to form a picture of
how a business with seemingly promising prospects could still fail. Specifically, the
challenges faced by small or single-person implementation teams are discussed, with
suggestions for overcoming these challenges to produce more realistic and viable businesses.

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 endeavour 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.

Figure 1. The Lunarbits Logo

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

Regardless of the size of the team, we routinely seek out the counsel of others when
determining the potential value of a new venture. We support this idea culturally with
business incubators, angel and venture capital investments, and strategic partnerships or
ecosystem development. 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. These are important tasks that I believe fit
further down the spectrum, certainly after the initial launch stage, where validation is no
longer on the radar. When you are in the thick of it, there is some small solace in knowing
that other people approved and believed in your vision, but putting too much stock in others'
armchair business development keeps you in your own metaphorical armchair, away from
making real progress that can be validated by paying customers, or a lack thereof.

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.

The reality is that front-end work is one of the most challenging details of a business, because
it is the most obvious to the customer. It is easy to take great design for granted, and that is
half of the trap, believing that it is an afterthought. It is not the pudding, it is the proof. Rather
than put the brakes on Lunarbits until I had articulated a complete picture of how the
application would work, I had the designer work on a basic concept, and I hoped I could slice
and dice and reuse most of the general layout to fill in the blanks for development areas I had
not fully imagined. This ended up being the kiss of death, because I spent more time trying to
jam an evolving application into the design elements I already paid for, rather than start over.
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.

Mockups are not enough. They are a great mental exercise, but they do not go far enough in
preparing you to truly know what you need from a graphic designer. Instead, you should
build a live interaction system, which is essentially the entire application, using an
unremarkable, unbranded theme. You can find clean, standards-compliant software
application themes from many online stores, though I have the most luck with modern
treatments at ThemeForest.net; these themes typically cost less than $20, but they are
priceless in that you can reassemble them into any of the screen designs you created at the
mockup stage. This live interaction system will allow you to build out your project from back
to front. Hire the designer last, but start the design first. This approach will pay off both in
terms of the ownership you will have over the vision of your product and in the amount of
input you will be able to provide to get the design you need the first time.

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. They cannot be the kind of
supporters that do not understand the problem space you are trying to tackle, have their own
focus and projects, or are able to separate themselves emotionally and financially from any
challenges that come up. Those kinds of supporters are called "friends", and while they are
essential for your well-being, they are not enough. Your true supporters need to be in it for
the long haul, and take on as much risk as you. These kind of people are called "co-founders",
and you need them if the kind of business you are building solves a problem your mother can
understand. In other words, if your business is well understood by non-technical people, and
it is trying to provide value to "anybody" (which is itself a sign of business planning
immaturity), the market you are after is so horizontal that there is little hope of achieving
success without a team.

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. The overhead of extracting takes you far away from shipping anything
tangible, and the myth of external contribution coming in a timely fashion, or for areas that
really need improving, is a vicious one. Nobody ever built a business with crowdsourcing
alone. Open source is an effective strategy for business development in a variety of situations,
especially when the core product is a platform used by other developers, or seeded to the
general population as well-documented, well-loved hosted platforms like WordPress. But I
suggest that, for hosted solutions that are charging monthly service fees up front and rely on
execution as a key market differentiator, there is simply too much pressure to ship and too
many proprietary aspects that must be carefully separated from any potentially sharable
infrastructure. The time and effort needed to open source before you have shipped your first
version will have a direct impact on your momentum, which is the most critical "soft" value
you have in the beginning. Save open source for when you have already established a first
version and are looking to improve cheaply, rather than gamble that the mere idea of open
source's potential, with no concrete examples, will be enough to gain developer confidence
and support.

Scratching Your Own Itch May Not Be Enough

A lot of the time, we take colloquialisms at face value because we expect a "truism" to be
true. That is why it is easy to read and believe sentiments like "scratch your own itch" - the
idea that a virtuous circle is created by the entrepreneur that is simultaneously solving a
problem that they themselves need solving, while at the same time being uniquely suited to
solve it. There are clear benefits to this strategy beyond capability, especially as an antidote
to the mistake of "going it alone", since the creator is intrinsically motivated by a real
frustration where they can see a solution and are capable of producing it. A lot of effort
normally destined for user stories and usability testing is liberated by the entrepreneur's
ability to use themselves for feedback.

Often what we want for ourselves is not generally useful to others, at least not in numbers
high enough to justify the time and cost necessary to see an idea through. As entrepreneurs
tend towards a narrow and focused view so that they can find underserved markets, we also
have unique needs. With Lunarbits, my initial frustration was that there were no turn-key
options for remixing and selling digital content (specifically instructional videos); existing
solutions did not have the flexibility of a hosted storefront or the ability to restrict purchased
content to download versus online consumption, or they required multiple integrations
between shopping cart, storefront, and back-end delivery systems. The frustration of realizing
that I would have to create my own platform to solve the problem of selling my digital
content was replaced by the idea that there was a real need for this in the general public,
rather than the idea that this might be useful for a small group of people who demanded
major publisher quality for their indie video commerce projects. In hindsight, I should have
realized that the needs of this niche group are clearly different from the needs of the general
public.

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

As indicated earlier, Lunarbits as a business idea is still just as viable and just as validated
today as it was when I began two years ago. What many entrepreneurs will pay lip service to,
but generally fail to recognize in any of their own ideas, is this: "if it's broke, it could be
because it ain't worth fixing." Similar to the Frind Paradox, sometimes bad solutions exist
because better solutions are not worth the effort. This is a real phenomenon. It could be a
function of the market's expectations, or the secret, real truth behind the profitability of some
seemingly attractive segments, but I believe that if I launched Lunarbits tomorrow, chances
are I would have a very real problem attracting a sufficient number of subscriptions to sustain
a business. I come to this conclusion based on the number of competitors that have launched
in two years (two) and by the number of those competitors that are deviating from the
existing entrenched and uninspired business metaphors (zero). This does not mean there is no
room for disruption in the digital goods market, but it does mean that I am skeptical that
anyone "going it alone" could crack it, at least without burning out ten feet from the finish
line. The idea is simply too big.

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.

You might also like