Most SaaS MVPs are not too small.

They are too wide.

The brief includes three user roles, a dashboard, subscriptions, chat, AI, analytics, mobile apps, referrals, and an admin panel.

Then someone says, “We only need the MVP.”

That list is not an MVP. It is a product roadmap without an order.

I start with one painful outcome

The first question is not “Which features do you want?”

It is:

Which user should be able to achieve which valuable outcome that they cannot achieve well today?

One sentence.

For example:

A small agency owner can turn an approved client brief into a trackable delivery plan without rebuilding the same spreadsheet every week.

That sentence gives us a user, a trigger, a task, and a reason to care.

“AI-powered project management platform” gives us almost nothing.

Draw one complete path

An MVP needs one complete path, not ten half-built modules.

I map:

1. how the user arrives;
2. what they must provide;
3. what the system does;
4. what result they receive;
5. what makes them return;
6. what happens when the path fails.

If a feature does not protect or complete that path, it moves out of the first release.

This is where many dashboards disappear.

The user may need one useful result page, not a configurable analytics center.

Separate “must work” from “must exist”

Every item goes into one of four groups:

Must work

The core value fails without it.

Must exist safely

Authentication, authorization, auditability, privacy, backups, and billing boundaries may not be the marketing hook, but the product cannot treat them as decoration.

Can be manual behind the scenes

The user’s experience can be complete while an internal step remains deliberately manual during validation.

Later

Useful after the first behavior is proven.

Manual is not the same as fake.

If an operator can reliably complete a low-volume step, automation may wait. If the manual step leaks data or breaks the promise, it cannot.

Define the evidence before the feature

An MVP should answer a decision.

Examples:

• Will the target user complete the workflow?
• Will they return without being chased?
• Will they pay for the result?
• Which step creates abandonment?
• Does the proposed automation save meaningful time?

The product needs enough instrumentation to answer that question.

It does not need every chart.

Protect irreversible decisions

I move fast on decisions that are easy to change:

• copy;
• layout details;
• notification wording;
• internal operational steps.

I slow down on:

• tenant boundaries;
• money movement;
• identity and access;
• data ownership;
• irreversible migrations;
• public URLs;
• provider lock-in;
• compliance promises.

Fast MVP work is not careless work.

It spends care where reversal is expensive.

Write the cut line

The scope document should say what is not included.

My cut line looks like:

• first user role included;
• exact happy path;
• required failure states;
• admin operations needed for launch;
• security and data boundaries;
• integrations included;
• explicit exclusions;
• evidence to review after launch;
• trigger for phase two.

This protects both the client and the developer.

Without exclusions, every idea sounds like a forgotten requirement.

The first release I prefer

I prefer an MVP that is:

• narrow enough to explain;
• complete enough to use;
• safe enough to trust;
• observable enough to learn from;
• maintainable enough to change.

Not impressive in every screenshot.

Useful in one real workflow.

What happens next

After launch, I review behavior, support questions, failure logs, and actual requests.

Then phase two is based on evidence instead of pre-launch imagination.

That is where the roadmap earns its order.

For architecture choices after the cut line, read MERN or Next.js? I Start With Product Constraints. For the first month of operation, read the SaaS first-30-days plan.

If your “MVP” is currently a long feature list, send me the user and the one outcome. That is enough to start cutting.