HN Explorer

Rethinking the Minimum Viable Product

9 points by jonutah ↗ HN
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

8 comments

[ 3.9 ms ] story [ 27.4 ms ] thread
ggm
Proof of concept in my workplace works for tech and design. It dies in the c suite who obsess with L&F and their favourite feature. At one remove, showing them prototype as mvp tickles this out but the "cost" in alienating the decision makers may be too high.

Training senior management to look beyond wireframes and lorum ipsum can be hard.

Consider that significant buildings were born from napkin sketches. I consider this problem pretty dire, but there you go.

I'd say a 3rd iteration of an mvp should be good, better at least. Holding them off from looking at it and getting permission to a/b test in public might be hard.

kentich
The concept of an MVP is wrong. There's no such thing as minimum viable product. A product can be viable or not. It's a binary thing.

This word "minimum" only confuses people. That led to the present situation of developers calling prototypes, raw, and demo versions of their products as MVPs.

sam29681749
I don't understand your issue with the concept. An MVP is a product with the minimum amount of features that still viably satisfies it's objective.
rozenmd
I think what most folks miss is that only building the core functionality is not enough to be viable for most customers.

The "core" part of OnlineOrNot took a weekend of engineering work to get into an MVP state.

The other 99% that non-early adopters need to feel like the solution is for them (user management, audit logs, and other SaaS table-stakes features) has taken more than 3 years.

sabbaticaldev
spamming it on every HN comment you make is included in the 99%?
mominji
It's called scamming customers. You have the same attitude as the Rabbit R1 guys
venuv
GenAI will make markets narrower and deeper. Vertical market consumers are performance intolerant. They are also far more enlightened about their needs than typical. Don't think you'll get 4 shots at goal - but the MVP concept will evolve to far more than todays
karmakaze
This is a gross mis-appropriation and application of MVP from "Lean Startup". Its use is for startups (not established corps) to learn about a problem space and find out what potential customers would be willing to pay for.

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.