A founder has a two-week demo and asks, “How do I position this for fundraising?”
The honest answer: prove something first.
A demo shows what could exist. An MVP tests whether a specific customer will change behavior because it exists. That behavior might be a paid pilot, repeated usage, a design partner agreement, a workflow switch, or a clear commitment to keep using the product.
TL;DR
Use this minimum viable product template to lock scope before you build.
The goal is not to list every feature your product might need someday. The goal is to define one customer, one painful problem, one small promised outcome, the few features required to test it, and the metric that tells you whether the first build worked.
The template is a scope lock, not a feature wishlist. If you are still deciding what proof matters, connect it to a business validation plan before you start building.
What this template is for
An MVP template is a short planning document that defines who the first version is for, what problem it tests, what the first build includes, what it excludes, and what behavior counts as proof. It keeps the team focused on learning before the MVP turns into a full product spec.
It should answer:
Who is this first version for?
What painful problem are we testing?
What does the smallest useful solution promise?
What must be included for that promise to work?
What are we explicitly not building yet?
What behavior will count as evidence?
That last point matters. The metric should measure behavior, not compliments. “People liked the demo” is weak. “Five teams used it twice in two weeks” is stronger. “Three design partners agreed to run real work through it” is stronger still.
Eric Ries’s MVP guide is commonly used to frame MVPs around learning before overbuilding. The founder translation is simple: build the smallest system that can test the promise.
Minimum viable product canvas
Copy this minimum viable product canvas into a doc and fill it in before writing tickets, hiring an agency, or making a minimum viable product presentation.
MVP name: [Short working name]
Target customer: [Specific person, company type, role, size, context]
Painful problem: [The expensive, frequent, urgent, or embarrassing problem they already feel]
Current workaround: [What they do today instead of using your product]
Smallest promised outcome: [The smallest valuable result the MVP must deliver]
Core use case: [The one workflow or moment the MVP supports]
Must-have features:
[Feature required to deliver the outcome]
[Feature required to deliver the outcome]
[Feature required to deliver the outcome]
Non-goals / deferred features:
[Feature we are not building yet]
[Edge case we are not handling yet]
[Integration, automation, or polish we can defer]
Manual steps allowed: [What the team can do manually behind the scenes for version one]
Success metric: [The primary behavior that proves the MVP mattered]
Failure signal: [The behavior or non-behavior that means the promise did not land]
Design partner profile: [The kind of early customer who feels this pain now and will work closely with you]
Design partner ask: [What you want them to commit to: pilot, calls, data access, usage, payment, feedback]
What we will learn: [The key assumption this MVP tests]
Next iteration trigger: [What result causes us to improve, pivot, narrow, or stop]
How to fill each field
Target customer
Do not write “SMBs,” “founders,” “creators,” or “service businesses.” Those are markets, not first users.
Use a narrow group with a shared situation.
Weak: workflow platform for service businesses
Better: onboarding automation for 10-50 person accounting firms losing prospects during document collection
One audience where the product can be excellent beats a universal product for everyone.
Painful problem
A good problem is already costing the customer something: time, money, deals, risk, reputation, attention, or sleep.
If the customer does not describe the pain as important, be careful. You may be solving a nuisance, not a business problem.
Current workaround
This is where many fake MVPs collapse.
If nobody has a workaround, the pain may not be strong enough. Workarounds can be ugly: spreadsheets, assistants, Slack threads, screenshots, manual reminders, consultants, half-used software.
Ugly is fine. Indifference is not.
Smallest promised outcome
The promise should be small enough to test and valuable enough to matter.
Bad: Make accounting firms more efficient.
Better: Reduce missing-document follow-up during client onboarding.
Bad: AI assistant for lawyers.
Better: Turn messy intake notes into a structured case summary with a missing-info checklist.
Core use case
Pick one moment, not the whole product.
The core use case might be:
A RevOps manager checks pipeline hygiene before forecast.
An attorney turns intake notes into a case summary.
A gym owner follows up with trial members before they go cold.
An accounting firm collects documents from a new client.
If the MVP cannot be described as one repeatable moment, the scope is probably too wide.
Must-have features
Start with only the features required to test the core behavior. Many MVPs can be scoped to a short list.
A must-have feature is required to test the core behavior. It is not included just because it is small, easy, or expected someday.
Non-goals / deferred features
Non-goals are as important as features. This is where you stop the first build from quietly becoming the full product. Put rare edge cases here unless they directly test the core use case.
Common deferred items include:
Full admin dashboard
Mobile app
Billing
Referral system
Custom roles and permissions
CRM replacement
All industry templates
Advanced analytics
White-labeling
Complex integrations
You can technically build many of these. That does not mean they belong in the MVP.
Manual steps allowed
The MVP does not need to automate everything. It needs to test whether the promised outcome matters.
Manual setup, concierge onboarding, human review, spreadsheet imports, and founder-operated workflows can be acceptable if they help you learn faster. Be honest about what is manual so you do not confuse service work with product behavior.
Success metric
Choose one primary metric. Good MVP metrics measure behavior.
These are illustrative examples, not universal benchmarks:
Three teams run real work through the MVP.
Five users return twice in 14 days.
Ten customers complete the workflow without founder hand-holding.
Three companies agree to a paid pilot.
Twenty households create entries four or more days in a week.
Five attorneys use it on real client calls and keep editing time under 10 minutes.
For a broader validation system, use a business validation plan so the MVP is tied to customer discovery, design partner commitments, and traction signals.
Failure signal
Write this before you build.
Examples:
Users praise the idea but will not try it on real work.
Design partners ask for unrelated features before using the core workflow.
Users complete setup but never return.
The promised outcome still requires too much manual explanation.
The buyer agrees the pain exists but will not commit time, data, or budget.
A failure signal is not a personal insult. It is the reason you built small.
Next iteration trigger
Your first MVP is a bet, not a monument.
Decide what happens next:
If users commit but do not activate, fix onboarding.
If they activate but do not return, re-check the use case.
If they ask for the same missing feature, consider adding it.
If every customer wants a different product, narrow the ICP.
If nobody will commit, revisit the problem.
MVP template vs product spec vs pitch deck
Asset | Main job | Best used when | Common mistake |
|---|---|---|---|
MVP template | Decide what the first build must prove | Before tickets, prototypes, or agency briefs | Turning it into a full feature wishlist |
Product spec | Explain how the agreed product should work | After the MVP scope is clear | Writing specs before agreeing on the customer and metric |
Pitch deck | Explain the company, market, traction, and plan | When you have a story worth pitching | Using slides to hide weak proof |
MVP presentation | Align partners around the first test | When cofounders, contractors, or design partners need clarity | Making the MVP look more certain than it is |
Filled example: B2B SaaS MVP
This example uses specific numbers to show how the canvas works. They are not recommended thresholds.
MVP name: Client Document Chase
Target customer: 10-50 person accounting firms that onboard new business clients and lose time collecting documents
Painful problem: New clients delay onboarding because document requests are scattered across email threads
Current workaround: Staff send manual email reminders, update spreadsheets, and ask partners for status updates
Smallest promised outcome: Help the firm collect required onboarding documents with fewer manual follow-ups
Core use case: An advisor creates a client intake link, assigns required documents, and sees what is missing
Must-have features:
Client intake link
Document checklist
Automated reminder sequence
Advisor status dashboard
Non-goals / deferred features:
Full CRM
Billing
Custom workflows for every service line
Client portal branding
Deep practice-management integrations
Manual steps allowed: Founder helps configure the first checklist for each design partner
Success metric: In this example, three firms use it for 10 or more real clients each within 30 days
Failure signal: Firms say the idea is useful but do not send the intake link to real clients
Design partner profile: Accounting firms with a visible onboarding backlog and one operations lead willing to test new process tools
Design partner ask: Use the MVP for 10 real client onboardings, join one setup call, and share completion data after 30 days
What we will learn: Whether document collection is painful enough for firms to change their onboarding workflow
Next iteration trigger: In this example, if three firms use it for 10 or more clients and request the same missing feature, add that feature next. If usage is low, revisit the problem or ICP.
Notice what is missing: no mobile app, no billing, no referral loop, no large dashboard suite, no “platform for all service businesses.”
That is the point.
Feature filter: must-have, later, not MVP
Use this when a feature feels “small” but starts pulling the product sideways.
Feature type | Include when | Example |
|---|---|---|
Must-have | Without it, the core promise cannot be tested | Document checklist for a document-collection MVP |
Later | It improves adoption after the core promise is proven | Custom branding, richer analytics, team permissions |
Not MVP | It serves a rare edge case or a different product | Replacing the customer’s full CRM |
A practical rule: if the feature does not help prove the success metric, it is probably later or not MVP.
How to use the finished template with design partners
The completed canvas should become a short design partner pitch. Not a 20-slide deck. Not a product manifesto. A clear ask.
Use this outline:
We are building [MVP name] for [target customer].
It helps with [painful problem].
The first version only does [must-have features].
We are not building [non-goals] yet.
We are looking for [number] design partners to test whether it can create [smallest promised outcome].
The commitment is [design partner ask].
If it works, we expect to see [success metric].
For example, using the sample canvas above:
We are building Client Document Chase for 10-50 person accounting firms. It helps reduce missing-document follow-up during client onboarding. The first version includes an intake link, checklist, reminders, and a simple status dashboard. We are not replacing your CRM or billing system. We are looking for three firms to run 10 real client onboardings through it over 30 days.
That is more useful than saying, “We are building a workflow platform for accounting firms.”
Once design partners agree, turn the canvas into tickets and a delivery plan.
How to turn the canvas into a 5-slide MVP presentation
A minimum viable product presentation is useful when you need to align cofounders, advisors, contractors, or design partners.
Keep it short:
Slide | What it should say |
|---|---|
1. Problem | The painful problem and current workaround |
2. Customer | The exact target customer and why they feel the pain now |
3. Scope | The must-have features and explicit non-goals |
4. Metric | The behavior that proves the MVP worked |
5. Ask | The design partner commitment you want |
Do not make the presentation look more certain than the business is. The point is to show what you are testing.
The Lean Startup principles are useful here because they frame startups as experiments under uncertainty. A good MVP presentation should carry that same honesty: this is what we believe, this is what we are building, and this is the behavior that will tell us whether we are right.
Before you build, answer these seven questions
Use this as the final scope check:
Can we name one specific target customer?
Can we describe the pain in words they would recognize?
Do we know the workaround they use today?
Can we state the smallest promised outcome in one sentence?
Are the must-have features limited to the core use case?
Have we written explicit non-goals?
Does our success metric measure behavior, not compliments?
If the team cannot agree on these, do not start by debating architecture. Agree on the product logic first.
FAQ
What should be included in an MVP template?
Include the target customer, painful problem, current workaround, smallest promised outcome, core use case, must-have features, non-goals, manual steps, success metric, failure signal, design partner ask, and next iteration trigger.
Is an MVP template the same as a product requirements document?
No. A PRD describes what to build in more detail. A minimum viable product canvas decides what is worth building first and what evidence will make the first version meaningful.
How many features should an MVP have?
Start with only the features required to test the core behavior; many MVPs can be scoped to a short list.
Can I use this MVP template to raise money?
Only as support for a traction story. The template can show clear thinking, but investors will usually care more about what real users did after seeing or using the MVP.
How do I use this for a minimum viable product presentation?
Turn the canvas into five slides: problem, customer, scope, metric, and design partner ask. Keep the deck focused on what you are testing, not everything the product could become.
