This is the same principle of Minimum Viable Product. In MVP you launch the first version of your product with sufficient features, but not all, to early adopters so that you can get feedback from them.
MVP and the "Build Measure Learn" feedback loop, gives you important tools to leverage your product.
The language around MVPs tends to be couched in terms that pretty directly implies designing a product for external customers, though, so it tends to be harder to internalize for people who are doing in-house work, and even people who are somewhat removed from the product design process, such as many junior developers. What I've seen in is that it's common for people who are eager to impress their clients or teammates to want to say "yes" to everything. So, even if they like the idea of building MVPs in principle, in practice, their MVPs end up being pretty maximal.
Which is why I think there's value in framing the principle in terms of human-human relationships, and not just in terms of stuff like finding product-market fit. It's a more personal, relatable way of thinking about it.
The magic insight for me was when I finally realized that I could give people less than what they asked for, and they'd actually be happier than if I tried to give them everything they wanted.
I consider that a form of art/skill that we learn through multiple experiences (and errors too).
I work closely with developers and I observed that the majority try to implement always the perfect solution that normally comes with a high cost and time to develop. Clients normally prefer a solution that is quicker to implement but that responds to 80% of what he wants.
Or, to put it a bit more optimistically - usable now is better than perfect later. I've found that, if I disappear behind a curtain and spend a long time trying to make something really well-polished and feature rich, that just gives the user a lot of time to build up their expectations, and also to get frustrated by the delay. By the time you ship, they'll be actively looking for ways to find fault. When I YAGNI my way into a 80% or 90% solution and turn it around quickly, though, more often than not, they'll initially just be impressed at how quickly I was able to help them. Requests for changes will come, but they're generally small, so it's usually relatively easy to turn those around quickly as well.