A long backlog can make a new SaaS product feel substantial before anyone uses it. Dashboards, integrations, reports, notifications and customisation all sound reasonable. The difficult question is which of them must exist for one person to get a useful result.

An MVP should make a specific promise and deliver on it. Small scope is helpful only when the experience inside that scope actually works.

Pick a task someone already needs to do

Start with an observable problem. For example, a real estate agent may need to remember which prospect to contact next. That is more precise than “agents need a better CRM”.

A first workflow might let the agent add a lead, record the next action, see what is due, and mark the follow-up complete. Those steps form a useful loop. A beautiful lead screen without a dependable way to find tomorrow’s follow-ups does not.

Use this as a product-planning example, not as a substitute for speaking to agents. Ask people to show you their current process. Look at the spreadsheet, notebook or messaging history they already use, with their permission. The workarounds reveal more than a general question about which features sound interesting.

Separate the essential path from convenient additions

For each proposed feature, ask: if this did not exist, could the user still complete the main task? If the answer is yes, it may belong after the first release. For a follow-up tool, a simple due-date list may be essential. A custom dashboard theme probably is not. A basic import may matter if users already have hundreds of records, but you should first understand their actual file format and the effort involved in importing it.

Put the backlog into three groups: necessary to complete the task, necessary to use it reliably, and useful later. The second group deserves attention. Validation, account isolation, recoverable mistakes and backups may not look exciting in a demo, but they determine whether users can trust the product.

Design the awkward states early

Write down what happens when the list is empty, a date is missing, an import contains duplicates, or a connection fails. Decide whether a user can undo a destructive action. Consider how they recover access to their account.

You do not need to solve every possible edge case before learning from customers. You do need to avoid making normal mistakes expensive. A small product should still be understandable when something goes wrong.

Define a useful test before writing more code

“People registered” is not the same as “people received value”. Define the action that indicates the main workflow has worked. In this example, a user adds a real lead, sets a next action and completes a follow-up.

You can then observe where the process stops. If users add leads but never set a next action, investigate the wording and timing of that step. If they set actions but do not return, ask how the tool fits their working day. The answer may call for a simpler interaction rather than another feature.

Choose a small pilot with a clear finish

Invite a few people who actually perform the target task. Explain that you are testing a specific workflow, agree what they will try, and arrange a short conversation afterwards.

During the pilot, keep a decision log: what happened, what evidence you saw, and what you changed. Distinguish a single request from a repeated obstacle. Avoid promising every suggestion immediately; explain which problem the first version is intended to solve.

Before expanding, ask whether the pilot users can finish the workflow without your help, whether they return to it, and whether they can explain its value in their own words. There is no universal number that proves a product is ready, but those observations are more informative than the size of the backlog.

The release checklist

Before calling a version an MVP, check that the primary task works from beginning to end, common errors have understandable responses, users can contact you, and you have a way to learn what is stopping them.

Build the smallest product that deserves to be used again. Once that workflow earns its place in someone’s day, you will have a stronger basis for deciding what to build next.

Planning a SaaS product? Send the main user, task and expected outcome to info@ahmednasser.dev. Those three details are enough to start a useful scope discussion.