Why do you build products with an MVP mindset?
It's more than just a buzzword term for building products
As someone who concentrated in Entrepreneurship in college, the Minimum Viable Product (MVP) was a term I learned about more often than I wanted to. As a student, I understood the concept to mean something along the lines of “building a basic product.” A basic product gets in customers’ hands faster. Don’t spend a lot of time and resources on an initial version. After all, its purpose is just to validate a concept and point your product, and business, in the right direction.
I wasn’t incorrect, but I did lack context and work experience at the time. Fast forward to 2021, the MVP means much more to me. After spending time working in product at a seed stage startup and now at a growth stage business, I’ve gathered two takeaways regarding why building product with an MVP mindset is essential:
You have limited resources —Companies do not have an unlimited amount of engineering resources, and you don’t have an unlimited amount of time to map out requirements. It’s also likely that your upcoming sprints include work on several different customer-facing features and engineering initiatives to keep the product running smoothly. If you are going to have the resources to work on all of this, something is going to have to give.
You have customers with varying feature requests and preferences (and a lot of feedback you haven’t yet received!) — by the time you release an MVP, you are fairly certain that the product meets the initial needs of a group of customers (let’s call this Group A). But the story for the product does not end there — there is a predictable set of events that usually follows:
After interacting with the product, Group A provides feedback. It is likely that there is a common thread amongst the group, and that common thread becomes a close follow on feature released a short time later.
A different set of customers, Group B, contains users that interact with the product a little bit differently; consequently, they provide different feedback and a feature request that you hadn’t considered!
Final post-launch feedback indicates that the feature request provided by Group B really resonates with more of your user base and can lead to greener pastures. The product becomes more marketable and differentiated from competitors.
In other words, releasing an MVP and closely monitoring customer feedback resulted in 1) a happy initial set up of customers, 2) saved upfront development time and 3) a better product just a few months later. As a PM, you’ve made customers happy while working on several different items that will make your colleagues across departments happy as well. Your MVP will actually end up making more customers happy than you thought it would. The way you decided to build the product was smart!
What have you learned about building with an MVP approach?
This post has been published on www.productschool.com communities.