35. MVP

An MVP is not the smallest product you can ship. It is the smallest experiment that can teach you something important about the business.

The point is not to build less for the sake of building less. The point is to learn before you spend months creating a product nobody urgently wants. Many founders use “MVP” to mean “version one with fewer features.” That is often wrong. If the riskiest assumption is whether customers will pay, the MVP may be a sales call, manual service, or paid pilot. If the riskiest assumption is usability, it may be a prototype. If the riskiest assumption is demand, it may be a landing page, outreach test, or waitlist with follow-up.

Minimum, Viable, Product

Each word matters.

Minimum

Minimum means the smallest thing that can test the current riskiest assumption. It does not mean careless, broken, ugly, or untrustworthy. If trust matters, the minimum still needs to feel credible.

Viable

Viable means the customer can experience enough value to behave honestly. If the test is too fake, customers may reject the execution rather than the idea. If the test is too polished, you may spend too much before learning.

Product

Product does not always mean software. A spreadsheet, WhatsApp workflow, manual service, Figma prototype, concierge workflow, paid pilot, or API wrapper can be a product if it tests the right assumption.

Learning Goal

Every MVP should have one sentence:

“We are testing whether [specific customer] will [specific behavior] because [specific pain] is important enough.”

Without this, the MVP becomes a feature list.

Start With The Riskiest Assumption

Do not start MVP planning by listing features. Start with risk.

Common startup assumptions:

• Customers have the problem.
• The problem is urgent.
• Customers will change behavior.
• Customers will pay.
• You can reach customers.
• You can deliver the promised outcome.
• The workflow can be repeated.
• The economics can work.
• Trust can be earned.
• Usage will repeat after novelty fades.

The MVP should test the assumption most likely to kill the company if wrong.

MVP Types

Choose the MVP type based on the question.

MVP type	Best for	Watch out for
Landing page	Demand, positioning, and message testing.	Email signups are weak unless followed by action.
Concierge	Learning the workflow manually.	Manual service may hide future margin problems.
Wizard of Oz	Testing customer experience before automation.	Be ethical; do not mislead customers in harmful ways.
Manual service	Understanding value, operations, and willingness to pay.	Do not confuse service delivery with product scalability.
Figma prototype	Usability, flow, and buyer feedback.	People praise demos more than they use products.
No-code MVP	Fast workflow testing.	Tool limits can distort the experience.
Spreadsheet MVP	B2B workflows, analysis, matching, operations.	Requires discipline to track repeatability.
Paid pilot	Value, urgency, trust, and payment.	Pilot terms must be clear.
API wrapper	Technical feasibility and developer demand.	Thin wrappers commoditize quickly.
Community or WhatsApp MVP	Behavior, support, and service delivery.	Hard to scale if learning is not documented.

An MVP can be manual and still be serious. The goal is evidence.

Choose The MVP By Risk

The best MVP is the one that tests the riskiest assumption directly. Do not choose an MVP type because it is fashionable.

Riskiest assumption	Better MVP	Weak MVP
Customers have urgent pain	Interview sprint, outbound test, manual problem audit.	Building full product first.
Buyers will pay	Paid pilot, deposit, signed LOI with clear scope, founder-led sales.	Free waitlist.
Users can complete the workflow	Prototype, usability test, concierge workflow.	Landing page only.
The product can deliver value	Manual service, spreadsheet, Wizard of Oz, narrow prototype.	Polished signup flow.
The channel can reach customers	Outreach test, content test, partner test, small paid experiment.	Building more features.
Retention will exist	Cohort test, repeat-use pilot, habit loop experiment.	Launch-day installs.
Unit economics can work	Paid pilot with tracked delivery cost.	Free concierge for everyone.

If the main risk is payment, do not hide behind prototype feedback. If the main risk is usability, do not hide behind interview praise. If the main risk is retention, do not hide behind launch traffic.

An MVP should make the uncomfortable question unavoidable.

Scope The MVP

Use four buckets:

Bucket	Meaning
Must-have	Required to test the assumption.
Nice-to-have	Useful, but not needed now.
Later	Valuable after the test works.
Dangerous	Adds complexity, delays learning, or hides the truth.

Most MVPs become bloated because “nice-to-have” features pretend to be must-have. Founders say, “Customers will need this,” before any customer has committed.

Ask:

• What must exist for the customer to experience the core value?
• What can the founder do manually?
• What can be faked safely and honestly?
• What can be explained in onboarding instead of built?
• What would delay learning without changing the result?
• What would create trust risk if missing?

