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

  • The “Phase One” of the project

  • Something of low quality that brings no or very little feedback to the team/business

  • The “In scope” requirement

  • The “what we have enough money for”

  • The “what we need in place by <DATE>”

  • The word to use with stakeholders so we 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 in this direction and try another approach?

  • Should we stop this idea entirely and go back to the 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 to express the desire to learn from customer feedback.

So, I started using the terms “Learning Release” and “Earning Release.” As you might guess, the idea behind this is that we agree to declare some releases to be about learning some things we are not entirely sure about. Then, based on the feedback that we get and the things that we learn, we do an earning release that promises sales and subscribers.

Only by using “Learning Release” language was I 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-er, 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 Epics and User stories. Maybe not even the Story mapping, although this exercise often serves to identify what we don’t know. 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 more critical, deeper, the ones that “if we figure that out, the rest will fall in place.” Those are the questions that will give us the most important 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 quick feedback, etc. If you choose to build something, try to make it as small as possible, as small effort 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. It brings to us the benefits we wanted and expected to get. At this point, it is about being curious and wanting to know an answer from the actual customers. It is not about who is right or finger-pointing the Business. It is about a group of people learning together how to build the most amazing product for their customers.

Product Managers need to be careful not to bombard customers with a lot of learning releases simultaneously. That might overwhelm customers, and they will complain about the unfriendly experience. Also, learning releases are short-lived. We can’t keep them on for a long time, or they will give our customers a negative experience. Learning releases need to face the customer until we reach the data threshold we wanted to gather to learn how to proceed with a decision. 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 can now 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 one or more Learning Releases, depending on how many questions they have or how complex the challenge is given to the team. The team will need to know how to measure the results of each Learning Release and demonstrate the lesson we learned.

Don’t be surprised if we quickly learn that we are on the right path. That makes the Earning Release come forward. However, don’t be surprised to learn 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 it was the wrong one. A Learning release can prevent precisely that.

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

Celebrate!

Celebrate that you are now a smarter team/organization and that you have new opportunities in your hands. Maybe you need to completely change the 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 believe our solution will support the development of this functionality, then we need to go for the Earning Release.

Earning Release is when the 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.

Some Examples of Learning and Earning releases

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:

alt_text

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

alt_text

Within three business days, they collected this data:

alt_text

It 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 many beta testers from 5000 to 75000, and the feedback was so positive that it was worth continuing with the Earning Release. And they have earned a lot since then!