MVP Requirements Template
Define the smallest product that tests your riskiest assumption with real users. This template forces the decisions that keep an MVP small: one core journey, a written out-of-scope list, and the events you will measure from day one.
On this page
MVP Requirements Template · Free template from Next Olive Technologies · https://nextolive.com/free-tools/mvp-requirements-template/
The MVP requirements template
Work through the sections in order — each one narrows the next. Replace the grey italic hints with your own answers. If a section takes more than a page, your MVP is probably too big.
It is one of several planning resources in our free tools library.
1. Problem statement
| Item | Your answer |
|---|---|
| The problem in one sentence | [Who] struggles to [do what] because [why], which costs them [time / money / risk] |
| How people solve it today | Spreadsheets, WhatsApp groups, a competitor, an agency, doing nothing — and what is wrong with each |
| Evidence the problem is real | Interviews held, search volume, waitlist sign-ups, pre-orders, letters of intent — with numbers |
| Why now | A regulation, platform shift, cost change or behaviour change that makes this solvable or urgent now |
2. Target user and job to be done
| Item | Your answer |
|---|---|
| Primary user (be narrow) | e.g. “Independent physiotherapy clinics with 1–5 therapists in UK cities”, not “healthcare providers” |
| Buyer, if different from user | Who pays and what they care about |
| Job to be done | When [situation], I want to [motivation], so I can [expected outcome] |
| Current trigger moment | The moment the user feels the pain enough to look for a solution |
| Early adopters you can reach | Named communities, lists or contacts for your first 20–50 users |
3. Riskiest assumptions
List what must be true for the business to work. Rank by risk (how likely it is wrong × how bad if wrong). The MVP exists to test the top one or two.
| # | Assumption | Type | Risk (H/M/L) | How the MVP tests it | Signal that proves / disproves it |
|---|---|---|---|---|---|
| A1 | Clinics will switch from paper diaries to online booking | Desirability | H | Onboard 15 clinics, observe weekly use | ≥ 10 clinics still booking weekly after 6 weeks |
| A2 | Clinics will pay a monthly fee of [amount] | Viability | H | Paid plan after 30-day trial | ≥ 30% of trial clinics convert |
| A3 | Calendar sync with Google works reliably enough | Feasibility | M | Technical spike in week 1 | No double bookings in test |
| A4 | Assumption | Desirability / Viability / Feasibility | Test | Signal |
4. Core user journey
Describe the one path from first visit to the moment the user gets value. Everything in the Must list should serve this journey.
| Step | User action | What the product does | Value moment? |
|---|---|---|---|
| 1 | Lands on site from a referral | Explains offer, shows sign-up | No |
| 2 | Signs up with email | Creates account, starts guided setup | No |
| 3 | Adds services and opening hours | Generates a booking page link | No |
| 4 | Shares link; first patient books | Sends confirmation to both sides | Yes — “aha” moment |
| 5 | Patient attends; clinic marks visit complete | Sends reminder for next visit | Repeat value |
| Item | Your answer |
|---|---|
| Time to value target | e.g. a new user reaches step 4 within 15 minutes of sign-up |
5. Feature list (MoSCoW)
| ID | Feature | Priority | Journey step / assumption served | Rough size (S/M/L) |
|---|---|---|---|---|
| M-01 | Email sign-up and login | Must | Step 2 | S |
| M-02 | Service and availability setup | Must | Step 3, A1 | M |
| M-03 | Public booking page | Must | Step 4, A1 | M |
| S-01 | SMS reminders | Should | Step 5 | S |
| C-01 | Google Calendar two-way sync | Could | A3 | L |
| ID | Feature | Must / Should / Could | Step / assumption | S / M / L |
Test for every Must: if we removed it, could a user still complete the core journey and could we still test the top assumption? If yes, it is not a Must.
6. Out of scope for the MVP
Writing this list down is what keeps the MVP small. Revisit it only after launch data arrives.
| Not in the MVP | Why not now | Manual workaround for early users | Revisit when |
|---|---|---|---|
| Native iOS and Android apps | Responsive web proves demand first | Mobile web, add to home screen | > [x] weekly active users on mobile |
| In-app payments | Pricing not validated | Invoice manually | After 10 paying customers |
| Multi-location clinics | Different buyer, more complexity | Separate accounts | 3+ requests |
| Admin analytics dashboard | Founders can query data directly | Weekly export | Team > 3 |
| Feature | Reason | Workaround | Trigger |
7. Success metrics
| Metric | Definition | Target by date | Decision if missed |
|---|---|---|---|
| Activation | % of sign-ups who reach the value moment within 7 days | e.g. 40% | Fix onboarding before adding features |
| Retention | % of activated users active in week 4 | e.g. 25% | Re-interview churned users |
| Conversion | % of trials that pay | e.g. 20% | Test pricing / packaging |
| Qualitative | Sean Ellis “very disappointed” share, or interview quotes | e.g. 40% | Narrow the segment |
North-star metric for this stage: one metric that best reflects value delivered, e.g. bookings completed per week.
8. Analytics events
Name events before build so they ship with the first release. Use one consistent naming style.
| Event name | Fired when | Key properties | Answers which question |
|---|---|---|---|
signup_completed | Account created | source, plan, referrer | Which channels bring users? |
onboarding_step_completed | Each setup step finished | step_name, duration_seconds | Where do users drop off? |
booking_page_shared | User copies or shares link | share_method | Do users reach activation? |
booking_created | First and subsequent bookings | is_first, lead_time_hours | Value moment reached? |
subscription_started | Payment succeeds | plan, price, trial_days_used | Is it viable? |
| event_name | Trigger | Properties | Question |
| Item | Your answer |
|---|---|
| Analytics tool | e.g. a privacy-friendly product analytics tool or your own event table; consent banner requirements |
9. Platforms
| Item | Your answer |
|---|---|
| Platform for launch | Responsive web / progressive web app / iOS / Android / cross-platform (Flutter, React Native) — and why |
| Devices and browsers to support | e.g. mobile Safari and Chrome, desktop Chrome and Edge |
| Admin / back office | Simple internal admin, off-the-shelf admin tool, or none (database access for founders) |
| Hosting and region | Cloud provider and region; data residency needs |
10. Integrations
| Service | Purpose | Must for MVP? | Alternative if it slips |
|---|---|---|---|
| e.g. Stripe | Subscriptions | No — manual invoicing first | Payment links |
| e.g. Twilio / local SMS gateway | Reminders | Should | Email reminders |
| e.g. Google sign-in | Faster sign-up | Could | Email magic link |
| Service | Purpose |
11. Design references
| Item | Your answer |
|---|---|
| Products whose UX you admire (and why) | Links plus the specific screen or pattern, e.g. “Calendly’s availability picker — obvious in one glance” |
| Brand assets available | Logo, colours, fonts — or “brand is in scope” |
| Design fidelity for MVP | UI kit with light customisation / custom design system — MVPs rarely need the latter |
| Accessibility baseline | e.g. WCAG 2.2 AA colour contrast and keyboard access for core journey |
| Existing wireframes or prototypes | Links |
12. Launch plan
| Stage | Who | When | Goal |
|---|---|---|---|
| Private alpha | 5–10 hand-picked users, onboarded by founders | Week [n] | Core journey works end to end |
| Closed beta | Waitlist, 20–50 users | Week [n] | Activation and retention signals |
| Public launch | Channels: communities, partners, Product Hunt, outbound | Date | First paying customers |
| Item | Your answer |
|---|---|
| Budget and timeline | e.g. USD 15k–40k over 8–14 weeks for build; plus marketing and running costs |
| Support at launch | Who answers users, in which channel, how fast |
| Legal basics | Terms, privacy policy, cookie consent, data processing agreement if B2B |
13. Post-launch learning loop
| Item | Your answer |
|---|---|
| Review cadence | e.g. weekly metrics review every Monday, fortnightly release |
| User conversations | e.g. 5 user interviews every two weeks; include churned users |
| Feedback capture | In-app feedback, support tags, session recordings (with consent) |
| Decision rules | Pre-agreed: when do we persevere, pivot the segment, change pricing, or stop? |
| Backlog intake | How new ideas are logged and compared against the out-of-scope list |
| Week | What we learned | Evidence | Decision / next experiment |
|---|---|---|---|
| 1 | |||
| 2 |
How to use this template
Fill in this template before you ask anyone for a quote. Founders often arrive with a feature list; this template turns it into a set of decisions. The order matters: the problem and user define the riskiest assumptions, the assumptions define the core journey, and the journey decides which features are genuinely Must-haves.
Plan on one or two focused sessions. Do sections 1–3 alone or with a co-founder, then walk the core journey with two or three target users — ideally on paper sketches — before you finalise the feature list. When you prioritise, attach every feature to a journey step or an assumption. A feature that serves neither belongs on the out-of-scope list, not in the MVP.
Name your analytics events before development starts. Adding tracking after launch means your first, most valuable weeks of data are lost. Keep the list short: sign-up, each onboarding step, the value moment and payment are usually enough.
Once complete, the template doubles as the brief for a development partner — or as the scope section of a formal software development RFP. Our MVP development services start from exactly this kind of document, and the longer MVP development guide covers validation, tech choices and common mistakes. To sanity-check budget, put your Must list into the app development cost calculator. Indicatively, a focused MVP often lands in the $15k–$40k range over 8–14 weeks, while a short discovery or clickable prototype is typically $3k–$8k.
Tips from our delivery team
- Test one assumption at a time. An MVP that tries to prove demand, pricing and a technical breakthrough at once rarely gives a clear answer on any of them.
- Prefer manual over automated behind the scenes. Invoicing by hand, onboarding users on a call, or curating data in a spreadsheet is fine for the first 50 customers.
- Design the core journey before the screens. A short UX design sprint on the value moment usually saves more build time than it costs.
- Keep the out-of-scope list visible. Share it with your team and development partner; point to it whenever a new idea appears mid-sprint.
- Choose boring, maintainable technology. If the MVP works, you will build on it. Pick a mainstream stack you can hire for, rather than something you will need to rewrite.
- Decide your pivot rules in advance. Writing “if week-4 retention is under X we narrow the segment” before launch protects you from rationalising weak results.
- Startups with investors: the problem, evidence and metrics sections double as the product part of a pitch narrative. See our startup app development page for how we work with early-stage teams.
Frequently asked questions
What should an MVP requirements document include?
A clear problem statement with evidence, a narrowly defined target user and job to be done, ranked riskiest assumptions, one core user journey, a MoSCoW feature list, an explicit out-of-scope list, success metrics, named analytics events, platform and integration choices, design references, a launch plan and a post-launch learning loop.
How many features should an MVP have?
There is no fixed number, but every Must-have should be needed to complete the core journey or to test the top assumption. Many successful MVPs have fewer than ten Must-have features. If your Must list keeps growing, the target user or journey is probably too broad.
What is the difference between an MVP and a prototype?
A prototype, often clickable designs, tests whether users understand and want a concept, without working software. An MVP is working software used by real users in real conditions, so it can test behaviour such as retention and willingness to pay.
Should an MVP be a web app or a mobile app?
Choose the platform where your target user meets the problem. Responsive web is usually faster and cheaper to change during validation. Go mobile first when the core value depends on the device itself, such as camera, location, push notifications or offline use.
How long does it take to build an MVP?
Indicatively 8 to 14 weeks for a focused MVP, after a short discovery. Timelines grow mainly with the number of user roles, integrations and platforms, which is why the out-of-scope list in this template has such a large effect on schedule.
Want us to review your completed template? — free
Share your completed MVP template and a Next Olive product lead will suggest what to cut, flag technical risks and give an indicative budget range. No obligation.
Request a free review