I like the idea of a Minimum Viable Product.
Whilst it's nice to think about the fullest expression of a piece of software that completely explores its potential, you'll go broke if you wait to get there before charging people. And if you are selling software on the web you can make something much smaller that is still worth paying for. It's generally a good thing to develop that way too, if you try to do too much with a blank page you end up paralysed.
So you start early, make money, then keep working. That sounds great. Nothing to see here, thanks for reading.
Still here? OK fine. I don't like thinking in terms of MVPs, largely because of what everyone else has in mind when they talk about MVPs.
See what most people think about an MVP is you spend like 3 months or something from idea to discovery to making a signup form, a couple of screens, glue together a couple of frameworks, docker, responsiveness, some smoke and mirrors, ba-da-bing ba-da-boom, give me money. You see people launch into a routine when you tell them MVP or POC, and this routine is the wrong way to build things, because the software doesn't do anything useful.
If you compare software to novels, the fullest expression of a piece of software is like a series: you come up with a rich world, a magic system or science fiction setting, social structures, interesting characters, and you develop that over the course of multiple books until all that territory is explored. Of course the most practical thing to do is write one book first, then use that money to fund yourself as you write the next few books.
But what most people have in mind when it comes to MVPs is more like immediately going to an illustrator for the cover art, maybe picking your shirtless model, writing a blurb, going to a printing press, and using some story template where you fill in the names of the characters (maybe after doing a little market research to figure out which demographics are in), and putting that in bookshelves, without ever writing a full book or thinking about a world or characters or plot or anything like that. That's literally what a 3 month book would be like.
I'm not just being pedantic. I'm in the midst of looking for investors to fund my startup, and many of the sites ask what stage you've gotten to, and they're basically organised like that - with MVP as one of the earlier options.
The first issue with MVPs is that Minimal is not well defined. Is there anyone that thinks you should do more than you need to? Everyone thinks that what they are doing is needed, and therefore included in the minimum. Charitably, the term Minimum here is about focus. Understanding what's the core and what's peripheral. In practice though, it's about doing a rush job
The other issue with MVPs in practice is the P - Product. The underlying idea people have in mind - something you can see they intuitively share from how readily they understand each other and work a certain way even if they were just hired - is that you quickly go from nothing to Product. If you've read Project vs Product, you'll know that's not how I think of things.
I think that you should start with a Project first - something where you aren't dealing with all the pesky Product stuff that gets in the way of making a good core you can build on. If you're steeped in Modern Corporate Agile, you're about to scream "That's what POCs are for". Or prototypes. Or spikes. But again this has in mind a time frame and focus that is fundamentally different from what's important. A Proof Of Concept (POC) is even shorter than an MVP. And a prototype is utterly unconcerned with designing something good (not visually but conceptually).
With POCS, spikes, and prototypes, you do something in a few weeks maximum not really caring about anything, and then write up some document, and go back to full Product Mode. I'm talking about a constrained form of caring, where you don't focus on visuals or working on people's machines or whatever, but on the underlying conceptual model, even going as far as rewriting it multiple times, and then focusing on it as a Product.
For me the point of starting with a project is exploring / developing a philosophy. Figuring out the right primitives, and the right algebra for your system, that everything else gets built on top of. This is not a rush job - it often requires a lot of back tracking and thinking in the hammock. You can't schedule this.
Two main reasons people advocate for MVPs is that it lets them say no to feature requests, and as a response to perfectionism. I think we should just say no without resorting to the MVP defence - just say "this stuff is complicated enough as it is and I can't think about more right now". As for perfectionism - well just use software and you'll see that we have no issue with too much perfectionism, if anything we have too much crap. As I said earlier, the perfect expression of a piece of software is like a series, and we just need to make a good book. A good book still takes a long time, but it takes a year rather than a decade or 3 months.
I'm fortunate that for my startup, I've basically got a whole book and I'm ready to put it in bookstores soon, in large part because I spent a lot of time off and on after work getting it there. For future products though, how would I go about this? Well, I'd need some spare capacity. Maybe extra employees, or time, so that not all of it is required to maintain the current product. Then I can spare having people work on and think about other things, until it becomes more fleshed out and then we can start thinking of how to productise it.
There are broadly speaking two kinds of people in software. The first kind are makers. You can call them artists. They care deeply about what their doing, and their goal is to make the right thing - and discover what that is. Whilst they have a general idea of what is wrong and what needs to be done, there are a lot of blanks, and they try to find the right thing to fill it. Releasing it to the world and making money from it is not their focus. The second kind are hustlers. Hustlers are basically indifferent to what they do as long as they make money. They don't know or care what they make, they'll figure it out based on how people react.
If that was the full story, it would horrifying, everything we use would be a product of people who don't care. Fortunately, it's possible to design something you care about, and then launch it. In fact, artists want to spread their art. Once their art is matured they lament that the rest of the world is stuck with crappy art. Although by default the artists are design-philic and hustle-phobic, and the hustlers are hustle-philic and design-phobic, it's possible to create an emulsion, where the thing that was initially created by a stubborn artist is then sold (semi) ruthlessly.
I don't call this a Minimum Viable Product. I just recognise that the Project has matured enough that I can make it a Product now, and work towards getting it there. It's not a strict stage with a strict time frame. I have a rough list of what needs to be done, and I strive for that but also keep a eye on how people are responding and revise my original Product list.