Define Success Before Launch

Define success before the MVP reaches customers. Otherwise you will reinterpret weak signals as progress.

Strong signals:

• A customer pays.
• A customer uses it repeatedly.
• A customer changes workflow.
• A buyer introduces the team.
• A user brings real data.
• A pilot converts to paid.
• A customer refers another customer.
• Usage survives after initial curiosity.
• A customer complains when access is removed.

Weak signals:

• “This is interesting.”
• “I would use this.”
• “Send me the link.”
• Signups from friends.
• Positive comments without behavior.
• Demo praise from non-buyers.

The MVP should force a customer behavior that matters.

MVP Evidence Ladder

Not all MVP evidence is equal. Treat signals as a ladder.

Evidence level	Example	How much to trust it
Opinion	”This sounds useful.”	Very low. Useful only for language and curiosity.
Intent	Signup, waitlist, “send me details.”	Low unless followed by action.
Effort	Customer shares data, books time, invites team, changes process.	Medium. Effort shows the problem may matter.
Payment	Paid pilot, deposit, subscription, implementation fee.	High. Payment shows commitment.
Repeated use	Customer returns without being pushed.	High. Repetition shows workflow fit.
Expansion or referral	Customer buys more or introduces others.	Very high. Value is becoming transferable.

Most founders overvalue opinion and intent because they are easy to collect. The MVP should move you up the ladder as quickly as possible. If a landing page gets signups, follow up and ask for a call, data, payment, or usage commitment. If a demo gets praise, ask for a paid pilot. If a pilot gets usage, ask what would make renewal obvious.

The sharper the evidence, the less room there is for founder storytelling.

MVP Test Plan

Write the test plan before you start building. It can be one page.

Section	Question
Segment	Who exactly are we testing with?
Risk	Which assumption can kill this idea?
Behavior	What customer action would prove progress?
MVP type	What is the simplest honest way to test this?
Scope	What must exist, and what stays manual?
Success threshold	What result makes us continue?
Failure threshold	What result makes us stop or change?
Time box	When will we review?
Follow-up	What will we ask customers after the test?

Example:

Section	Example
Segment	Seed-stage Indian SaaS founders selling to US customers.
Risk	They say sales is painful, but will not pay for structured call help.
Behavior	Three founders pay for a two-week founder-sales pilot and use the call template at least twice.
MVP type	Google Doc template plus weekly review call.
Success threshold	At least two founders use it in real calls and ask to continue.
Failure threshold	Founders praise it but do not use it before calls.

This plan prevents the founder from moving the goalpost. If the MVP fails, that is useful. The failure tells you what to test next.

MVP Cutline

The cutline is the boundary between what must be included and what must be refused. Write it before building starts.

Use this table:

Item	Include now?	Reason
Core workflow	Yes, if needed to test value.	Without it, the customer cannot experience the promise.
Trust basics	Yes, if risk is meaningful.	Missing trust may invalidate the test unfairly.
Manual admin	Yes, if it speeds learning.	Founders can do work manually before automating.
Integrations	Only if the workflow cannot be tested without them.	Integrations can consume the whole MVP.
Team permissions	Only if buyer/user structure requires them.	Useful later, distracting early.
Analytics dashboard	Only if it is the core value.	Many dashboards are post-MVP reporting, not value.
Custom requests	Usually no.	They hide repeatability risk.
Polish	Enough for credibility, not perfection.	Trust matters; decoration does not prove demand.

The most useful MVP sentence is: “We are intentionally not building [X] because it does not change the learning goal.”

Manual For Now

Label manual work explicitly:

• Manual data import.
• Manual report generation.
• Manual onboarding.
• Manual reminders.
• Manual quality review.
• Manual customer success.
• Manual billing.

Manual work is acceptable when it teaches the repeatable system. It is dangerous when nobody tracks the effort. For every manual step, record time spent, errors, customer value, and whether it can later become product, process, or partner work.

The goal is not to keep manual work forever. The goal is to avoid automating something you do not understand yet.

Designing A Paid Pilot

For B2B startups, a paid pilot is often the best MVP because it tests pain, trust, value, and willingness to pay together. The pilot does not need to be large. It does need to be clear.

A good paid pilot includes:

