135. MVP Scope Playbook

An MVP is not the first bad version of a big product. It is the smallest useful test of the riskiest assumption.

Use this playbook before design, engineering, agency work, or no-code building starts.

Assumption stack

Most MVPs fail because founders test too many assumptions at once. Write the stack first.

Layer	Assumption	How to test before or inside MVP
Customer	This exact segment has the problem.	Interviews, segment-specific outreach, current workaround evidence.
Problem	The problem is painful and frequent enough.	Recent examples, cost of delay, repeated complaints, existing spend.
Value	The proposed outcome is worth switching for.	Prototype review, concierge workflow, paid diagnostic, pilot.
Behavior	Users will do the required action repeatedly.	Manual test, usage tracking, repeat task completion.
Buyer	Someone can approve budget or adoption.	Buyer discovery, price conversation, procurement path.
Delivery	We can create the value reliably.	Manual operations, service blueprint, support log.
Economics	The work can become profitable or scalable.	Time per customer, gross margin estimate, support burden.

Pick one primary assumption for the MVP. Track the rest, but do not let them expand the scope.

Name the riskiest assumption

Choose one primary risk:

Risk type	Question
Problem risk	Does this problem really matter?
Customer risk	Is this the right segment?
Value risk	Does the solution create meaningful value?
Usage risk	Will users repeat the behavior?
Payment risk	Will someone pay or commit seriously?
Delivery risk	Can we deliver the value reliably?
Channel risk	Can we reach the customer repeatedly?

Write:

The MVP exists to test whether [specific customer] will [specific behavior] because [specific value].

Must-build list

A must-build item is required to test the assumption.

Use this filter:

• Without this, can the user reach first value?
• Without this, can we measure the success signal?
• Without this, would the test be misleading?

Table:

Must-build item	Why it is required	Owner	Deadline

Manual list

Manual work is not cheating. It is often the fastest way to learn.

Things you can do manually:

• Data import
• Setup
• Reporting
• Matching
• Customer support
• Analysis
• Notifications
• Payment follow-up
• Admin operations

Track manual effort honestly:

Manual step	Who does it	Time per customer	Product lesson

Manual work becomes dangerous only when you hide it from your own model.

Not-now list

Put attractive distractions here:

• Advanced settings
• Multi-user permissions
• Full mobile app
• Admin dashboards
• Integrations
• Custom branding
• Automation
• Edge cases
• Scale infrastructure

Not-now does not mean never. It means “not needed to test the current risk.”

Success metric

Choose one main metric and two supporting signals.

Examples:

MVP type	Main metric
B2B workflow	First workflow completed and repeated
Marketplace	First successful match or transaction
SaaS tool	Account reaches first value within 7 days
Consumer product	Repeat action in natural usage cycle
Paid pilot	Customer pays or commits after value delivered

Supporting signals:

• Time to value
• Activation rate
• Qualitative feedback
• Payment intent
• Repeat use
• Referral
• Expansion ask

MVP experiment board

Track the MVP as an experiment, not a project.

Field	Example
Hypothesis	Export ops managers will complete supplier document collection faster with a guided workflow.
Test group	8 export manufacturers with 20-200 suppliers.
MVP format	Founder-led onboarding plus simple web workflow and manual reminders.
Main success signal	5 of 8 complete one real collection cycle within 14 days.
Supporting signal	At least 3 ask to use it for the next shipment/audit.
Kill signal	Users still prefer WhatsApp/spreadsheets after guided setup.
Review date	14 days after first active user.

The board should be visible to everyone building the MVP. Scope arguments become easier when the experiment is clear.

Learning instrumentation

Decide how you will learn before building.

Question	Instrument
Did the user reach first value?	Activation event, manual checklist, customer confirmation.
Did the user understand what to do next?	Onboarding notes, support questions, session review.
Did the user return?	Repeat usage event or manual follow-up.
Did the buyer see value?	Review call, pilot success criteria, payment discussion.
Which manual step repeated?	Operations log.
What blocked adoption?	Lost-user interview, support tag, sales note.

