Post-Mortem for 10 Products

Dana Levine has written an insightful post-mortem of ten products that he has built (and ultimately failed). Below is a quick summary of the products he built and why they failed:

  1. Tweedledo (web to-do list) – no traction
  2. InstantQ (queue management for restaurants) – no customers
  3. InstantQ V2 (restaurant marketing platform) – low customer (i.e. restaurants) willingness to pay
  4. Rentize (local rental marketplace) – gave up after deciding that the idea wouldn’t work very well and that the commissions would be low
  5. Wish List (search for best prices on internet) – no traction and co-founder difficulties
  6. SimplyHours (office hours scheduler) – co-founder left to work on something else
  7. SpeakerGram (marketplace for conference organisers and speakers) – market wasn’t big enough
  8. About/Team/Press (app to manage about, team and press pages) – co-founder left to work on something else

The last two were consulting projects, both of which didn’t launch.

Some of my thoughts:

  • Most of the products are pretty standard tech startup ideas (e.g. a to-do list, marketplaces for X and Y, etc)
  • None of them actually address a real pain point – they are all simply “nice to have” products, but in no way essential
  • Startups focusing on local small businesses are notoriously difficult and are hardly ever successful. Despite this, they are somehow always seductive to tech entrepreneurs (e.g. InstantQ, V2 and Rentize)
  • Alot of these products would need to rely on network effects to grow large
  • This list implies an approach to startups that goes along the lines of – acquire tech skills, find some general problem that you don’t necessarily have, try to solve it with a web app and then attempt to monetize it. This seems completely backwards. It would probably work better to start from the opposite side – be involved in a field outside of web technology, understand the problems, needs and wants of the people in the field, then learn tech skills to help them solve these problems.

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?