I spent two years of my time, effort and resources to build a product. Then I killed it.
Two and a half years ago I had the idea to build a product where teams can share knowledge (called wikit) but for distributed teams. After releasing three iterations of the product, gathering feedback and analyzing the market, I threw it all away.
Here’s why: it had no stickyness. We had built a ‘set it and forget it’ product.
We’d built something teams would use once or twice a month, that’s not a good product. It only solved a tiny problem, nothing more.
How did we know this? Feedback.
We did demos and invited teams use our product. Once we looked at metrics and feedback: it was clear that the product wasn’t as useful as I once thought it was.
That’s the deal when you are building a software product: your ideas are not always that amazing. Or you are solving a small, or not existing problem. That is why it is so important to release early, with very few features and start showing it around and getting feedback.
This is the true definition of MVP, the smallest, fastest-shippable piece of software you can build in weeks (not months or years) and go from there. Your target customer should drive the product, not your ideas.
I killed it. But I learned a lot:
- learned the value of shipping small.
- learned the value of honest feedback.
- learned a TON about my target customer.
- learned what solution was actually needed by those target customers.
It was not a loss. It was an investment. A learning investment.
Back to the drawing board I went and for the last 6 months I’ve been working on something new, something we believe remote teams will actually use, to work more efficient and calmly. But that’s for another post.
TLDR; Build quick, build small, get it in front of potential customers. Validate and iterate. You will eventually find the right product-features-market mix.