mystartupfail - Tumblr blog

[mystartupfail]

Unifyo Post-Mortem Analaysis

Unifyo was a funded relationship management startup which spanned across six products. Product Manager and Android developer Ben Wirtz wrote a post-mortem of what he thinks went wrong with Unifyo. Unifyo targeted enterprises, which has presented its’ own unique challenges. Here are their lessons learnt:

Sales and Marketing

Although somewhat spread across a few lessons, the Unifyo team identified that they didn’t focus on enterprise customers at the beginning. This lead them to focus on enterprise too late in the game, without salespeople. Ben even went as far as saying that having a co-founder who had sales experience would have been a good idea. I am unsure whether I agree or disagree with this, my assumption is that he means so they feel they have a larger stake in the outcome. This article has a nice overview about B2B sales.

Once targetting enterprise customers they hit another problem. When dealing with enterprise customers, the sales cycles were quite long. Even after a customer committed, the internal processes in the company would take too long. The sales cycle was around the same length or longer than their remaining runway.

Although this lesson might seem directly related sales and marketing, fundamentally it seems like it was a problem of not understanding the target market well enough. This then led to targetting later in the startup’s life and unable to get the money from the sale quick enough.

Some might say this is a weakness in enterprise (Not being able to move fast enough), however it could also be viewed as a survival mechanism. Let’s say Unifyo needed X amount of customers to keep themselves afloat, X/2 sign up, Unifyo gets no more funding then shutdown. Those X/2 who paid, now have a shutdown product and need to find an alternative.

Impression of Quality

One of the tough problems that Unifyo identified they faced was managing customer expectations. Although their proposition of allowing customers to see contact details within a web page (Somewhat similar to Rapportive’s offering for email). When the system didn’t work however, customers would take note of it (Availability Bias). They were trying to solve a hard problem (But an easy problem for customers to understand) and underwhelming a customer isn’t ideal, a rule of thumb is to “underpromise and overdeliver”.

Company’s Goals

Not having a written down set of goals or statement for your startup may seem small but the simple activity of writing it down gives you more clarity and helps when explaining it to others. One useful template I used from the Founders Institute’s Adeo Rassi is:

My Company <name> is developing <offering> to help <target audience><solve a problem> with <a secret sauce>.

Really helps distill and narrow your vision.

Conclusion

I would like to thank the guys at Unifyo for their post-mortem and congratulations on all that they achieved. The article was a good read and provides a lot of useful information for B2B startups. I do think that their post-mortem only looked at the surface and didn’t look beyond the obvious mistakes, so I hope I was able to add an outsiders perspective.

Original Source

[mystartupfail]

Qhojo's Startup Mistakes

Qhojo was a peer-to-peer marketplace for lending equipment started by Manish Sinha. Manish, took a chance and quit his job to build a business, however it didn't go to plan. You can read the original article here. Below is what I think of Manish's article.

1. No Customer Development

After reading the first paragraphs of the article, I had already figured this would have been one of the mistakes. Not talking to customers and getting an idea of what they want is a big mistake, something that I make a lot. It is really tempting as an engineer to jump headfirst into building a solution however you must know what your customer wants (Or importantly needs!). As the famous saying goes (Often attributed to Henry Ford) “If I had asked people what they wanted, they would have said faster horses.” and or a newer update "No one said they wanted faster horses, they wanted less horseshit", figuring out what problem the customer actually wants solving is not trivial. However you need to start somewhere.

2. Bad name

Although this one didn't hit me straight away, spelling of a name can be problem for spreading the word. So when coming up with a name it is best to be careful. I would suggest if you are going for a non-existent word, make sure it is easy to transcribe "Twitter". If you are making a change to an existing word, make sure it is easy to explain e.g. "Fiver with an extra r on the end".

3. High risk-to-reward ratio

Manish raised a really interesting point about how Qhojo had a lot of risk for users, so it wasn't worth their while. You could break this down even more to say, the product didn't offer enough value to the user. Selling something on eBay will give both the seller and buyer a gain, Qhojo was putting a lot of risk on the lender.

4. Over engineered

Once again going back to the engineers mindset, Manish wanted to make the code perfect. This is good for a long term solution however Qhojo was just an MVP and hadn't even proven its' business model yet. As I write this, I realise I am making the same mistake with one of my projects...

5. Lack of lender protection

