EventVue

Launched: May 2007

Shut Down: February 2010

Founders: Rob Johnson, Josh Fraser

Funding: $256k

EventVue started off as a private social network for conferences helping attendees network for more effectively. They pivoted twice, once to focus on a widget that would drive attendees to conferences and then again to turn EventVue into an application that promised to be “the best way experience and discuss shared events in realtime” (essentially realtime conversations for events).

Several months after the second, EventVue decided to shut down after not seeing enough traction from their new product. The founders wrote a blog post post-morten accompanying their shutdown announcement with a short history of EventVue and the mistakes they made.

Why EventVue Failed

Given that EventVue underwent two major pivots, it could be argued that the company actually failed three times. In any case, one of the clear reasons why the company failed was because it lacked product-market fit. As co-founder Josh Fraser put it in a follow up discussion, EventVue was “a vitamin instead of a painkiller. Conference organizers typically liked our product but none of them said they needed it.  It didn’t make their lives easier, make them more money or cut any of their expenses — it was just “nice to have”.

EventVue started off trying to make the conference experience better. But they found out that conference organisers didn’t really care about the quality of the experience, let alone pay for someone to improve it. As one customer bluntly put it, “If I wanted to improve the conference experience I would buy everyone steak dinners. I don’t care about the conference experience. I care about selling tickets. What can you do to help me do that?”

So EventVue pivoted in the most logical manner – find ways of marketing and driving attendees to conferences in order to cash in on affiliate payments. They did this with the EventVue Discover widget, which would let people know who else was coming to a conference. But it had the  unintended consequence of actually losing money for customers. To quote Josh, “One statistic that is true for almost every event: 80% of ticket sales come in during the last 2 weeks.  This meant that showing the list of people attending the event actually had the opposite effect than intended. Instead of seeing their friends that were attending, they saw that no one had registered yet and assumed the event was a dud.”

I suppose by this stage EventVue had no concrete idea how it was going to make money since its first forays had failed and its assumptions more or less proven to be wrong. They tried pivoting again, but eventually ran out of steam and money.

EventVue’s post-mortem discusses the other mistakes they made, but none were really as significant as not finding the right product-market fit. In other words, EventVue hadn’t built something enough people wanted to pay for. The other mistakes include:

  1. Not testing their assumptions beforehand about whether or not there was a market of paying customers for their product, and not reacting until it was too late
  2. Too much early focus on trying to sell a weak product without investing the time to improve it
  3. Not committing fully to the product pivot (for the Discover widget)
  4. Dubious business model – EventVue tried to pursue an enterprise sales model with a “non-recurring, small price”
  5. Too much push, not enough pull – EventVue wasn’t configured to allow anyone to come and use the product (i.e. no “self-serve” option)
  6. It’s also implied that they made bad hiring decisions

Lessons Learned

The overall lesson from EventVue is to solve a problem that people will pay money for, or perhaps on a more general level simply – build a product that people will pay for. Obviously this is easier said than done, but coupled with this key point are three more specific lessons:

  1. Test your assumptions and test them quickly – EventVue built a product then went out on the road trying to sell it without testing their assumptions, tweaking the product and creating something that enough people would actually pay for. By the time they realised it wasn’t going to work and pivoted, it was already probably too late.
  2. Keep iterating – until you have a product that has good market fit, or until you become convinced that it won’t work, or worse, run out of money.
  3. Understanding the customer’s needs – in EventVue’s case, their customers were the conference organisers. But EventVue started out by trying to make a product to meet the needs of the conference attendees (i.e. the customers of their customers). But they soon found out that the needs of the organisers and attendees were not necessarily aligned.

Lastly, co-founder Josh Fraser has some specific advice for startups in the social networking for events space in this follow-up post.

Advertisements

Newstilt

Launched: April 2010

Shut Down: July 2010

Founders: Paul Biggar, Nathan Chong

Funding: Seed funding (Y Combinator)

Newstilt was a journalism startup that operated for only 3 months after launch (or 8 months from being founded). The Newstilt concept was to provide a set of online services for professional news journalists to build their own brands and content networks (e.g. services such as web site design, content management and syndication, advertising, etc). It was conceived as a means to provide a sustainable business model for online journalism.

Co-founder Paull Biggar wrote a lengthy blog post titled “Why we shut NewsTilt down“, which provides detailed and insightful commentary into why the company failed. Along with my own thoughts and input from several other analyses, the reasons for NewsTilt’s failure and the lessons that can be garnered are distilled below.

Why NewsTilt failed

There were quite a few factors suggested that contributed to NewsTilt’s downfall, but they fall under a few major categories: 1) poor execution, 2) lack of industry understanding and passion, 3) problems between founders and 4) lack of investment.

