I was talking to a designer recently. She explained:

I’ve been burned far too many times on this MVP bullshit. We never actually iterate. It is an excuse to get stuff out the door faster.I’ve heard this exact same sentiment many, many times (from both designers and developers). The response from the front-lines is predicable: big upfront design, gold-plating, over-engineering, and general foot-dragging. Which makes perfect sense given the situation. Who wants to do a crappy job? Do good work while you can.

This isn’t just an MVP thing. It’s an issue with iterative/incremental development in general. If you’re not going to even consider changing course, and if the solution is preordained from the start…then why even bother releasing at the end of each sprint? You’re basically doing waterfall in little sprint-length chunks.

The purpose of an MVP is to have a conversation. The whole idea is to learn. You’ll probably end up throwing most of it (the MVP) away.

When that learning does not happen, then it is natural to feel like this is your only shot. I feel like designers especially are used to being in this spot. Design is typically highly iterative, so iterative development is not a stretch. Neither is putting up a rough scaffold and confidently filling in the gaps over time. But when software development is cast as construction and not as part of the iterative/learning process, then your only choice is “big design upfront”. Design then build.

Obviously, people should stop misusing the term “MVP” if what they they’re hoping to do is release something “minimal” and just walk away. That’s something else.

But on an even higher level…the goal with iterative/incremental approaches is to learn, and to incorporate those learnings. If that’s not happening — if the end of each sprint is a song-and-dance demo to a product owner checking the story “to spec” — then you’ll need to go back to the drawing board with your process.