MVPs are about prioritized Depth, not crappy Width

MVPs are about depth not widh

Even though product people now already start arguing about whether to focus on the riskiest assumptions instead of a viable product, the good old term MVP is still a good conversation starter. Especially within companies which may not be exactly ‘cutting edge’ when it comes to product development, the intent to launch earlier and ‘leaner’ poses a huge mindset shift.

The biggest pushback I often hear about the MVP approach of a new product is the assumption that it is a shittier version of the overall vision gets shipped. This fundamentally wrong misconception then leads to huge concerns about the negative impact of a broken product for the brand which then leads to a ‘build everything and build it perfectly’ attitude before any iteration of a product idea gets into the hands of actual users.

To condense the real intent of an MVP in the context of this wrong perspective on the subject, I liked the following conclusion the best:

An MVP is about building the most critical value proposition (meaning feature) to prove your product idea’s potential first and shipping it in the best possible quality to your target users. It is not about building slimmed down or extremely compromised versions of all your feature ideas and bringing those to market.

While probably every product manager out there enters compromises as part of her regular product iterations, those are not meant to decrease a product’s quality but are the result of necessary trade-off decisions to make the biggest impact within the (given) constraints of time or resources.

A great visualization of what the difference between a shitty version of an overall product vision and sufficient qualitative iterations of the main value propositions can be found at the top of this post.(intellectual property of Spotify).

Hopefully, this helps you the next time you are in the midst of a discussion with stakeholders (or even yourself) about what it means to build an MVP after the general intent of a project was expressed and aligned.
The best food for thought from the image above is from my perspective that an MVP doesn’t even necessarily need to be in the same format or channel of the overall vision. For example, a manually curated newsletter could be the MVP of an app-based community platform (yes, that’s precisely the story of Product Hunt).

MVP vs. Jobs-to-be-Done Discussion with Bram Kanstein and Mark Jäger

After a lively discussion on twitter about the most popular MVP visualization out there, I recorded a brief conversation on that topic with Mark Jäger and Bram Kanstein.
We discussed the challenges of building an MVP ‘the right way’, un-covering user jobs along the process and how to validate your earliest assumptions.
Enjoy and please share your thoughts on this topic with us. Either by commenting on this post or on Twitter. Enjoy the video!

What’s your elevator pitch stating what an MVP is supposed to be and what it’s not?

Leave a Reply

Your email address will not be published. Required fields are marked *