If you cannot observe the learning, the MVP may create activity without evidence.

First user selection

Do not give the MVP to random friendly users. Choose first users deliberately.

Good first user	Why
Has the exact problem now	Feedback is grounded in current pain.
Can show the current workaround	You can compare old and new behavior.
Will tolerate roughness if value is real	You learn without overbuilding polish.
Can make or influence the decision	Payment or adoption signal is meaningful.
Will give direct feedback	Polite silence is expensive.

Avoid users who are curious but not pained, too senior to touch the workflow, too different from the target segment, or only helping because they like the founder.

Kill criteria

Define what will make you stop or change.

Examples:

• Fewer than 3 of 10 target customers reach first value
• Users need founder explanation every time
• Customer likes the idea but will not take any next step
• Value requires custom work that does not repeat
• Wrong buyer controls the budget

Kill criteria protect you from emotional attachment.

MVP scope document

Use this one-page format:

Field	Answer
Target customer
Problem
Riskiest assumption
First value moment
Must-build
Manual work
Not-now
Success metric
Kill criteria
Review date

Scope negotiation rules

Early users will ask for many things. Some requests reveal the real problem. Others are distractions.

Use these rules:

Request type	Default response
Needed for first value	Consider building or doing manually
Needed by many target users	Add to next review
Needed only by one customer	Do manually or decline
Needed for compliance or trust	Evaluate carefully before launch
Nice-to-have polish	Defer
Custom workflow for wrong segment	Decline

The MVP should be narrow enough that failure teaches something. If it tries to satisfy every request, failure will only tell you that the product was messy.

Concierge layer

For many Indian startups, the first MVP may include manual service: onboarding calls, WhatsApp support, spreadsheet imports, founder-run reports, or manual reconciliation. That is acceptable if you label it honestly.

Manual work allowed	Manual work not allowed
Helps understand workflow	Hides that users do not care
Creates first value faster	Makes unit economics impossible
Can become product later	Requires custom logic for every customer
Builds trust with early buyers	Creates founder-only delivery

Manual work is useful when it reveals product truth. It is dangerous when it becomes the product without being priced that way.

Review meeting

Schedule the MVP review before building starts. In that meeting, answer:

• Did the target customer reach first value?
• Did they return without founder pressure?
• Which manual steps repeated?
• Which feature requests came from good customers?
• Which assumptions are now stronger?
• Which assumptions failed?
• Do we continue, narrow, rebuild, or stop?

Post-MVP decision table

Use the evidence to decide.

Evidence	Decision
Target users reached first value and asked to continue	Continue and improve onboarding/reliability.
Users cared but needed heavy manual help	Keep concierge layer, identify what must become product.
Buyer liked value but would not pay	Revisit pricing, buyer, urgency, and budget owner.
Only one segment cared	Narrow ICP and remove features for other segments.
Users asked for unrelated custom workflows	Decide whether this is services, product, or wrong segment.
No repeated behavior	Stop or rebuild around a different pain.

Do not call every MVP “validated.” Name what was validated and what remains risky.

MVP scope negotiation

The hard part of MVP scope is not writing the first list. The hard part is defending it when customers, co-founders, investors, agencies, and your own anxiety try to expand it.

Use this negotiation script when a new request appears:

“This may be important. For this MVP, we are testing whether [customer] will [behavior] because [value]. Does this request directly affect that test, or can we learn without it?”

Then classify the request.

Request	Ask	Decision rule
Blocks first value	”Will the user fail without this?”	Build, fake, or manually handle.
Improves trust	”Will the user refuse to try without this?”	Add only the minimum credible version.
Improves convenience	”Can the user still complete the core workflow?”	Defer.
Supports one customer	”Is this segment-defining or one-off?”	Do manually or decline.
Supports a future product vision	”Does the current MVP need to prove it?”	Put in not-now.
Makes the founder feel safer	”What fear is this feature reducing?”	Do not build until evidence supports it.

