Entrepreneurship Failure: Case Example: Lunarbits

Summary:
The experiences of a technological entrepreneur who started the development of
"Lunarbits," an online marketplace for the sale of digital goods, are the subject of this case
study. He has a broad perspective or vivid imagination of what lunarbits might become.
However, as the plot progresses, he finds himself confronted with a variety of obstacles. The
first issue is that the brand name "Lunarbits" is not particularly memorable or catchy on its
own. The Lunarbits platform was put through its paces by Lead to win, and happily, it
prevailed. After the validation, Lunarbits still faced a number of obstacles, some of which
include the following:
1. Validation is not enough
2. Mockups are not enough
3. Going alone may not be enough
4. Scratching your own itch may not be enough
5. Big ideas may not be enough.
And in the end, Lunarbits was unsuccessful because to the typical challenges faced by
humans. In conclusion, the difficulties that can be experienced by a single person or by a
small business are covered, along with some tips and suggestions for overcoming those
difficulties.

Lessons’ Learnt: Founder’s Perspective

Validation Is Not Enough:
When analyzing the potential worth of a new endeavor, we always seek the advice of
others, regardless of the size of the team we have assembled. This concept receives cultural
support from us in the form of company incubators, investments from angel investors and
venture capitalists, strategic collaborations, and ecosystem development. We are looking
for permission to commit a large amount of time, effort, and money into creating our vision
from those who have previous experience, from well-informed business theory, and from
within ourselves. According to this line of reasoning: if our strategy is approved, it will have
a far higher probability of succeeding, and the risk will be worth it if we have to make
sacrifices.
However, validation is not sufficient on its own. Because it takes you out of the details of
delivery and engages you in a socially acceptable form of pretending through financial
forecasting, customer and market analysis, and partnership development, the act of
validation is, in many respects, a brilliant way to postpone the hard work that needs to be
done. This is because validation takes you out of the details of delivery. These are crucial
duties that, in my opinion, belong further down the spectrum, certainly after the initial
launch stage, when validation is no longer on the radar. In other words, after the initial
stage of the project. When you are in the thick of it, it is a small source of solace to know
that other people approved of and believed in your vision. However, placing too much stock
in the armchair business development of others will keep you in your own metaphorical
armchair and prevent you from making real progress that can be validated by paying
customers, or the lack thereof.
Validation was never an issue with Lunarbits; the company maintains, on paper, that it is still
a viable business, and the landscape of its competitors has remained virtually unaltered
after two years. Despite this, it is not necessarily a wise course of action. And this does not
rule out the possibility that it will fail for the myriad of other reasons.

Mockups Are Not Enough

We frequently hear generalizations about the lessons that may be learned from failure, but
there are a lot of specific reasons why initiatives fail. One of these is designing without using
mockups, which is more applicable to the realm of software development but has wider-
ranging implications. This method operates under the presumption that the vision you have
for your company already possesses its own natural metaphor and can express itself in
software without the need for any disciplined labor. When the founder used Lunarbits, he
made an upfront payment, which included the high-quality graphic design of the website
(also known as the brochure), the admin interface (also known as the back end), and the
default shop theme (i.e., the marketplace). When he had his meeting with the designer, he
had a concept in his head of how the application needed to "feel," but all he brought to the
table were his sentiments. His vision seemed crystal clear, and he was confident that the
solution would present itself naturally. It wasn't the case. When asked very straightforward
questions about the customer workflow, such as "What happens next?" he was taken aback
to discover that he was unable to articulate a response.
The lesson that should be taken away from this is that you cannot know the general without
first experiencing the specific. Before you spend any money on graphic design, there are two
very particular steps that you need to take. The first step involves outlining each screen of
your application using a mockup tool (or a decent pencil and pad of graph paper), even the
screens that appear to be self-explanatory to you. Make duplicates, and then combine the
copies into "decks" that represent tasks that your clients need to complete, such as "upload
a new video" and "sign up for an account." As soon as you have a clear picture of how all of
these things are interacting with one another, the next step is to get rid of them.
Mockups are not sufficient on their own. They are a wonderful way to challenge your mind,
but they do not go nearly far enough in terms of teaching you to know exactly what you
require from a graphic designer. You should, rather, design a live interaction system, which
is essentially the entirety of the programme, utilizing a theme that is nondescript and
unbranded. The designer should be hired after the project has already begun. This strategy
will prove beneficial not just in terms of the amount of ownership you will have over the
vision of your product, but also in terms of the amount of input you will be able to provide
in order to obtain the design you require the very first time.
Going Alone May Not Be Enough
I have always been a supporter of individuals starting their own businesses on their own. I
consider myself to be a "code soloist," which refers to a person who possesses the
imagination to find a solution to a problem as well as the broad base of technical and
communication skills required 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, a
"code soloist" is someone who has the ability to build something from the ground up.
Nevertheless, as time has gone on, I've come to see that certain classes of issues require
teams, regardless of how ambitious or capable the soloist may be. It has less to do with the
nature of the individual than it does with the basic dynamics of human relationships. People
are energetic beings, and as such, we are unable to maintain a high degree of intensity or
capacity for labor indefinitely if we do not receive consistent encouragement and feedback,
both of which are difficult or impossible to give for oneself.

