6 Lessons Learned Creating a SaaS MVP (Minimally Viable Product)

Over the past few years, we’ve become big proponents of developing new products by creating an MVP: a minimally viable product.

An MVP is the smallest set of functionality required to meet the needs of your targeted User.

The goal of an MVP is to rapidly validate your product hypotheses. Every great product should have an opinion, a way of seeing the world. That view may (and should) evolve, but at some fundamental level, your product is based on some view of how something should work.

As a company, founder, or product owner, your goal is to get real feedback as early (and often) as possible to validate and refine your hypotheses. While it sounds easy, it can be difficult, especially learning to say no to things in order to remain “minimal”.

At MindFire, we’re 16 months past our MVP milestone for one of our products. While we’re still learning and iterating by gaining feedback from 400+ users, here’s a bit of what we’ve learned about developing an MVP:

• The idea of an MVP may be hard for people accustomed to more traditional development methods to understand. You may find yourself working hard to remind your organization why everything isn’t perfect. The goal of an MVP is not perfection.

• Creating a successful MVP requires that your engineers understand the User’s domain, their struggles, and the job they’re trying to do. In the absence of this understanding, it is very difficult to communicate an idea (or User Story). Without domain experience, you may find your team asking for detailed instructions. If this happens, you probably need to spend more time introducing your engineers to real Users.

• The sooner your MVP is in the hands of real Users, the better off you are. Nothing counts until this happens. Customer feedback and usage is oxygen to your efforts.

• You’ll have to work hard to resist over-engineering things. Don’t try to get things perfect. It’s better to acknowledge that its hard to predict the future, and thus, to instead get working software into the hands of users ASAP. The goal is not perfection; rather, you seek feedback on the question: do you have a product that provides value to your Users?

• On the topic of feedback: be prepared for lots of it. If you’ve got a real MVP (one that although buggy, inherently works … at least most of the time), rest assured things will be missing. Users will ask for features, improvements, and sometimes flat-out tell you that something sucks. You may even hear “How on earth could you not have feature x?!?”  If you hear things like this, you’re on the right track. That’s oxygen!

• A part of the MVP philosophy is an understanding that there is no one specific release point. In traditional methods, everyone works from detailed specs for months (or years!) towards a huge goal — often, in the end, falling short (been there, done that). In the MVP philosophy, you still have goals and milestones, but what’s more important is a deep respect for valuing fast iteration based on user feedback, rather than working towards monumental releases. What happens if you’re wrong when you get there? Much better to find out sooner.

Developing an MVP certainly hasn’t been easy, so perhaps in another post, I’ll share some of the things I’d do differently with an MVP the next time around. But what I can tell you from first-hand experience is that the benefits far exceed the difficulties.

What do you think of the idea of an MVP? In what situations is it best? If you’ve developed an MVP, what lessons have you learned?