A sculptor begins with a block of marble and an unusual definition of progress: most of the material must disappear. SaaS founders often work in the opposite direction. Every conversation produces another feature, every competitor contributes a tab, and the minimum viable product grows until “minimum” describes only the team’s remaining patience. The difficult craft is not imagining what the product could contain. It is recognising the smallest shape that already proves the idea.

Start with one sentence that describes a change in the customer’s world: after using this product, a particular person can complete a particular job with less time, cost, or risk. Then trace the shortest complete journey that produces that change. A customer may need to create an account, supply information, receive the promised result, and return to it later. Those steps belong because removing one would break the evidence. A feature belongs in the MVP when the core promise cannot be tested without it.

This creates a useful distinction between a product feature and a business assumption. A complex settings panel may look like product maturity, but it tests little if the unanswered question is whether anyone wants the main workflow. By contrast, a crude payment step may be essential because willingness to pay is the assumption the founder most needs to examine. The right MVP is not the smallest amount of code in the abstract. It is the smallest working experiment around the most dangerous uncertainty.

Some supporting features still earn their place because customers cannot safely reach the outcome without them. Accounts and permissions may be necessary when information is private. Basic error handling matters when failure would destroy trust. A simple way to contact support can compensate for rough edges and reveal where users become confused. The standard is not polish everywhere; it is enough reliability that the experiment measures the idea rather than the product repeatedly falling over.

The easiest features to postpone are those designed for an imagined crowd. Advanced roles, elaborate reporting, deep customisation, multiple integrations, and automation for rare cases often arrive before the first few users have established a pattern. Handle exceptions manually when possible. Manual work is not embarrassing at this stage; it is an instrument. If the same exception appears repeatedly, the case for automation becomes evidence-based instead of speculative.

A feature earns stronger priority when it helps the team learn. Record whether users complete the core journey, where they stop, and whether they return. Invite feedback at the moment of friction rather than relying on a broad survey weeks later. This does not require an ornate analytics system. A handful of meaningful events, direct observation, and customer conversations can tell the team which part of the workflow deserves investment next.

Put every excluded idea somewhere visible so saying “not now” does not feel like saying “never.” Then release the narrow path before the roadmap has time to disguise itself as a requirement. If users complete it and value the result, the next features will be chosen under better light. If they do not, a smaller build leaves more runway to change direction. The discipline of a SaaS MVP is subtraction in service of learning: remove everything you can while preserving one honest encounter between the customer and the promise.