1. Poor Execution

The idea behind NewsTilt sounded good in theory and generated a fair bit of enthusiasm, but poor execution helped to derail the company. There were a few key components behind the poor execution:

a) Not delivering the core features that would have attracted journalists – NewsTilt promised alot of features to journalists, but then didn’t deliver them. This may not have been a problem if the promised features were incidental, but even the most important features weren’t provided. For example, one of the core promises was that NewsTilt would help journalists build their own brand using their own domains, but this was inexplicably cut from the minimum viable product “in order to make the launch date”. Instead, NewsTilt hosted all the content in its own website, barely differentiating itself from other news organisations. This was understandably perceived badly by the journalists and content eventually dried up.

b) Overpromising, but not delivering – this seems to be a recurring theme with NewsTilt. They promised the journalists their own platform, promised to do the promotion and marketing for the journalists and then promised a bunch of technical features that were never implemented. The problems probably weren’t the promises themselves, but rather the capacity to fulfil them. In each case, NewsTilt either didn’t have the expertise or the resources to actually deliver on the promises.

c) Re-inventing the wheel – NewsTilt decided to build the entire platform from scratch, rather than using commercial or free software components (e.g. WordPress) that people were already familiar with. This turned out to be a mistake, as their limited resources were sucked into building the common platform instead of developing the core features.

2. Lack of Industry Understanding and Passion

Neither founder knew much about the news industry or journalism in general, and Paul Biggar admits that neither of them really even cared. This contributed to a number of problems including a lack of understanding of who the customers were and what they wanted to read and choosing the wrong journalists. Moreover, Paul didn’t even use the product himself and wasn’t particularly passionate about news and journalism. As a result, both founders were completely ignorant as to how they could actually deliver on their promises.

3. Problems Between Founders

Paul Biggar alluded to “communication problems” with his co-founder Nathan Chong, which resulted in them having disparate visions of NewsTilt. Living in different cities didn’t help their communication problems either. The co-founders hadn’t worked on any projects prior to NewsTilt and found their relationship stressed from the very beginning.

4. Lack of Investment

NewsTilt received only seed funding from Y Combinator (around $50k) but what they needed was alot more investment capital so that they could pay the journalists and give them incentives to write. Their scope was far too ambitious to be implemented on a bootstrap budget and it was likely bound to fail without further funding to pay for the content, development and marketing costs in order to build the audience and gain traction.

Lessons Learned

  1. Make sure the minimum viable product (MVP) includes the core features that will attract customers (or contributors in NewsTilt’s case). Ensure that the MVP delivers on the key promises of the product.
  2. As a corollary to 1), work on the core features that will differentiate your startup. Where possible, try not to re-invent the wheel by using standard third-party packages.
  3. Industry knowledge or at least passion for the subject is essential. As NewsTilt have demonstrated, trying to start a business in an industry you don’t care much for is not likely going to end well.
  4. Co-founders should have some past experience working together and should have a good rapport. It’s often said that being startup co-founders is like being in a marriage and therefore personal compatibility and a strong relationship is a must.
  5. Once you alienate your customers or contributors, it’s a long road to winning back their trust. NewsTilt managed to alienate both their contributors (by not delivering on promised core features) and customers (e.g. requiring Facebook integration and launching without any content).
  6. If the scope of your startup requires large amounts of funds to build traction, then you need to either secure funding or reduce your scope.

We didn’t fail, we just showed that it didn’t work

An interesting and optimistic take on startup failure by Boris Veldhuijzen van Zanten, founder of The Next Web and Twitter Counter. The gist of the story is that Boris and his team developed an idea for some anti-spam software that ultimately didn’t work out. That’s not a particularly novel story by itself, but the interesting part is how they framed it – as a successful “dis-proof of concept”.

What is admirable about the story is that Boris and his team conceived an idea, developed it, tested it and then let it go when they realised it didn’t work. In other words, they failed fast. Having taken on investor money, they could have tried to keep developing the software or even pivot, but they chose to honestly explain the situation to their investors, return the leftover money and move on.

Unfortunately, the evaluation of most software startups isn’t so cut and dry. In this particular example, Boris had an idea that could be assessed solely on its performance, i.e. it either works or it doesn’t. But for most startups, the metric isn’t if the software actually works, but if people want to use it and perhaps more importantly, are willing to pay for it. Therefore it’s more difficult to decide when to let a startup fail; for a startup founder, it becomes a question of judgement and opportunity cost – is it worth our time to keep persisting with this or are we better off just doing something else?

Skribit

Launched: December 2009

Shut Down: July 2011

Founders: Paul Stamatiou, Calvin Yu

Funding: Seed funding (Georgia Tech Edison Fund)

