“Success is simply a matter of luck. Ask any failure.”
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.
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.
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.
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.