Your MVP probably has
too many “must-haves.”

Ask what the MVP is supposed to prove.

An MVP is not the smallest version of your five-year vision. It is the smallest useful product that can answer the important question in front of you.

If you are trying to learn whether a specific customer will pay for a specific outcome, every feature should have to justify itself against that goal.

Use the “remove it and test” rule.

For each feature, ask: if this disappeared from version one, could a user still reach the core outcome? If yes, it is a candidate to wait.

• Does it create the value, or decorate the value?
• Does the first user need it, or does the imagined future company need it?
• Will its absence prevent learning something important?
• Can you perform the job manually for the first few users?
• Are you building it because users asked, or because launch feels scary?

Look for duplicate ways to solve the same problem.

Early products often contain three versions of the same idea because each sounded useful during a different week of building. Pick the clearest path and remove or hide the others until real usage proves you need them.

Protect the product's center of gravity.

Cutting scope does not mean making the product arbitrary. Keep the pieces that make the core outcome complete, trustworthy, and understandable. Cut the branches before you cut the trunk.