M Viable P

“If the company doesn’t yet have users, we try to figure out the minimum thing to build first to test the hypothesis—i.e., if we work backwards from the perfect experience, we try to figure out what kernel to start with.” [1]


“A minimum viable product (MVP) helps entrepreneurs start the process of learning as quickly as possible. It is not necessarily the smallest product imaginable, though; it is simply the fastest way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort.”

“Minimum viable products range in complexity from extremely simple smoke tests (little more than an advertisement) to actual early prototypes complete with problems and missing features. Deciding exactly how complex an MVP needs to be cannot be done formulaically. It requires judgment. Luckily, this judgment is not difficult to develop: most entrepreneurs and product development people dramatically overestimate how many features are needed in an MVP. When in doubt, simplify.” [2]


“[A common mistake is] too much “minimum” in MVP. Competing in existing markets means there’s a baseline. Build something simpler, and different, but you’ll want to focus on switching people.” [3]


“There’s a limit to the “launch fast and iterate”. If you frustrate your users and they hate the experience, then there’s nothing much to iterate. They’re gone.” [4]


How ‘minimum’ a first iteration must be depends on a number of factors:

Users have become less tolerant of defective/bad UX. The general standard we have as users is very high - which is a good thing.

It’s better to have something simple and to the point with a good basic experience, than something more ‘complete’ and a defective UX.

Look for validation, but with the user in mind.

Pay more attention to ‘viable’ in MVP.

Back to the blog.