Founders often add scope because the MVP feels embarrassing. That feeling is not always a problem. A good MVP can feel narrow, manual, and unfinished while still being useful. The question is whether the incompleteness prevents learning.

When a customer asks for a feature, respond with curiosity before saying yes:

• “What would this help you do?”
• “How do you solve that today?”
• “Would this stop you from using the current version?”
• “Is this needed by your team or just preferred?”
• “If we did not build this for 30 days, what would happen?”

These questions separate pain from preference. Early product conversations are full of polite feature ideas. The founder’s job is to find the few that reveal real workflow value.

Manual fulfilment plan

Write the manual fulfilment plan before launch. This protects the team from quietly creating a services business without noticing.

Manual step	Who does it	Time per customer	Quality risk	Product signal
Onboarding call	Founder	30 minutes	Founder skill hides product gaps	Which questions repeat?
Data cleanup	Ops/founder	45 minutes	Messy formats delay value	What should import handle later?
Report preparation	Founder	20 minutes	Slow turnaround	Which insights matter most?
WhatsApp support	Founder	Variable	Support becomes invisible work	What confuses users?
Reconciliation	Ops/founder	60 minutes	Errors reduce trust	What logic needs automation?

For each manual step, decide whether it is temporary learning work, paid service work, or a future product requirement.

Step type	How to treat it
Temporary learning work	Do it personally and document every repeated pattern.
Paid service work	Price it honestly or limit it clearly.
Future product requirement	Keep examples, edge cases, and acceptance criteria.
Wrong-customer custom work	Decline before it reshapes the company.

This matters in India because early customers may expect high-touch support, WhatsApp responsiveness, custom reports, and flexible payment follow-up. Those behaviours can help you win trust, but they can also hide a product that does not yet stand on its own. Put manual work in the open.

Post-MVP learning review

Run the learning review within 48 hours of the MVP test window closing. Do not let the team drift into the next sprint before deciding what was learned.

Use this agenda:

Question	Evidence to inspect
Did the right customer try it?	ICP, role, company type, urgency trigger.
Did they reach first value?	Activation event, completion, output created, buyer/user reaction.
Did they come back?	Repeat usage, second action, follow-up request, renewal or payment signal.
What required founder force?	Reminders, support, manual data work, personal persuasion.
What was requested repeatedly?	Feature requests grouped by customer type.
What surprised us?	Failed assumptions, unexpected segment, hidden workflow, new objection.
What should be killed?	Features, segments, channels, promises, pricing assumptions.

End with one of five decisions:

Decision	When to choose it	Next action
Continue	Core assumption got stronger.	Improve the bottleneck and add more target users.
Narrow	One segment cared much more than others.	Rewrite ICP and remove off-segment work.
Rebuild	Problem is real but workflow/product is wrong.	Keep learning, change solution path.
Change buyer	User likes it but buyer will not act.	Run buyer discovery before more product work.
Stop	No strong signal after honest testing.	Capture lessons and move to a better problem.

The output of an MVP is not a product. The output is a sharper decision.

MVP cut-line rule

When scope starts expanding, use a cut-line rule. Every proposed feature must sit above or below the line.

Above the line:

• Required to test the riskiest assumption.
• Required for the first user to reach value.
• Required for trust, safety, payment, data handling, or basic reliability.
• Required to measure the success metric.

Below the line:

• Makes the product feel more complete.
• Supports an edge case.
• Helps a future segment.
• Automates work that the founder can manually handle for learning.
• Exists mainly because the team is embarrassed by roughness.

Use this table in scope discussions:

Proposed item	Assumption it tests	What breaks without it?	Manual workaround	Decision
				Build / manual / later / cut