• A specific customer segment and buyer.
• A defined problem and workflow.
• A start date and end date.
• A price or deposit, even if discounted.
• A narrow scope.
• Success criteria agreed before the pilot starts.
• Customer responsibilities, such as data, access, team time, or approvals.
• A review meeting.
• A conversion path if the pilot works.

Avoid pilots that are free, endless, vague, and custom. They teach less than founders hope. A free pilot can still be useful in high-trust or complex markets, but then ask for another form of commitment: data, reference access, executive time, or a written success review.

For Indian B2B customers, a small paid pilot can also test practical realities: GST invoicing, procurement, payment delays, data quality, staff adoption, and support expectations. These operational details are part of the business model, not admin noise.

When To Kill, Continue, Or Expand

Before launch, set a review date.

Kill or rethink when:

• The target customer does not care.
• The pain is weak.
• The buyer will not pay or commit.
• Usage does not repeat.
• The workflow is too custom to repeat.
• Trust cannot be earned with the current approach.

Continue when:

• Customers use it repeatedly.
• Customers pay or commit meaningfully.
• The same segment responds.
• The same value proposition works.
• Manual delivery reveals a repeatable system.

Expand only after learning is clear. Do not turn every request into roadmap.

After The MVP

An MVP should end with a decision. Do not leave it as a half-product forever.

Possible decisions:

Decision	When to choose it	What to do next
Double down	Strong behavior from the target segment.	Build the repeatable version and improve onboarding.
Narrow	Some users love it, but only a specific subset.	Rewrite ICP, positioning, and scope around that subset.
Change MVP type	The test did not reach the real risk.	Design a sharper test.
Change problem	Customers use it but do not care enough.	Return to discovery and pain mapping.
Change model	Value exists but economics do not.	Test pricing, packaging, or delivery model.
Kill	Weak pain, weak usage, weak payment, and no clear learning path.	Stop spending product time and document lessons.

Founders often keep weak MVPs alive because killing feels like failure. The real failure is letting a weak test consume months of attention.

Make the decision visible. Write what was learned, what changed, and what the company will not do next. This creates organizational memory and saves future team members from reviving old ideas without context.

India Angle

In India, MVPs often need more trust and support than founders expect. A bare landing page may not validate a product if customers require a call, WhatsApp follow-up, local proof, GST invoice, or implementation help. For B2B, a founder-led pilot may teach more than a self-serve signup flow. For consumer products, language, payments, device quality, family involvement, and support expectations can shape the MVP.

Do not blindly copy a self-serve SaaS MVP if your customer buys through relationships. The right MVP is the one that tests real buying and usage behavior in your market.

Common Mistakes

• Building a mini full product.
• Starting with features instead of assumptions.
• Refusing manual work.
• Treating free users as proof of willingness to pay.
• Measuring signups but not activation or retention.
• Adding polish to avoid sales.
• Keeping the MVP alive after it has answered the question.
• Ignoring trust, support, and onboarding.
• Changing the MVP goal mid-test.
• Hiding from price conversations.

Anti-Scope Checklist

Before adding anything to the MVP, ask:

• Does this test the riskiest assumption?
• Will the customer refuse to participate without it?
• Can the founder do it manually for the first ten customers?
• Can it be handled with onboarding, documentation, or a call?
• Does it reduce trust risk or only make us feel more complete?
• Does it create maintenance burden before we know the market cares?
• Will this feature change the decision after the MVP?

If the answer is “no,” move it to later. The discipline is hard because building feels like progress. But every extra feature adds time, bugs, explanation, support, and emotional attachment. A bloated MVP can hide the truth for months.

MVP Learning Contract

Before building, write a learning contract. It keeps the MVP from turning into a small version of the dream product.

Contract Item	Answer
Question	What exact uncertainty are we testing?
Customer	Which segment will test it?
Behavior	What action would prove seriousness?
Scope	What is the smallest product or service that can test it?
Manual work	What will the founder do manually for now?
Time limit	When will we judge the result?
Continue rule	What evidence means continue or expand?
Kill rule	What evidence means stop or change?
Debt accepted	What rough edge are we knowingly allowing?

The learning contract should be visible to the team. When someone asks for another feature, compare it with the contract. If it does not improve the test, it waits.

MVP Scope Ladder

Use a ladder instead of arguing “build versus don’t build.”

