What This Template Covers
The MVP scope document template covers seven core areas that together define exactly what is being built and what is not. The first area is the product summary: a two to three sentence plain-English description of what the product does, who it is for, and what problem it solves. This sounds trivial but it is the anchor statement the whole team returns to when scope discussions arise. The second area is the feature list. Each feature is described in one sentence and then given a set of acceptance criteria. Acceptance criteria are testable conditions that define when a feature is done. Without them, "done" means different things to the developer, the founder, and the QA reviewer. The third area is the out-of-scope list. This is the section most teams skip and most teams regret skipping. Explicitly naming what is not in scope, and why, prevents misaligned expectations. Common out-of-scope items include mobile apps when only web is planned, third-party integrations that can come post-launch, admin dashboards, reporting features, and internationalisation. The fourth area is dependency mapping. Which third-party APIs, services, or data sources does the product rely on? Are those accounts set up? Are API keys available? Unresolved dependencies are a common cause of mid-sprint delays. The fifth area is technical constraints. What stack is mandated? Are there hosting requirements? Does the product need to integrate with existing infrastructure? The sixth area is the milestone structure. For a four to eight week build, what does the team deliver at each checkpoint? The seventh area is sign-off. Who has authority to approve the scope, and what happens if new requirements emerge after sign-off? Answering this in writing prevents the informal scope additions that derail delivery.
How to Use This Template Step by Step
Step one is to complete the product summary before anything else. If you cannot describe the product in two or three sentences, the scope document will not save you. You need conceptual clarity first. Step two is to run a feature brainstorm. Write down everything the product could do. Do not filter yet. Get it all on paper. This typically produces a list of 20 to 40 items for a first MVP. Step three is to apply the MVP filter. Go through each feature and ask: does the product fail to deliver its core value without this? If the answer is no, it goes to the out-of-scope list. Be ruthless. The goal of an MVP is to test a hypothesis, not to build a complete product. Most teams end up keeping eight to twelve features for a genuine MVP. Step four is to write acceptance criteria for each in-scope feature. Use the format: "Given [context], when [action], then [outcome]." Write two to four criteria per feature. These become the checklist your QA process works from. Step five is to populate the out-of-scope list. For each item, add a one-line reason. "Mobile app - web-only for MVP to reduce build time" or "Admin reporting dashboard - Phase 2 after user validation." The reason matters because it shows the decision was deliberate, not forgotten. Step six is to map dependencies. Go through each in-scope feature and ask what external services, APIs, or data it needs. Create a dependency table with: dependency name, which features it affects, current status (account created, API key obtained, testing complete), and owner. Step seven is to define milestones. For a six-week build, a typical structure is: end of week one - architecture and design approved; end of week three - core features in staging; end of week five - full feature set in staging, QA complete; end of week six - production deployment. Step eight is to circulate for sign-off. Get written agreement from everyone with authority over the project before build starts. Email confirmation is sufficient. The document becomes your change-control baseline.
Section-by-Section Walkthrough
The product summary section should be no longer than three sentences. The first sentence names the product and its primary user. The second sentence describes the core action the product enables. The third sentence states the problem it replaces or reduces. Example: "TradeSync is a web application for independent financial advisers. It allows advisers to upload client portfolios and receive automated rebalancing suggestions. It replaces a manual spreadsheet process that currently takes advisers four hours per client review." The feature list section uses a table format. Columns are: feature name, description, acceptance criteria, priority (must-have or nice-to-have), and estimated complexity (small, medium, large). Complexity is a relative estimate, not a time estimate. It helps the development team identify which features need more planning time. The out-of-scope section is a simple list but each item needs a category. Common categories are: Phase 2 (planned for later), Not Required (not needed at all), Dependency Not Available (cannot build yet because an external service is not ready), and Design Decision (deliberately excluded to simplify UX). The dependency mapping section is best presented as a table. For each dependency, record: the service name, which feature uses it, what credentials are needed, who owns obtaining them, and the current status. Review this table in your first project kickoff meeting. Unresolved dependencies on day one are a warning sign. The technical constraints section records any fixed decisions about technology. These might include: the hosting provider (AWS, GCP, Vercel, Railway), the authentication provider (Auth0, Clerk, Supabase Auth), the database technology, the frontend framework, or the AI model provider. If there are no constraints, say so explicitly. An unconstrained tech choice is itself a decision that needs making. The milestone structure section needs dates, not just week numbers. "End of week three" is ambiguous if you are not sure when week one starts. Put calendar dates. Assign each milestone a named owner who confirms completion. The sign-off section should list every stakeholder name, their role, and the date they approved the document. For GDPR purposes, if the product handles personal data, the sign-off section should also confirm that a data protection review has been scheduled before launch.
Common Mistakes This Template Prevents
The most common mistake is launching into build without a written feature list. Teams assume everyone shares the same mental model of the product. They do not. The developer is imagining one thing, the designer another, and the founder a third. The scope document creates a single written reference that resolves disagreements before they become expensive. The second common mistake is treating the MVP as a miniature version of the full product. An MVP should test a specific hypothesis, not deliver partial versions of everything. This template's MVP filter step forces that conversation explicitly. The third mistake is omitting acceptance criteria. Without them, features get marked as "done" when they are technically functional but practically broken for the actual user journey. Acceptance criteria shift the definition of done from "it runs" to "it works correctly." The fourth mistake is ignoring dependencies until they cause problems. A team can spend a week building an integration before realising the third-party API requires a paid enterprise account with a two-week onboarding process. The dependency mapping section surfaces these blockers before they delay the build. The fifth mistake is scope addition without change control. Once build starts, well-meaning additions accumulate. Each one seems small. Collectively they push the launch date by weeks. The sign-off process and the out-of-scope list create a documented baseline. Any addition requires a deliberate change-control decision, not a casual conversation.
Customisation Tips for Different Project Types
For AI products, add a section specifically for AI-specific scope decisions. Which AI model or provider? What is in scope for prompt engineering? What evaluation criteria will you use to determine if the AI output is good enough? What are the fallback behaviours if the AI provider returns an error or a poor response? These questions are specific to AI products and standard scope templates do not address them. If your product falls under the EU AI Act, note the risk classification in the constraints section. For SaaS products with multi-tenancy, the scope document needs to address data isolation. Is organisation-level isolation required from day one? Is row-level security in scope for the MVP? These are architectural decisions that must be in scope or explicitly out of scope before build starts. For products handling regulated data, the scope document should include a GDPR or sector-specific compliance section. This is particularly important if the product is in fintech (FCA considerations), healthtech (NHS Digital data standards or MHRA requirements), or any product that processes special category data. Compliance is not a Phase 2 item. For corporate innovation projects where a separate agency is doing the build, the scope document becomes the contract appendix. Add a change-request process section that specifies the notice period, approval authority, and cost implications of scope changes. SpeedMVPs includes this in all fixed-price engagements.