Personally, I think if you try to launch a product with loads of functionality off the bat you end up building in misconceptions and assumptions and the product is worse as you spend a load more time fixing those later!
An example Tom gave recently was the emojis in notifications - so if you go to Dunkin’ Donuts you get a in your notification. Jonas initially built this on a Sunday afternoon to surprise people on Monday morning. The office (such that it was back then!) thought this was really neat and they decided to roll it out to everyone However, it was assumed people might not like this feature and find it annoying or superfluous - after all, it doesn’t serve a practical function and is only there to delight! The solution of course is to build in a toggle to turn them off; but this requires a load of engineering time and effort, and then you end up with yet another switch, and something else to go wrong!
This was launched as an MVP and has gradually improved over the years. The caveat was, if anybody asked for a way to switch it off then they’d build the toggle in. No one has every asked for it to be switched off! (and no, we’re not going to build it now )
I think the point of this is, Monzo could have spent another day refactoring the code to support a toggle. There would have been another switch in the app and it would have been a bit more complicated but the product would be totally solid and no one would be able to find fault with it. When you amplify this to scale of projects we do now, you can see why building an MVP, launching early, taking a risk and then iterating on feedback works so well.