In the startup world, Minimum Viable Product (MVP), is a term that is thrown around a lot. The problem is that most companies get their MVP wrong. They build too little or they build too much (more often too much). Customers don’t get product in their hands, feedback cycles are delayed, and valuable resources are wasted perfecting something that might not even sell. Below are some strategies I’ve developed over time for making sure you’re building an MVP that is both minimum and viable.

Focus on one problem

Companies try to solve too many customer problems in an MVP. The goal of your MVP is prove some initial value to the customer and hook them in so that you can continue the relationship down the line. To do this, focus on one customer problem first and avoid the urge to do more. Typically, the one customer problem you choose to solve should be what you’ve deduced to be the customer’s biggest problem. But, balance that with the level of effort required to solve. If the biggest problem takes three months to solve, and the second biggest problem takes one month, solve that second problem first.

At Faire, we knew that apparel retailers could not find good apparel on Faire. We also knew that apparel retailers could not easily evaluate the apparel products they did find. Discovery and evaluation were both substantial problems that directly impacted GMV. But, instead of solving both problems at once, we chose to solve the discovery problem first. Discovery sequentially happened before evaluation and we believed better discovery would have a larger impact on GMV. This prioritization let us focus our energy on increasing apparel inventory supply on the marketplace and using that supply to build out a better apparel discovery experience. Features like image zoom and fabric product details that could improve the apparel product evaluation process, were explicitly out of scope.

De-scope the interface

Do you need to build anything? Sometimes, doing something manually is just good enough. When I was testing out an idea to better connect factories and brands – instead of building out a website that actually connected factories and brands, I simply sent out a tweet offering to help brands find factories. This let me validate the market for the product without writing a single line of code.

Can you get away with just building out BE functionality? At Material Security, when we built out a new product that could sync security relevant file data from Google Workspace, the most paired down version of the product’s interface was to not build an interface and simply expose the ability to query the synced data via an API call. This type of strategy works especially well if you’re willing to initially handhold customers through using the product or if your customer base is technical.

If you do need a true UI / UX, keep it simple. Reuse existing components where you can and don’t spend time perfecting the pixels.

Know the baseline

Make sure you know what your target customer’s baseline is. This helps you understand how much work you need to do to be better than their baseline.

Material Security’s file security product was most often competing against a baseline where customers had no visibility into their file security posture. Because that was the baseline, we were able to make decisions like only scanning the most recent and easy to process subset of files for MVP, because that was still better and more useful than zero.

Sometimes, you’ll learn that your target customer’s baseline actually is quite advanced. Instead of building towards full feature parity, typically you can integrate with existing tooling and provide a better UI / UX for certain core flows. As an example, at Vial, we built out tooling for medical clinics to manage their clinical trials business. These clinics were often using other software that, while clunky, had many features built over decades. Instead of reaching complete feature parity before converting a single clinic, we chose to integrate with existing software and focus on making a select set of core flows a step function better. This let us launch and test the product significantly faster.