An attempt to solve mistake #3 however not well thought out and encountered problems. A lesson from this is that sometimes a solution to a problem creates more problems itself'.

6. No team

As Paul Graham said, a single founder is a bad thing. Paul's last point really resonates with Manish's story, bearing the sad times can be hard when you are alone. Although Manish had another founder working part-time with him, it wasn't enough to drive the company forward.

7. Misleading encouragement

When you pitch your idea to friends many will say it is great (Sometimes just encouragement), which feeds into your confidence in the product. However sometimes it is very easy to ignore critical voices, but they are the most important! You need to balance these out. Make sure the people who say it is great put their money where their mouth is, an excuse should be treated as a no.

Conclusion

Once again a very interesting article with some nice take homes. For a company entering an area where a lot of risk is placed on users, Qhojo offers a lot of lessons and things to think about.

I would like to congratulate Manish on his achievement and subsequently sharing what he learnt.

Original Article

[mystartupfail]

Nextt Post-Mortem Analysis

Nextt was a funded social planning mobile app started by Mark McGuire. Recently I read the former CEO's post-mortem outlining why he believes the startup failed, let's explore their lesson's learnt.

Over-Design

Early on in the article you get the impression that Nextt was trying to do too much too soon (Swiss Army Knife). Although it seems despite best efforts, the team wasted a lot of time thinking about and designing future elements as opposed to working on their current view.

Although it is good to have a long term view of your products future, don't waste too much time as you never know if your basic product is even attractive!

Hiring

For the early designs Nextt used consultants to build the products. Once full-time developers were on board they did not want to work with the existing codebase. For outsourcing there are always hidden costs.

As a software company, hiring your own in-house development team is a very good idea. However, outsourcing sections of work can be a cost effective way to keep costs low. I can't say I fully agree with Mark's advice on outsourcing, however he does raise a legitimate point.

Multi-platform

For a social media app, being on only one platform is not ideal. You are cutting out some of your users and probably more importantly you are cutting out your existing user's friends from using it. With an SOA approach the underlying code shouldn't be an issue anymore, writing interfaces on top should then be relatively. Nextt seemed to have focussed on a native solutions straight up, being way too ambitious and ultimately not delivering. 

Mark suggested trying to test your idea on only one platform, however I drew a different conclusion. By building the MVP with a Cordova/PhoneGap like framework, multi-platform problems could be ignored. Although for an app company having a native solution may be ideal, a non-native solution whilst you are starting out is a good way to get something quickly out the door to as many people as you can. The expensive native apps can come later when you are 100% sure what features you want.

Network effect

The network effect essentially extends from the telephone being useless until there is enough people using it. For any app to work you need to create value for your user, for any social media app to work that value is through your circle of friends. Facebook isn't interesting if your friends don't have accounts, likewise for Nextt. The Nextt team were overly optimistic about getting new users to join after an existing user sends an invite.

The network effect is a hard thing to work with however by providing a good service to non-customers can be a good marketing channel. This decision is quite a big one though, should non-customers be able to enjoy the benefits of the app? It might require more work on your developers end (Maybe a mobile website version using session tokens), but maybe is an expensive channel. But the founders take home message is don't be too optimistic.

Deadline Consequences

I have seen this mistake many times and I am glad Mark pointed it out. Startups will often have their product deadlines missed, it is a normal part of technology. However the problem is often these project slips have no consequences.

Instead when deadlines are missed, consequences should be imposed. Not on the people who are making the product but the product itself'. For example limiting features, redo estimates, etc.

Conclusion

Overall the author gave a good message, that as long as you try your hardest and learn from your experience everything will be alright. My Startup Fail's core values are about trying and failing then learning from those failures, so his message definitely resonates with me.

The article provided some interesting insights into failure. If you have time, I suggest reading the original article.

[mystartupfail]

How Not to Write a Startup Post-mortem

There are many right ways to write a startup post-mortem. Most startup post-mortems I’ve read are quite well written, however sometimes founders miss the point. Here are some tips on things to avoid when you are writing a post-mortem.

Focus

Although focus on a product, niche, etc. is a failure which is worth noting however talking about a lack of motivation, laziness, etc. without a real cause does not help anybody. Everybody struggles with these problems to different degrees and have ways to overcome them. Passion for your product and believing your vision are good ways to keep yourself focussed, if you don’t have these then maybe the startup isn’t for you.

