I know shipping an MVP on time can give you so big a mental relief that you wouldn’t bother to have another look at your product for a while. But how often did that “for a while” become “never”?
In all fairness, defining and shipping a minimum viable product have its own merits. They let you build only the essentials and helps ensure the deployment of your product on schedule. It’s easy to think all you need to do is build, deliver on time, and be done with it.
But that’s wrong. Your MVP should never be declared done, until it goes through iterations. The goal of doing an MVP is to get meaningful user feedback for a product as fast as possible and therefore compress an iteration cycle. Never is it for you to cop out to a new task or, even worse, mediocrity.
Products can be a big project as launching a new product or a small task as building a signup landing page. Whether big or small, if you leave your MVP at where it was when first deployed, you’ll end up getting mired in the two problems. First you will find yourself with a half-assed product which you neither love nor hate. Second you will let your standard for quality of your work skid onto mediocrity.
It’s dangerously appealing to dwell on the premature comfort from the first deployment and move to another project, especially if you’re working in a small team with tight resources and feel like there are thousands of other things to do out there. You need to resist precisely that comfort and persevere through multiple iterations. If it’s already good, why not do some extra legwork and make it excellent? Of course, only if it matters. But if it doesn’t matter, why did you build it in the first place?
Don’t tick your MVP off the to-do list too soon. At the end of the day, none wants to live where the sense of pride is lost.