Startup Failure – We Need a New Word

startup failureI came to the realization the other day that we need a new term for startup failure. For some reason, articles such as this one, seem to link childhood failure in school and on the sports field with startup failure. But the linkage is just not there.

Let’s look at how we use the term failure.

If you take a course in school and do not pass, this is called a failure. And this is one place where the term is properly used. You have failed to pass.

Now in school again, if you lose a game of baseball, some people call this a failure but it is actually only losing a game. You haven’t failed when you lose a game because you can’t win every game the way you.

And look at the field of scientific research. I have a friend who is researching malaria. He has been at this for over 30 years. Is he a failure because he hasn’t cured malaria yet?

When you look at startups, we use the term startup failure to describe all sorts of different situations. If you look at the stats, something like 75% of startups fail, quite like batter stats in baseball.

But these aren’t really failures, they are startup attempts that are just like times at bat or scientific experiments. The problem with the term startup failure is that is lends such a negative connotation and a sense of shame to the entrepreneur.

When someone tries a new business venture they start out with a thesis or proposition that they need to test in the market. They try a bunch of tests until they get it right.

Some entrepreneurs get it right faster than others and they succeed. Others might be trying something more difficult and it may take longer but if they run out of money, they stop trying.

This unfortunately is called a startup failure when it really isn’t a failure. Much like a scientific experiment it is the act of stopping trying.

The Germans solve the problem by having so many different words that their meanings are nuanced and have much less chance of connecting with an negative emotional response. In German, academic failure is Schulversagen and liver failure is Leberversagen.

Startup failure in German is covered by the phrase Startfehler which effectively means Startup Error and this is closer to the mark but not there yet.

Since I have such a huge following in the blogosphere (not) I’m going to invent a new word which will immediately catch on. Going from the German for Stop Trying – “Stoppen zu versuchen”, I’m going to propose we use the term Versuchen for failure.

Thus a failed startup is now a versuchen startup. You can use the term in ways such as “I really versuched that startup” or “he’s a serial versucher.”

I feel better already.

Necessity is the Mother of Invention

Necessity is the mother of inventionI was preparing a talk for Techno at the Impact Centre recently recently on evaluating new innovations and I ran into this old proverb again: Necessity is the mother of invention.

I thought about it for a while and realized that the expression is very apt but that there is a corollary to it and that is that “Innovation depends upon Necessity.”

My thesis, which I presented in not quite so elegant terms to the Techno participants is that innovation only happens when people are forced to innovate. I’m not talking about the people who come up with innovative products or services but about necessity being a precondition to users actually adopting an innovation.

And why is this? It’s because for the most part, there are all sorts of natural barriers to innovation. You can probably summarize these natural barriers in a few buckets:

  • Costs of implementing the new innovation.
  • Risks of failure
  • Changes required to behaviour
  • Psychological barriers to change

And the biggest one of all I think is that people are generally lazy. They can expend no extra effort to do what they have always done but to innovate, they need to expend energy, time, and money.

I’ve seen lots and developed a few products and services that go absolutely nowhere in the market despite being real improvements over what is out there. When I look back at all of them I can find one of the barriers listed above standing in the way.

When all is said and done, there must be some powerful force to counteract the barriers to innovation. Unfortunately, having a better product just isn’t enough.

There must be some other force, whether it is regulatory, competitive, technological or economic that makes someone need to innovate. So I think the corollary works: Innovation depends on necessity.

A Culture of Helpfulness

Today’s TED Talk made me think long and hard about the issue of culture in startups, especially about how to create a culture of helpfulness. The research on the subject is quite clear, that helpful cultures outperform unhelpful ones hands down.

I’m struggling though with whether a culture of helpfulness is at odds with a results oriented culture. Is it possible to have both? If helpfulness leads to better results, should you focus on the end goal or on the process to get there?

I’m disturbed that I may have been mistaken my whole life, trying to create results oriented cultures when I know I would much rather work in a culture of helpfulness without the competition.

I left an organization a number of years because I just didn’t enjoy working there. I had ended up in a job I didn’t like and that was a good enough reason but fundamentally I didn’t like the organization.