It is however noting that burnout can be a cause for lack of motivation, which could be worth discussing. Unsustainable work practices can lead to burnout which is something that many entrepreneurs ignore.

Personal Attacks

This sometimes is subtle sometimes not so subtle but personal attacks on members of your previous team is not professional. Regardless of whether your startups demise was or you believe it was responsible because of someone, it is not professional to single him or her out with a personal attack.

Instead you can focus on what decisions you made which lead to their poor performance. Was it poor hiring? Was it poor management? These might be the real root cause, so don’t be so quick to cast blame.

Your product

Don’t focus on how people didn’t understand your product. If people didn’t understand your product you either didn’t explain it properly or it is ahead of its’ time. Even if customers understood your idea, maybe they just don’t need or want it.

Instead you should focus on problems with the implementation and marketing. Maybe you had an amazing product but it wasn’t marketed properly, user interface was confusing, etc. There are many examples of inferior products beating superior ones.

Promotion

Don’t use it as a shameless plug for your next project. Most people will see through the advertisement and it might even degrade the quality of your article.

Instead mention your next project only where it is relevant. For example if you made mistake X in your previous startup and you have avoided it in your new one, it is worth mentioning. Otherwise just place a link at the start/end when introducing yourself.

No action

To me, one of the most important things that a lot of startup post-mortems miss out on is having actionable steps on how to avoid the mistake. This can then lead to someone who is stuck in a similar situation seeing a set of steps to take to actually avoid the mistake.

Instead after you talk about a lesson there should be a suggestion of how to avoid the problem. Better yet, mention what you would do differently if you got the chance to go back and redo it.

Conclusion

These are just a few things you can avoid to make your post-mortem write-up not only more professional but more useful to others!

For tips on how to write a startup post-mortem, read here.

[mystartupfail]

How to choose a technology

Recently I read an interesting article on whether technology matters, here is its’ discussion on Ycombinator’s Hacker News. The article presented an interesting point of view, however it got me thinking. I came to the conclusion I think there are a lot of reasons why technology is important.

For a tech startup, technology will most likely be core to the business. The customer will interface with it and its’ reliability, value and feature set will be crucial to customer acquisition and subsequently retaining them.

I am going to frame this in terms of building a web app, however some of the points should apply to other tech startups. In this article I define technology as quite a broad term, e.g. programming languages, libraries, frameworks, etc. Here are some factors I believe are important for choosing technology:

Speed and Reliability

The speed and reliability of a technology is a very important factor when making a decision. For example, choosing a fairly new technology could introduce a myriad of reliability problems. A famous example is Twitter’s choice of Ruby on Rails, the website would experience a lot of outages which nowadays is nearly unthinkable. The reliability problems lead to a crucial part of the website being migrated to Java. Ruby on Rails at the time was still in its’ infancy and had an unofficial motto “Rails doesn’t scale”. Despite PHP being quite old and “uncool”, Facebook still uses it for backend code (Compiling down into C first) for performance. So performance is a very important.

Speed and reliability of code can also be highly related to code quality. For example a poorly written program using a highly reliable technology might not compare to an extremely well written program using an unreliable technology.

Familiarity

Particularly if you are just starting up, your developer's familiarity to the technology is very important. Although for an experienced programmer learning a new language is relatively easy, you are still losing some essential knowledge. This will then affect development time and to a lesser extent software quality. For example a .Net developer learning Node.js might lead to some delays.

However something important to note is a developer’s will. Developers like to try new things, so when working on a start up it is a perfect opportunity to try a new language or framework. For example recently for one of my projects, I decided to learn Ember.js whilst building it because it seemed cool. A developer’s will is something that might need to be balanced with the other points, especially if you aren’t paying cash. A new technology might be appropriate for the job or might just be an excuse to learn something new. Research it before making a decision.

Development Speed

Your technology choice can also change the speed of development. Higher speed means you can ship more iterations to your customer faster, (ideally) improving the offering. For example writing a web application from scratch in Javascript might take you a lot longer than using jQuery, which will already have many features you need out of the box. This also applies to programming languages, Ruby and Python are quite verbose and compared to some other languages may lead to shorter development times. MVC (Model View Controller) frameworks are also infamous for cutting development time in Saas (Software as a Service) and backend driven web apps in general.

Features