Creating a successful technology company requires a lot of hard work. You need allies, both
for accountability and momentum, just like you would need them on any difficult and all-
consuming endeavor. They can't be the kind of supporters who don't comprehend the
problem space you're attempting to address, who have their own focus and projects, or who
can't emotionally and financially detach themselves from any challenges that may arise.
These kinds of supporters are referred to as "friends," and even though they are necessary
for your wellbeing, having friends is not sufficient on its own. Your actual supporters should
be invested in the endeavor for the long haul and be willing to take on the same level of risk
as you. People of this type are referred to as "co-founders," and you will need them if the
kind of company you are constructing offers a solution to an issue that even your mother
can comprehend. If your company is easily understood by non-technical people and it is
attempting to deliver value to "everyone" (which is itself an indicator of immaturity in
business planning), then the market you are pursuing is so horizontal that there is little
possibility of attaining success without a team.

In the case of Lunarbits, the mistake was carrying on despite being unable to assemble a
group of players. When I was left to my own devices for an extended period of time with the
enormous challenge of designing a platform that everyone could use, I lost interest. I
attempted to create a technical support team by isolating components of the underlying
infrastructure and making these components available to others under an open source
license. I did this in the hope that their release would entice other developers to join my
cause and provide technical assistance. This should not be done. Because of the costs
associated with extraction, you are prevented from exporting anything concrete, and the
notion that external contributions would arrive in a timely manner or for areas that truly
require improvement is a vicious one. Crowdsourcing has never, ever been enough to build
a business on its own. When the core product is a platform that is used by other developers,
or when it is seeded to the general population as well-documented and well-loved hosted
platforms like Word Press, open source is an effective strategy for business development in
a variety of situations. This is especially true when the core product is a platform that is used
by other developers. But I propose that, for hosted solutions that are charging monthly
service fees in advance 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. This is because there are simply too
many proprietary aspects that must be carefully separated from any potentially sharable
infrastructure. Your momentum is the single most important "soft" value you have in the
beginning, and the time and work required to open source your software before you have
launched your first version will have a direct impact on that momentum. Instead of
gambling that the mere concept of open source's potential, with no real examples, will be
enough to attract developer confidence and support, save open source for when you have
already developed a first version and are trying to upgrade it on the cheap.

Scratching Your Own Itch May Not Be Enough

Because we anticipate that a "truism" will be correct, the majority of the time we take
colloquialisms at their literal meaning. Because of this, it is easy to read and believe
sentiments such as "scratch your own itch." This is the concept 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. This is why it is easy
to read and believe sentiments such as "scratch your own itch." The creator is intrinsically
motivated by a real frustration in which they can see a solution and are capable of
producing it, which is one of the clear benefits of this strategy that go beyond capability. In
particular, this strategy serves as an antidote to the mistake of "going it alone," which is why
there are clear benefits to this strategy beyond capability. The ability of the entrepreneur to
utilize oneself as a source of feedback frees up a significant amount of effort that would
otherwise be intended for user stories and usability testing.

Quite frequently, the things that we want for ourselves are not generally valuable to other
people, at least not in numbers large enough to justify the amount of time and cost that is
necessary to see a concept through to its completion. Because entrepreneurs have a
tendency to have a narrow and focused view in order to locate markets that are not being
served, we also have specific requirements. My initial frustration with Lunarbits was that
there were no turn-key options for remixing and selling digital content (specifically
instructional videos). Existing solutions either did not have the flexibility of a hosted
storefront or the ability to restrict purchased content to download rather than online
consumption, or they required multiple integrations between shopping carts, storefronts,
and back-end delivery systems. This was one of the reasons why I created Lunarbits. The
disappointment I felt when I realized I would have to build my own platform to solve the
problem of selling my digital content was quickly replaced by the realization that there was
a genuine demand for this in the general public. Rather than the idea that this might be
useful for a smaller group of people who demanded major publisher quality for their
independent video commerce projects, I realized that there was a real need for this in the
general public. This was the realization that helped me get over the frustration I felt when I
realized I would have to build my own In retrospect, I should have been more aware of the
fact that the requirements of this specific subgroup are obviously distinct from those of the
broader population.

