When Your MVP Misses the Mark

How do you know when a minimum viable product is too minimal, and what can you do about it? 

This comes up a lot during custom application projects, and we have found it helpful to review what an MVP is, how to develop it, and how to use it to set up your project for success.

What is an MVP?

An MVP is a version of a product or application that is not completely developed, but can be deployed and used in production. The benefit of an MVP is that you generate feedback and have a workable version earlier in the project life cycle. The challenge is that you can run the risk of underwhelming your stakeholders and affect their support for the project.

When is an MVP useful?

An MVP tends to be useful when a project has either a time constraint or a budget constraint. 

A time constraint tends to be easier because stakeholders are usually happy to just have something that works. In this case, your MVP is meant to demonstrate basic functionality, and everyone usually understands that there is a plan to build out the full application at a later time. A time constraint could also mean that you’re scrambling. Maybe the product is going to market, or the scope changed. 

A budget constraint is the more complicated and interesting conversation because it tends to be more difficult to agree on how to demonstrate value. When this happens, the goal is to get as much development as possible within that budget. 

All of these considerations factor into how “minimal” the MVP should be. Determining what belongs in the MVP comes down to the client’s needs. If you have a reasonable budget and aren’t scrambling on the timeline, you can typically add lots of bells and whistles before the first release. If your goal is to make a splash at release, you’ll tend to augment it a lot more. Just remember, that at that point, you’re not releasing an MVP.

What’s the difference between an MVP and a proof of concept?

Sometimes people refer to an MVP, but they really mean proof of concept. A proof of concept is a demonstration that an idea can work. An MVP is something that works and is released, but what one person considers minimum and viable might not be what someone else thinks. 

The goal of a proof of concept is to answer some preliminary questions that your project might be dependent on later in the dev cycle. Sometimes you have to go down a certain road to test whether components work together, whether data integrates properly, etc., before you build the next phase of the project. You’re trying to make an informed decision and you don’t have enough info yet. Can it even function, will it meet your needs, and are you willing to take on this much burden? 

An MVP solves similar problems. It’s meant to help answer the question of whether your functionality will achieve your goals at that stage of the project. It’s meant to provide feedback. The biggest difference is that it is intended to be deployed in a live environment. 

It’s very rare that something isn’t doable. Maybe it isn’t doable while integrating with your current tool, or maybe that tool can’t perform up to spec, but it usually will work.

What happens if the MVP is too minimal?

One of the most frequent challenges of developing an MVP is striking a balance and including the right things to still impress your stakeholders. The technical requirement of an MVP is often functionality driven. 

Sometimes what impresses the user can feel unimpressive to the person building it. Some things make sense to the engineer or developer, but aren’t enough of a guide for the user. The development team might put a lot of work into functionality, but the stakeholder might be focused on something else. When that happens, the user can lose faith in the product and question your ability to develop the fully functional version. 

There can also be some miscommunication or mismatched expectations. For instance, suppose the development team spends a lot of effort to connect the APIs of several applications to display data from lots of sources in a single place. But maybe the MVP only includes a table for displaying that data, and it isn’t very easy for the end user to read. The developers might be proud of their work to funnel that data (and rightly so), but the user only notices that it’s hard to read because they don’t know the work that it took to get to that point. 

To prevent this from happening, you need to put yourself in the shoes of the people that you need buy-in from, and think about what their experience is going to be. Sometimes that can be hard, but it’s critical. You can’t succeed if you’re not telling the right story to the people that need to buy in. 

Spending that little extra time to polish something in an interface or user design can go a long way to prove that the application works as intended. It can be something small. You can miss the forest for the trees if your goal is just, “Yes, it works.” That’s why it’s important to agree on the story of what the app is supposed to do.

How can you bridge the gap?

Few would question the need to connect the function and the end user in a meaningful way, but there isn’t always agreement about who’s responsible for that connection. This is where a business analyst (BA) can help. A BA can act as an intermediary between the project stakeholders and the development team. One of their responsibilities is to understand both the technical requirements and the stakeholders’ perspective, and bridge that gap. By doing so, they can prevent things from getting lost in translation. (Forbes has a good article on the role of a business analyst if you’d like to learn more.)

If you don’t have a BA, you can usually lean on the vendor. They should have the expertise to guide you based on past successes. Giving the vendor access to the stakeholders can also help the process and allow them to confirm the project requirements directly. Otherwise, it’s guesswork that can put you in a difficult spot because you’re not clear on what’s important. If a vendor is not concerned about sharing their expertise, then they’re failing their customer. 

Once you know what the stakeholders care about, the entire team can point to why you made the choices you did. You can collaborate, build excitement, and generate consensus. That gives you some flexibility so that maybe you don’t have to get it exactly right the first time. If you come back to your stakeholders without having gathered their input and provide an application that doesn’t match up with their needs, then you damage your credibility. Just a couple of extra questions could have completely changed the narrative.

Any other tips for an MVP to succeed?

• Understand the problem you’re solving
• Understand your purpose and constraints 
• Understand the perspective of the people you’re solving for
• Generate some consensus ahead of time 

Getting feedback is the only real way to succeed. Iteration is healthy. An MVP is how you get that process off the ground. 

---

Relevant Resources: 

• Taking Your App from V1 to V2: Planning for the Initial Launch & Future Iterations
• FAQs: Development Timelines for Medtech Apps
• Why We Provide Direct Communication with Our Developers to Clients