Level	What You Do	When It Fits
1. Conversation	Test pain, buyer, and workflow.	You do not know the problem well enough.
2. Artifact	Show spreadsheet, mock, checklist, or workflow map.	You need reaction to a concrete approach.
3. Manual service	Do the work by hand.	Trust and workflow are messy.
4. Concierge product	Product plus heavy founder support.	You need usage and payment evidence.
5. Narrow software	Automate the repeated core.	Workflow repeats across customers.
6. Scalable product	Remove founder dependency.	Activation, retention, and support are understood.

Most founders want to start at level 5. Many should start at level 2 or 3. Manual does not mean unserious. Manual is often the fastest path to learning the truth.

MVP Experiment Log

Keep an experiment log from day one. Otherwise the company forgets why it built the MVP and repeats old arguments.

Field	What to record
Date	When the test started and ended.
Segment	Who the test was for.
Assumption	The risk being tested.
MVP format	Landing page, concierge, prototype, paid pilot, spreadsheet, or software.
Customer action requested	Call, data share, payment, usage, referral, workflow change.
Result	What customers actually did.
Learning	What changed in your understanding.
Decision	Continue, narrow, change, kill, or expand.
Next test	The next assumption to test.

The log should focus on behavior, not founder interpretation. “Five users liked it” is weak. “Two target customers shared real data and one paid for a pilot” is stronger. If the MVP did not create customer behavior, write that plainly.

Failed MVP Diagnosis

A failed MVP is useful when it tells you what failed.

Failure pattern	Possible meaning	Next move
People do not respond to outreach	Segment, pain, or message may be weak.	Narrow ICP and test a sharper trigger.
People take calls but do not commit	Pain may be interesting but not urgent.	Ask about current workaround, budget, and consequence of inaction.
People use once and disappear	Workflow fit or repeat value may be weak.	Study the moment after first use and test a habit trigger.
People praise but will not pay	Buyer value, trust, or pricing is unclear.	Run paid pilot or proposal test.
People pay but need heavy custom work	Problem may be real but not yet productized.	Document delivery steps and find repeatable core.
People churn after pilot	Value did not persist or success criteria were wrong.	Review actual usage, buyer proof, and onboarding.

Do not treat every failed MVP as proof the idea is bad. Sometimes the segment is wrong, the promise is unclear, the MVP type missed the risk, or the product required more trust than the test provided.

MVP To V1 Gate

Move from MVP to a real version one only after the evidence deserves it.

Use this gate:

Gate	Good sign
Segment	The same kind of customer responds repeatedly.
Pain	Customers describe a painful current workaround.
Commitment	Customers pay, share data, invest time, or change workflow.
Repeatability	The delivery steps repeat across customers.
Activation	Customers reach the core value without heroic explanation every time.
Economics	Manual work reveals a plausible path to margin.
Trust	Customers are willing to rely on the product or service for a real job.
Roadmap clarity	The next product work is obvious from evidence, not imagination.

If the gate is weak, stay in MVP mode. That does not mean delay forever. It means run a sharper test before turning a learning tool into a permanent product.

MVP Operating Rules

These rules keep the team honest:

• Every MVP has one primary learning goal.
• Every MVP has a review date before launch.
• Every MVP has a kill or continue rule.
• Every MVP has a written list of non-goals.
• Every manual step is measured for time, quality, and repeatability.
• Every customer-facing promise is something the team can actually deliver.
• Every strong signal is followed by a stronger ask: payment, data, repeat use, referral, or conversion.

The MVP is not the first chapter of the product fantasy. It is a truth machine. Design it to tell the truth quickly.

MVP Proof Ladder

Not all MVP signals are equal. Use a proof ladder to decide whether the evidence deserves more investment.

Proof Level	Signal	How To Treat It
1	Prospect says the idea is interesting.	Useful for language, not proof.
2	Prospect describes a painful recent example.	Problem may be real.
3	Prospect shares data, access, workflow detail, or team time.	Commitment is starting.
4	Prospect agrees to a specific pilot with success criteria.	Strong test opportunity.
5	Customer pays, uses, or changes workflow.	Real evidence.
6	Customer returns, renews, expands, or refers.	Evidence of durable value.

Move up the ladder deliberately. A founder should not spend months building because level-1 feedback felt encouraging. Ask for a stronger commitment after every promising signal: time, data, access, payment, workflow change, referral, or renewal.

For Indian B2B, a paid pilot with clear scope, invoice path, and buyer sponsor is much stronger than a friendly “let us try.” The paperwork and payment behavior are part of the signal.

MVP Learning Review

