MVP or Full Product: What Should You Build First?

The right first release depends on what you know and what you still need to learn. An MVP is a focused working product that helps you test a core assumption with real users. It is not simply a larger product with random features removed.

Name the question before choosing the features

Are you testing demand, usability, an operational workflow, or a technical integration? These questions call for different deliverables. If the main uncertainty is whether people understand the experience, a prototype may be useful before building a production application.

Keep one complete user journey

A narrow but complete journey is often more useful than many unfinished features. A booking product, for example, may need a customer to select a service, request a time, receive confirmation, and resolve a cancellation. Identify what makes that journey useful and reliable before adding secondary features.

Do not remove essential safeguards

A smaller scope still needs appropriate authentication, permissions, data handling, error states, and testing. Decide which safeguards are required for the information and workflows involved. Internal tools and public applications have different operating contexts; discuss those requirements explicitly.

When a broader release may make sense

A broader first release may be appropriate when users must complete a connected workflow, a replacement system must preserve essential capabilities, or an integration cannot be tested in isolation. The aim is to include the capabilities needed for a useful release, with a clear reason for each one.

Plan the learning and the next decision

Before launch, agree what feedback you want, how you will collect it, and what would justify the next phase. Combine product usage with conversations and operational observations. Avoid promising growth from a feature list alone; use the first release to inform the next investment.