When choosing a specific technology, a feature or set of features could help steer your decision. This could then lead to less code being written and more productivity. For example you may choose to go with NoSQL instead of a SQL because the data is semi-structured, leading to a lot less code being needed. Another example is choosing Ruby on Rails over Python with Django due to the amount of Gems with required features Rails has.

Cost

Another big factor in deciding on what technology to use is financial cost. Sometimes a paid solution provides more features or much needed support however they often have trial versions. Many cash strapped startups avoid technologies that require paid licenses to use to save money. For example many startups avoid .Net as it normally requires a paid licence.

Maturity

A technology’s maturity is also a very important factor. As Twitter found out, Ruby on Rails was not mature enough at the time to handle the load from its’ users. Maturity not only shows a technology is capable but also that other companies and developers have trust in it. For example despite being considered “uncool” among a lot of developers, .Net and Java are still heavily used in corporations and are quite reliable.

Legacy

Although similar to maturity, legacy is a doubled edged sword. Legacy shows that the code works well and serves its’ purpose, but can become a nightmare to maintain. For example making changes to an existing app with an unpopular framework can make a developers life difficult and decrease productivity, as they don’t have as much support as a more popular framework. Due to the fickle nature of technology, you might choose a technology that is currently popular and will still be alive in 5 years or have faded into obscurity.

Stage of development

What stage of development your product is in can play a big part in what technology choices you make. For example an MVP which you plan to throw away after validation, the technology choices aren’t that important. However for an existing web app a change in technology can be an expensive and time consuming choice but also possible a necessary decision.

Balance

For example if development speed is important to you and your developers are familiar with a particular technology stack, it might be wise to choose that stack. Running speed or lack of maturity might be worth compromising on. This is very important for an MVP (Minimum Valuable Product) as a lot of startup leaders suggest throwing your MVP away after validation. So by building your MVP using familiar technologies to get it out the door the as fast as possible to validate your idea. This then leaves you an opportunity to use technologies that suit your problem better and expand your feature set.

Thus the final choice thus comes down to balance, each technology will have its’ own advantages and disadvantages. So you need to decide what is important to you and compare the options. My suggestion is a weighted decision matrix, which you can get here.

[mystartupfail]

4 Reasons You Should Write A Startup Post-mortem

As any reader of Hacker News, entrepreneurial subreddits or read startup related news would know, a lot of founders like to talk about the lessons they learnt from their failed startup's. These post-mortems are nearly always packed full of gems of information and are invaluable for other entrepreneurs. So should you write a post-mortem? There answer is yes! Here is why:

1. There is no shame in failure

As you most certainly know by now, building a startup is hard and as you sail out into uncharted waters mistakes unavoidable. In fact it is often quoted that only 0.4% to 10% of startups succeed and most successful startups are started by entrepreneurs who had previously failed.

Even the most successful entrepreneurs and businesses have made mistakes, they chose to learn from them and they are some of the things that have made them so successful. Rovio (Creators of Angry Birds) developed 51 game titles before hitting it big with Angry Birds. Richard Branson’s self-confessed biggest failure was taking on Coca Cola with the launch of Virgin Cola. PayPal co-founder Max Levchin started 4 startups before making it big with PayPal. If Roxio, Richard Branson and Max Levchin all have failed at one point, then you are definitely in good company.

Failure is merely a part of the journey, if you don’t make any mistakes then you aren’t trying hard enough. There is no need to feel embarrassed about sharing your failures. You might be able to help someone else who is in a similar position. The best lesson I learnt from someone else’s post-mortem is about how to test an MVP against your market properly.

2. It can be therapeutic

Talking about your failed startup can be very therapeutic, helping you process and release emotions. Startups can be an emotional rollercoaster and at the end it could even be comparable to a minor version of PTSD (Post-Traumatic Stress Disorder). Talking about what happened can be helpful to get to terms with it. Note: If you are suffering from depression symptoms please see a healthcare or mental healthcare professional.

During my interviews for My Startup Fail, I have noticed the change in mood of the interviewees. I often see the interviewee become a lot more relaxed and they often tell me it feels like a weight has been taken off their shoulders. Even without releasing it to the world, I think writing about your failed venture and what you learnt from it can also be very helpful.

3. To avoid mistakes

In a year or two when you are head deep inside your new startup you may have forgotten about the details of your previous startup or even simply not thought about it. To help prevent you making the same mistakes again, a documented list of what you learnt could be a handy reminder. As Steven Dunn said:

