Chapter III – MVP – Minimum Viable or Minimum Valuable?
The concept of the minimum viable product is indeed a fascinating one. The term viable makes us see the least amount of features that can be pushed out to the market to get started on early feedback. This does sound convincing, in a sense that you could wait from further expensive investments till you know if your product garners the required attention.
All well said, but how sure are we that our MVP is both viable and valuable to our users? With the competition now, if your MVP does not appeal enough or stand out with a unique selling point, you might risk having your users lose interest to look forward to the completed version.
I had shared this thought of mine with my co-product owner, as we sat down to define and prioritize the backlog. The first task at hand was to decide on what was our USP (unique selling point) and what we wanted to showcase to our users so that they keep coming back.
Since the concept of our product was quite unique, we had the first half of our problem solved. We also decided that a classy, attractive design coupled with a user interface as easy as possible, would be our “valuable” part of the MVP. However unique your concept is, your product needs to be appealing and user-friendly to get the “wow” factor going.
Once these points were discussed, it was easy to get the priority assigned to the backlog. Once the prioritized backlog was ready, we called in our team for the first sprint planning. As a team, we revisited the MVP that was drawn on a chart in the room (Explained in my previous post- Chapter I- The Product Vision). As a team, we discussed the USP and the importance of a captivating design and user interface for the first release.
Poker cards in hand, we were all set to visit our first epic or user story – “As a user, I would like to have the concept of the product explained in a visual manner when I first visit the website so that I would know what the product is all about”
The above epic pretty much summarizes on the branding and how the homepage should be designed to lock in user interest. It was interesting to see how this one epic was being split up into numerous user stories and further into executable tasks.
And if anyone has doubts on the poker cards and their relevance, believe me, nothing helps you better in knowing for sure that your whole team understands your product, as well as you do!
Stay tuned for my next chapter where we see the magic of poker cards and also how we figure out the first sprint release and team velocity.