Minimal Viable Product is old and busted

You're expecting normal people to successfully invent the car? I have much more faith in them forming a relationship with a paying customer, and offering a small process improvement through a MVP.

An MVP will also help with appropriately market timing of your product. If the client is asking for a faster horse, you might want to look at innovating the saddle or horseshoe first. You might be 1000 years too early with your car engine idea.

It’s quite rare that a customer knows exactly what they need; often, if they do, they build it.

The wins happen when a customer knows what problems they have, and you can present a solution that solves them better than they could otherwise get elsewhere.

Otherwise, as you say, they will build it or buy it elsewhere.

Agreed.

The management of requirements in building anything needs to be structured properly to manage client expectations because it's often the first point of failure on development projects. MVP is a concept that is implemented on mission critical projects in order to insure a minimally acceptable point of project success, not to "be" project success... Anything else that can be added (within the implementation time frame) after base goals are met is a bonus.

Scope and schedule creep are 2 of the biggest threats to any major project, and it takes technical oversight just as much as managerial oversight... Technical Architects usually bridge this gap on projects.

An MVP is meant to be something that is generalized enough to fit KEY customer needs in a limited time frame, not ALL of the customer's needs, and customers inherently try to squeeze changes in during execution in large-scale projects. MVP for small-scale and startup projects may not mesh well, unless needs are well defined by an accountable customer.

An MVP is a contractual deliverable, so it shouldn't be delivered or even started before that contract is properly written and signed off.

Key aspects of a successful MVP -

It needs to be scale-able and mindful of future integrations and functionality.

It needs to be able to pivot and adjust to change, especially changes outside of your control (e.g. The Pandemic).

The data therein needs to maintain integrity and transfer-ability.

This is why experienced IT/Business architects are necessary on key projects. They incorporate business drivers, requirements, project management objectives, and technical teams into meaningful language, documentation, and project outcomes.

When you struggle on without an architect, projects suffer from a lack of direction, mixed communication, and often waste lots of money on back tracking solutions.

MVP is also a "version control" and project/client management concept/methodology, not a development language. The author broke down the title based on the words used. Taking time out to really investigate an understand why so many credible people use the term is a better move than declaring it obsolete.

I've worked on products where customer development was essential and also on products where it was largely useless for product development. You are assuming things about the product development process and customer interactions that are not always true. That doesn't imply that you don't talk to customers or don't understand their problems, just that this can be disconnected, often necessarily, from the product being developed.

As an example, hard tech products in data infrastructure often have this property. Famously, there are no incremental product outputs to show customers (or investors) as a matter of fundamental engineering; the product has to be almost fully baked before it can demonstrate anything of value at all. Customers have a difficult time understanding the implications of fundamentally new capabilities until they have time to play with them; they provide no useful feedback until the product has already reached a stage where this is possible (read: almost fully baked). And of course, there is no "iterate quickly" because the product value follows from architecture; if the architecture isn't correct the first time then iterating on the product means starting over from scratch. Consequently, the only people that can successfully build these products are people with serious expertise in the product and its use case. Even if you try to do customer development, there is nothing for the customer to engage with until you are well past the point where their feedback can materially change the product.

In these cases, no amounts of customer development will make up for a lack of deep domain and market expertise. The lean startup/MVP/customer development etc literature tacitly assumes that every product is an "app" of some type. If you work on software products that are not "apps" then you may find some of the advice to be misguided or useless.

If it doesn't stand a chance it's not viable, right?

What is smallest product we can build to learn something from and iterate with. If you build something too small that no one uses because it doesn't have enough features, then you can't learn anything from it (apart from you need to build more).