If the team cannot name the assumption a feature tests, it probably belongs below the line. This does not mean the feature is bad. It means it is not MVP-critical.

Founders often overbuild because they want the first version to defend their taste, ambition, or technical ability. Customers do not care whether the MVP proves the founder is talented. They care whether it solves a painful job. Keep the MVP narrow enough that the result teaches something unmistakable.

MVP risk budget

Give the MVP a risk budget before building. The risk budget says which risks you are allowed to carry and which risks must be reduced before launch.

Risk	Allowed in MVP?	Notes
Rough UI	Usually yes	Acceptable if users can still reach first value
Manual onboarding	Often yes	Good for learning if documented
Limited automation	Yes	Manual work can reveal product logic
Data/security ambiguity	No	Trust and safety basics must be clear
Payment ambiguity	No for pricing MVP	If payment is the test, the payment path must exist
Undefined target user	No	You cannot learn from everyone at once
No success metric	No	Activity without a metric becomes theatre
Heavy custom work	Usually no	Unless the test is explicitly a services/concierge model

This prevents the common mistake of accepting the wrong roughness. It is fine for an MVP to look simple. It is not fine for the founder to be unclear about who it is for, what it tests, or whether users can trust it.

First-value storyboard

Before building screens, storyboard the first-value path.

Step	User action	Founder/product action	Evidence captured
Arrives	Understands who this is for	Page/onboarding names segment and promise	Source and segment
Starts	Gives minimum required input	Setup, import, or manual intake begins	Activation start
Works	Completes the core workflow	Product/manual system creates output	Completion event
Sees value	Receives useful result	Report, answer, match, workflow completion	First-value confirmation
Returns	Uses again or asks for next step	Reminder, follow-up, or natural repeat	Retention/repeat signal
Commercial step	Buyer discusses payment or rollout	Proposal, pilot, invoice, or contract	Payment path

If the storyboard has too many steps, the MVP may be asking too much before value. If the storyboard has no commercial step, the MVP may validate usage without validating a business.

Scope kill switch

Use a kill switch when the MVP starts turning into a full product.

Pause building if any of these happen:

• Must-build list grows for 3 consecutive reviews.
• A feature is added without naming the assumption it tests.
• The team cannot describe the first-value moment in one sentence.
• New work is mainly for a customer outside the target segment.
• Manual work is hidden instead of measured.
• The launch date moves but the learning question stays vague.

When the kill switch fires, hold a 45-minute reset:

Question	Decision
What is the one riskiest assumption now?
What is the smallest test of it?
What can be manual?
What can be cut?
What evidence will decide continue/change/stop?

The goal is not to punish ambition. It is to stop ambition from smuggling in a product plan before the startup has earned one.

Agency and freelancer brief

If you use an agency, freelancer, or no-code builder, give them an experiment brief instead of a product dream.

Brief section	Founder answer
Customer	Exact user/buyer and why they care now
Learning goal	Riskiest assumption being tested
First-value moment	What the user must experience
Must-build	Only items required for the test
Not-now	Features explicitly excluded
Manual work	What founder/team will do outside the product
Tracking	Events, notes, calls, and review date
Change control	No new feature without founder approval and assumption link

External builders often try to make the product feel complete. That instinct is useful later. In the MVP stage, the founder must protect the learning goal.

MVP evidence review

Before declaring the MVP successful, separate product completion from evidence. Shipping the MVP is not the same as learning from it.

Use this review:

Evidence area	Question	Proof
First value	Did target users reach the promised first-value moment?	Event data, screen recordings, notes, customer confirmation.
Time to value	How long did it take?	Timestamp, onboarding notes, setup effort.
Founder explanation	Did value require founder hand-holding?	Support logs, call notes, repeated confusion.
Repeat behavior	Did users come back or continue the workflow?	Repeat usage, next session, follow-up request, retained task.
Payment or commitment	Did value create willingness to pay, expand, introduce, or share data?	Invoice, paid pilot, buyer intro, stakeholder meeting, serious next step.
Scope pressure	What did users ask for that is outside the current wedge?	Feature requests grouped by segment and value.