Do not end an MVP test with only a feeling. Hold a learning review within a few days of the test window closing. The goal is to decide what the evidence says, what it does not say, and what the next bet should be.

Use this agenda:

Review item	Question
Original assumption	What did we say we were testing?
Target segment	Did the people we tested with match the intended customer?
Customer behavior	What did customers actually do, not just say?
Commitment	Did they pay, share data, invite others, repeat usage, or change workflow?
Delivery effort	How much founder or team effort was required per customer?
Value proof	What outcome did the customer receive?
Trust friction	Where did customers hesitate, ask for proof, or need support?
Repeatability	Did the same pattern appear across multiple customers?
Surprise	What did we learn that was not in the plan?
Decision	Kill, change segment, change promise, run another MVP, or build V1?

The review should produce a written learning note. Keep it short:

We tested ______ with ______.
The strongest evidence was ______.
The weakest evidence was ______.
The biggest surprise was ______.
We will now ______.
We will stop or delay ______.

This habit compounds. After five MVP reviews, the founder should see patterns in customer pain, workflow, trust, pricing, and delivery effort. That record is more useful than a polished deck because it shows what the market taught you.

Kill, Continue, Or Change

Use explicit rules:

Decision	Use when	Next move
Kill the idea	Target customers do not show pain, effort, payment, or repeat behavior.	Archive learnings and move to a stronger problem.
Change segment	Some customers care deeply but they are not the segment you expected.	Rewrite ICP and run a sharper test.
Change promise	Customers care about the area but not the outcome you offered.	Rework positioning and test again.
Change MVP type	The test did not reach the real risk.	Choose a test closer to payment, usage, trust, or delivery.
Continue testing	Evidence is promising but still narrow or weak.	Ask for stronger commitment from the same segment.
Build V1	Commitment, repeatability, and delivery path are strong enough.	Convert learning into product scope and operating process.

The most common founder mistake is choosing “continue” by default. Continue only when the next test can produce stronger evidence than the last one. Otherwise you are avoiding a decision.

Reader Action

Write your MVP brief:

Section	Answer
Customer segment
Problem
Riskiest assumption
MVP type
Must-have scope
Manual work
Success signal
Kill or continue date

If you cannot name the riskiest assumption, do not build yet.

MVP Scope Ledger

An MVP fails when its scope silently expands. Founders start with one risk to test, then add nice-to-have features, edge cases, admin panels, analytics, integrations, automation, polish, and “just in case” work. By launch, the MVP is no longer minimum and the learning is delayed.

Create a scope ledger before building.

Category	Include now?	Rule
Core workflow	Yes	Must be needed to test the riskiest assumption.
Trust requirement	Yes if blocking	Include only what is required for the customer to try seriously.
Manual operations	Prefer yes	Keep manual if automation is not the risk.
Edge cases	Usually no	Handle manually unless common and dangerous.
Admin tools	Usually no	Use spreadsheets, scripts, or manual work first.
Integrations	Only if central	If integration is the risk, test it; otherwise delay.
Analytics	Minimal	Track the few events needed for the decision.
Visual polish	Enough	Earn trust, but do not hide weak value with polish.

For every requested addition, write:

Request:
Does it test the riskiest assumption?
What happens if we do not build it now?
Can we do it manually?
Will this delay learning?
Decision:

This forces a tradeoff. A good MVP is not ugly or careless. It is focused. It protects the learning goal from the founder’s fear of embarrassment.

The manual-first test

Before automating, ask:

• Has this workflow repeated across enough target customers?
• Do we understand the variations?
• Is manual delivery too slow, too expensive, or too error-prone?
• Would automation teach us more, or merely make us feel like a software company?
• Can a manual workflow become a product spec after ten real uses?

Many Indian startups begin with service-heavy execution because customers expect help. That can be useful if treated as learning. It becomes dangerous when the founder mistakes custom service revenue for product repeatability.

MVP decision threshold

Do not end an MVP with “people liked it.” End with a decision threshold:

Signal	Weak	Strong
Pain	General interest	Recent, specific, costly problem
Commitment	Praise or meeting	Time, data, access, money, workflow change
Usage	One-time curiosity	Repeat use in real workflow
Payment	Discounted experiment	Budget owner pays or commits
Delivery	Founder heroics	Process can repeat without chaos

If the signal is weak, either change the test or change the idea. Do not keep polishing a weak signal.

MVP Contract With The Customer

