How can we learn to build if not by building? One may think this goes without saying but we have often ended up building products that don’t generate that desired long term resonance with users. This does not in any way invalidate the need for the product to have the right product-market mix. Here in lays the concept of the Minimum Viable Product (MVP) in product development.
Introducing the Minimum Viable Product
Eric Ries defines the Minimum Viable Product as that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. The definition's use of the words maximum and minimum means it is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense.
The definition implies the product you are looking to present to potential customers must be viable. A quick comment on this statement as it relates to the Nigerian ecosystem. We don’t really do MVPs rather we want to be sure if we can sell this shiny new product. Viability tends to imply survival which I think slightly hints at negativity. We just want to sell it. The idea though stemming from our inherent survival instinct can be attributed to a whole lot of things. *For startups financing is a major factor. We have seen in recent times startups that are looking to develop solid products but nothing really comes out of the beautiful noise. This is not to cast aspersions on entrepreneurs but we want to see more products hitting the market; a sure way to have a robust diversified ecosystem.
So the question is why create a product you can’t sell? Why expend so much energy, effort and time on a novelty? Is it to generate a buzz around your company? Then we can say every publicity helps but imagine the amount of everything spent on this app. My personal take on this is if you can’t sell it don’t make it unless there are other intrinsic benefits that are unrelated to the market. If this is the case, by all means keep building.
Saleability precedes viability
To assess whether your product is viable you need to genuinely ask yourself the question, is there a use case for this product? Will it meet the needs of my potential customers? Expending hundreds or even thousands of coding hours on a fad doesn’t really cut it. If there is the potential to sell, then it must be viable. I prefer to call it minimum sellable product. It makes sense right as we are always asking the question, can I sell it?
Viability depends on engagement. You engage with your customers to enhance the product. You create the feedback loop to get the right information. This is the whole point of MVP re MSP. Can I sell it? Yes. Then I will create a minimum viable version of the product so that I can get feedback from my customers to improve the product. This usually takes the form of testing. At PrognoStore, we have tested our product in-house and we are looking to let potential customers use (test) it. This means we can gather more information that we would have had access to only if we are currently running our own stores.
Avoiding scope creep in MVP
Scope creep is a killer of time and an eater of money. You need to avoid scope creep to enhance your chances of creating that killer MVP on time and on budget. You don’t have a ‘forever’ time. MVP should be created quickly and delivered to the users for real time testing and feedback.
- Think of the user – The user comes first; this goes without saying. You need to understand your target market. You must seek to satisfy the needs of your potential customers. You may not have a current need to satisfy but rather to change behaviour; this should also be identified quickly as well. Satisfaction of customers’ need is the cornerstone of a successful application development
- Is it over-designing or over-engineering (like trying to take the perfect camera shot). Do you have an SRS? Is it a robust working document? You can’t just design from your ‘head’. You need the wireframes and designs before letting the front end and back end guys do anything. Having wireframes of every design does help in eliminating or reducing design iterations. We usually work off the back of wireframes of pages that are part of the SRS. This reduces ambiguity. The design objectives that are clearly stated are easier to achieve.
- Ease of use -- one step or one-two steps? If it is not easy to use, you should rightly expect some strong negative feedbacks. If it’s not easy to use you may have to re-engineer the logics and processes.
MVP and User Feedback
This is where you make your bacon. Potential problems can be avoided with useful customer feedback. They are the users and will have a thing or two to say about the product. This is not your regular testing. It is granted that you would have tested the product to satisfaction. Bugs have been captured and resolved.
Be the smartest in the room
Give it a try, you can unsubscribe anytime. Privacy Policy.
For PrognoStore, we have had to change designs over and over before putting users on the system for user-testing and feedback. We have changed features severally only to end up at the starting point. The key thing to keep in focus is the user. I have learnt that no matter how brilliant or innovative a feature is, simplicity should overrule. If not, you may end up with a monster that will totally throw off the users and you will need to ‘unbundle’ and rework everything. So think, design, develop, test, rework or rather stop, think and build that MVP.
*Unavoidable digression that needed to be mentioned as it is the bane of most Nigeria startups
Photo Credit: wvs via Compfight cc
