MVP isn’t just a startup trick—it’s a mindset that helps portfolio-level delivery stay adaptive, evidence-based, and ruthlessly focused on value.

The term Minimal Viable Product (MVP) is used in many different ways today, often depending on the context in which it’s applied. Originally popularized by Eric Ries in "The Lean Startup", the MVP was introduced as a strategy for startups seeking product-market fit. It provided a way to test hypotheses about customer needs with the least amount of effort necessary to generate validated learning.

While rooted in startup thinking, MVP has since been adopted far beyond that context—particularly within larger organizations managing portfolios of initiatives, where innovation, speed, and feedback-driven learning are critical. This expansion isn’t inherently problematic—but it has led to confusion. MVP now carries multiple interpretations, which can hinder clarity and alignment across teams and stakeholders. Differing assumptions about what qualifies as “minimal” or “viable” often result in misaligned expectations between product teams, business sponsors, and customers. What one group sees as a valuable learning opportunity, another may see as incomplete or insufficiently polished.

Despite these challenges, MVP remains a powerful concept because it encourages organizations to:

• Focus on customer and business outcomes, not just outputs
• Treat learning as a valuable form of progress
• Embrace iterative, incremental delivery consistent with lean-agile approaches
• Reduce risk through early validation, enabling decisions to pivot, persevere, or stop
• Build only what customers actually need by leveraging early feedback
• Demonstrate progress and value, giving stakeholders confidence and evidence to justify further investment

While these characteristics are clearly valuable, context matters. To apply MVP effectively, we must tailor its use to the situation at hand. In this discussion, we are applying MVP thinking specifically within the portfolio management process.

Let’s assume we have an approved Epic with a defined Business Case. The Epic enhances an existing product or solution—something new and promising, but not entirely unfamiliar. We already have some understanding of how customers use the product and how it generates revenue.

The Business Case represents a significant investment opportunity and the potential for meaningful return. As part of its development, we identify several high-level MVP experiments. These early MVPs are intended to address the key risks and uncertainties associated with the Epic before committing major resources. Specifically, we explore:

• Desirability – Do customers or users want this solution? Does it align with our strategy?
• Feasibility – Can we realistically deliver the right solution through build, buy, partner, or acquisition options?
• Viability – Will the approach generate substantially more value than cost?
• Sustainability – Can the solution evolve across its product-market lifecycle?

Each MVP is designed with a clear learning objective: what critical assumption are we trying to validate (or invalidate)? We often need multiple MVPs, each targeting a different type of risk - technical, market, financial, or operational.

This early-stage thinking is critical. It prevents a “big bet” mentality where large investments are made on unvalidated assumptions. MVP thinking at the Business Case stage allows portfolio investments to progress iteratively, adapting as we learn rather than following a single, high-risk delivery cycle.

Once the Epic is approved, we plan how to systematically validate assumptions through execution - typically by breaking the Epic down into more detailed (Program) Features.

These Features aren’t arbitrary slices of functionality. They’re shaped by the MVPs we’ve defined and the learning objectives we’ve outlined. In other words, we prioritize and implement Features that help us validate assumptions, reduce uncertainty, and incrementally realize value.

This is where MVP continues to guide us: decomposition from Epic to Feature becomes strategic, not just functional. To apply MVP thinking effectively, we use different techniques depending on the type of risk being addressed.

For Desirability, we focus on customer validation. One powerful tool is a Story Mapping exercise, which visualizes how the product might be assembled from the customer’s perspective. It helps define:

• A minimal horizontal slice through the solution—capturing a core workflow or journey—delivered first to test interest. This becomes the Epic’s first Feature.
• A high-level view of the full solution, surfacing the most important elements to inform the remaining Features.

Each Feature then becomes a learning checkpoint - an opportunity to validate, adjust, or stop based on evidence.

For Feasibility, we explore technical risk. This might involve new technologies or system changes. We create Enabling Features that test different technical paths. These often take the form of vertical slices through the architecture to validate scalability, performance, or integration.

Critically, these two tracks - Desirability and Feasibility - often run in parallel, enabling faster learning by testing both customer and technical assumptions simultaneously.

Each MVP experiment leads to new understanding and a decision point - continue (persevere), change course (pivot), or stop.

MVP also applies where there’s no traditional user experience - such as data pipelines, internal platforms, or automation. In these cases, Desirability is reframed in terms of stakeholder or system outcomes: improved accuracy, processing speed, or operational efficiency. MVP might look like a simplified pipeline that processes one dataset end-to-end, validating integration and performance assumptions early.

Work done to reduce Desirability and Feasibility risks often informs our understanding of Viability and Sustainability. By aligning learning activities with business needs, we:

• Minimize investment by focusing only on what matters
• Accelerate time-to-market through early direction validation
• Reduce waste and rework by grounding decisions in reality

Once key risks are validated, we shift focus from learning to delivering value at scale. This marks the transition from the MVP phase to full implementation—from discovery to delivery.

Now the Epic is realized through a series of (Program) Features. These Features are no longer learning experiments. Instead, they:

• Build on validated insights
• Deliver incremental customer or business value
• Are evaluated for their contribution to outcomes - not risk reduction

At this point, we transition from Features as experiments to Features as value streams:

As delivery progresses, portfolio stakeholders should regularly assess marginal return—what value we get from each additional Feature. Often, the first 60–80% of the Features deliver most of the value. Beyond that, returns diminish.

This is where we apply the principle of “trimming the tail.” Instead of completing every planned Feature:

• Have we delivered enough to meet the original objectives?
• Are the remaining Features still the best use of our limited capacity?
• Could this effort deliver more value elsewhere?

By recognizing when we’ve delivered “enough,” we avoid over-engineering, shorten time-to-market, and maximize throughput.

MVP thinking doesn’t stop once risks are reduced. It evolves into a habit of continuous value evaluation, ensuring that portfolio investments stay grounded in evidence and aimed at outcomes.

MVP is not just a product technique - it’s a portfolio mindset. One that turns ideas into outcomes through learning, adaptation, and focus.

• Eric Ries in "The Lean Startup" - The original source of the MVP concept.