The concept of "scratching your own itch" is fraught with complications, one of which being
the fact that desiring something for oneself is not the same as wanting it for everyone else.
Although it is simple to come up with imaginative justifications for the ways in which other
people will benefit from the solution to a problem that you have, and although it is possible
that you represent a large market of people who are looking for solutions, it is a mistake to
believe that a solution that solves your problem will also be generally useful in its current
form. Entrepreneurs are notorious for severely underestimating the amount of time and
effort required to take a notion that is already working and make it broadly available, stable,
scalable, and supported by others. From a design point of view, interactions that are
comprehensible when applied to a prototype are unlikely to be well received by the broader
population if they are not refined. A further challenge is that if the solution is implemented
and proven effective, the issue at hand will be resolved for the entrepreneur. This removes
the motivational leverage, but it leaves behind a significant body of labor that rarely
resembles the initial problem and has more to do with maintenance than it does invention.

Big Ideas May Not Be Enough

As was mentioned before, the concept of Lunarbits as a business is still as feasible and
justified in the present day as it was when I first started working on it two years ago. The
phrase "if it's busted, it could be because it ain't worth mending" is something that a lot of
business owners will say they believe in, but they almost never actually acknowledge when
it comes to any of their own ideas. In a manner analogous to the Frind Paradox, it is possible
that good answers do not exist because the pursuit of better solutions is not worthwhile.
This is an actual occurrence in the world. If I were to launch Lunarbits tomorrow, I believe
there is a very good chance that I would have a very difficult time attracting a sufficient
number of subscriptions to sustain a business. This could be because of the expectations of
the market, or it could be because of the secret, real truth behind the profitability of some
segments that appear to be very attractive. Either way, I believe this to be the case. This is
the conclusion I get after considering the number of new competitors that have emerged in
the past two years, which is two, as well as the amount of those new competitors that are
breaking away from the traditional, uninspired business metaphors that are currently in use
(zero). This does not imply that there is no potential for disruption in the market for digital
goods; but, it does mean that I am sceptical that anyone "going it alone" could crack it, at
least without stumbling and falling ten feet from the finish line. The concept is simply
excessive in scope.
Sometimes the large problems that we are trying to address for all of the people, all of the
time, cannot be solved well. Big ideas all begin with an optimistic burst of energy that seeks
to topple the status quo; however, their proponents forget that the existing solutions did
not spring up out of the mind of a lazy person, and it is a mistake to take any of them lightly,
despite the apparent gap between a new idea and their reality. This is a curious property of
big ideas. When confronted with a large vision that cannot be addressed well for all of the
people, all of the time, the appropriate approach is to either decrease the vision or get a
new one. Doing so will allow you to maximize your chances of being successful.

Conclusion
In the end, Lunarbits was unsuccessful not because it was a horrible idea, because no one
believed that it would work, or because the team that created it did not have the ability to
create it. It was unsuccessful for typical, human-related reasons. It just couldn't keep up the
effort for the required amount of time. Before deciding to invest budget on a designer, they
did not spend enough time in the beginning to solidify the understanding of founder’s
experience. Despite the fact that the magnitude and work required to implement a full-scale
platform obviously necessitated it, they were unable to recruit a co-founder for the
company. Too much of work was spent broadening the scope of infrastructure details in the
hope of attracting outside involvement through open source initiatives. I persisted in trying
to solve a massive issue, which I was unable to do on my own in a reasonable amount of
time, for the greatest number of people as I could. The lack of movement in the market was
not interpreted by me as a probable warning indication that there was not a strong market
to begin with. My own problem, which was that I needed a flexible content commerce
application, became confused in my head with a problem that warranted a common and
generally wanted solution. I scratched my itch for such a long time that I lost track of what it
was that I was actually itching. After putting in a lot of effort for two years, I was no longer
able to tap into any of the original inspiration that I had previously felt. The issue was and
continues to be "dead to me."
Reference: https://timreview.ca/article/447