Skribit is a tool to help bloggers cure their writer’s block by crowdsourcing post suggestions. Readers get what they want to read and bloggers get ideas and a sense of what topics are popular with their audience.

As co-founder Paul Stamatiou puts it, “Skribit provides bloggers and readers with a unique form of interaction. Bloggers put our widget module on their blog and readers may suggest (anonymously or through an account) article topics through it. Readers can also vote for these topics. However, the widget does not just show the top 5 post suggestions. There is an algorithm behind it that displays suggestions that are hoppin’ based on recency, number of votes and a few other factors.”

Why Skribit failed

From their shutting down announcement, the official explanation is that Skribit only appealed to a niche group of bloggers and wider traction wasn’t forthcoming. Thus the team decided to move on to other things.

A look at some of the blogs that used Skribit offers some further clues as to why they weren’t getting any traction:

  1. Skribit widget blog integration – the widget is quite unobtrusive and could have been mistaken for another comment form, chat box or contact form. Differentiating the Skribit widget more clearly as a suggestion box and also providing information to users about Skribit may have helped (but it’s certainly a fine line between unobtrusive and garish).
  2. Bloggers themselves seemed to taken a laissez faire approach to using Skribit. They installed the widget and just let it go. In some cases, bloggers didn’t even install the widget and added only a vague “Make a suggestion” type link. Perhaps they needed to push Skribit more heavily in their blogs, but ultimately, if a new service requires that much active marketing by customers, then it’s probably going to struggle.
  3. There are many social media options for bloggers and new ones appearing all the time. For some bloggers, Skribit may have just gotten lost in the many available widgets and applications
  4. Some bloggers pointed out that the Skribit widget was code-heavy and slow (at least in the early versions).

Moreover, the business model seemed a bit suspect to me. Skribit employed a freemium model with a free basic account and a PRO account for $24.95 per year allowing for unlimited blogs, unlimited suggestions (normally limited to 15 active suggestions on the free account), suggestion moderation and widget customisation. Skribit never revealed the number of PRO account subscribers they had, but I can’t imagine that it would’ve been too many given the PRO features really aren’t very compelling.

Overall, from a complete outsider’s perspective, the Skribit team seems to have been too ambitious in their expectations  – they wanted a big win in a crowded space of social media applications and tools. The service was popular enough amongst bloggers although it may have taken Skribit a longer time to differentiate themselves from other services. The business model was also probably in need of a workover. While Skribit could still work as a side project, it appears as though the team ran out of both funding and interest.

Wesabe

Launched: November 2005

Shut Down: July 2010

Founders: Marc Hedlund, Jason Knight

Funding: $4.7M

Wesabe was a personal finance management web app that allowed users to track their spending and help them manage their finances. There was also an element of data mining and analysis where Wesabe would use the data collected in aggregate and offer suggestions to the users.

By Co-Founder and CEO Marc Hedlund’s own words (from “Why Wesabe lost to Mint“), Mint overshadowed Wesabe almost from its launch in September 2007 (10 months after Wesabe). Wesabe eventually folded after running out of cash and not generating enough revenue to continue.

Why Wesabe Failed

Ultimately, Marc Hedlund puts the failure down to user experience, the key difference between Wesabe and Mint:

  1. Mint used a third-party financial data scraper and aggregator (Yodlee) while Wesabe tried to make their own, which wasn’t nearly as good.
  2. Mint focused on making their service as user friendly as possible (e.g. automatic import, categorization, editing, etc), essentially allowing the user to do as little work as possible, while Wesabe focused on tools and other features.
  3. Mint’s site was better designed

Another takeaway was the difference in the marketing spend of the two companies; Mint embarked on an agressive marketing and user acquisition campaign while Wesabe “spent almost nothing”.

Some other reasons that were floated for Wesabe underperforming vs. Mint:

  1. Branding – the name Mint was superior and led to better brand recognition. The value of the name is debatable, but may have been factor on top of the usability differences (not least because it was easier to remember and spell).
  2. The value of blogging – Mint were continuously blogging about topics in personal finance, often with very popular infographics, which no doubt helped to build their brand.
  3. Targeting the right audience – Mint purposely targeted an audience of middle-aged men and “soccer moms” who were neither financially or technologically proficient.  The argument was that Wesabe (and other personal finance apps) were directed at those who were already financially / technically aware and ultimately Mint’s target audience was just bigger.
  4. iPhone app – Mint had one, Wesabe didn’t (at least not to begin with)

There is more post mortem discussion at Hacker News.

Lessons learned

  1. Focus on user experience, make your product as easy to use as possible.
  2. Use third-party applications and packages for things outside of your core business (don’t re-invent the wheel)