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 
Leave a reply to Consulting Services Within Product-Based Startups | David Cummings on Startups Cancel reply