What Should Be in Your MVP and What Should Wait
A decision framework for keeping the first release complete, credible and much smaller.
MVP scope arguments are difficult because almost every proposed feature has a plausible reason. Accounts help security. Notifications improve engagement. Analytics support learning. Settings create flexibility. An admin panel saves operational time.
The problem is not that these features are useless. It is that usefulness alone does not justify building them now.
Your MVP should contain what is required to deliver and evaluate one complete customer outcome. Everything else must earn its timing.
Begin with the customer’s before and after
Write a specific sentence describing the change for the user.
“A property manager can turn an incoming maintenance request into an assigned, confirmed job without coordinating across email and spreadsheets” is an outcome. “A maintenance management platform” is a category.
Describe the before state, the trigger, the action and the after state. Then identify the shortest product path that makes the change real.
If a feature does not support that path, protect the user from a serious risk or help you measure the result, it probably waits.
This framing prevents the MVP from becoming a collection of standard software furniture. The first release does not need everything users expect from mature products. It needs enough credibility and reliability for the specific promise you are testing.
Include the complete value path
The core workflow must work from beginning to end. A marketplace needs both sides of one transaction, even if matching is manual. A reporting tool needs data input and a useful output, even if formatting is basic. A booking product needs a request and a confirmed result, not just a calendar interface.
Do not distribute effort evenly across the eventual product. Make the valuable path complete and keep adjacent paths thin.
Supporting steps may be deliberately manual. You can create accounts for early users, approve records yourself, handle exceptions through support or issue invoices outside the product. Manual steps are acceptable when they do not falsify the customer outcome you are testing.
Document them so you learn what repeats and what should later be automated.
Include trust proportional to the risk
Minimum does not mean reckless. Security, privacy, data integrity and accessibility depend on the context.
If you handle health, financial or sensitive personal information, the first version must respect the relevant obligations. If an action moves money or deletes data, confirmation and auditability matter. If users depend on the result for critical work, reliability requirements are higher.
Do not copy enterprise controls without reason, but do not postpone real safety as “later polish.” Decide what trust is necessary for an honest test with the intended users.
Use established providers for authentication, payments and infrastructure where they reduce risk. Keep access limited. Back up important data. Explain limitations clearly. A narrow product can still be professionally operated.
Include only the learning you will use
Analytics belongs in an MVP when it answers a decision. Track the small number of events needed to understand acquisition, activation, completion and return.
Do not instrument every click because data feels responsible. More events create implementation work and a pile of numbers nobody interprets.
Pair analytics with direct observation. Watch early users attempt the workflow. Ask what they expected. Review where manual support was needed. Quantitative data tells you what happened; conversations help explain why.
Define the success and failure signals before launch. Otherwise the team may reinterpret any result as a reason to continue.
Usually wait on flexibility
Flexibility is one of the largest sources of premature scope. Multiple roles, configurable workflows, custom fields, themes, language systems and generalized integrations all multiply states.
Early users may ask for flexibility because they are comparing your narrow product with mature tools. Investigate whether the request blocks the core outcome. Often a fixed process, one account owner or a manual configuration is enough for the first users.
Constraints help you see the pattern. Once repeated customer behaviour is clear, you can design flexibility around reality instead of imagination.
Wait on features that exist primarily for unknown future segments. A product that serves one target customer well produces better evidence than a platform that theoretically serves everyone.
Usually wait on scale architecture
Use an architecture that is secure, maintainable and suitable for plausible near-term demand. Do not build a multi-region, microservice or event-driven platform because success might eventually require one.
Keep the code modular, the data backed up and the deployment repeatable. Those choices preserve options. Large operational systems exercise options before the need exists.
Similarly, avoid premature native apps, complex real-time systems and custom infrastructure unless the core behaviour depends on them. A managed service or simpler interaction may test the same value sooner.
The future team will make better scaling decisions with actual usage data.
Use four scope buckets
Put every proposed item into one of four groups:
Core outcome. Without it, the user cannot receive the value being tested.
Trust requirement. Without it, the test would be unsafe, misleading or inappropriate for the context.
Learning requirement. Without it, you cannot evaluate the important assumption.
Later. Useful, attractive or efficient, but not necessary for the first three groups.
Be strict. “Customers expect it” needs evidence. “It will be harder later” needs a concrete explanation. “It only takes a day” ignores maintenance and distraction.
Then look for manual or simpler versions inside the first three buckets. Required does not mean fully automated.
Set exit criteria before development
The MVP should lead to a decision. Define the number and type of users, the behaviour you need to observe, the period of use and the commitment that matters.
Also define what would cause you to stop or change direction. This protects the company from continuing because the product now exists.
Review scope whenever a new item appears. Ask which bucket it enters, which assumption it addresses and what leaves the plan to make room. A fixed launch date without scope discipline creates overtime and poor quality. A fixed learning objective makes tradeoffs clearer.
Your MVP is ready when it can deliver one meaningful outcome safely and teach you whether that outcome deserves more investment. It does not need to look like the final company. It needs to make the next decision possible.