I have had the experience of asking 5 people to explain what MVP is and heard 7 different answers. Minimum Viable Product has become an acronym that is used very differently from what is meant to be in the Lean Startup world. When MVP came to corporate world was translated to:

  • Something of low quality that brings no or very little feedback to the team/business
  • The “Phase One” of the project
  • The “In scope” requirement
  • The “what we have enough money for”
  • The “what we need in place by <DATE>”
  • The word to say to look agile
  • MMF
  • ….

All these require a “Pause and Align” type of conversation. Preferably with the sponsor present. Continuing without alignment is a clear indication that we will face challenges down the road.
Using the Lean Startup thinking, MVP’s purpose is to learn, to get feedback that will help us make one of these decisions:

  • Should we stop working on this direction and try another direction?
  • Should we stop this idea completely and go back to drawing board?
  • Should we continue with the initial idea without changes?
  • Should we continue with the initial idea but bring in some changes?

Having these conversations over and over with different teams, made me think that there’s got to be a better way for us to express the desire to learn from customer feedback.
So I started using the terms “Learning Release” and “Earning Release”. The idea behind, as you might guess, is that we agree to make some releases to learn some things we are not completely sure about and then, based on the feedback that we get and the things that we learn, we do an earning release which promises sales and subscribers.
Only by using “Learning Release” language, I was able to stop the long conversations around different understandings of MVP, comparing thousands of articles online to prove who is right and who is wrong, and just get to the important discussion/questions quicker.

  • What do we want to learn?
  • What is the smallest thing we can do to learn that?

It is not uncommon to have a lot of things we want to learn. If this is the case, then create a Backlog of questions. Yes, forget about roadmaps or backlogs with user stories. Not even Story mapping. If we have questions, it is too early for us to write stories. They would be pure guesses and most likely wrong. But a backlog of questions can help us focus. We can prioritize the questions and bring on top the ones that are more critical, more deep, the ones that “if we figure that out, the rest will fall in place”. Those are the questions that will give us the biggest lessons.
You can continue from here in the same way that you would go to decide what to do. Will you need to build something, survey people, napkin drawings with someone for a quick feedback, etc. If you decide to build something, try to make it as small as possible, as little efforts as possible, in the range of days.
At this point we have removed the emotions away from the results we will get. It is not anymore about hoping that what we build works and brings to us the benefits we wanted to get. At this point it is about being curious and wanting to know an answer from the real customers. It is not about someone being right and someone else being wrong. It is about a group of people learning together something they had questions about.

Product Managers need to be careful to not bombard customers with a lot of learning releases at the same time. That might overwhelm customers and they will complain for negative experience. Also, learning releases are short lived. We can’t keep them on for a long time or they will give to our customers a negative experience. Learning releases need to face the customer until we reach the threshold of the data we wanted to gather for our learning. For this Product managers need to set very clear learning challenges such as “ first 1000 customers”, “1% of clients from Asia”, “Customers from Toronto that are dog owners”, etc. If we do not put boundaries around our Learning releases, we would be running tests that will not give us focused lessons.
By creating the concept of “Learning Release” to help us answer questions and learn more about our clients and our product, we now can change the conversation with product managers and sponsors. Instead of creating a plan that gives the expectation of starting to collect the benefits right away, we lay out a plan that sets expectations for learning and earning. Initially the team will need to have 1 or more Learning Releases, depending how many questions we have, or how complex is the challenge given to the team.
Don’t be surprised if we learn quickly that we are on the right path. That makes the Earning release come forward. However, don’t be surprised to learn quickly that customers use or expect something different from our product. This is actually a big win because it saves the company a lot of effort and money that would have gone to building the wrong feature/solution only to learn late that was the wrong one. A Learning release can prevent exactly that.

How to recover if our Learning release teaches us something we didn’t expect from our customers?

Celebrate!
Celebrate that now you are a smarter team/organization and that you have new opportunities in your hands. Maybe you need to completely change direction. Maybe you need to just change some things here and there and continue. Whatever the case, you are not going by the seat of your pants but by data.

However, if we arrive at a place where we get positive feedback and we believe our solution will support the development of this functionality, then we need to go for the Earning Release.
Earning Release is when product manager has a tested and working functionality and is now ready to get Marketing, Sales, Account Managers, etc to go out and promote … loud and proud! At this point, we already have high confidence that we will do well since we already have had feedback on it.

Group chat
Original: https://www.industriallogic.com/blog/fast-frugal-learning-with-a-feature-fake/

When Industrial Logic was looking to add a Group Chat for their eLearning platform, within 3 hours they added on their website a message that pulled attention and looked like this:

When you clicked to join the group chat, you would see this:

Within 3 business days they collected this data

Was not compelling enough to make them go ahead and develop the Group Chat feature all the way. They learned that users were not very interested and developers could put their efforts into another idea.

Dropbox
Original: https://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/

Dropbox needed to test its leap- of- faith question: if we can provide a superior customer experience, will people give our product a try?
While developers were struggling with the technical challenges they had to overcome, the founder, Drew, made a video. The video is a fake product and was made of low quality. However it was a good test of the response people would have if this product was all done and polished.

The video drove a lot of beta testers from 5000 to 75000 and the feedback was so positive that it was worth it continuing with the Earning release. And they have earned a lot since then!

Customers buy products not project, so make good products. Change and be Lean. If nothing ever changed, there would be no butterflies