Post Mortem on a Failed Product

Just over two years ago, at the beginning of 2008, we set out to build a web content management system with community functionality infused throughout — eCrowds. The idea was that companies would need a solution for facilitating product communities with the following functionality:

  • Content management
  • Forums
  • Blogs
  • Idea exchanges
  • Wikis

We were solving the traditional challenges brought on by disparate silos of data with separate user authentication systems and inconsistent interfaces/template designs. 2008 was spent building the product and we launched it for our own internal customer success communities after nine months of development. It was a failure.

Here are some of our lessons learned:

  • We spent way to much time building it for ourselves and not getting feedback from prospects — it’s easy to get tunnel vision. I’d recommend not going more than two or three months from the initial start to getting in the hands of prospects that are truly objective.
  • We made the product much too broad such that it did a little bit of everything. Unfortunately, it didn’t do anything exceptionally well. As an example, when we used it to replace our phpBB message board instance, our community was in an uproar because it lacked many of specialized features a mature forum offers (e.g. notifications and handling code examples in a comment).
  • The tools we were replacing were pretty cheap (e.g. each item was typically under $100/month), and we wanted to focus on the small-to-medium sized business, as that was our area of expertise, so we priced the product around $500 – $1,000/month. This caused another major disconnect — the integration costs were typically $10,000 to migrate an existing site into the system. With those integration costs, the sales cycle became prohibitively long/expensive relative to the lifetime value of the customer and the recurring revenue.
  • As the product became more and more complex, the performance degraded. In my mind, speed is a feature for all web apps so this was unacceptable, especially since it was used to run live, public websites. We spent hundreds of hours trying to speed of the app with little success. This taught me that we needed to having benchmarking tools incorporated into the development cycle from the beginning due to the nature of our product.

So, to summarize, I recommend getting something simple into the hands of prospects quickly, picking out a narrow niche and doing it well before going broad, thinking through the economies of customer acquisition costs relative to the revenue generated, and making sure the app always runs fast.

What else? What are some other lessons you’ve learned from a failed product?

16 thoughts on “Post Mortem on a Failed Product

  1. I think that from business point of view it might make sense to provide more specialized solutions (ie. software customization and such). Generic solutions, such as the one you described, tend to be risky due to their vast scope. You have to cater for everything that already works and then some.

    Instead I believe it’s easier for smaller companies to go directly to the customer and respond to actual problems in their process. This ought to give more tangible value. It’s also less risky as the projects tend to be smaller.

    This sort of approach should help to mitigate possible migration costs or at least make them more manageable (no big bang, just incremental approach).

    • Thanks Juho for the great comment. My advice is to launch early and often and get feedback from the beginning.

  2. Pingback: Launch Fast, with Minimum Viable Product « 10,000 Startup Hours – David Cummings

  3. Pingback: 25 Best Startup Failure Post-Mortems of All Time | ChubbyBrain Blog

  4. Pingback: Founders Block » Blog Archive » 25 Best Startup Failure Post-Mortems

  5. Pingback: Usage is Like Oxygen for Ideas (in Products) « 10,000 Startup Hours – David Cummings

  6. Thank you for the post, David. This is great advice for the new startup! I’m sorry it came at the cost of a failed product for you. You learned a very important lesson from your experience and I appreciate you sharing it with us so our product won’t suffer the same demise.

  7. Pingback: Insights into Blog Traffic « 10,000 Startup Hours – David Cummings

  8. Pingback: Fortune Brain » Why Startups Fail: An Analysis of Post-Mortems

  9. Pingback: Why Big Companies Buy Small Startups « 10,000 Startup Hours – David Cummings

  10. Pingback: 5 Simple Reasons Entrepreneurs Fail « 10,000 Startup Hours – David Cummings

  11. Pingback: Startups Need to Cross-10 Out of the Gate | David Cummings on Startups

  12. Pingback: When to Kill an Idea and Move On | David Cummings on Startups

  13. Pingback: 51 Startup Failure Post-Mortems

  14. Pingback: The Most Popular Blog Posts Here | David Cummings on Startups

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s