|
|
|
Rethinking the Minimum Viable Product
|
|
9 points
by jonutah
668 days ago
|
|
We build a lot of applications for internal use only and most of the conversations start with "what's the MVP". I think planning to deliver the MVP in version 1 is wrong and instead you should be aiming for version 3 to be the MVP. I have been pushing for 2 prior versions to be released but I only think it's relevant for corporate/LOB apps. This is largely a reflection of my working primarily for large organisations with heavy governance overheads and as a result low trust from end users. Version 1 should be the version that is functional in so far as it has all or most of the application components in it. It is the version that goes through the slog of your internal change process and governance ie it should be done as early as possible. It is the version that proves to your customer that an app can exist. Version 2 should be a more functional version of the app and follow pretty closely behind version 1. If you're lucky the governance processes for application "changes" will have less friction. This is the version that proves to your customer that application upgrades are simple and can happen more frequently than once a year (which is often the expectation). It also proves to your team that application enhancements can be made in small chunks and not big bang. Version 3 is where you shine with the first usable version of the product without all the stress and delay of what you have conquered in the first 2 versions. Version 3 makes versions 4 and beyond really meaningful to the end users as you have built their trust in your delivery process and ability. Interested in thoughts on this or other approaches to gaining trust and traction when building LOB apps? Cheers |
|
An internal tool doesn't have these aspects. What's being labelled 'MVP' here is a first fully usable version of an internal tool--quite different.
Folks can go redefining terms and writing about it, just don't expect everyone to follow along.