The Minimum Viable Product is one of the most misunderstood concepts in product development. Teams either build too much (a "minimum" product with 40 features) or too little (a landing page that tests interest but not the actual experience). Design thinking provides the framework for scoping an MVP correctly: build the smallest thing that tests your riskiest assumption about whether real users will find real value in your solution.

An MVP is not a small product — it is the result of systematically filtering ideas through validation

What an MVP Actually Is

Eric Ries defined the MVP as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." The key words are "validated learning." An MVP is not a small product. It is a learning tool that happens to be a product.

The MVP answers one question: "Will people use this to solve a real problem?" If the answer is yes, you have evidence to invest in building more. If the answer is no, you have learned something valuable at low cost. If you cannot determine the answer from your MVP, your MVP was poorly designed.

This is where design thinking becomes essential. Without understanding the user problem deeply (through empathy research), you cannot identify the riskiest assumption. Without clearly defining the problem (through the Define stage), you cannot scope the MVP to test the right thing. And without prototyping and testing before building, you risk building an MVP that tests something nobody cares about.

Prototypes vs MVPs

Design thinking prototypes and Lean Startup MVPs are related but distinct:

A prototype tests desirability and usability. "Do users want this? Can they use it?" Prototypes do not need to be functional. Paper mockups, clickable wireframes, and simulated interfaces are all valid prototypes. They are tested in controlled settings with small groups.
An MVP tests viability. "Will users adopt this in real life? Will they pay for it? Will they come back?" MVPs must be functional enough for real-world use. They are tested in the actual market with real users making real decisions.

The design thinking process should produce a validated prototype before you build an MVP. The prototype validates that the concept is desirable and usable. The MVP validates that it is viable. Skipping the prototype phase and going directly to MVP means you are testing viability of a concept that might not even be desirable. This is the most common reason MVPs fail.

The Design Thinking + Lean Startup guide explores this relationship in detail.

Using Design Thinking to Scope Your MVP

Step 1: Identify the Core Job

From your empathy research and Jobs to Be Done analysis, identify the single most important job your product helps users accomplish. Not the three most important jobs. One. Your MVP should do that one job well. Everything else is feature creep.

A project management tool's core job might be "help me see what everyone on my team is working on today." Not "manage projects, track time, generate reports, and integrate with 15 other tools." The MVP tests whether solving that one job provides enough value for users to adopt the product.

Step 2: Map the Critical Path

Using your journey map, identify the minimum set of steps a user must take to accomplish the core job. These steps define the MVP's scope. Every step that is not on the critical path is out of scope for the MVP.

For the project management example: sign up, create a team, invite members, each member updates their status, view the team dashboard. That is five steps. The MVP needs to support exactly these five steps and nothing else.

Step 3: Define the Riskiest Assumption

Assumption mapping reveals which beliefs about your product are most uncertain and most critical. Your MVP should test the riskiest assumption first.

For the project management example, the riskiest assumption might be: "Team members will voluntarily update their status every day without being forced to." If this assumption is wrong, the entire concept fails. The MVP should be designed to test specifically whether people will actually update their status when no one is making them do so.

Step 4: Choose the Minimum Implementation

For each step on the critical path, choose the simplest possible implementation. This is where design thinking's prototyping mindset helps. You do not need the perfect solution. You need a solution that works well enough to test the riskiest assumption.

User accounts? Start with email/password. OAuth integration can come later.
Beautiful dashboard? Start with a functional list view. Visual design refinement can come later.
Mobile app? Start with a responsive web app. Native apps can come later.
Notifications? Start with email. Push notifications can come later.

What Makes an MVP Fail

Most MVP failures fall into predictable categories:

Testing the wrong assumption. The MVP validates something that was never in question (yes, people like dashboards) while ignoring the real uncertainty (will they update their data?). Design thinking's problem definition work prevents this by clarifying what you actually need to learn.
Building too much. Fear of launching something imperfect leads to scope expansion until the "minimum" product has 20 features and took 6 months to build. At that point, it is no longer minimum, and the learning cost of failure is high.
Building too little. A landing page with a "sign up for early access" button tests interest, not viability. It tells you people are curious, not that they would use or pay for the product. An MVP must deliver enough real value for users to evaluate whether the product solves their problem.
No measurement plan. An MVP without metrics is just a small product. Before launching, define what you will measure, what constitutes success, and what constitutes failure. "We will consider this validated if 40% of users update their status at least 3 times in the first week."
No iteration plan. An MVP is the beginning of a learning loop, not a one-shot test. Before launching, decide: if the results are ambiguous, what will you test next? If the results are negative, what will you change? If positive, what will you build next?

The MVP Quality Debate

A common criticism is that MVPs excuse low-quality products. This misunderstands the concept. "Minimum" refers to scope, not quality. The features you include should work well. The design should be usable. The experience should be coherent. You are cutting breadth (number of features) not depth (quality of each feature).

Design thinking prototyping and user testing ensure that the features you include in the MVP are actually usable. A buggy, confusing MVP does not test your hypothesis. It tests your users' patience. You cannot learn whether users want your product if they cannot figure out how to use it.

After the MVP: Interpreting Results

MVP results require interpretation, not just measurement. Some patterns to watch for:

Strong adoption, low retention. Users try the product but do not come back. The concept might be right but the execution needs improvement. Go back to the Test stage to understand what disappointed them.
Low adoption, strong retention. Few users sign up, but those who do love it. You have a positioning or distribution problem, not a product problem. The product works; you need to find better ways to reach the right users.
Users using the product differently than intended. This is often the most valuable signal. If users adopt your project management tool but use it for personal to-do lists instead of team coordination, you may have found a different (and possibly better) product than the one you set out to build.
Users requesting the same missing feature repeatedly. When multiple users independently ask for the same thing, you have found your next development priority. This is market-driven roadmap planning.

MVP for Different Contexts

The MVP approach adapts to different situations:

For startups: The MVP is often the first real product. The riskiest assumption is usually about market demand. Build the minimum that proves people will use and pay for your solution.
For enterprise teams: The MVP is often a new feature within an existing product. The riskiest assumption might be about internal adoption. Build the minimum that proves the organization will change its workflows to use the new capability.
For nonprofits: The MVP is often a new program or service. The riskiest assumption might be about beneficiary engagement. Build the minimum that proves people will participate and benefit.

The MVP is where design thinking's empathy meets the market's indifference. Get it right, and you have a learning engine that compounds insight with every iteration. The combined Design Thinking and Lean Startup methodology provides the broader framework for this cycle. Before building, rapid prototyping lets you validate desirability at a fraction of the cost. Assumption mapping ensures you are testing the beliefs that actually matter, and measuring design impact gives you the metrics vocabulary to interpret what your MVP data is telling you.