MVPs (Minimum Viable Product) while working for start-ups are the smallest but most significant feature set, you can build and sell! Not just an experiment.
So what is the truth? Is an MVP a product, a subset of a product, or just an experiment?
The Minimum Viable Product was first found by Steve Blank and then made popular by Eric Ries in The Lean Startup. While researching for the term, what I found out is as below.
“The minimum viable product is that product which has just those features and no more that allows you to ship a product that early adopters see and, at least some of whom resonate with, pay you money for, and start to give you feedback on.” –Eric Ries, 2009
“Minimum feature set (“minimum viable product”) is a Customer Development tactic to reduce engineering waste and to get product in the hands of Earlyvangelists soonest.” – Steve Blank, 2010
“An MVP is not just a product with half of the features chopped out, or a way to get the product out the door a little earlier. In fact, the MVP doesn’t have to be a product at all. And it’s not something you build only once, and then consider the job done.” – Yevgeniy Brikman, Y Combinator, 2016
MVP is something that comes after you validate your startup ideas. All these products were searching for product-market fit. Practically speaking, the concept of experimenting and building a minimum feature set needs to be successful and there comes the goal of an Minimum Viable Product. It is to rapidly learn what your customers want. So when we start off building a new feature or product, there are a million questions to answer. “Is this solving the customer’s problem? Does this problem really exist? What does the user expect to gain with the end result?” We have to find the answers to these questions before committing ourselves to building a solution.
This is why starting with a minimum feature set is dangerous. When you jump into building a version one of a new product or feature you forget to learn. Experimenting helps you discover your customer’s problems and the appropriate solutions for them by answering these questions. It also doesn’t end with just one experiment. You should have multiple follow-ups that keep answering questions. The more you answer before committing yourself to the final solution, the less uncertainty there is around whether users will want or use it.
This process is will help your company find problem-solution fit. If you are creating a new feature or a new business line that solves a different problem for your user, this method can help ensure you’re building the right thing for your customer. But what if you have a mature product and are not starting from scratch?
Experimenting in Enterprises
Many enterprises today are introduced to the Minimum Viable Product by consultancies who propose creating an entirely new product from scratch. This is may not be the best idea. When your company already has product-market fit, you have already built a product that customers are using. You do not need to rebuild your product, you need to improve it. The methods should to be adapted for this case.
Something that sets these two methods apart is the goal. When searching for product-market fit, you want the user to adopt and probably pay for your product. This is not always the goal when improving existing products. It could be to improve retention or increase engagement with certain parts of your product. Whatever you decide your goal is, it should be clear to the team and informing all their decisions.
Once the goal is clear, you again focus on learning. What do you need to learn before committing to a solution. Write out these hypotheses on what you think will move the needle, and then design a Product Experiment to test it. You don’t have to create an entirely new product. Maybe you will find out a new product is necessary while experimenting, but that should not be the end goal.
The next step to solving this problem was to see if they could deliver value and learn at the same time. They created the hypothesis, “If we give users the information they are searching for in the sign-up flow, they will convert more.” They also wanted to learn which questions people would click on most to see which problem was the strongest. They planned a simple way to get people the information they needed while signing up: adding a few links into the sign-up flow, echoing the questions back to users. When the links were clicked, it showed a pop up explaining the answer to the question.
Learning is the Goal
Finally, it’s important to balance good design with fast design and good development with fast development. The best way to do this is getting UI designers and developers to pair together. After defining what the goal is for the iteration or experiment, sit down together and talk through ideas on how to execute. If we design in a slightly different way, is it just as useful to the user, but easier to build? Prototype together. Sketch together. Work side by side and talk about trade offs the whole time. This is how good teams move quickly and avoid rework.
This is why it’s so important for teams to experiment, whether they are B2B or B2C. Give the product teams access to users. A better way to create a Feedback Group with a subset of users. Build infrastructure so you can turn on experiments and features just for smaller group. These users will guide you to create features that will fit their needs.
Finally, learning what your users want before you build is a good product development. Make sure when you do invest in a feature or solution, it’s the right one. As Steve Blank, 2013 once stated, “A minimum viable product (MVP) is not always a smaller/cheaper version of your final product.”