You can never make the same mistake twice because the second time you make it, it's not a mistake, it's a choice.

4. Promotion

Writing about a failed startup can also be a chance to promote any new ventures. Particularly if your previous startup had a high profile or a loyal customer base, it could be a subtle way to funnel those people to your new startup.

Conclusion

So writing a post-mortem has many benefits, not only just to other entrepreneurs but also to yourself. So if in doubt write one, it could make you feel better, help someone else or even help your current venture.

My Startup Fail is happy to interview any founders from failed startups and share their story’s. Please contact Brendon at bbody@mystartup.fail

[mystartupfail]

Interview with Angela Li - Moodva

Could you please explain the company briefly and what problem it tried to solve? What was your role? We worked on a mood-based search engine called Moodva that gave results based on your mood search. My role was in an operating capacity, having been a cofounder. Could you briefly explain what you believe led to the startups failure? Mainly a lack of team belief in the idea. Also a lack of understanding in the market and our customers - never really finding the right market/product fit. What are some pivotal choices/moments that you believe were key to the startups downfall? The first week after we got into an accelerator, it became apparent that our team was not really motivated on working on the project for the long-term. What lessons have you learnt from this experience? The biggest takeaways were in considering entrepreneurship as an alternate career path and in understanding the importance of domain expertise in your business. What are you currently doing now, any current ventures? Currently I am finishing off my undergraduate studies. I am in the process of raising funding for a venture which I hope to start after graduation.

[mystartupfail]

Epiclist Post-Mortem Analysis

The founders of Epiclist have written a post-mortem about their company Epiclist. Epiclist was an app that lets you plan, book and share travel plans. It allowed users to compile stories, pictures and locations on their phone.

Epiclist like many failed startups was not able to find a place on the market and unable to form a viable business model.

...it became a vitamin instead of becoming a painkiller.

However the post-mortem outlines some lessons the new to entrepreneurship have learnt in their 1000 day journey. I will share some of the ones that stood out to me.

One of the lessons that they learnt was to ask "Why". In particular:

Why do you want to solve this problem?

Why are you going to be different and unique?

These questions are important for any startup, whilst writing this article I asked myself about these questions. I am not very pleased with my answer either, so I have some more thinking and tough decisions in the near future.

Another lesson they mentioned was always delivering more than you promise. Despite this being common sense to most, it is very easy to overlook. One famous example is of a company that never told their customers they use next-day delivery. This way they were able to pleasantly surprise customers but also in the case that it was delayed they would not be breaking any promises.

One pitfall I see many entrepreneurs (Including myself) fall into is how to conduct customer interviews. Many people ask their friends for validation for a business idea, most people will reply with the affirmative. E.g. Would you buy this? The question you should ask is "Will you buy it now?". There are many ways during user testing that you can lead users to answer the way you want. It is an art, how to ask the right questions. You might not get the right answer always but you are learning something. This was another lesson that the Epiclist team encountered.

Finally the last lesson I wanna point out is that they learnt was to just give it a go, your product will never be perfect. Something any entrepreneur can understand, the fear of your product not being good enough. However if you delay too long you will never know what works! So don't be ashamed to show others what you are building, the more feedback early on the less you may have to change.

Epiclist's adventure is a very interesting story, spread all across the globe. If you get a chance you should read it, there are also some amazing photos in the article!

[mystartupfail]

Founder Depression

Sam Altman of Ycombinator wrote an amazing article about Founder Depression. Although I have never experienced it first hand, I know people who have. It is a major part of startup life, more so when your startup is failing. The pressure with any business owner to put on a brave face regardless of how their business is doing is enormous.

An article I read recently on Startups Anonymous really captured this fear and helplessness after the decision to shutdown was made. The founder describes the anxiety of disappointing his family, his employees, his investors and most importantly himself. In many post-mortems this is a common theme, a feeling of failure and being embarrassed. In my analysis of Chris Poole's DrawQuest and Canvas startup's one thing that stuck out was that even though he got funding and user traction his startup still failed, causing him even more anxiety.

Despite my Psychology degree, I will not bore you with a lame attempt at why this makes us feel bad, regardless the feeling of failure isn't fun. So if you are struggling, reach out to someone. Take an hour for yourself to talk to someone (Other founders understand), write on Startups Anonymous, etc. but just don't bottle it up. As Sam Altman stated in his article:

