Finding MVP

Just like finding Waldo in a crowded picture book, finding the MVP (Minimum Viable Product) in a sea of stakeholder requests is about cutting through the noise to spot what truly matters.

Photo by Marten Newhall on Unsplash

🛫 Introduction: More Doesn’t Always Mean Better

As a Business Analyst, one of my recurring experiences during project kickoffs or requirement-gathering sessions is the long wishlist of features that stakeholders present. They come in enthusiastic, sometimes overwhelmed, with a feature-rich vision that includes everything they believe users want.

But here’s the twist: most of those features aren’t actually needed to launch.

This is where Minimum Viable Product (MVP) thinking comes in, and it’s not just a product management term. It’s a crucial mindset shift for analysts, developers, designers, and decision-makers alike.

💡 What Is an MVP — Really?

The Minimum Viable Product (MVP) is the smallest version of a product that can be released to solve a specific user problem, deliver value, and collect feedback. It’s not a half-baked product or just a landing page. It’s a focused version of your product with just enough functionality to:

• Validate assumptions
• Solve one core problem
• Engage early adopters
• Learn from user behavior

🎯 Common Stakeholder Pitfalls

Here are three patterns I’ve seen when working with stakeholders:

1. “Let’s Add Everything Now”

Many stakeholders believe more features = more value. But overloading early versions delays release and increases complexity.

🛠️ BA Tip: Use prioritisation techniques like MoSCoW (Must have, Should have, Could have, Won’t have) to bring focus.

2. “If One User Asks, Let’s Build It”

One-off requests from power users can quickly become scope bloat if not weighed against actual product goals.

🛠️ BA Tip: Ask, “How many users are affected?” and “Is there a workaround?” before jumping into solutions.

3. “This Is How Competitor X Does It”

Emulating competitors is tempting, but their business model, audience, or maturity may differ entirely.

🛠️ BA Tip: Bring conversations back to your product’s unique value proposition and business objectives.

These conversations are not bad; they show vision and passion. But shipping a bloated product is not the same as shipping a useful product. As BAs, our job is to challenge assumptions, uncover true business needs, and keep the team focused on solving the right problem first.

🚦How I Guide Stakeholders to MVP

Over time, I’ve built a structured approach that helps stakeholders confidently decide what goes into the MVP and what can wait. Here’s how I break it down:

1. Start with the Problem Statement

Before diving into feature requests, I ask:

• What’s the core problem we’re trying to solve?
• Who is experiencing it?
• What’s the impact of not solving it?

🎯 If we can’t articulate the problem clearly, we can’t define the MVP.

2. Identify Your Primary User

You might have 5 personas, but for MVP, pick one.

Example: If we’re building an internal tool for HR and Finance, we may choose to serve HR first, and roll out Finance functionality in version 2.

3. Map Features to Value

I often lead a feature-value mapping session using tools like:

• MoSCoW Method (Must have, Should have, Could have, Won’t have)
• Impact vs. Effort Matrix
• User Story Mapping

This helps reveal which features:

• Solve the core problem (keep)
• Support future use cases (maybe)
• Are unnecessary for now (cut)

4. Validate with Scenarios

Instead of debating features, we walk through real-world scenarios:

“If the user signs up, how do they complete their main task? What’s essential at each step?”

This storytelling approach exposes unnecessary complexities quickly.

5. Document and Align

I always document what the MVP includes, and more importantly, what it doesn’t include yet. This becomes a reference point to prevent scope creep and keep the development team focused.

OR…

In stakeholder sessions, I usually frame the MVP this way:

“If we had to launch next week, what’s the one thing this product must do to be useful?”

Then we:

• Map features to core problems
• Validate assumptions with real data or interviews
• Remove anything that doesn’t directly support the product goal

This has helped me shift conversations from “Can we build this?” to “Should we build this now?”

🛡 Bonus: This also helps when management or stakeholders say “Let’s just add this one more thing…”

📈 Why MVP = Speed, Clarity, and Feedback

MVPs allow teams to:

• Ship faster
• Learn from users early
• Avoid overengineering
• Focus on outcomes, not output

Launching a lean MVP is not a shortcut; it’s a smart path to product-market fit.

🧠 Realisations from the Field

🔸 Stakeholders want impact, not just features. When we frame decisions around user value and business goals, they are more open to narrowing scope.

🔸 Less truly is more. A small but usable product gives faster feedback and builds momentum. MVP isn’t about doing less. It’s about doing what matters first.

🔸 MVP is not a phase — it’s a mindset. Even post-launch, MVP thinking helps teams iterate without bloating the product unnecessarily.

🚀 Final Thoughts: MVP Is a Team Sport

Finding the MVP isn’t just a BA responsibility, it’s a collaborative effort across product, design, engineering, and stakeholders. But as Business Analysts, we play a critical role in:

• Asking the right questions
• Challenging assumptions
• Prioritising value over volume

So next time you’re handed a long wishlist, don’t panic, listen, probe, prioritise, and help your team build less, but better.

“Every feature you don’t build is a feature you don’t have to support, maintain, and test.” — From every exhausted developer

Enjoy the read? Connect with me on LinkedIn