A useful SaaS MVP lets one kind of user finish one important task. Start by writing down the result they need, then build the smallest complete path to that result. Cut extra features before you cut the steps that make the task work.
For example, a CSV cleanup tool might do one job: let a user upload a file, check a specific set of rules, correct problems, and download a usable file. A dashboard with six empty tabs does not complete that job.
Y Combinator's MVP design guide makes a helpful distinction between a product's purpose and the features around it. Use that distinction to decide what belongs in your first release.
Write the finish line before the feature list
Use this sentence:
A [specific user] can [complete a task] using [a realistic input], and can tell it worked because [an observable result].
Here is an example, not a validated business idea:
A freelance analyst can check a client's CSV against an agreed column format and download a file that passes those checks.
This is narrow enough to test. It also forces you to decide what success looks like before the interface takes over the project.
Write down what the tool will not do yet: merge multiple files, guess missing values, sync with a warehouse, or manage a team. These may become useful later. They are not required by the sentence above.
Map the whole path, including failure
Walk through the job in order:
- The user understands which files the tool accepts.
- They provide a file.
- The tool checks it and explains any problems.
- The user fixes or accepts the result.
- They download an output they can use elsewhere.
Now add the ordinary failure cases. What happens with an empty file, the wrong columns, or an interrupted upload? Can the user recover without starting a support conversation?
You do not need an elaborate solution for every rare case. You do need a clear boundary. Saying that the first version supports one documented file format is better than silently accepting files it cannot process.
Separate necessary work from convenient work
For each proposed feature, ask whether the user can complete the stated task without it.
For this example, clear validation messages and a working download belong in the first version. Custom themes and a saved dashboard can wait. A login may be unnecessary if the task needs no stored history, but that depends on how you handle access and data.
Do not use “MVP” as a reason to ignore basic data handling. Decide what is stored, who can access it, and how long it stays. If you cannot handle a kind of data responsibly, exclude it from the first version and say so clearly.
Choose manual steps deliberately
Some early work can happen behind the scenes. You might configure the first customer's column rules yourself instead of building a rule editor.
Paul Graham's Do Things that Don't Scale describes the value of doing early work by hand. Use that as permission to learn, while being clear with users about what the service does and when they will receive a result.
Record each manual step. Note who performs it, how long it takes, and what would make it fail. That gives you a reason to automate later instead of guessing which internal tool to build first.
Test completion with a real input
Before inviting more users, run the full task with a realistic sample. Check the output independently. Then let someone from the intended audience try it without a running explanation from you.
Keep a short test record:
- What the person was trying to do.
- Where they paused or asked for help.
- Whether they reached the result.
- Whether the result was correct and usable.
- What they would otherwise have done.
A successful signup is not the same event as a completed job. For the CSV example, the important evidence is a correct file the user can use, not a visit to the dashboard.
Let the next feature answer an observed problem
After a few attempts, group the blockers. If users repeatedly get stuck understanding an error, improve that message. If they finish the task but do not need it again, investigate demand before adding more screens.
When building in public, share the useful change in plain terms: “The first version flagged bad rows but gave no way to fix them. This week I added an editable preview.” Use your actual observations, not this example as a personal story.
A narrow product can still feel complete. The test is whether a real person can finish the job you promised.
Sources
Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.
Subscribe for more stories on growing your audience by building in public.
Join us on Buildside: the social network for founders building in public.
Top comments (0)