Since then, I’ve struggled to define what it was exactly that I didn’t like. Over the years I have identified a number of factors that influenced my decision but until I watched this TED Talk, I didn’t see the whole reason. And that reason was that there was not a culture of helpfulness.

There may have been helpfulness within various teams in the organization but fundamentally there was no helpfulness between teams. Each team had its own budget and there was intense competition for and jealousy of other teams budgets. Results were team based and not organization based and there was intense competition to see who could be the shining star, individually or as a team.

This resulted in a general lack of helpfulness between teams, in fact it was so bad that teams would encroach upon each other, stealing good ideas and replicating programs. There was poor handoff of clients between teams and even a competition between teams for clients.

The problem was, that as bad as it was, the organization was not open to change. And his made it extremely frustrating when you needed to get things done in conjunction with another team. While the problems were easy to see and the consequences quite predictable, the organization was not open to analytical self criticism. Eschewing self-critical analysis, it buried conflict because candor was not safe.

Anyway, enough of my lamenting. Watch the video and think about your own organization. And if you need to either create or go find a culture of helpfulness.

 

Why Startups Succeed

There is a great TED Talk you should watch that went live yesterday. In the talk Bill Gross who is the founder of IdeaLab and has founded a lot of startups talks about some research he has done about why startups succeed and others fail.

“He has gathered data from hundreds of companies, his own and other people’s, and ranked each company on five key factors. He found one factor that stands out from the others — and surprised even him.”

And that factor is timing. It is his proposition that the one thing that contributed most to a business’s success was timing. The startups that came out at the right time succeeded and the ones that were early or late didn’t do as well.

Two other factors that he felt contributed to why startups succeed were the characteristics of the founding team and the degree of differentiation of the idea.

Unfortunately, as a recipe for success, that leaves a little bit lacking. You really should ask the question, then: “How do I get my timing right and how do I know this is a good time for my business?”

I think I have an answer for the question of timing. While I haven’t done the quality of the research that Bill has, I’ve been doing similar research for 15 years, trying to figure out why startups succeed. But more on that tomorrow.

Watch the talk, it’s only about six minutes long, and return tomorrow for my take on how you can get your timing right.

End If

UnknownSince I wrote a post on Monday entitled If, Then, Else, I figured I should follow up that one with ‘End If’. Bear with me here for a sec and you’ll see why this is relevant and interesting (at least to me.)

In computer terms End If is the command that is used to terminate a multiple line “If” command. (Written ‘endif’ for those who like to correct my spelling.) But I’m not talking about programming here but how you know when you’ve reached the end of a task.

The best case in point is in the development of process. How do you know when you’ve finished creating a process? I’m working with a growing company called Veloxsites that has developed a platform for partially automating the production of websites for small businesses. We are growing like gangbusters these days with all sorts of new resellers being signed up.

Signing up a new bunch of resellers in a short period of time has really shown how bad our on-boarding process was. To be frank, it really wasn’t much of a process and we were probably guilty of winging it.

So being good worker bees we worked hard to document the process and to create pre-packaged Statements of Work, Project Plans etc that we could re-use so we could reduce the complexity of the reseller on-boarding.

This wasn’t hard to do and we accomplished the task of setting up the new process in rapid order. But the funny thing was that when we thought we were finished, we kept getting funny questions from resellers that indicated that the process wasn’t meeting their needs.

So we looked at this process again and decided that we were creating all sorts of artificial hoops and barriers that resellers had to go through that they didn’t appreciate. We had adopted a big process mentality when it just wasn’t needed.

So when we could have said “End If” the process was documented and automated to the extent possible, we decided that we should “End If” the process was as short and painless to resellers as possible.

What we then did was take apart the process, trying to figure out which steps added value and which ones didn’t. As it turned out, few of these steps added value so we started chopping and then we really started automating.

What we have arrived at looks nothing like where we started. We decided that we could almost entirely eliminate the process of on-boarding resellers if we eliminated stages and skipped straight to the end stage of an implementation. We could also eliminate complexity by almost entirely automating the process.

We haven’t finished yet but we are planning to arrive at a point where a salesperson can on-board a new reseller in five minutes in the middle of a sales call. We can take a process that used to take two weeks and five people and bring it down to something trivial.

We decided to “End If” the process took us no work whatsoever.