Most of my recent discussions with startup founders working with us @ Spring revolves around budget -of course :)- and consequently about what makes an MVP, I find myself having to go back to adjust the definition of the term to be able to reach a resolution and reprioritize the product backlog accordingly.
This is what the MVP page on wikipedia says:
A Minimum Viable Product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development. Some experts suggest that in business to business transactions an MVP also means saleable: “it’s not an MVP until you sell it. Viable means you can sell it”. — https://en.wikipedia.org/wiki/Minimum_viable_product
And below is what I believe it means and doesn’t mean:
- Viable doesn’t mean taking shortcuts to delivering an enjoyable and productive user experience
- Viable doesn’t mean ugly or so 2009!
- Viable doesn’t mean ad-hoc branding.
- Viable doesn’t mean filling the product with all jobs that need to be done from the get go so competitors can’t find a way to compete with you! You’ll end up spreading your operation thin and becoming unfocused to a point where nothing really gets done.
- Viable means carefully selecting the jobs that can be done offline before you invest too much into automating them. Not to mention the feedback you will have to warrant a better investment in design & development later on.
- Viable doesn’t mean catering for all the types of user personas that might need to use the app, focus on the few who will definitely need your product and would be happy to participate in it’s early days.
- Viable doesn’t mean free, try freemium, try a closed beta, have a monetization strategy early on.
- Last but not least; viable doesn’t cater only to the customer-interfacing aspects of your product, your operations team needs their own MVP as well.
In short, the MVP should get your product validated: USED, WANTED, BOUGHT & LOVED.
This story was first published @Springing Forward
