Learn early, Learn often
I’ve always been struggling in my head with the whole ‘release early, release often’ VS ‘release when the product is decent enough’ debate. There are advantages and disadvantages for both methods, but I never took a step back to really think of the the problem product owners or founders are trying to solve when considering this.
Release early, release often VS Release when it doesn’t suck
Houston suggests that maybe the wrong question is being asked here. We need to take a step back and understand why one would want to do this in the first place? Feedback – we want to do this to get feedback as quick as possible so that we can validate our product before over-investing in a particular direction.
So if our purpose is to listen, validate and adapt – then what we are trying to do here is to:
Learn early and learn often
If we are trying to build products which customers want we need to learn early and learn frequently from them. The question around when to ship becomes becomes a bit irrelevant if what you are trying to do is learn. What product owners or founders really need to be asking is when do I have something that is enough for me to learn about my target audience?
For Dropbox, the output of their Minimum Viable Product (MVP) wasn’t a prototype or a limited demo account. Their MVP was presented in a video. A simple screencast. This video provided enough information to get feedback from their target audience. It allowed them to learn early, and learn often. This screencast was posted on Hacker News and almost instantly, it began to receive inputs from the outside world feedback into the product. Dropbox didn’t actually ship until after the first 18 months – the screencast they had was sufficient enough to enable them to learn from their users.
If what you have is enough to enable you to learn, gather feedback and validate your ideas with users, why worry about when to release? Show someone! You’re ready to gather feedback!
You can watch the rest of the talk or slides here: