How do I stop an MVP project growing out of control?

Question

Accepted Answer

Almost every MVP that overruns overruns for the same reason, and it is not the developers. It is that the list of what is being built never actually closed. Everyone agrees scope should be controlled. Almost nobody writes down how. Three mechanisms genuinely work: A closed list with a date on it. Not "the agreed scope" referred to in a proposal, but a numbered list, and a specific date after which anything new goes to a second list for a later phase. Vagueness here is always resolved in the supplier's favour, because they are the ones holding the estimate. If your engagement has no dated scope freeze, it has no scope control. One named decision maker on your side. Committees add features; that is what committees are for. A single person with the authority to say "not in this version" is worth more than any contract clause, and the absence of one is why "could we just also…" arrives in week three and nobody has the standing to refuse it. A stated question the MVP exists to answer. One sentence, agreed before work starts. It is the only tool that lets you turn down a genuinely good idea, not because it is bad, but because it does not help you find out what you are paying to find out. There is also a structural fix, and it works better than all three. Most scope creep comes from scope being decided before anyone had evidence. A working prototype, real enough to put in front of users, built in days rather than months, turns that conversation from opinion into observation. You arrive at the MVP already knowing which features people used and which they ignored, so the list is shorter and it stays shorter. Read the full guide to MVP development engagements → Talk to us about your idea →