The first step is always to listen to the voice of the customer. The voice of the customer directs you to the problem, and eventually to the solution.
MVP experimentation is not about building a minimal product once and calling it a day. It is an ongoing process of learning and validating that guides you from a hypothesis to a product customers actually want. The trap is treating MVP as a checkbox exercise instead of a rigorous experiment.
The actual job is to listen carefully to the customer’s voice, form assumptions, and then systematically test those assumptions with minimum investment. This approach reduces risk and sharpens your product decisions.
The voice of the customer is your starting point
Before you build anything, you must understand the problem you are solving. That means listening to real users — their pain, their context, their motivations.
Ask yourself:
- Who will buy this product?
- Why will they buy it?
- How will they buy it?
Uber’s founder noticed a real problem: premium black cars were too expensive to rent or lease from local taxi companies. This insight shaped their solution.
Product discovery workshop
You (PM): “Who exactly are our customers? What are their pain points?”
User Researcher: “We heard from office goers that timely rides in premium cars are hard to get.”
You (PM): “Why do they care about timeliness more than price?”
User Researcher: “Because they often have important meetings and can’t afford delays.”
This conversation anchors the problem before jumping to solutions.
Understanding the customer's context is non-negotiable before solutioning.
Prioritize your assumptions by risk
Once you have a problem and a rough solution set, you have made many assumptions — about customers, their needs, and how your product meets those needs.
It is vital to identify and rank these assumptions by how risky they are. A risky assumption is one that, if false, could derail your entire product.
User personas help here — they give you a detailed picture of your target audience and their context.
For example, Uber assumed that timeliness was the most important attribute for office-going millennials. That was a risky assumption worth validating early.
Hypotheses must be testable and measurable
Assumptions are guesses. Hypotheses are assumptions made concrete — measurable, actionable, and with a clear outcome.
The difference is crucial:
| Hypothesis | Assumption |
|---|---|
| Actionable | Not actionable |
| Measurable | Not measurable |
| Has a target audience | No target audience |
| Has an impactful outcome | No outcome |
| Example: We believe millennials will be indifferent to price changes because they belong to a higher income group. We will know we're right when the number of customers who are millennials remain unchanged. | Example: Millennials are less sensitive to price changes |
Your MVP experiment revolves around validating or invalidating these hypotheses.
Define success criteria to validate hypotheses
Every hypothesis needs minimum criteria for success — the break-even point that determines if your assumption holds.
These criteria are your north star metrics for the experiment.
Begin by listing costs involved (wages, materials, branding) and expected rewards (revenue increase, customer rating, lifetime value).
For example, if your hypothesis is that users will pay ₹200 more for faster service, your success criterion might be a 20% conversion at that price point in your MVP test.
| Minimum Criteria for Success | Data Source | How will data be collected | Who collects | When collected | Sample size | Collected? |
|---|---|---|---|---|---|---|
| Customer satisfaction | Survey results | In-app survey | External firm | Week of May 1 | 100 users | No |
| Revenue increase | Financials | Manual tracking | Priya | May 1 - May 30 | Full cohort | No |
This plan ensures you know exactly what data to capture, when, and how.
Choose MVP techniques that fit your test
The goal of an MVP is not to build a fully polished product but to test your core hypothesis quickly and cheaply.
There are various MVP testing techniques:
- Piecemeal MVP: Use existing tools or components to simulate a feature.
- Email MVP: Gauge interest or validate a concept through email campaigns before building.
- Concierge MVP: Provide a manual service to simulate the product experience.
- Wizard of Oz MVP: The product looks automated but is manually operated behind the scenes.
Your choice depends on what you are testing and your resources.
Product team discussion
You (PM): “To test whether timeliness matters, can we run a concierge MVP where drivers call customers to confirm ETA?”
Engineering Lead: “That avoids building an app upfront.”
You (PM): “Exactly. We want to learn before we invest heavily.”
Choosing the right MVP technique saves time and money while maximizing learning.
Plan and execute your MVP experiment with rigor
With your hypotheses, success criteria, and MVP technique ready, you must plan the experiment execution carefully.
Data collection is critical:
- What data will you collect?
- How much data is needed for statistical significance?
- When and how will data be collected?
- Who is responsible for collecting and validating it?
For example, if customer satisfaction is a success criterion, plan a survey with a clear timeline and ownership.
Gather feedback and iterate continuously
Launching your MVP is just the start. Early adopters and enthusiasts provide valuable feedback.
Collect feedback through:
- Surveys (Qualtrics, SurveyMonkey, Google Forms)
- Live chat sessions on your platform
- Direct calls or interviews with customers (less scalable but sometimes insightful)
Use this feedback to:
- Validate or invalidate your hypotheses
- Surface new problems you hadn’t anticipated
- Form new assumptions and hypotheses for the next iteration
Product development is a continuous loop of learning and improving.
Test yourself: MVP prioritization challenge
You are a PM at a Series A Indian startup building an on-demand premium car rental app. Your riskiest assumption is that office goers prioritize timeliness over price. You have a limited budget and a small pilot user base of 100 customers.
The call: How do you design an MVP experiment to test this assumption? What MVP technique do you choose, what metrics do you track, and how do you plan data collection?
Your reasoning:
You are a PM at a Series A Indian startup building an on-demand premium car rental app. Your riskiest assumption is that office goers prioritize timeliness over price. You have a limited budget and a small pilot user base of 100 customers.
Your task: How do you design an MVP experiment to test this assumption? What MVP technique do you choose, what metrics do you track, and how do you plan data collection?
your reasoning:
Field exercise: Design your MVP experiment (20 min)
Pick a product idea you are currently working on or considering. Follow these steps:
- Identify the core problem by listening to the voice of your customer.
- List all assumptions you have about the problem and solution.
- Rank these assumptions by risk.
- Build testable hypotheses for the riskiest assumptions.
- Define minimum success criteria for each hypothesis.
- Choose an MVP technique suitable for testing these hypotheses.
- Plan your data collection: what, how much, when, and who.
- Outline your plan to gather feedback and iterate after launch.
Document your answers in a shared doc or notebook. This exercise will sharpen your ability to plan MVP experiments rigorously.
Where to go next
- If you want to deepen your user research skills: User Research Methods
- If you want to learn how to translate strategy into a product vision: Product Vision and Strategy
- If you want to practice prioritization and decision-making: Prioritization Frameworks
- If you want to learn about metrics and measuring success: Metrics and KPIs
PL alumni now work at Flipkart, Razorpay, Swiggy, PhonePe, and dozens of other companies.