For a serious MVP, especially in B2B, write a simple customer-facing contract for the learning. This does not always mean a legal agreement. It means both sides know what is being tested.

Item	What to clarify
Problem	Which customer problem or workflow is being tested?
Scope	What the MVP includes and explicitly does not include.
Customer effort	Data, access, time, users, feedback, payment, or decision meeting required.
Success criteria	What outcome would make the customer continue, pay, renew, or expand?
Timeline	Start date, review date, and decision date.
Support model	What help the startup will provide and what is still manual.
Commercial expectation	Free test, paid pilot, refundable deposit, discounted first plan, or normal price.

This protects the founder from vague pilots. If the customer will not commit time, data, money, or a decision date, the MVP may be a demo disguised as learning.

From Concierge To Software

A concierge MVP is useful only if it creates a path to repeatability.

After each manual delivery, write:

Question	Why it matters
Which steps repeated across customers?	Repetition points toward product.
Which steps were custom?	Custom work may need pricing, rejection, or segmentation.
Which step created customer value?	Automate value, not internal busywork.
Which step created trust?	Some human trust may need to remain longer.
Which step created cost?	Margin can break even if customers love the output.
Which step can be standardized?	Standardization is often the bridge before automation.

Do not automate the first version of everything. First, understand the workflow. Then standardize. Then automate the parts where speed, accuracy, scale, or margin improves.

MVP Learning Report

At the end of an MVP cycle, write a one-page learning report.

Customer segment:
Riskiest assumption:
MVP type:
What we shipped or did manually:
Who used it:
What they did:
What they paid or committed:
What broke:
What surprised us:
Decision: kill / change segment / change promise / continue / build V1
Next test or build step:

The report should be uncomfortable if the evidence is weak. That is the point. An MVP exists to force a decision, not to produce a comforting story.

MVP Customer Debrief Script

The most valuable MVP learning often comes after the customer has tried the product, service, concierge workflow, prototype, or pilot. Do not ask only, “Did you like it?” That question produces politeness. Ask about behavior, alternatives, value, trust, and willingness to continue.

Use this script within 24-72 hours of meaningful use.

Thanks for trying this. I want honest learning more than praise.

1. What were you trying to get done when you used it?
2. What did you actually do step by step?
3. Where did you hesitate, get confused, or need help?
4. What was valuable enough that you would want again?
5. What felt unnecessary, annoying, risky, or unclear?
6. What would you use instead if this did not exist?
7. Who else would need to trust, approve, or use this for it to become part of your workflow?
8. What would make you continue for the next 30 days?
9. What would make you pay, renew, refer, or expand?
10. What would make you stop using it?

Do not defend the MVP during the debrief. If the customer misunderstood the product, that is learning. If they needed the founder to explain every step, that is learning. If they liked it but would not use it again, that is learning.

Debrief evidence table

After the conversation, write the evidence in this format:

Evidence area	What happened	Strength
Workflow	What the customer actually did, not intended to do.	Weak / medium / strong
Pain	Whether the original pain appeared during real use.	Weak / medium / strong
Value	What outcome the customer noticed or cared about.	Weak / medium / strong
Trust	What made them hesitate or believe.	Weak / medium / strong
Effort	Setup, support, training, manual work, integration, data, migration.	Weak / medium / strong
Commitment	Payment, next meeting, data shared, intro, repeat use, buyer involvement.	Weak / medium / strong
Repeatability	Whether this pattern could repeat across similar customers.	Weak / medium / strong

Founder interpretation rule

Translate the debrief into one of these decisions:

Debrief pattern	Interpretation	Next move
Customer used it, got value, and wants the next step	Strong MVP signal	Ask for stronger commitment and define V1 scope.
Customer liked it but did not change behavior	Interest, not validation	Test urgency, workflow fit, and switching cost.
Customer needed heavy founder help	Value may exist, delivery is not repeatable yet	Standardize manual steps before automating.
Customer wanted a different outcome	Promise may be wrong	Rework positioning or segment.
Customer would pay only after custom work	Product/service boundary is unclear	Revisit segment, pricing, and customization rules.
Customer found risk or trust blockers	Trust is part of the MVP	Add proof, security, accuracy, references, or onboarding.

The debrief should make the next build smaller and sharper. If every debrief produces a longer feature list, the founder is collecting requests instead of extracting evidence.

MVP Evidence Integrity Review

MVPs are easy to misread. Founders often turn weak signals into a strong story because they want permission to continue.

