What is an MVP?

Introduction

Recently I’ve written a comparison between two of my personal apps, both are quite simple MVP-type apps. I’ve also talked about how maintaining a piece of software over multiple years can be trickier than you might expect, in some situations. I’ve also talked about how it’s often the case that communication between a founder and the team they get to initially build some software for them can be less than amazing. All of which got me thinking, if MVP is the generally accepted as a point of entry into the world for most startups…

• what is an MVP?
• and what are the other alternatives to an MVP?

What is a Minimum Viable Product (MVP)?

A Minimum Viable Product (MVP) is a basic version of a product that includes only the essential features necessary to launch to early adopting customers. Then, the idea is the users provide feedback for future development. The idea behind an MVP is to quickly bring a product to market, test assumptions, learn from real users, and make improvements without investing a lot of time or money upfront.

Ok, so what does that mean?

An MVP is…

• Built quickly.
• A simple version of a product with the bare minimum functionality and without all the bells and whistles of an established product.
• Basic Looking.
• Low cost.

An MVP isn’t…

• The full product.
• Perfectly designed.
• Very expensive.

I’ll talk about this later, but I think a lot of the time the thing people get wrong is to spend too much time and money on getting the look absolutely correct, or putting too much functionality into it.

What are we trying to do by making an MVP?

• Build a skeleton product that fixes only one core problem a user will have.
• Get user feedback from real users.
• Do it quickly.
• Do it cheaply.

An MVP is about testing if something should be built, addressing market demand and the needs of our early adopting users.

What comes next when the MVP is built?

After the MVP, if the MVP goes according to plan, and we like the feedback we can then choose to expand the MVP.

The feedback is one of the most important things here though. If people don’t like the software, or it doesn’t solve their problems any better than anything else, or there is a boatload of competition, those factors need to be listened to. The whole point in starting off small and fast is to see if it could potentially be a full-blown product. Or, if it was nice in theory, but no, thanks.

If you don’t care about user feedback why are you building an MVP?

Everyone starts off with an MVP. But, it comes down to why again, as it always does. In this case, why are they starting off with an MVP? They are starting off with an MVP, or they should be, to get the valuable user feedback.

If you think you know that your product will be amazing, and don’t really need any feedback, you just want to build the software, then you’re in a different situation to the MVP crowd. While the MVP should be almost thrown together speed-wise, if you’re starting off building your finished product but in stages, there are different factors to consider.

Maybe you’re saying my “MVP” is just stage one, and I already have all the stages mapped out in my brain. If this is the case, do you also want it to look like the final product from the beginning? So, already we’ve added some time/money to the project. Do you also want to build it in a similar way to how a piece of software with a small team of developers would be? If that’s the case, you may be looking at more time.

Questions to consider/ask when discussing building an MVP

• Do I want it to look pretty?
• Do I want it built in a way that a team may want to build it, or do I just want something quick and dirty?
• Do I care about feedback?
• What am I paying for?
• Is what I’m being sold what I want?

What are the other alternatives to an MVP?

Instead of diving straight in with an MVP, which can be expensive and can often overrun time-wise, consider some other options. An MVP might not be what you’re after…

Proof of Concept (PoC)

The primary goal of a PoC is to test whether an idea is feasible. It’s used to validate that a particular concept, technology, or approach can actually work as intended. It would be for internal use-only, not for external users. Typically faster/cheaper than an MVP.

Prototype

A basic, often non-functional version of your product that visually demonstrates the core features, interface, and flow. Faster/cheaper than an MVP.

Explainer Video

A short video that visually explains the problem, solution, and value of your product concept without actually building it. This might be useful if you are also looking for investors or are trying to attract people to your startup.

Landing Page and/or Ad Campaign Testing

A simple website that explains your product idea, features, and value proposition. It may include sign-up options, for a newsletter, say, or some other call-to-action (CTA) to gauge interest. I.e. if I market the product in the way I want to will there be a demand for it? To drive traffic to the website you may use an ad campaign.

Concierge or Wizard of Oz Test

A test where you manually perform the service or simulate the product’s functions behind the scenes without automation. Netflix started off by mailing out DVDs, then moved onto streaming, maybe you can do something similar. This works particularly well with a manual process when the idea of the product would be to automate something.

Pre-Sales or Crowdfunding Campaign

A campaign to raise funds or pre-sell a product idea on platforms like Kickstarter or Indiegogo.

Customer Interviews and Surveys

Direct conversations with potential customers to discuss their pain points, current solutions, and response to your idea.

Single-Feature MVP (aka Pre-MVP)

Develop just one core feature (the most essential) that addresses the primary problem you want to solve. Unlike a full MVP, this is stripped down to the absolute basics. You may not even have individual user accounts, for example, just the pure functionality you want to examine.

Mistakes and Miscommunication with MVPs

I’d say many mistakes I’ve seen with MVPs have come down to miscommunication.

Having a clear idea of exactly what it is you want, and why, is the first step. Then, if you are non-technical, work with people you trust to find the best way to get to tha point.

Is it just an MVP?

If it’s just an MVP you have to be laser-focussed on time and money. What is being built and do I want it all? Whoever is building the software will want to make it the way they want to build it, but you have to be firm about what it is you actually want. And also, how often will you get feedback about how things are going? Unless you’re getting daily briefings, you should really trust these people.

Something else that can happen is that at the beginning it starts off as an MVP, then over time extra bits get added on and the scope of the project morphs into something else. As the client or the founder, it is your responsibility to make sure this doesn’t happen. If they ask you if you want something, you might like the idea of it, but if it’s not in the original plan it’ll slow the project down and/or make it more expensive.

Is it more than an MVP?

If it isn’t an MVP, it’s more like step one on the ladder to being a proper company, then that should be identified too. Do you want to start off with an agency? Or, would it be better to start off with one person who can build it then become a Lead Developer?

In this case, there are completely different things to consider because you’re going for longevity and considering steps two and three. If you know from the start there is likely to be many different types of users, or use cases, then if it’s more than an MVP, you may decide to make it very flexible from the start.

Making the perfect product for one User

Another issue that can arise with MVPs, as we’re reliant on the feedback users give us, is that we focus too much on one user. If we think that one user is going to represent many others, this may be fine. However, sometimes, especially if we’re only getting feedback from a small number of users, a talkative user can almost hijack our process. Again, this comes down to the founder knowing what they want to do and steering the ship in the right direction.

Making the product the developers want to make

Similarly, making the product the developers, or the development company, want to make is something else to be aware of. The development company wants to get paid, they also may want to showcase various aspects of what they do. If you’re not interested in the extras you have to say so, it’s possible another company would be a better fit.

Alternatively, are they building it in a way that only they can understand? That has its own problems if you do wish to expand the project.

Conclusion

Hopefully, if you’ve got down to here you’ve started to think about what an MVP is. You’ve seen than an MVP isn’t always the best first step. And, you’ve also hopefully seen that maybe an MVP isn’t for everyone.

If nothing else, like many of the things I write, I’d say being a startup in the early stages is all about trust. While it might seem like you just hand the project over to someone, and they build the idea you have in your head, there is plenty more work to be done by a potential founder. The most important being keeping the project on track. Even if there is a project manager, you still need to manage your new project yourself. Be clear from the outset what you want, stick to it, then everything else can wait for after it’s done. But also, make sure you ask for the right thing at the beginning.

Good luck!

All this can be difficult for a non-technical founder to navigate through. How do you know if what someone is telling you is true or false?

If you’d like to discuss ideas for a new project please contact me. Or, if a project has gone off the rails, I can help too.