How to Define your Minimum Viable Product (MVP)

When you set out to build a product, whether it's a mobile app, website, or a physical product, you'll envision how people will use your product and what qualities they need of your product. What often happens when building products is there's a disconnect between what you think people need and what they actually need.

If you take the Lean Startup approach to designing and building your first product, the minimum viable product (MVP), you're more likely to build exactly what your users need, and eliminate waste from building features they don't need.

I've built several companies (including Detective), and when you're building a startup company, you have real constraints with how much money and time you have to build something. These constraints force you to be smart about what you spend time building; any wasted effort could put you out of business.

The classic model to create a product is called Waterfall, and it doesn't work. With Waterfall, you start by defining all requirements, then design the product, then build it then launch it. This sounds completely logical, but problems arise if requirements change at any point in the process. Requirements always change. When this happens, your project goes way over budget and you blow past the deadline.

With a lean approach to building a product, the idea is you take the steps in Waterfall and repeat them many times over. You divide up the problem into several product phases, where each phase fully delivers on a set of objectives.

The first phase is the minimum viable product (MVP), and fully achieves the most critical objectives of your project. People start using your product early on in the development cycle, while development is still happening. The beauty of this is you'll get fast & early feedback. People tell you what's working and what isn't, and you can respond by altering the product roadmap.

Think of it this way: if you set out to build a car to get people from here to there, you don't start by building a wheel. That doesn't get you to where you need to go. You could start by building a bike. From there you could build a scooter, then finally a car. At each phase of the project, people are able to use your product to achieve the main objective: transportation. They'll give you feedback along the way ("it's too slow!"), and you'll incorporate that feedback and iterate the product.

This process allows for changes in your product roadmap during active development. Changing requirements doesn't mean pushing back your delivery date - because the process accounts for change. After people use your MVP, you might decide to cut entire features, and improve other features that they actually use.

After the MVP, you'll continue iterating the product in mini releases - every week or so. The product takes shape, change by change, until you've achieved all of your objectives. The product is tested in realtime during active development, so at the end, you'll have confidence that you hit the mark.

At Foxbox Digital, we take a lean approach to building mobile apps. We tap into our entrepreneurial experience of building startup companies, and apply that experience to how we build products. We'll help you define your product vision, design an incredible interface, then build your product with a lean, agile approach.

At the end, you'll have a product that meets your objectives, has the features you need, and eliminates the features you don't actually need. This is how you build a product that hits the mark and deliver it on time.