Your MVP is neither minimal, viable nor a product
![](data:image/svg+xml;charset=utf-8,<svg height="570" width="1012" xmlns="http://www.w3.org/2000/svg" version="1.1"/>)
Image Credits: Haje Kamps / Haje Kamps for TechCrunch (Image has been modified)
Whenever I talk about minimal viable products with product-driven startup founders, I often find myself in a frustrating conversation. The term MVP is such a profound misnomer; a good MVP is not viable, and it is certainly not a product. Chances are it isn’t as minimal as you want it to be either, come to think of it.
In the world of lean startups, founders have to stay hyper-focused on figuring out how to fail as fast as possible. Ideally, you fail to fail, which means you end up with a functioning business. A lot of the “trying to fail” approaches involve looking at your business opportunities and contemplating where your business might fail in the future. Then go and figure that part out.
It’s no good to build the world’s best platform for selling Beanie Babies if the entire customer base is already happy using eBay and wouldn’t switch away, even if your product is superior. It’s no good to create a great lock specifically for rideshare scooters if it turns out that the scooter companies don’t care if the scooters get stolen. It would be great if there was a way to figure out if anybody would buy your product before you write a single line of code.
So where do MVPs come in? As a startup, you have a hypothesis; an MVP is the smallest amount of work you can do to confirm or dispel your hypothesis. Eric Ries — yes, the guy who wrote “The Lean Startup” — famously uses Dropbox’s MVP as an example. It was not a fully fledged product, full of features. It was not a product with a lot of features stripped away. It was a video, showing how a product might work. The response to that video was the confirmation the company needed: If they build it, they’ll be able to find a customer base for its yet-to-be-built product. So that’s what they did: Built the product, and became a huge success.
![](data:image/svg+xml;charset=utf-8,<svg height="450" width="800" xmlns="http://www.w3.org/2000/svg" version="1.1"/>)
Designing a good MVP
Designing a good MVP means thinking outside of the box. How little code can you write? Can you get away with doing no design? If your biggest question is whether you can attract customers for a customer acquisition cost that makes sense, could you run just an advertising campaign and a check-out page, and then just refund whoever places an order? If that sounds like fun but you’re worried about brand risk, could you create a fake brand and get an answer to your product?
The trick is to think carefully about the hypothesis — what needs to be true about your product, the market, the problem space you are entering, the customers you are hoping to attract and the competitive landscape? How sure are you that your assumptions are correct? Designing a good MVP is an art, but it starts with a really good question. Here are a few examples:
- Is it possible for us to reduce four hours of manual accounting tasks to a script that can be run in three minutes? This is a technical MVP — you probably need to hack together some code to see if you can reliably automate manual tasks.
- Can we find someone who is willing to pay to automate this task? In some cases, the answer will be “no” — yes, you might save a junior accountant some time, but in some industries, people simply don’t care about how much time junior staffers spend on doing manual tasks. In this case, you need to determine whether you can find 20-30 customers who are willing to pay for it. Remember that someone saying “oh that sounds like a good idea” is different from them reaching into their pockets and actually paying you money.
- Does design matter for this product? A lot of B2B software is hideously ugly. It isn’t because good designers don’t exist, but because it simply isn’t a priority; the people who have to use the product might prefer a better design or an easier UX, but the decision-makers don’t care, and the users don’t get a say. In other words: Don’t spend half your development budget on making something easier to use, if you can’t find a business case for it. Especially if it turns out that you inadvertently end up developing the wrong featureset in the process.
- Will an incumbent copy us and destroy us? If you have a number of incumbents in your space, do some research and see how they have reacted to other startups. If they tend to acquire them, great. If they tend to copy their features and innovations and then crush them, less great. A little bit of Googling (and, of course, reading TechCrunch for your industry) can save you a lot of headaches in the future. If the incumbents are routinely stealing innovations, invest more in patents and set some money aside for lawyers.
- Does this feature make sense to our customers? It may be that you get a very loud minority of your customers asking for the same feature, but you wouldn’t be the first company to have launched a new feature to great fanfare only to be met by a collective shrug. Loud customers don’t speak for your whole customer base, so be judicious in how you groom your backlog — if a feature doesn’t add significant value to the overall business objectives of your company, don’t prioritize it over ones that do. One way to design an MVP around this is to just add a button to your UI and track how many people click on it. Throw up a “coming soon!” message when it is clicked, for example. Yes, it is annoying to the users, but it’s a lot “cheaper” than spending several development cycles adding a feature that almost nobody will use.
In a nutshell, the key is to think very carefully about what the question is, and then come up with elegant, low-lift ways of asking that question. Instead of shipping code, could a survey work? Could a video demo get you the answers you need? Can you call 50 customers and ask them circumspect questions and see if they suggest the feature you are thinking about as a potential solution to the problem? They might surprise you in two ways: Your customers may either overwhelmingly want what you’re suggesting (great!), they may hate it (also great — it means you don’t have to waste time and money developing something they don’t want) or they may have a completely different way of solving the problem that hits the sweet spot, is cheaper to develop and helps them feel involved with your process.
I don’t have a suggestion for a better name for MVP, just don’t fall into the trap of thinking of it as a product, being viable or, necessarily, being small, simple or easy. Some MVPs are complex. The idea, though, is to spend as little of your precious resources as you can to get an answer to your questions.
![](data:image/svg+xml;charset=utf-8,<svg height="104" width="187" xmlns="http://www.w3.org/2000/svg" version="1.1"/>)
![](data:image/svg+xml;charset=utf-8,<svg height="105" width="187" xmlns="http://www.w3.org/2000/svg" version="1.1"/>)
![](data:image/svg+xml;charset=utf-8,<svg height="125" width="187" xmlns="http://www.w3.org/2000/svg" version="1.1"/>)
![](data:image/svg+xml;charset=utf-8,<svg height="140" width="187" xmlns="http://www.w3.org/2000/svg" version="1.1"/>)
