An MVP Scoping Checklist for Non-Technical Founders

Start with the decisions your MVP must support

Before asking a supplier to estimate or build your MVP, define the problem, intended user, assumption you need to test and smallest useful journey that can test it. For every proposed feature or task, mark it as required to test the assumption, useful later or unresolved. This helps keep the first release focused while making uncertainty visible.

Use this checklist to start the conversation:

• Problem and user: Who has the problem, and what are they trying to do?
• Assumption: What needs to be true for your idea to be useful?
• Main journey: What is the shortest sequence of steps in which the user can try the proposed solution?
• Capabilities: What must the product let the user do during that journey? Mark optional enhancements as useful later.
• Boundaries: What will the first release deliberately not do? Record anything you have not decided as unresolved.
• Evidence of success: What observable user action or outcome would help you judge whether the assumption holds?
• Inputs and dependencies: What content, data, integrations or decisions does the journey rely on, and who will provide or manage them?
• Running the product: What does someone need to do to support users, manage information and deal with problems? Note any accessibility, privacy or security needs to discuss.

For each item, write enough context to explain who needs it and why. For example, “send a confirmation” is clearer when you say who receives it, what it confirms and what should happen if the information is missing. Keep open questions on the checklist rather than silently treating assumptions as agreed requirements.

This is a scoping aid for discussion, not a complete technical specification or a promise of cost or delivery time. The next steps are to make the user problem and assumption precise, then map the journey and decide which capabilities genuinely need to be in the first release.

Define the problem, user and assumption to test

Make the idea specific enough that a supplier can understand whose problem the first release addresses and what belief it is meant to test. Complete these prompts before turning proposed features into requirements.

• Who experiences the problem? Describe the intended first users by their role, situation or task. For example, distinguish a small business owner who handles bookings personally from a customer making a booking. Avoid descriptions so broad that they could mean almost anyone.
• When does it happen? Note the trigger and context: what the person is trying to do, what information they have to hand and what needs to happen next. If different users encounter different problems, record them separately rather than combining them into one imagined user.
• How do they handle it now? Write down the current steps, including any emails, spreadsheets, phone calls, existing software or manual work. Identify who does each step and where delays, repeated entry, missed information or hand-offs occur. This gives a supplier a concrete starting point without assuming that a new product is the only answer.
• What is unsatisfactory about the current approach? State the specific difficulty for the user or the business. Separate what you have observed or heard directly from what you infer; do not present a guess about user behaviour as established demand.
• What do you know, and how do you know it? Record the source beside each important point: a conversation, an observed workflow, existing records or your own assumption. Note when evidence is indirect or when you have not yet spoken to the people who would use the product.
• Which single assumption should the first release test? Complete: “We believe that a specific user will take an observable action in a relevant situation, because of a stated reason.” Choose the uncertainty that most affects whether the proposed product is worth pursuing. Testing one behaviour is more useful than asking the first release to prove the whole business plan.
• What remains unresolved? Mark unclear user groups, problem details or assumptions as unresolved. Do not disguise them as requirements: decide whether to investigate them before estimating, or explicitly ask the supplier to help clarify them.

Keep the answers short and concrete. They should help you distinguish the person with the problem from the person who may pay, and give the next section’s journey a real user and situation to follow.

Map the shortest meaningful user journey

Map one primary journey from the point where your intended user starts to the outcome that will help you assess your assumption. Keep the map focused on what that person must do and what your product must provide; do not design every screen or account for every possible situation yet.

Write the journey as a sequence. For each step, note what the user needs to see, enter, choose or receive, then mark each proposed capability as Required, Later or Unresolved.

• Starting point: Where does the user arrive, and what brings them there? Record the information or context they need before they can begin.
• First action: What is the main thing the user needs to do? For example, do they need to describe a need, select an option, submit a request or create something?
• Information provided: What must the user enter or choose to move forward? Separate information needed for the test from details that would simply make the experience more convenient.
• Product response: What should the user see or receive after acting? Describe the outcome in practical terms, such as a confirmation, a result or a next step. If nothing useful follows the action, reconsider whether the journey tests the assumption.
• Human involvement: Does someone need to review, approve, match, fulfil or respond to the submission? Identify who does it, what information they need and how they will know there is work to do.
• Observable end point: What event tells you the journey reached its intended outcome? Keep this tied to the behaviour you want to learn about, rather than adding unrelated measures.

Then check the journey for extra branches. A second user type, alternative route or exception belongs in the first release only if leaving it out would prevent the primary test. Record other routes as Later or Unresolved, rather than quietly adding them to the build.

For each capability, ask whether it must be software at this stage. A founder or team member might review submissions, send a response or perform a matching step manually while the idea is being tested. If so, describe that temporary process: who owns it, where the request is recorded, what information they use and how the user receives the result. Manual work still needs a clear owner; otherwise requests can be missed or handled inconsistently.

