Today is the equivalent of “Demo Day” if you are familiar with the Scrum product development methodology. Demo Day happens at the end of a sprint (typically 2 weeks of development work) where the word done during that time is presented for review and approval. The demo is given to the product owner who will accept the work as done or not done; according to a pre-determined ‘definition of done’.
In our case, we reduce the time to develop a product from 2 weeks down to about 2 days. Although we did spend a good amount of time up front answering some of the big questions that often remain unanswered until things go wrong after product launch. Specifically, we worked on the marketing aspect of our products first to ensure that there is a need and a customer base that we are servicing. Without those, we end up spending time and money on something that we can’t sell.
So, how can we finalize and prepare out product for acceptance and then launch? There are a few important steps to keep in mind when you are finalizing your product development and preparing the product for sale.
First, feature review. Second, MVF (minimum viable feature). Third, buildable.
Does Your MVP Have Correct Features
It’s very easy to become subject to feature creep. Feature creep is a very similar concept to scope creep; which means your original objectives no longer define the boundaries of your project. As a result, you end up building something much larger and more complex than you ever intended. This happens incrementally and almost undetected. While it might seem like a good thing to accidentally create something bigger than you originally set out to build. But, more projects have been canceled or killed as a result of going over budget and past the scheduled delivery date. And scope creep is to blame.
To avoid scope creep, and in our situation feature creep, it’s important to make sure that you have properly and accurately documented what your product is supposed to do. Of course, this abstract idea of feature creep isn’t helpful without a concrete example. So, lets use a real-world project that I worked on that suffered from feature creep.
I was contracted to build a mobile application for a new business. The business was simple in concept; sell bread to customers through the mobile app and then deliver it to their homes. Now, for several reasons, a simple app that only sold bread and then had it delivered to the customer’s home doesn’t seem too sexy.
What happened pretty quickly is that the scope of the project quickly became much bigger than providing a bread-buying portal and often was thought of as the beginning of a nation-wide app-based farmers market.