Classify the MVP result:

Result	Meaning	Next move
Value clear, scope small, users repeat.	Keep improving the wedge.	Build reliability, onboarding, and pricing proof.
Value clear, setup heavy.	Product may work but delivery is fragile.	Simplify onboarding or charge for implementation.
Users like demo but do not use.	Demo interest is ahead of workflow fit.	Watch real usage and revisit first value.
Users use one tiny part.	The real product may be narrower.	Cut around the used workflow.
Users need a different buyer or context.	Segment or buyer hypothesis may be wrong.	Return to discovery or buyer mapping.

The MVP should create a sharper company, not just a larger backlog.

Scope Change Log

MVPs usually expand through small, reasonable-sounding requests. One customer asks for a field, one co-founder wants polish, one investor suggests a dashboard, one edge case feels embarrassing. Keep a scope change log so expansion is visible.

Date	Requested change	Source	Assumption affected	Build/manual/later/cut	Reason	Review date
		Customer / founder / sales / investor / support

Use this rule:

No scope change enters the MVP unless it names the assumption it tests or the first-value failure it prevents.

If a request is useful but not MVP-critical, put it in the not-now list with context. That way the team does not lose the insight, but the current test stays clean.

Review the log every Friday:

• Which requests came from exact ICP customers?
• Which requests came from wrong-fit customers?
• Which requests reveal first-value friction?
• Which requests are really trust, security, payment, or onboarding requirements?
• Which requests mainly reduce founder embarrassment?

The scope change log turns scope creep into evidence. Some requests deserve to change the MVP. Most deserve to wait.

Commitment Test

An MVP should test value, but founders should also decide what kind of commitment is required for the stage. Free usage is not useless, but it is weaker than a serious commitment.

Choose one commitment target before launch:

Commitment type	What it proves	When it is enough
Time commitment	User gives time for onboarding, setup, review, or repeated usage.	Early problem/value test.
Data/workflow access	Customer shares real artifacts, samples, or process details.	Workflow or concierge MVP.
Stakeholder intro	User brings buyer, manager, team, or technical owner.	Buyer-path or implementation risk.
Paid diagnostic	Customer pays for analysis, setup, or manual value creation.	Payment/value risk before full product.
Paid pilot	Customer pays for a scoped outcome in a time window.	Strong B2B validation.
Renewal/expansion ask	Customer wants continued or broader use.	Post-first-value proof.

Write the commitment test:

For this MVP to count as strong evidence, at least [number] target customers must [commitment] by [date] after experiencing [first value].

Examples:

MVP	Weak signal	Stronger commitment
Founder-led reporting tool	Customer says dashboard is useful.	Customer shares real reports and pays for a 30-day diagnostic.
SaaS workflow MVP	User completes one demo workflow.	Team uses it for a real workflow twice and introduces the buyer.
Marketplace MVP	Supply and demand say they are interested.	One real match or transaction happens with clear follow-up.
AI support assistant	Support head likes demo.	Team uses it on real tickets with human review and agrees to pilot criteria.

The commitment test protects the founder from building for applause. The right commitment depends on stage, but there should be some cost to the customer’s signal: time, data, reputation, workflow change, or money.

Common mistakes

• Treating the MVP as a smaller version of the full vision
• Building for edge cases before the core value is proven
• Automating before understanding the manual workflow
• Adding features because early users ask, not because the riskiest assumption needs them
• Failing to define what would make the MVP a failure

Done when

The MVP scope is ready when:

• The riskiest assumption is explicit
• The must-build list is shorter than the not-now list
• Manual work is named and accepted
• Success and kill criteria are written before building
• The first users are identified
• The review date is on the calendar

Related chapters

• 35. MVP Scope
• 34. Product Discovery
• 147. Product Templates