I appreciate blog post “Making sense of MVP” by Henrik Kniberg as it addresses a few important points when it comes to shipping customer solutions. In my professional carrer I have encountered already a few times issues along these points:
- the customer wants a spaceship but gets a toaster delivered
- product requirements are based on internal assumptions
- a lot of time is spend on planning and implementation to get the real thing with the first shot, but for some reason the project gets abandoned before having impact
The blog article advices to overcome these issues with MVPs. The basic idea is: What is the minimal, most basic, yet testable/usable product that an actual customer can give feedback on. Does it have to have all features? No. Does it have to be shiny? No. It really just should be something tangible that a user can test in order to validate our intial assumptions. This might re-direct the direction in which we’re going and might prevent us from building something that nobody needs or doesn’t need anymore because requirements have changed (scope creep).
In other words, we shouldn’t aim at “big bang” releases, rather we should do incremental releases to get instant user feedback.
Obviously this requires that the user has the possibility to actual test something, so ideally there is a UI and low technical friction.
One thought I was having though, is that often times MVPs are ugly and lack good UX. This makes the barrier for users to use it actually very high. So getting users to test your product in an early stage might actually be pretty hard. I don’t know what the solution is to be honest, still figuring out.
Oh and here’s the link to the blog: https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp