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

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.