> making sure the engineers really understand the problem they're solving
Yes, absolutely. And how would software engineers gain that understanding?
Experience is the key here. Avoiding an initial implementation because you're afraid of "wasting work" is counterproductive - it cuts off the primary mechanism by which developers gain understanding! That's like saying athletes shouldn't practice because it wastes their energy for the big game.
One small note on terminology that might help: Using "MVP" implies that what you're developing is a product. It's more accurate to call this "POC" or proof-of-concept since that's exactly what it does - with that data in place, the product and engineering plans can proceed faster and more effectively knowing they have a firm tether to reality.
Another aspect is that (in my experience / opinion) if you're doing an MVP then it really needs to be as minimal as possible - big enough to give you evidence for your future plans but not comparable to what you eventually hope to build. Otherwise it's hard to adapt or to throw away.
The biggest thing I've found to help in any design work is making sure the engineers really understand the problem they're solving, so they can judge independently if plans they're making are complimentary to it.