Your journey is ready to share when a supplier can follow the steps, see which capabilities are required for the test and understand what is being done by a person instead. If a step has no clear owner or outcome, mark it unresolved and settle it before treating it as part of the agreed scope.

Make the first-release boundaries explicit

For every proposed capability, mark it as required, useful later or unresolved. The first label means the capability is needed to test your chosen assumption, not simply that it would make the product more complete.

• Capability: Name the feature or task, such as creating an account, submitting a request or viewing a result.
• Priority: Required / useful later / unresolved.
• Reason: If required, explain which step in the test depends on it. If useful later, say why it can wait.
• Unresolved decision: State what information or choice would settle it, who will provide that, and when it needs to be decided.

Then write a short out-of-scope list. Include appealing ideas that are not necessary for the first test, so a supplier does not have to guess whether they are included.

• Extra user types or permission levels: does the first test need more than one kind of user, or can one account type serve the journey?
• Additional channels: does the test require a mobile app as well as a website, or can it begin in one place?
• Advanced reporting: what decision must a report support now, and can a simple record or manual review suffice?
• Automation: which task must the software perform, and which could a founder handle manually while testing?

For each item, decide whether simplifying it would invalidate the test. If not, consider leaving it out or handling it manually. For example, if a founder can review submissions and send a response themselves, automated routing may not be needed to learn whether users will submit a request.

Record the boundary plainly:

• Included in this release: the required capabilities and any essential supporting work.
• Not included in this release: the enhancements deliberately deferred.
• Still to decide: unresolved items and the information or decision needed to resolve each one.

An exclusion sets the estimate and build boundary; it does not rule out adding the feature later. If an unresolved item could change the journey, effort or supplier’s approach, flag it before asking for an estimate rather than letting it become assumed scope.

Describe what success looks like in observable terms

Write acceptance criteria as outcomes that a founder and supplier can both observe. They should show whether the first-release requirement works without dictating how the software is built. Use the checklist below for each essential step in the journey.

• Action: What can the user or administrator do? For example: “A user can submit a request with their contact details and a description of what they need.”
• Confirmation: What should the person see or receive when the action succeeds? For example: “After submitting, the user sees a confirmation that the request has been received.”
• Required information: Which information must be provided for the step to work? Name each required field in plain English, and say what the user sees if it is missing. For example: “If the contact details are missing, the request is not submitted and the user is told which details to add.”
• Exceptions: What foreseeable situation could prevent the normal outcome, and what should the user or administrator see or do next? Include only exceptions that matter to the first-release test.
• Evidence: What can you check to tell whether the requirement was met? This might be the confirmation shown to the user or a request visible to the person responsible for handling it.

Complete this sentence for each requirement: “When a condition applies, the user or administrator can take the relevant action, and the expected result is observable. If an important exception occurs, state the expected outcome.” Keep the wording specific. “The form is intuitive” is hard to assess; “the user can tell which fields need completing and sees a confirmation after a valid submission” describes an outcome to check.

Keep acceptance criteria separate from broader business measures. A working first-release test might show that a user can submit a request and that it reaches the intended person. Whether enough people choose to submit requests to support the business idea is a separate question to measure during the test. Agree which outcomes must be demonstrated before treating the requirement as complete, and record any still unresolved conditions rather than letting each party assume a different answer.

List the content, data and dependencies the scope relies on

Give a supplier enough context to understand what information the first journey depends on, who provides it and where it needs to go. You do not need to design a technical data model: describe the information and handovers in ordinary business language, then mark each item as Required to test, Later or Unresolved.

• Content for the journey: List the words, images, documents, listings or other material a user must see or provide. For each item, note who will supply it, whether it needs to be created or brought over from somewhere else, and who will keep it up to date. Mark content as unresolved if its owner or readiness is not clear.
• Information the product handles: Describe what a user enters, what they need to see afterwards and what information must pass to another person. For example, note whether a person submits an enquiry and someone else needs its details to respond. Say what information is essential to test the assumption; leave decisions about how it is stored or structured for a technical discussion.
• User roles: Name each type of user involved in the journey and describe what they need to do. If one person submits information and another reviews it, explain who does each step and what each needs to see. Mark any uncertainty about who can access or change information as unresolved.
• Existing systems and services: List any system, external service or payment step the journey relies on. For each, write what it contributes and who can confirm access or provide relevant information. Do not assume a connection is straightforward; mark access, ownership or the way information moves as unresolved where you do not know.
• Manual work: Record any task a person will perform outside the product during the first test, such as checking a submission, updating information or passing details to someone else. Name who will do it and when. This helps distinguish a deliberate temporary process from a missing product capability.
• Dependencies and open questions: Note missing content, uncertain data quality, permissions, supplier involvement or decisions that could affect the scope. For each, record who will find out and what must be known before the supplier can estimate that part. Keep detailed API or integration design for a separate specialist discussion if the scope needs one.

