What Should Be Included in an MVP?

Start with one primary user, one painful problem, and one observable outcome. A marketplace may need to learn whether supply and demand can complete one transaction. An internal tool may need to prove that a connected workflow removes duplicate entry. Without a decision, 'minimum' becomes arbitrary.

Write the product hypothesis in plain language and define the evidence that would change your next investment decision. Downloads alone are rarely enough; completed workflows, repeat use, time saved, or successful handoffs are usually more informative.

A viable product lets the user complete the central job from beginning to end. A booking MVP needs more than a booking form if nobody can manage availability or confirm the result. A quoting tool needs the data, calculation, document, and status steps required to make the quote usable.

Supporting screens should exist only where the core flow depends on them. This usually includes purposeful onboarding, clear empty and error states, and enough account recovery or support handling to avoid stranding users.

The interface is only part of the MVP. Authentication, authorization, data storage, essential business rules, basic administration, logging, backups, and deployment are part of a credible service when the product handles accounts or operational data.

Security and testing should be proportional to risk, not postponed as decoration. An MVP that loses data, exposes another user's records, or cannot recover from common failures tests the wrong thing: whether users tolerate an unreliable implementation.

Advanced reporting, deep customization, secondary user roles, broad integration catalogues, elaborate automation, and edge-case workflows often belong later. They may be valuable, but they dilute the first learning cycle if the core proposition is still unproven.

Defer intentionally. Record the reason, dependency, and signal that would bring an item forward. A managed later list prevents the MVP from feeling like an arbitrary rejection of stakeholder ideas.

Describe user journeys and acceptance outcomes rather than collecting disconnected feature nouns. Identify integrations and unknowns early, because payment, identity, legacy data, and external APIs can dominate risk even when their screens look small.

Plan a short discovery step, a build sequence that produces testable increments, and a measured release. The result should be deliberately narrow but coherent enough that the feedback is about the product idea rather than missing basics.