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?
David Cummings on Startups 
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.
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.
Thanks for sharing your insight David. This is really helpfull.