Review the list against the primary journey: if an item is not needed to run that journey or learn from it, mark it Later rather than silently including it. Take unresolved items into the supplier conversation so they can be discussed as assumptions or questions, not mistaken for agreed requirements.

Record operational, accessibility, privacy and security needs

Add operational and quality needs to the same checklist as product features. For each item, mark whether it is required to test the assumption, a later enhancement or unresolved; note who will decide any open point.

• Who will run it? Name the person responsible for adding or correcting content, managing user accounts, answering support enquiries and handling routine administration. If one person will cover several roles, say so and note what happens when they are unavailable.
• What must work in practice? Describe the devices and situations the first users are likely to use, such as a mobile phone while travelling or a desktop at work. Specify practical needs such as readable text, clear error messages and a usable route through the main task. Record any accessibility requirements you already know about, and leave specialist questions open for discussion rather than assuming they are covered.
• What information will the product handle? Note what users enter, what the product stores and who needs to see it. If personal data may be involved, record what you need to check about its use, access, retention and handling, and who will obtain appropriate advice before build or launch.
• What privacy questions remain? Record whether users need to be told what happens to their information, who will answer requests about it and whether any external services receive it. Treat these as questions for appropriate advice or compliance checks, not conclusions to settle by guesswork.
• What security needs should the supplier understand? List concerns such as who can access accounts or administrative functions, how access should be removed when roles change, and what should happen if something appears wrong. Ask the supplier to discuss the controls and operational responsibilities relevant to your product; take detailed security planning to the appropriate specialist discussion.
• What support is needed after release? Note who will receive reports of faults, decide whether they block the main journey and keep users informed. Mark any support process you cannot yet staff as unresolved, rather than treating it as included by default.

Use the checklist to prepare for a supplier conversation

Turn the checklist into a short brief that lets suppliers respond to the same version of the idea. Include the essentials below, and mark each item as required to test the assumption, a later enhancement or unresolved.

• Problem and user: Who has the problem, and what are they trying to do?
• Assumption to test: What behaviour or response would give you useful evidence?
• Main journey: What does the user do first, what happens next, and what outcome completes the journey?
• First-release capabilities: Which functions are needed for that journey, and which can be handled manually?
• Boundaries: What is explicitly excluded from this release?
• Acceptance criteria: What should a user be able to do, and how will you recognise that it works as intended?
• Dependencies and open questions: What content, data, access, integrations or decisions are needed, and who will provide or resolve them?

Ask each supplier to identify the assumptions behind their response, the dependencies that could change it and the decisions they need from you. Ask them to separate discovery work, which clarifies requirements and options, from the proposed build scope. Find out how they would investigate unclear acceptance criteria, content readiness, integrations and operational needs before either side commits to a build.

When comparing proposals, check that each addresses the same user journey, capabilities and exclusions. Look for differences in assumptions, unresolved decisions and what discovery includes; headline figures alone are not a like-for-like comparison. An estimate depends on the scope and information available, so the checklist does not establish a fixed cost or timescale. Ask suppliers to explain what information would make their estimate more dependable and how changes in scope would be handled.

If you are exploring a subscription software product, you can Discuss your SaaS project. If the idea can be tested with a manual process or an existing product, that may be a better next step; a custom web application is another option when the test depends on a tailored digital workflow. Keep unresolved items visible rather than allowing them to become assumed requirements.

Check whether you need custom software yet

Custom software is not automatically the best way to test a product idea. Choose the simplest approach that lets you learn whether users need the proposed solution and can complete the important journey.

• Try a manual pilot if your main uncertainty is the problem or process, and you can deliver the service with people handling steps behind the scenes. Note which tasks are manual, who owns them and what you need to learn from each user interaction.
• Use an existing product or package if it supports the workflow you need to test. List any workarounds and check whether its limits would change the user experience or prevent you from observing the behaviour that matters.
• Make a simpler prototype if you need to explore whether people understand a proposed screen flow or service, but do not yet need a complete, operating product. Be clear about what the prototype will not do.
• Explore custom software if the essential journey relies on a workflow or capability that existing options cannot suitably provide, and that capability is necessary to test your assumption.

Before you decide, write down:

• The uncertainty you need to resolve.
• What users will do in the test, and what you need to observe or record.
• Which steps can be handled manually, and what limitation would make that misleading.
• What you still need to decide before anyone can estimate the work.

Approach a supplier when the test, essential journey and first-release boundaries are clear. Refine the scope if important decisions remain unresolved. If users can take part in a meaningful test without software, try that route first and revisit the build decision with what you learn.