Run an evidence integrity review before declaring the MVP successful:

Evidence	Weak version	Stronger version
Interest	”This sounds useful."	"Can we try it with our data next week?”
Usage	User opened the product once.	User completes the target workflow repeatedly.
Payment	User says they would pay someday.	Buyer pays, signs, deposits, or commits budget.
Feedback	User suggests features.	User explains what changed in their workflow.
Referral	User says they know others.	User makes a specific intro or shares the product unprompted.
Pilot	Customer agrees to test.	Pilot has timeline, success criteria, owner, and decision date.

Ask:

• Which signal is real behavior, not opinion?
• Which signal came from the target segment, not friendly outsiders?
• Which signal would survive if the founder stopped pushing?
• Which signal connects to the eventual business model?
• What evidence contradicts the positive story?

If the MVP creates enthusiasm but no commitment, treat it as discovery, not validation. That is still useful. It tells you what to test next.

MVP Commercialization Gate

Before moving from MVP to V1, decide how the product will become a business.

Gate	Question
Buyer	Who pays or approves the workflow change?
Price logic	What unit of value can the buyer understand?
Delivery cost	What human effort, support, infrastructure, AI, or implementation cost is required?
Repeatability	Can similar customers use a similar version without custom rebuild?
Trust	What proof, security, accuracy, or support is needed before paying?
Sales motion	How will the next 10 similar customers be reached?
Retention	What makes the product worth using again after the first success?

Do not build V1 only because the MVP was fun to build. Build V1 when the MVP has revealed a path to repeated value, a buyer, and a business model that might survive real costs.

MVP Founder Decision Memo

At the end of each MVP cycle, the founder should write a short decision memo. The memo prevents the team from drifting into the next build just because momentum exists.

Use this format:

Field	What to write
Original assumption	The belief the MVP was designed to test.
Customer segment	Who actually used, paid, committed, or rejected it.
Workflow observed	What customers really did, not what they said they would do.
Strongest positive evidence	Payment, repeat use, referral, urgency, data shared, workflow change.
Strongest negative evidence	Drop-off, no budget, low urgency, trust gap, support overload, bad fit.
Manual work required	Founder/service/support effort needed to create value.
Business implication	What this says about pricing, sales, delivery, margin, and retention.
Decision	Kill, narrow segment, change promise, run another MVP, or build V1.
Next proof needed	The next evidence that would raise or lower confidence.

The decision should be written in plain language:

We learned that:
We still do not know:
We are deciding to:
We are not deciding to:
The next 14-day proof is:

Do not allow the memo to become a pitch deck slide. Its job is truth. If the MVP only proved that customers like the founder, say that. If the product created value but the delivery cost is too high, say that. If one segment loved it and another ignored it, narrow the next test.

Founders in India often run MVPs through relationships, warm introductions, services, pilots, or manual delivery. That is fine. Just separate relationship energy from product evidence. A friendly pilot is useful only when it reveals repeatable value beyond the founder’s personal push.

MVP Pricing Probe

An MVP should not only test whether people like the product. It should begin testing whether value can become money. Pricing does not need to be final, but the founder should avoid leaving willingness to pay as a vague future question.

Use a pricing probe during serious MVP cycles:

Probe	What to ask or test
Current spend	What do customers already spend in money, time, people, tools, errors, or delay?
Budget owner	Who can approve payment, and from which budget?
Value unit	Is value tied to users, transactions, revenue saved, risk reduced, time saved, location, seat, API call, or workflow?
Price anchor	What alternative cost does the customer compare this against?
Payment moment	When is the customer most willing to pay: before setup, after first value, after a pilot, monthly, annually, or usage-based?
Collection risk	In India, will payment be delayed by procurement, GST details, vendor onboarding, or internal approval?
Discount reason	Are discounts needed because price is wrong, value is unclear, trust is weak, or the segment is wrong?

Write the result:

The MVP suggests customers may pay for:
The buyer is:
The value unit is:
The likely pricing risk is:
The next pricing proof is:

Do not confuse “too early to price” with “too afraid to discuss money.” For B2B, even a small paid pilot, deposit, LOI with commercial terms, or written budget confirmation is stronger than another round of praise. For consumer products, watch whether users spend scarce attention, invite others, repeat behavior, or pay for a narrow premium action.

Related Links

• 34. Product Thinking
• 36. Product Discovery
• 40. Product-Market Fit
• 135. MVP Scope Playbook