Failing sucks—there is no way to sugarcoat that. But startups are not life-and-death matters—it’s just work.

[mystartupfail]

Proper Shutdown

As of the 29th of October, Proper shut down operations. Proper was a startup for freelancers to easily create, send and sign contracts online. In the post-mortem post, Ryan Glover, founder of Proper goes into detail as to what went wrong. Most notably, Ryan talked about burning out early. He did not see the amount of activity he would have liked to, something which can be hard on any founder to keep working. Reading a friend's Facebook post recently about finally getting signups and the anxious wait really brings it home. Having no-one or not enough people use your product feels demeaning. This also affected the amount of marketing and promotion the founder was able to do. As Ryan mostly worked with himself he broke the important thumb rule, that single founders usually mean a bad thing. Although building a startup by yourself isn't a death sentence in itself (Plenty of examples of successful single founders), you are going against statistics. However this does not mean you should get another cofounder for the sake of it, quality and passion are very important. Another important caveat that Ryan also pointed out was that if you are going at it alone, make sure it is within your limits. An overly ambitious idea which you can't do yourself will definitely contribute to burnout. In this case, outsourcing could take some pressure off (Trading money for time). The amount of new knowledge a technical founder could gain in the process is valuable but you need to learn to pick your fights and understand your own strengths and weaknesses. On a more technical note, Ryan talks about how he was unorganised with his code and its' process. This is quite understandable as an engineer, the problem solving part is the most exciting and it is easy not to follow any processes. This is alright in the short term if you are quickly slapping together an MVP or a proof-of-concept however when you need to change functionality it gets tricky (Technical debt), some even suggest throwing out your MVP after its' finished. There are many tools and methodologies today which help manage these things e.g. Kanban, BDD, TDD, code analytics, refactoring, etc, however the most important thing is discipline. If you get a chance to read the post-mortem I highly suggest it, some good bits of information.

[mystartupfail]

Interview with Cody Chang

This week we are interviewing Cody Chang, a serial entrepreneur. We didn’t follow the normal format but don’t worry there are plenty of useful information! In your experience, what are some things that you think makes a startup fail? Founder Problems - In almost all of the ventures I started, I was the more experienced entrepreneur. The venture was always the entrepreneurial idea that my partner had though. This had some very serious consequences. Do you have some examples of those consequences? For one, it was difficult to explain to them why investing time in an actual product, instead of business cards, logos, etc was important. They were distracted by the novelty of it all. I was patient but this only exacerbated the problem because I wasn't willing to cut them off immediately. This was a clear gap, not only in experience, but also communication. Time would be wasted on trivial matters and I was always too hesitant to curb their enthusiasm because I felt that it was a process for them to learn about it. In turn, it wasted my own time and sabotage valuable momentum into actually growing the venture. Secondly, communicating expectations and meeting them was a constant problem. When you're working with a partner, you want to think that they are equally as enthused about spending countless hours on this 'idea'. But many people just like to discuss and talk about the wonders and grandeur of successful entrepreneurship. When you need them to call X customers to get market research, find suppliers and vendors, understand external market forces, etc - they suddenly can't seem to find the time. What value do these people have on your team? You have to be clear about what role each person plays in the venture and be clear about how they will contribute to the venture. Don’t just start bringing people on board because you think they are 'smart' or seem enthusiastic in front of you. I have seen that before, too many people being brought onto a team without much value being added. I guilty of it myself, however now I am much more cautious. Lastly, understand that if you commit to bringing a partner on to your team, treat them like one by communicating expectations effectively. Be a leader and just lead. Don't be a coward. There's going to be tough conversations. Have them. Be mature about it and plan it in advance. If you think someone is not pulling their weight, confront them about it but get information beforehand. Know that you brought them on for a reason, and if they are not fulfilling that intended purpose reconsider why they are there. Will they be important in the future? Don't sacrifice long-term expertise and relationships for shortsightedness. Communicate. Talk things over and approach difficult topics calmly, and nicely. Treat them like the partner you intended them to be.

[mystartupfail]

An interview from Entrepreneur with Jesse Lear (V.I.P. Waste Waste Services), Jonathon Nostrant (IVEE) and Grace Ng (Javelin). These entrepreneurs talk about their own startup failures and bouncing back from them. You can see a more in depth perspective from Grace in this video.

[mystartupfail]

An amazing video with founders discussing failure.

[mystartupfail]

Interview with Nish Bandara

Today we are interviewing a former engineering consulting firm owner turned tech startup entrepreneur. Hey Nish, can you give us a bit of background of your business experience? My experiences so far are primarily based in traditional businesses, not tech start-ups. While I've toyed with some absolutely awful start-up ideas in the past, they've not made it past the thought experiment stage until now, with my current project, CloudSmart. What kind of traditional business? For the past few years, my main focus has been my structural engineering consultancy. This business has been able to generate enough revenue to provide me, my mother and younger sister a comfortable lifestyle, so I would consider it a financial success, but nothing of particular note. About 18 months ago, I dabbled with two online stores, each targeted at one gender. Driftwood, the store for females, was able to generate a surprising amount of revenue in a month. But I (stupidly) decided to not to continue with it because it wasn't making anywhere near as much money as the engineering firm. The male store, Flexed Urban was a similar story. So if you don’t mind me asking, what happened to your consultancy business? The business is effectively closed because of what it has done to me as person. As a matter of weeks ago, I have cancelled all work with my clients (apart from one) and let both of my engineers go. What lead you to that decision? The stresses of looking after every component of the business, looking after staff and looking after customers gave me sleepless nights, serious weight gain, and panic attacks. I just wasn't cut out for it. I decided I had enough. My life was suffering and I wasn't really going anywhere. Realistically, the most I could have hoped for was growth of $10k - $20k a year, but it also meant giving up on a lot of opportunities. I've been lucky enough to work from iLab Accelerator via their Incubate program, which has exposed me to a world of business of higher risks, but many more learnings and opportunities for personal and business growth. What are some takeaways lessons from your experience? I've learnt not to work in an environment that I hate! I haven't had an income for the past month, but I still have clients who want to hire my firm. I could deliver work for pretty decent pay, but the horrible memories keep rushing back! So what is next for you? I've been recently accepted into the iLab Germinate program with my first true start-up business, CloudSmart. I'm have to work twice as hard than I did in my engineering firm. The chances of this business being revenue positive in the next year are pretty slim. But I absolutely love it. I wake up early because I want to, stay late because I want to. I want to put in the hours because I want to, not because I have to. I'm learning every day, I'm being pushed to achieve new goals every day, and I'm being guided by some amazing people. It's one of the best things that have ever happened to me. Thank you very much for your time, I hope this has been therapeutic for you. Good luck with CloudSmart!

[mystartupfail]

Microcosm

Founder of Microcosm, David Kitchen wrote a very interesting article on his startups failure. It is a story of a startup trying to disrupt the community/forum space. Despite gaining some user traction, unfortunately they were not able to raise funding and simply failed.

Here are the lessons:

Their MVP took too long

Their MVP looked bad

Solving non-existent pain points

Raise more funding than you think you need

Sales process took too long

Not being prepared to scale

Tried to raise money on a short runway

Presented the wrong things to Angel Investors

Didn't own customer data

Last but most importantly, even they admitted they didn't take on advice from existing startup resources.

A very easy to read and insightful article, I definitely suggest reading it! Source

[mystartupfail]

Paul Graham: Mean People Fail

Paul Graham is a sage for Startup advice, however his recent article Mean People Fail I found to be a little off the mark. Although the article definitely has basis, however it maybe "mean" isn't the right word? Or maybe because Paul Graham is such a nice guy, the startup people he gets along the best with are also nice. There are many people who'd society would deem mean who have successful startups, or have at least done some horrible things to get to the top. Not necessarily bad people but Mark Zuckerberg and Bill Gates have both stabbed people/companies in the back. Steve Jobs, is famous for lying to Steve Wozniak over a bonus for a project with Atari. He is also well known for his aggressive style of management. These are quite high profile example. I think the word Paul Graham is looking for might be non-likeable. People want to work for personable people, because they emit an attractive aura around them. But in addition to that these likeable people need to know how to make a tough decision. I believe these two attributes are more encompassing of what could lead to startup success. These two terms are also able to describe the previously high profile examples mentioned.

[mystartupfail]

Failure sucks. You may have heard of the famous startup maths: nine of out 10 startups fail. The bitter truth about failure hurts but the most important thing

A free definitive collection of documented startup failures and lessons learnt from them.